에디.이이

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

1단계. Pod의 Ephemeral Volume을 사용하여 Pod를 삭제 후 재배포시 데이터의 연속성이 없음을 확인 1) 10초에 1번씩 시간을 찍는 Pod를 배포하여 해당 Pod 내 데이터를 확인 2) 배포된 Pod를 삭제하고, 재배포 후 해당 Pod 내 데이터를 확인 - 과거의 Data 없이 새로운 데이터만 확인 2단계. Host Path를 사용하는 PV/PVC 배포하여 Node 내 데이터가 유지됨을 확인 1) localpath 스토리지 클래스를 생성 - local path provisioner도 새로운 pod로 배포 2) PVC를 생성하고 생성된 PVC 정보를 확인 - PVC는 생성되었으나, Status가 Pending : 아직 사용되고 있는 pod가 없어 PVC만 생성된 상태 3) PVC를 사용하..

k8s에서 기본적으로 제공하는 워크로드 타입은 Stateless한 애플리케이션입니다. 즉, 컨테이너는 상태가 없는 애플리케이션이며, pod가 삭제되면 더이상 pod에 저장된 데이터는 확인할 수 없습니다. pod 내 컨테이너에서 사용되는 스토리지는 Ephemeral(임시) Storage로 pod가 사라지면 함께 사라지기 때문입니다. 만약 하나의 pod 내의 다수의 컨테이너가 pod내에 생성된 Ephemeral Volume을 이용하는 경우에도 마찬가지입니다. 결국 pod가 사라지면 함께 사라지며, pod의 lifecycle에 따라 컨테이너에서 사용하는 데이터 lifecycle도 정해지게 됩니다. 그러나 DB를 사용하거나, 문제 발생시 Log 분석등을 위해 데이터를 지속적으로 유지해야 하는 경우가 있습니다. ..