WIPI

프로그래밍과 기술 이슈를 빠르게 정리하는 개발 블로그

목록으로

Programming Notes

# Kubernetes v1.34: 파드 레벨 리소스, 베타 기능으로 승격

쿠버네티스 커뮤니티를 대표하여, 파드 레벨 리소스 기능이 쿠버네티스 v1.34 릴리스에서 베타로 승격되었으며, 기본으로 활성화된다는 기쁜 소식 하나를 전해드립니다! 이 중요한 이정표는 파드의 리소스 할당을 정의하고 관리하는 데 있어 새로운 수준의 유연성을 제공합니다. 이...

작성자

쿠버네티스 커뮤니티를 대표하여, 파드 레벨 리소스 기능이 쿠버네티스 v1.34 릴리스에서 베타로 승격되었으며, 기본으로 활성화된다는 기쁜 소식 하나를 전해드립니다! 이 중요한 이정표는 파드의 리소스 할당을 정의하고 관리하는 데 있어 새로운 수준의 유연성을 제공합니다. 이 유연성은 파드 전체에 대한 CPU 및 메모리 리소스를 지정할 수 있는 능력에서 비롯됩니다. 파드 레벨 리소스는 컨테이너 레벨 사양과 결합하여 애플리케이션에 필요한 정확한 리소스 요구 사항과 제한을 표현할 수 있습니다.

파드 레벨 리소스 사양

최근까지 파드에 적용되는 리소스 사양은 주로 개별 컨테이너 레벨에서 정의되었습니다. 이 방식은 효과적이었지만, 때로는 단일 파드 내 여러 컨테이너에 걸쳐 리소스 요구 사항을 중복해서 정의하거나 세심하게 계산해야 하는 번거로움이 있었습니다. 베타 기능으로, 쿠버네티스는 이제 CPU, 메모리, 휴지 페이지(hugepages) 리소스를 파드 레벨에서 지정할 수 있도록 허용합니다. 이는 이제 전체 파드에 대한 리소스 요청 및 제한을 정의하여, 필요하지 않은 경우 세밀한 컨테이너별 리소스 관리가 필요 없이 더 쉬운 리소스 공유를 가능하게 합니다.

파드 레벨 사양이 중요한 이유

이 기능은 파드와 컨테이너 레벨 모두에서 _유연한 리소스 관리_를 제공함으로써 쿠버네티스의 리소스 관리를 향상시킵니다.

  • 리소스 선언에 대한 통합된 접근 방식을 제공하여, 특히 여러 컨테이너를 가진 파드의 경우 세심한 컨테이너별 관리의 필요성을 줄여줍니다.

  • 파드 레벨 리소스는 파드 내 컨테이너들이 사용하지 않는 리소스를 서로 공유할 수 있게 하여, 파드 내에서 효율적인 활용을 촉진합니다. 예를 들어, 사이드카 컨테이너가 성능 병목 현상이 되는 것을 방지합니다. 이전에는 사이드카(예: 로깅 에이전트 또는 서비스 메시 프록시)가 개별 CPU 제한에 도달하면 메인 애플리케이션 컨테이너에 충분한 여유 CPU가 있더라도 파드 전체가 스로틀링되어 속도가 느려질 수 있었습니다. 파드 레벨 리소스를 사용하면 사이드카와 메인 컨테이너가 파드의 리소스 예산을 공유하여 트래픽 급증 시 원활한 작업을 보장합니다. 이는 전체 파드가 스로틀링되거나 모든 컨테이너가 함께 작동하는 방식으로 이루어집니다.

  • 파드 레벨과 컨테이너 레벨 리소스가 모두 지정된 경우, 파드 레벨 요청 및 제한이 우선합니다. 이는 사용자뿐만 아니라 클러스터 관리자에게도 파드의 전체 리소스 경계를 강제할 수 있는 강력한 방법을 제공합니다.

    스케줄링의 경우, 파드 레벨 요청이 명시적으로 정의되면 스케줄러는 개별 컨테이너의 집계된 요청 대신 해당 특정 값을 사용하여 적합한 노드를 찾습니다. 런타임 시, 파드 레벨 제한은 모든 컨테이너의 결합된 리소스 사용량에 대한 엄격한 상한선 역할을 합니다. 중요하게도, 이 파드 레벨 제한은 절대적인 강제자입니다. 개별 컨테이너 제한의 합계가 더 높더라도, 총 리소스 소비는 파드 레벨 제한을 초과할 수 없습니다.

  • 파드 레벨 리소스는 파드의 서비스 품질(QoS) 클래스에 영향을 미치는 데 우선순위를 가집니다.

  • 리눅스 노드에서 실행되는 파드의 경우, OOM(Out-Of-Memory) 점수 조정 계산은 파드 레벨 및 컨테이너 레벨 리소스 요청을 모두 고려합니다.

  • 파드 레벨 리소스는 기존 쿠버네티스 기능과 호환되도록 설계되어, 워크플로우에 원활하게 통합됩니다.

