에디.이이

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

1단계. EKS 컨트롤플레인의 로깅을 활성화 1) 콘솔에서 로깅 관리를 통해 컨트롤플레인 로그에 대한 활성화 2) 클러스터 구성 업데이트 진행 중 안내 화면 보이면서 EKS 구성 변경 발생(3~5분 소요) 3) Cloudwatch에서 로그>로그 그룹 아래에 eks 이름으로 신규 로그 그룹 생성 확인 2단계. AWS 콘솔을 통한 로그 확인 1) 하위 로그 스트림에서 현재 로그 확인 2) 모든 로그 스트림 검색을 통해 시간대별 세부 로그 확인 3단계. AWS 콘솔을 통한 로그 쿼리 조회 1) Cloudwatch 내 로그>Logs Insights 로 이동하여 로그 그룹선택 2) kube-scheduler 관련 로그를 시간의 역순로 정렬하여 보여주도록 조회 3) 동일 로그 AWS CLI를 통해서 조회 및 확인 ..

1. 목표구성도 - EKS 클러스터 : Control Plane - VPC 1개 : 퍼블릭 서브넷 3개, 프라이빗 서브넷 3개 - 관리형 노드 그룹 : EC2 3대 - Add-on : 최신 버전 kube-proxy, coredns, aws vpc cni 2. 배포 방법 : CloudFormation을 통해 실습 환경 배포 - CloudNet@ 제공 YAML 파일을 이용하여 CloudFormation으로 배포 1단계 : node IP와 pod의 IP가 같은 대역임을 확인 - pod의 IP와 pod 내 위치한 kube-system용 pod(aws-node, kube-proxy)가 pod와 동일한 IP를 보유 - coredns pod는 랜덤하게 2개의 node에 배포되어 있음 1) 192.168.3.234 :..

Kubernetes(=K8s)는 컨테이너화된 애플리케이션의 배포, 확장 관리를 자동화하기 위한 오픈 소스 시스템으로, 클라우드 네이티브의 핵심으로 급부상하여 현재는 컨테이너 관리의 디팩토(defacto) 스탠다드로 자리잡았습니다. 실제로 많은 곳에서 On-premise와 클라우드를 가리지 않고, 다양한 형태의 K8s 기반의 클러스터를 운영하고 있습니다. 그러나, 가용성, 다중화, 성능, 최적화, 확장, 업그레이드, 기술지원, 패치, 네트워크와의 연동 등에 있어 전문적인 기술/운영 인력이 없을 경우 K8s를 활용하는데 많은 어려움을 겪고 있는 것이 현실입니다. AWS에서는 이러한 어려움을 해소하기 위해, Amazon EKS(Elastic Kubernetes Services, 이하 EKS), 보통 EKS라 ..