에디.이이

클라우드 네이티브 형태의 애플리케이션이 늘어나면서, 결국은 수명주기가 짧고 많아진 애플리케이션들을 어떻게 관리할 것인가가 또 하나의 화두가 되었습니다. 베어메탈 서버에서 가상머신으로, 다시 컨테이너 그리고 K8s 로 흘러가면서 모든 관리는 자동화로 진화하고 있습니다. 개발자는 애플리케이션은 상태만을 선언하고, K8s에서 그 상태를 유지시켜주기 위해 알아서 관리하는 형태도 자동화의 한 형태라고 할 수 있습니다. EKS에서의 자동화는 API를 연동하거나 스크립트를 통해 구현할 수도 있지만, 단지 K8s에 대한 관리뿐만 아니라 추가적인 생태계에 대한 관리까지 자동화의 범위에 포함시키기 위해 다양한 솔루션들이 함께 사용되고 있습니다. 1. AWS Controller for Kubernetes(ACK) K8s를 ..

1단계. RBAC 관련 krew 플러그인 - access-matrix : 서비스 리소스별 RBAC access 정보 확인 - rbac-tool : rbac 관련 lookup, whoami policy-rules 등 여러가지 확인 기능 제공 - rbac-view : 웹을 통해 Cluster Roles와 Roles를 확인 - rolesum : 사용자, Service Account별 RBAC 역할에 대해 간략하게 요약 정리 ※ 2/3단계 참고 2단계 : 인증 과정 따라가기 - kubectl 관련 임시자격 토큰 요청 확인 : ~./kube/config 파일 내에 user 부분에서 요청 확인 : eks get-token --output json --cluster-name myeks --region ap-north..

모든 보안의 기본은 올바른 인증과 권한(인가)을 어떻게 제어하느냐로부터 시작합니다. K8s도 예외는 아니며, 특히 EKS에서는 다양한 native AWS 서비스를 활용하여 인증과 인가를 처리합니다. - 인증(Authentication) : 접근한 사용자 또는 서비스가 정상적인 사용자인지를 확인 - 인가(Authorization) : 해당 사용자가 어떠한 권한을 가지고 있는지, 어떤 역할을 담당하는지 정의 EKS는 인증/인가와 관련하여 AWS IAM 서비스에 대한 의존도가 높습니다. AWS IAM에서 제공하는 자격증명과 정책 설정 등을 통해 EKS 자체의 운영환경뿐만 아니라 EKS와 연계되어 운영될 수 있는 다양한 AWS 서비스에 대한 권한관리를 수행합니다. 결과적으로 EKS에서는 기본적인 k8s의 인증 ..

1단계. HPA 구성 1) CPU 50% 초과시 pod를 1개에서 10개까지 HPA를 이용하여 Scaling이 조절되도록 설정 2) 반복 연산을 통한 CPU 부하를 통해 사용량 증가시 pod 수량 증가 확인 2단계. KEDA 구성 1) 설치 후 기본 구성 확인 2) Cron을 통해 ScaleObject 정책을 설정하고 모니터링 - 현재 Active가 False인 이유는 KEDA 정책에 시간대별로 정책 적용 시간이 다르기 때문 - MINPODS 1개에서 MAZPODS 2개까지 설정 - 시간이 지난후 신규 php-apache 가 자동으로 추가됨을 확인 3단계. VPA 구성 1) VPA 구성확인 2) 초기 pod 상태 : 2개 pod가 100m CPU와 50Mi 메모리를 보유 3) 신규 pod가 추가되며 기존..

K8s를 사용하다보면, 사용량 증가에 따라 애플리케이션의 성능을 높히기 위해 Pod의 성능이나 수량을 증가시켜야 할 때가 있습니다. 또는 반대로 비용절감 등의 이유로 리소스를 회수하기 위해 Pod의 성능이나 수량을 축소시켜야 할 때도 있습니다. Pod의 경우 Node의 성능 내에서는 자유롭게 변경이 가능하겠지만, 어느 순간 Node의 자원이 부족해지는 상황도 발생할 수 있으며, 이러한 경우에는 Node 수나 성능을 증가해야 합니다. 이부분에 있어 만약 베어메탈 기반의 K8s를 사용중이라면 Node의 수나 성능 향상에 있어서는 자유롭지 못할 수 있습니다. 그러나 EKS를 비롯한 클라우드 또는 가상화 기반의 K8s에서는 해당 기능을 사용할 수 있습니다. EKS에서는 Pod의 수량을 조정하는 Horizonta..