파드 전체에 대한 리소스를 지정하는 방법

PodLevelResources 기능 게이트를 사용하려면 컨트롤 플레인 및 모든 노드를 포함한 모든 클러스터 구성 요소에 쿠버네티스 v1.34 이상이 필요합니다. 이 기능 게이트는 v1.34에서 베타이며 기본으로 활성화됩니다.

예시 매니페스트

CPU, 메모리, 휴지 페이지 리소스를 파드 스펙 매니페스트의 resources 필드에서 파드 전체에 대해 직접 지정할 수 있습니다.

다음은 파드 레벨에서 CPU 및 메모리 요청과 제한이 모두 정의된 파드를 보여주는 예시입니다:

apiVersion: v1
kind: Pod
metadata:
  name: pod-resources-demo
  namespace: pod-resources-example
spec:
  # 'resources' 필드는 파드 사양 레벨에서 이 파드 내 모든 컨테이너를 합한
  # 전체 리소스 예산을 정의합니다.
  resources: # 파드 레벨 리소스
  # 'limits'는 파드가 사용할 수 있는 최대 리소스 양을 지정합니다.
  # 파드 내 모든 컨테이너 제한의 합계는 이 값을 초과할 수 없습니다.
    limits:
      cpu: "1" # 파드 전체는 1 CPU 코어 이상을 사용할 수 없습니다.
      memory: "200Mi" # 파드 전체는 200 MiB의 메모리 이상을 사용할 수 없습니다.
  # 'requests'는 파드에 보장되는 최소 리소스 양을 지정합니다.
  # 이 값은 쿠버네티스 스케줄러가 충분한 용량을 가진 노드를 찾는 데 사용됩니다.
    requests:
      cpu: "1" # 파드는 스케줄링될 때 1 CPU 코어를 보장받습니다.
      memory: "100Mi" # 파드는 스케줄링될 때 100 MiB의 메모리를 보장받습니다.
  containers:
  - name: main-app-container
    image: nginx
    ...
    # 이 컨테이너는 리소스 요청 또는 제한이 지정되지 않았습니다.
  - name: auxiliary-container
    image: fedora
    command: ["sleep", "inf"]
    ...
    # 이 컨테이너는 리소스 요청 또는 제한이 지정되지 않았습니다.

이 예시에서 pod-resources-demo 파드 전체는 1 CPU와 100 MiB의 메모리를 요청하고, 1 CPU와 200 MiB의 메모리로 제한됩니다. 내부에 있는 컨테이너들은 다음 섹션에서 설명하는 바와 같이 이러한 전체 파드 레벨 제약 조건 하에서 작동할 것입니다.

컨테이너 레벨 리소스 요청 또는 제한과의 상호 작용

파드 레벨과 컨테이너 레벨 리소스가 모두 지정된 경우, 파드 레벨 요청 및 제한이 우선합니다. 이는 노드가 파드 레벨 사양을 기반으로 리소스를 할당한다는 것을 의미합니다.

파드 레벨 CPU 및 메모리 요청과 제한이 정의되어 있고, 하나의 컨테이너만 명시적인 리소스 정의를 가진 두 개의 컨테이너가 있는 파드를 생각해 보세요:

apiVersion: v1
kind: Pod
metadata:
  name: pod-resources-demo
  namespace: pod-resources-example
