Kubernetes v1.37에서 사이드카의 전용 코어 낭비 줄이기

파드 단위 리소스 선언과 리소스 매니저를 사용해 주 컨테이너와 사이드카의 CPU 할당을 설계하고 확인하는 방법을 설명한다.

2026-09-25

사이드카에 전용 코어를 배정하던 이유

지연 시간에 민감한 주 컨테이너에 배타적인 NUMA 정렬 CPU 코어를 주려면, 이전에는 같은 파드의 로깅·텔레메트리 사이드카에도 정수 리소스 요청을 지정해야 했다. 사이드카가 전용 물리 코어를 쓸 만큼 무겁지 않아도 파드 전체가 그 선택을 따라야 했다.

Kubernetes v1.37에서 베타로 승격된 PodLevelResourceManagers는 이 배치를 달리할 수 있게 한다. Kubelet의 Topology Manager, CPU Manager, Memory Manager가 파드의 .spec.resources를 직접 읽는다. 주 컨테이너에는 배타적 NUMA 정렬 리소스를 할당하고, Guaranteed가 아닌 사이드카는 파드 격리 공유 풀에 둘 수 있다. 사이드카는 전용 물리 코어를 소비하지 않으면서 NUMA 지역성과 노드의 다른 워크로드로부터의 격리 혜택을 얻는다. 이 기능은 베타지만 기본 비활성화 상태다. Pod-Level Resource Managers 베타 발표

⤢✕파드의 spec.resourcesKubelet 리소스 매니저주 컨테이너: 배타적 NUMA정렬 리소스비 Guaranteed 사이드카:파드 격리 공유 풀

적용 전에 피처 게이트를 구분한다

파드에 CPU·메모리 요청과 제한을 선언하는 기능은 PodLevelResources가 담당한다. 공식 태스크 문서는 이를 사용하려면 컨트롤 플레인과 모든 노드에서 해당 피처 게이트를 활성화해야 한다고 안내한다. 서버 버전은 1.34 이상이어야 하며 kubectl version으로 확인할 수 있다. 파드 레벨 CPU·메모리 설정 문서

NUMA 정렬을 포함한 리소스 매니저의 파드 단위 배치 판단에는 별도의 PodLevelResourceManagers 피처 게이트가 필요하다. 이 게이트를 활성화하지 않으면 Topology Manager, Memory Manager, CPU Manager는 파드 레벨 리소스를 기준으로 파드와 컨테이너를 정렬하지 않는다. 따라서 .spec.resources가 적용됐다는 사실만으로 원하는 하드웨어 배치까지 이뤄졌다고 판단하면 안 된다.

⤢✕ 파드 레벨 리소스의 두 피처 게이트 PodLevelResources vs PodLevelResourceManagers PodLevelResources 기능 파드에 CPU·메모리 요청과 제한을 선언 활성화 조건 컨트롤 플레인과 모든 노드에서 피처 게이트 활성화 필요 버전 서버 버전 1.34 이상 VS PodLevelResourceManagers 기능 Topology Manager CPU Manager Memory Manager 파드 레벨 리소스를 기준으로 NUMA 정렬을 포함한 배치를 판단 버전·상태 v1.37 베타 기본 비활성화 PodLevelResourceManagers를 켜지 않으면 .spec.resources가 적용돼도 리소스 매니저는 파드 레벨 리소스를 기준으로 정렬하지 않는다 Kubernetes v1.37에서 사이드카의 전용 코어 낭비 줄이기 | infra-system

지원 범위도 먼저 확인한다. Kubernetes 1.37에서 파드 레벨로 지정할 수 있는 리소스는 CPU, 메모리, hugepages이며 Windows 파드는 지원하지 않는다. 파드 레벨 리소스의 제자리 크기 변경에는 별도의 InPlacePodLevelResourcesVerticalScaling 피처 게이트가 필요하고, 이 기능은 1.37에서 알파다. 파드 레벨 리소스의 제한 사항

파드 선언부터 확인한다

기존 매니페스트에서 컨테이너마다 요청을 반복하던 부분을 검토하고, 파드 전체의 CPU·메모리 예산을 spec.resources에 선언한다. 공식 태스크 문서의 메모리 예제는 다음 구조를 사용한다.

spec:
  resources:
    requests:
      memory: "100Mi"
    limits:
      memory: "200Mi"
  containers:
    - name: memory-demo-ctr
      image: nginx
      command: ["stress"]
      args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]

실제 워크로드에서는 주 컨테이너와 사이드카의 역할에 맞춰 각 컨테이너 선언도 함께 검토한다. 파드 레벨과 컨테이너 레벨에 리소스를 모두 지정하면 파드 레벨 요청과 제한이 우선하며, 파드의 QoS 클래스 판단에도 파드 레벨 리소스가 우선한다. 컨테이너별 값을 그대로 둔 채 파드 선언만 추가할 때는 이 우선순위를 고려해야 한다. 파드 레벨 CPU·메모리 설정 문서

배포 후에는 kubectl get pod <파드 이름> --output=yaml로 파드의 리소스 선언을 확인한다. 이는 설정이 반영됐는지 보는 단계다. 배타적 CPU·메모리가 실제로 어떻게 할당됐는지는 별도로 확인해야 한다.

배타 할당은 파드 단위로 계상한다

모니터링 도구가 컨테이너별 할당만 합산하면 새 할당 방식을 잘못 읽을 수 있다. Kubernetes v1.37의 v1 PodResources gRPC 서비스(PodResourcesLister)는 PodResources 응답의 최상위에 cpu_ids와 memory 필드를 제공한다. 파드 레벨 배타 할당을 조회할 때 이 필드를 읽고, 컨테이너 할당과 이중 계상하지 않도록 수집 로직을 점검한다. PodResources API 변경 설명

⤢✕PodResourcesListerPodResources 응답최상위 cpu_ids·memory컨테이너 할당모니터링 도구이중 계상 방지

이 기능은 Kubernetes v1.37 릴리스 개요에 포함된 베타 승격 기능이다. 도입 판단에서는 릴리스에 포함됐다는 사실보다, 피처 게이트 활성화 여부와 실제 파드 단위 할당 결과를 확인하는 일이 먼저다.

KubernetesNUMACPU사이드카리소스관리