솔직히 말해서, 쿠버네티스는 정말 거대하죠. 특히 ML 학습, 초저지연 트레이딩 시스템, 숨 쉬듯 작동하는 데이터베이스 같은 성능 민감 워크로드를 관리하는 건 언제나 섬세한 춤과 같았습니다. 안정적인 성능을 원한다면, 핵심 애플리케이션을 위해 전용 NUMA 정렬 자원을 확보해야 하죠. 하지만 요즘 파드는 더 이상 외로운 단일 컨테이너가 아닙니다. 로깅, 모니터링, 서비스 메쉬, 데이터 인입 등을 위한 사이드카까지, 하나의 생태계죠.
과거에는 주요 애플리케이션에 최고급 전용 자원을 할당하려면 모든 것을 걸어야 했습니다. 파드 내 모든 컨테이너는 정수 단위의 CPU를 할당받았죠. 낭비였냐고요? 당연하죠. CPU를 거의 안 쓰는 작은 메트릭스 익스포터에도 말입니다. 이 엄격한 할당을 건너뛰면, 파드는 귀한 ‘보장된 QoS(Quality of Service)’ 등급을 포기해야 했고, 일관되고 최상의 성능을 기대할 수 없게 됩니다. 까다로운 애플리케이션을 운영하는 누구에게나 정말 어려운 선택이었죠.
새로운 희망: 파드 레벨 관리자의 등장
하지만 쿠버네티스 v1.36은 파드 레벨 자원 관리자의 알파 도입으로 판도를 바꾸고 있습니다. 이건 단순한 수정이 아니라, kubelet의 토폴로지, CPU, 메모리 관리자의 역량을 확장하는 근본적인 아키텍처 변화입니다. 핵심은? 이제 .spec.resources에서 파드 레벨 자원 사양을 지원한다는 겁니다. 기존 컨테이너별 할당 모델에서 명확히 파드 중심 모델로 나아가는 거죠.
이 새로운 기능 게이트(PodLevelResourceManagers와 PodLevelResources)를 활성화하면, kubelet은 하이브리드 자원 할당 모델을 오케스트레이션할 수 있게 됩니다. 덕분에 핵심 성능을 내는 컨테이너를 위해 NUMA 정렬과 전용 자원 할당을 받으면서도, 덜 까다로운 동반자들에게 CPU 코어를 낭비하지 않아도 됩니다. 드디어 유연성과 효율성이 만난 셈입니다.
실제 시나리오: NUMA와 현실의 만남
이 새로운 접근 방식의 장점은 실제 사용 사례에서 빛을 발하는데, 이는 토폴로지 관리자의 스코핑 방식에 크게 좌우됩니다. 메인 컨테이너, 로컬 메트릭스 익스포터, 백업 에이전트 사이드카를 갖춘 지연 시간 민감 데이터베이스 파드를 예로 들어보죠.
토폴로지 관리자를 pod 스코프로 구성하면, kubelet은 파드 전체 자원 예산을 기반으로 단일 NUMA 정렬을 수행합니다. 중요한 데이터베이스 컨테이너는 해당 NUMA 노드에서 전용 CPU 및 메모리 슬라이스를 확보합니다. 남은 자원은? 파드 공유 풀(pod shared pool)이 됩니다. 이곳에서 메트릭스 익스포터와 백업 에이전트가 서로 자원을 공유합니다. 물론 서로 자원을 공유하지만, 결정적으로 데이터베이스의 전용 슬라이스와 노드의 나머지 부분과는 격리됩니다. 이건 엄청난 변화입니다. 노드의 전용 코어를 낭비하지 않고도 동일한 NUMA 노드에 보조 컨테이너를 배치할 수 있으니까요.
pod토폴로지 관리자 스코프로 구성 시, kubelet은 파드 전체 예산을 기반으로 단일 NUMA 정렬을 수행합니다. 데이터베이스 컨테이너는 해당 NUMA 노드에서 전용 CPU 및 메모리 슬라이스를 얻습니다. 파드 예산에서 남은 자원은 새로운 파드 공유 풀을 형성합니다.
YAML에서는 이렇게 보일 수 있습니다:
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
# 이 '보장된' 컨테이너는 파드 예산에서 전용 6 CPU 슬라이스를 받습니다.
# 남은 2개의 CPU와 4Gi 메모리는 사이드카를 위한 파드 공유 풀을 형성합니다.
resources:
requests:
cpu: "6"
memory: "12Gi"
limits:
cpu: "6"
memory: "12Gi"
다른 예로, 인프라 사이드카가 있는 ML 워크로드를 생각해 봅시다. 이때는 container 토폴로지 관리자 스코프를 활용할 가능성이 높습니다. kubelet은 각 컨테이너를 개별적으로 평가합니다. 최대 성능을 갈망하는 ML 학습 컨테이너는 전용 NUMA 정렬 CPU와 메모리를 받습니다. 서비스 메쉬 사이드카는? 그런 특별한 처리가 필요 없죠. 노드 전역의 공유 풀에서 행복하게 실행됩니다. 총 자원 소비는 여전히 전체 파드 제한으로 억제되지만, 전용 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' 스코프 하에서, 이 '보장된' 컨테이너는 전용 NUMA 정렬 자원을 받으며,
# 사이드카는 노드의 공유 풀에서 실행됩니다.
resources:
requests:
cpu: "3"
memory: "6Gi"
limits:
cpu: "3"
memory: "6Gi"
CPU 쿼터와 격리의 예술
격리는 핵심이며, 이러한 혼합 워크로드에 대해 다르게 처리됩니다. 전용 CPU 슬라이스를 받는 컨테이너의 경우, CPU CFS(Completely Fair Scheduler) 쿼터 강제가 컨테이너 수준에서 비활성화됩니다. 즉, 커널의 CFS가 일반적으로 부과하는 스로틀링 없이 작동하여, 방해받지 않고 급증하고 수행할 수 있도록 합니다.
반대로, 전용 CPU 슬라이스를 받지 않는 컨테이너는 파드 레벨 공유 풀 또는 노드 전역 공유 풀의 일부가 됩니다. 이 컨테이너에는 CFS 쿼터 강제가 활성화됩니다. CFS 스코어링 정책에 따라 자원을 공유하죠. 이는 필수적인 프로세스를 굶주리게 하는 무분별한 프로세스를 방지하면서도, 고위험 애플리케이션을 위한 전용 레인을 제공하도록 설계된 미묘한 시스템입니다.
근본적인 변화: 컨테이너에서 파드로
파드 레벨 자원 관리로의 전환은 단순한 최적화를 넘어 쿠버네티스 내 철학적 변화입니다. 수년 동안 스케줄링 및 자원 할당의 기본 단위는 컨테이너였습니다. 이 새로운 기능은 현대 애플리케이션이 종종 파드 내에서 분산되며, 이러한 분산 구성 요소를 통합된 단위로 관리하는 것이 성능과 효율성을 위해 중요하다는 점을 인정합니다. 파드를 독립적인 프로세스 모음으로 취급하기보다는, 복잡하지만 단일한 애플리케이션 인스턴스로 취급하는 것입니다.
이는 고성능 애플리케이션을 설계하고 배포하는 방식에 매력적인 가능성을 열어줍니다. 각 컨테이너의 자원 요구 사항을 세심하게 계산하고 QoS 문제를 씨름하는 대신, 이제 파드의 전체 자원 발자국을 정의하고 해당 예산 내에서 지능적으로 위임할 수 있습니다. 운영을 간소화하고, 더 중요한 것은 성능 저하 없이 더 타이트한 자원 활용을 가능하게 합니다. FinOps 팀과 까다로운 성능 지표를 쫓는 엔지니어에게는 희소식입니다.
개발자와 운영자를 위한 의미
개발자에게는 복잡한 파드의 자원 요구 사항을 지정하는 보다 직관적인 방법이 생겼습니다. 성능이 중요한 구성 요소와 이를 지원하는 구성 요소를 명확하게 구분할 수 있습니다. 운영자에게는 노드 활용도가 높아지고 잠재적으로 비용 절감 효과를 얻을 수 있습니다. 더 이상 메인 애플리케이션의 QoS를 유지하기 위해 사이드카에 자원을 과잉 프로비저닝할 필요가 없기 때문입니다. 가장 까다로운 워크로드를 위한 쿠버네티스를 더욱 실현 가능한 플랫폼으로 만드는 중요한 단계입니다.
물론, 아직 알파입니다. 약간의 거친 부분, 변경 사항, 그리고 당연히 성숙해짐에 따라 더 많은 탐색적 질문이 있을 것으로 예상됩니다. 하지만 방향은 명확합니다. 쿠버네티스는 기본 하드웨어의 제한된 자원을 어떻게 할당하는지에 대해 더 똑똑해지고 있으며, 이는 주목할 만한 발전입니다.
🧬 관련 인사이트
- 더 읽어보기: GitHub를 복제하고 핀테크 비밀을 빼낸 12줄 PHP 스크립트
- 더 읽어보기: 도망치고 싶지 않은 릴리스: 신화 속 안전한 배포를 쫓다
