피드로 돌아가기
Kubernetes BlogKubernetes Blog
DevOps

Kubernetes v1.34에서 Pod 수준 리소스 선언을 Beta로 정식 도입해 Pod 내 컨테이너들이 리소스를 동적으로 공유 가능하도록 변경

Kubernetes v1.34: Pod Level Resources Graduated to Beta

2025년 9월 22일9intermediate

Context

Kubernetes는 기존에 리소스 요청과 제한을 개별 컨테이너 단위로만 지정할 수 있었으므로, 다중 컨테이너 Pod에서 사이드카(logging agent, service mesh proxy 등)가 자신의 CPU 제한에 도달하면 전체 Pod의 성능 저하를 초래했다. 멀티 컨테이너 Pod에서 각 컨테이너의 리소스를 정확하게 산정하고 관리하기 위해 반복적인 계산과 선언이 필요했다.

Technical Solution

  • Pod 수준 리소스 선언: Pod spec의 resources 필드에서 CPU, memory, hugepages를 Pod 전체에 대해 직접 지정
  • Pod 수준 요청과 제한 우선순위 설정: 동일하게 지정된 컨테이너 수준 리소스보다 Pod 수준 리소스가 우선되어 전체 Pod의 리소스 경계를 강제
  • 스케줄러 통합: Pod 수준 request가 명시되면 스케줄러가 개별 컨테이너 request의 합계 대신 Pod 수준 request 값을 사용해 노드 선택
  • 런타임 리소스 공유: Pod 수준 limit이 모든 컨테이너의 결합된 리소스 사용의 절대 상한으로 작동하므로, 한 컨테이너의 미사용 리소스를 다른 컨테이너가 활용 가능
  • QoS 클래스 및 OOM 점수 계산 영향: Pod 수준 리소스가 QoS 클래스 판정과 Linux의 Out-Of-Memory 점수 조정 계산에 우선 적용

Key Takeaway

Pod 수준 리소스 관리는 멀티 컨테이너 환경에서 전체 Pod에 대한 리소스 경계를 단순화하면서도 컨테이너 간 동적 리소스 공유를 가능하게 해, 사이드카가 기존에 야기하던 성능 병목을 제거한다. Kubernetes 스케줄링과 런타임 정책이 Pod 수준과 컨테이너 수준 리소스를 모두 인식하는 설계로, 상위 수준의 제약이 하위 수준을 투명하게 제어하는 계층적 리소스 관리 패턴을 제시한다.


Kubernetes v

1.34 이상을 운영하는 팀이 사이드카(logging agent, monitoring proxy 등)를 포함한 다중 컨테이너 Pod을 배포할 때 Pod 수준에서만 CPU와 메모리 request/limit을 선언하면, 개별 컨테이너별 리소스 산정 오버헤드를 제거하면서도 Pod 내 컨테이너들이 미사용 리소스를 자동으로 공유해 트래픽 스파이크 상황에서 특정 사이드카의 throttling으로 인한 전체 Pod 성능 저하를 방지할 수 있다.

원문 읽기