Kubernetes v1.36: 포드 수준 리소스 관리자 (알파) | WIPI의 프로그래밍 및 기술 블로그

Kubernetes v1.36은 성능에 민감한 워크로드에 더 유연하고 강력한 리소스 관리 모델을 제공하는 포드 수준 리소스 관리자(Pod-Level Resource Managers)를 알파 기능으로 도입했습니다. 이 향상된 기능은 kubelet의 토폴로지(Topology), CPU 및 메모리 관리자를 확장하여 포드 수준의 리소스 사양(.spec.resources)을 지원함으로써, 기존의 엄격한 컨테이너별 할당 모델에서 포드 중심 모델로 진화시켰습니다.

왜 포드 수준 리소스 관리자가 필요한가요?

머신러닝(ML) 학습, 고빈도 매매(HFT) 애플리케이션 또는 저지연 데이터베이스와 같이 성능이 중요한 워크로드를 실행할 때는 예측 가능한 성능을 보장하기 위해 기본 애플리케이션 컨테이너에 대해 NUMA 정렬된 전용 리소스가 필요한 경우가 많습니다.

하지만 현대의 Kubernetes 포드는 단일 컨테이너로만 구성되는 경우가 드뭅니다. 로깅, 모니터링, 서비스 메시 또는 데이터 수집을 위한 사이드카 컨테이너가 포함되는 경우가 빈번합니다.

이 기능이 도입되기 전에는 메인 애플리케이션에 NUMA 정렬된 전용 리소스를 할당하려면 포드의 모든 컨테이너에 정수 기반의 전용 CPU 리소스를 할당해야 하는 트레이드오프가 있었습니다. 이는 가벼운 사이드카 컨테이너에는 리소스 낭비가 될 수 있었습니다. 만약 그렇게 하지 않는다면 포드의 보장형(Guaranteed) 서비스 품질(QoS) 클래스를 포기해야 했고, 결과적으로 성능상의 이점을 잃게 되었습니다.

포드 수준 리소스 관리자 소개

리소스 관리자에 대한 포드 수준 리소스 지원을 활성화하면(PodLevelResourceManagers 및 PodLevelResources 기능 게이트를 통해) kubelet이 하이브리드 리소스 할당 모델을 생성할 수 있습니다. 이를 통해 NUMA 정렬을 유지하면서도 고성능 워크로드에 유연성과 효율성을 제공할 수 있습니다.

실제 사용 사례

구성된 토폴로지 관리자(Topology Manager)의 범위(Scope)에 따라 이 기능이 어떻게 적용될 수 있는지 보여주는 몇 가지 실제 시나리오는 다음과 같습니다.

1. 긴밀하게 결합된 데이터베이스 (토폴로지 관리자의 pod 범위)

메인 데이터베이스 컨테이너, 로컬 메트릭 내보내기(exporter), 백업 에이전트 사이드카를 포함하는 지연 시간에 민감한 데이터베이스 포드를 가정해 보겠습니다.

토폴로지 관리자의 범위가 pod으로 설정되면, kubelet은 전체 포드의 예산을 기반으로 단일 NUMA 정렬을 수행합니다. 데이터베이스 컨테이너는 해당 NUMA 노드에서 전용 CPU 및 메모리 슬라이스를 할당받습니다. 포드 예산에서 남은 리소스는 새로운 **포드 공유 풀(pod shared pool)**을 형성합니다. 메트릭 내보내기와 백업 에이전트는 이 포드 공유 풀에서 실행됩니다. 이들은 서로 리소스를 공유하지만, 데이터베이스의 전용 슬라이스 및 노드의 나머지 리소스와는 엄격하게 격리됩니다.

이를 통해 보조 컨테이너에 전용 코어를 낭비하지 않고도 기본 워크로드와 동일한 NUMA 노드에 안전하게 배치할 수 있습니다.

apiVersion: v1
kind: Pod
metadata:
  name: tightly-coupled-database
spec:
  # 포드 수준 리소스는 전체 예산과 NUMA 정렬 크기를 설정합니다.
  resources:
    requests:
      cpu: "8"
      memory: "16Gi"
    limits:
      cpu: "8"
      memory: "16Gi"
  initContainers:
  - name: metrics-exporter
    image: metrics-exporter:v1
    restartPolicy: Always
  - name: backup-agent
    image: backup-agent:v1
    restartPolicy: Always
  containers:
  - name: database
    image: database:v1
    # 이 보장형(Guaranteed) 컨테이너는 포드 예산에서 전용 6 CPU 슬라이스를 할당받습니다.
    # 남은 2 CPU와 4Gi 메모리는 사이드카를 위한 포드 공유 풀을 형성합니다.
    resources:
      requests:
        cpu: "6"
        memory: "12Gi"
      limits:
        cpu: "6"
        memory: "12Gi"

2. 인프라 사이드카가 포함된 ML 워크로드 (토폴로지 관리자의 container 범위)

일반적인 서비스 메시 사이드카와 함께 GPU 가속 ML 학습 워크로드를 실행하는 포드를 상상해 보세요.