spec:
  resources:
    limits:
      cpu: "1"
      memory: "200Mi"
    requests:
      cpu: "1"
      memory: "100Mi"
  containers:
  - name: main-app-container
    image: nginx
    resources:
      requests:
        cpu: "0.5"
        memory: "50Mi"
  - name: auxiliary-container
    image: fedora
    command: [ "sleep","inf"]
    # 이 컨테이너는 리소스 요청 또는 제한이 지정되지 않았습니다.

  • 파드 레벨 제한: 파드 레벨 제한(cpu: "1", memory: "200Mi")은 전체 파드에 대한 절대적인 경계를 설정합니다. 모든 컨테이너가 소비하는 리소스의 합계는 이 상한선에서 강제되며 초과할 수 없습니다.

  • 리소스 공유 및 버스팅: 컨테이너는 사용하지 않는 용량을 동적으로 빌려와 필요한 만큼 버스트(burst)할 수 있으며, 파드의 총 사용량이 전체 제한 내에 유지되는 한 허용됩니다.

  • 파드 레벨 요청: 파드 레벨 요청(cpu: "1", memory: "100Mi")은 전체 파드에 대한 기본 리소스 보증 역할을 합니다. 이 값은 스케줄러의 배치 결정에 영향을 미치고, 노드 레벨의 경합 상황에서 파드가 의존할 수 있는 최소 리소스를 나타냅니다.

  • 컨테이너 레벨 요청: 컨테이너 레벨 요청은 파드의 보장된 예산 내에서 우선순위 시스템을 생성합니다. main-app-container가 명시적 요청(cpu: "0.5", memory: "50Mi")을 가지고 있으므로, 리소스 압력 하에서 명시적 주장이 없는 auxiliary-container보다 리소스 할당에 있어 우선권을 가집니다.

제한 사항

  • 첫째, 쿠버네티스 v1.34(또는 이전 버전)에서는 파드 레벨 리소스의 인플레이스 리사이즈가 지원되지 않습니다. 실행 중인 파드의 파드 레벨 리소스 제한 또는 요청을 수정하려고 하면 오류가 발생하여 리사이즈가 거부됩니다. v1.34의 파드 레벨 리소스 구현은 전체 파드에 적용되는 전체 리소스 엔벨로프의 초기 선언을 허용하는 데 중점을 둡니다. 이는 이름과 달리 실행 중인 파드 내에서 컨테이너 리소스 요청 및 제한을 동적으로 조정할 수 있고, 잠재적으로 컨테이너 재시작 없이도 가능한 인플레이스 파드 리사이즈와는 다릅니다. 인플레이스 리사이즈는 아직 안정적인 기능이 아니며, v1.33 릴리스에서 베타로 승격되었습니다.

  • 파드 레벨에서는 CPU, 메모리, 휴지 페이지 리소스만 지정할 수 있습니다.

  • 파드 레벨 리소스는 윈도우 파드에 대해 지원되지 않습니다. 파드 사양이 명시적으로 윈도우를 대상으로 하는 경우(예: spec.os.name: "windows" 설정), API 서버는 유효성 검사 단계에서 파드를 거부합니다. 파드가 윈도우용으로 명시적으로 표시되지 않았지만 윈도우 노드에 스케줄링되는 경우(예: nodeSelector를 통해), 해당 윈도우 노드의 Kubelet은 승인 프로세스 중에 파드를 거부합니다.

  • 토폴로지 매니저, 메모리 매니저, CPU 매니저는 현재 파드 레벨 리소스를 지원하지 않으므로, 파드 레벨 리소스에 따라 파드와 컨테이너를 정렬하지 않습니다.

시작하기 및 피드백 제공

파드 레벨 리소스 기능을 탐색할 준비가 되셨나요? 쿠버네티스 v1.34 이상 버전이 실행되는 클러스터가 필요합니다. 컨트롤 플레인 및 모든 노드에서 PodLevelResources 기능 게이트를 활성화하는 것을 잊지 마세요.

이 기능이 베타 단계를 거치면서 여러분의 피드백은 매우 소중합니다. 표준 쿠버네티스 커뮤니케이션 채널을 통해 문제점을 보고하거나 경험을 공유해 주십시오: