에디.이이

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..

기본적으로 VMware Cloud on AWS의 vSAN 환경에서는 TRIM/UNMAP 기능이 disable 되어 있습니다. 즉 OS에 할당되어 사용되었던 스토리지 공간이 OS상에서는 더이상 사용하지 않더라도, vSAN 상에서는 데이터가 사용중으로 표기되어 필요 없는 공간의 낭비가 발생할 수 있습니다. 이러한 낭비를 막기 위해서는 SDDC 배포 후 Service Request를 통해 TRIM/UNMAP의 활성화가 필요합니다. 적용이 되고 나면, Guest OS에 적용을 위해서는 OS의 재부팅이 반드시 필요하며, 즉시는 아니더라도, OS의 재부팅이 발생한 이후에 정상적인 적용이 가능하기 때문에 빠른 재부팅을 권장합니다. 물론 OS에서 자동으로 작업이 진행되는 경우도 있으나, 별도의 Command를 통해 T..

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