container 토폴로지 관리자 범위에서 kubelet은 각 컨테이너를 개별적으로 평가합니다. ML 컨테이너에는 최대 성능을 위해 NUMA 정렬된 전용 CPU 및 메모리를 부여할 수 있습니다. 반면, 서비스 메시 사이드카는 NUMA 정렬이 필요하지 않으므로 일반적인 노드 전체 공유 풀에서 실행될 수 있습니다. 전체 리소스 소비는 여전히 전체 포드 제한에 의해 안전하게 묶여 있지만, 실제로 필요한 특정 컨테이너에만 NUMA 정렬된 전용 리소스를 할당하게 됩니다.

apiVersion: v1
kind: Pod
metadata:
  name: ml-workload
spec:
  # 포드 수준 리소스는 전체 예산 제약을 설정합니다.
  resources:
    requests:
      cpu: "4"
      memory: "8Gi"
    limits:
      cpu: "4"
      memory: "8Gi"
  initContainers:
  - name: service-mesh-sidecar
    image: service-mesh:v1
    restartPolicy: Always
  containers:
  - name: ml-training
    image: ml-training:v1
    # 'container' 범위에서 이 보장형(Guaranteed) 컨테이너는 전용 NUMA 정렬 리소스를 받으며,
    # 사이드카는 노드의 공유 풀에서 실행됩니다.
    resources:
      requests:
        cpu: "3"
        memory: "6Gi"
      limits:
        cpu: "3"
        memory: "6Gi"

CPU 쿼터 (CFS) 및 격리

포드 내에서 이러한 혼합 워크로드를 실행할 때, 격리는 할당 방식에 따라 다르게 적용됩니다.

전용(Exclusive) 컨테이너: 전용 CPU 슬라이스를 부여받은 컨테이너는 컨테이너 수준에서 CPU CFS 쿼터 강제가 비활성화되어 Linux 스케줄러에 의해 스로틀링(throttling)되지 않고 실행될 수 있습니다.
포드 공유 풀 컨테이너: 포드 공유 풀에 속한 컨테이너는 포드 수준에서 CPU CFS 쿼터가 강제되어, 남은 포드 예산 이상을 소비하지 않도록 보장합니다.

포드 수준 리소스 관리자 활성화 방법

이 기능을 사용하려면 Kubernetes v1.36 이상이 필요합니다. 기능을 활성화하려면 적절한 기능 게이트와 정책으로 kubelet을 구성해야 합니다.

PodLevelResources 및 PodLevelResourceManagers 기능 게이트(feature gates)를 활성화합니다.
토폴로지 관리자(Topology Manager)를 none 이외의 정책(예: best-effort, restricted, single-numa-node)으로 구성합니다.
KubeletConfiguration의 topologyManagerScope 필드를 사용하여 토폴로지 관리자 범위를 pod 또는 container로 설정합니다.
CPU 관리자(CPU Manager)를 static 정책으로 구성합니다.
메모리 관리자(Memory Manager)를 Static 정책으로 구성합니다.

관측성 (Observability)

클러스터 관리자가 이러한 새로운 할당 모델을 모니터링하고 디버깅할 수 있도록, 기능 게이트가 활성화되었을 때 몇 가지 새로운 kubelet 메트릭을 도입했습니다.

resource_manager_allocations_total: 관리자가 수행한 전용 리소스 할당의 총 횟수를 계산합니다. source 레이블("pod" 또는 "node")은 노드 수준 풀에서 할당된 것인지, 사전 할당된 포드 수준 풀에서 할당된 것인지 구분합니다.
resource_manager_allocation_errors_total: 의도한 할당 source("pod" 또는 "node")별로 전용 리소스 할당 중 발생한 오류 횟수를 계산합니다.
resource_manager_container_assignments: 특정 할당 유형으로 실행 중인 컨테이너의 누적 수를 추적합니다. assignment_type 레이블("node_exclusive", "pod_exclusive", "pod_shared")은 워크로드가 어떻게 분산되어 있는지에 대한 가시성을 제공합니다.

현재 한계 및 주의 사항

이 기능은 새로운 가능성을 열어주지만, 알파 단계이므로 몇 가지 유의해야 할 사항이 있습니다. 호환성, 요구 사항 및 다운그레이드 지침에 대한 자세한 내용은 공식 문서의 한계 및 주의 사항(Limitations and caveats) 섹션을 반드시 확인하시기 바랍니다.

시작하기 및 피드백 제공

이 기능의 기술적 세부 사항 및 구성에 대해 더 자세히 알아보려면 공식 개념 문서를 확인하세요.

포드 수준 리소스 관리자 (Pod-level resource managers)

전반적인 포드 수준 리소스 기능과 포드에 리소스를 할당하는 방법에 대해 알아보려면 다음을 참조하세요.

포드 수준 CPU 및 메모리 리소스 할당 (Assign Pod-level CPU and memory resources)

이 기능이 알파 단계를 거쳐 발전함에 따라 여러분의 피드백은 매우 소중합니다. 표준 Kubernetes 통신 채널을 통해 문제점을 보고하거나 경험을 공유해 주세요.