에디.이이

모든 보안의 기본은 올바른 인증과 권한(인가)을 어떻게 제어하느냐로부터 시작합니다. 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..

대부분의 IT 업무에서는 현재 상태를 점검하거나, 발생한 문제를 해결하기 위해 수많은 과거/현재 데이터를 확인합니다. 특히 시스템을 운영하다보면 평상시 모니터링이라 불리는 업무를 상시적으로 진행하게 됩니다. 이는 전반적인 시스템의 상태를 점검하고,문제 발생시 해당 문제를 해결하기 위한 여러가지 값들을 점검하는 업무입니다. 어떻게보면, 그동안의 경험을 바탕으로 현재 상태의 메트릭과 지나온 로그를 분석하여, 문제의 지점이나 원인을 빠르게 찾아내는 것이 IT 운영자의 숙명이자 필수적인 요구 능력이라고 볼 수 있습니다. - 메트릭(metrics) : CPU 사용량, 메모리 사용량, 네트워크 트래픽과 같은 시스템 성능과 관련된 정량적 정보 - 로그(log) : 사용자 작업 및 오류를 포함하는 시스템 활동에 대한 ..

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를 통해서 조회 및 확인 ..