Kubernetes resources
Kubernetes 팀들이 resources 필드를 추측으로 채워 OOMKilled, Pending, Evicted 등의 운영 장애를 야기하는 상황을 측정 기반 정의로 해결
AI 요약
Context
대다수의 Kubernetes 팀이 resources 필드를 다른 Deployment에서 복사하거나 임의의 값으로 채우고 있다. Kubernetes가 이 값을 기반으로 Pod 스케줄링 위치, 메모리/CPU 소비량, 노드 리소스 압박 상황의 동작을 결정하기 때문에 잘못된 정의는 Pending 상태, OOMKilled 재시작, CPU throttling, 스토리지 부족으로 인한 Evicted 등의 운영 장애로 직결된다.
Technical Solution
- requests 및 limits 값의 역할 구분: requests는 스케줄러의 Pod 배치 결정용 최소 필요량을 정의하고, limits는 런타임 컨테이너의 최대 소비량을 제어하는 별개의 설정
- 실제 애플리케이션 소비 패턴 측정: 초기 기동 시, 정상 부하, 피크 트래픽 상황에서의 CPU/메모리 실제 사용량을 관찰하여 데이터 수집
- requests 값을 정상 사용량에 맞춰 설정: Kubernetes 스케줄러가 과도한 Pod을 배치하지 않도록 예약량을 현실에 맞춰 조정
- limits 값을 피크 대비 여유를 두고 설정: 트래픽 급증 시 컨테이너 강제 종료를 방지하되, 거짓된 클러스터 용량 정보 제공을 피함
- ephemeral-storage 리소스 정의 추가: Jenkins 파이프라인, Kaniko 빌드, 배치 작업, 임시 파일 생성 워크로드에서 /tmp 디스크 사용량을 제한하여 Evicted 발생 방지
Impact
아티클은 정량적 성능 개선 수치를 제시하지 않으며, 올바른 resources 정의의 효과를 안정성과 예측 가능성 향상으로만 서술한다.
Key Takeaway
Kubernetes에서 resources는 YAML의 장식적 블록이 아니라 애플리케이션의 클러스터 내 생존 방식을 결정하는 핵심 정책이며, 측정 기반의 requests/limits 정의는 애플리케이션 오류처럼 보이는 운영 장애들을 근본적으로 예방할 수 있다.
실천 포인트
Kubernetes 환경에서 운영 중인 서비스에서 Pod Pending, OOMKilled 재시작, 또는 Evicted 현상이 발생할 때, 애플리케이션 코드 검토 전에 먼저 해당 Deployment의 resources.requests와 limits 값이 실제 메모리/CPU 사용 패턴과 일치하는지 확인하고, 필요시 프로메테우스나 쿠버네티스 메트릭 수집 도구로 진정한 소비량을 측정한 뒤 재정의하면 대부분의 초기 운영 불안정성을 해결할 수 있다.