cgroup v1 CPU Shares에서 v2 CPU Weight로의 새로운 변환

Source: Kubernetes Blog

Announcement: Improved Conversion Formula for CPU Shares → CPU Weight

우리는 cgroup v1 CPU shares를 cgroup v2 CPU weight로 변환하는 새로운 변환 공식을 도입하게 되어 기쁩니다. 이 개선은 cgroup v2를 사용하는 시스템에서 실행되는 Kubernetes 워크로드의 CPU 우선순위 할당과 관련된 중요한 문제를 해결합니다.

배경

Kubernetes는 원래 cgroup v1을 염두에 두고 설계되었으며, 이때 CPU share는 컨테이너의 CPU 요청을 millicpu 형태로 지정함으로써 간단히 정의되었습니다.

예시: 1 CPU(1024m)를 요청하는 컨테이너는 cpu.shares = 1024를 갖게 됩니다.

시간이 흐르면서 cgroup v1은 차세대 버전인 cgroup v2로 대체되기 시작했습니다. cgroup v2에서는 CPU share(범위 2 ~ 262 144, 즉 (2^{1}) ~ (2^{18})) 개념이 CPU weight(범위 1 ~ 10 000, 즉 (10^{0}) ~ (10^{4}))로 바뀌었습니다.

cgroup v2로의 전환과 함께 **KEP‑2254**는 cgroup v1 CPU share를 cgroup v2 CPU weight로 변환하는 공식을 도입했습니다:

cpu.weight = (1 + ((cpu.shares - 2) * 9999) / 262142)

이 공식은 ([2^{1}, 2^{18}]) 범위의 값을 ([10^{0}, 10^{4}]) 범위로 선형 매핑합니다.

이 접근 방식은 단순하지만, 선형 매핑은 성능과 설정 세분성 모두에 영향을 미치는 여러 중요한 문제를 야기합니다.

Source: …

이전 변환 공식의 문제점

현재 변환 공식은 두 가지 주요 문제를 야기합니다.

쿠버네티스 외 워크로드에 대한 우선순위 감소

• cgroup v1에서는 CPU share의 기본값이 **1024**입니다.
  1 CPU(1024 m) 를 요청하는 컨테이너는 쿠버네티스 밖에서 실행되는 시스템 프로세스와 동일한 우선순위를 갖게 됩니다.

• cgroup v2에서는 기본 CPU weight가 **100**인데, 현재 공식은 1 CPU(1024 m) 를 ≈ 39 weight 로 변환합니다 – 기본값의 40 % 미만에 해당합니다.

예시

영향
cgroup v2 로 전환한 뒤, 쿠버네티스(또는 OCI) 워크로드는 쿠버네티스 외 프로세스에 비해 CPU 우선순위를 잃게 됩니다. 이는 시스템 데몬이 많이 실행되는 노드에서, 특히 자원이 부족한 상황에서 심각한 영향을 미칠 수 있습니다.

관리하기 어려운 세분화 수준

현재 공식은 작은 CPU 요청에 대해 매우 낮은 값을 반환하므로, 컨테이너 내부에서 세부적인 리소스 분배를 위한 서브‑cgroup을 만들기 어렵게 합니다(Kep #5474 참조).

예시

영향
cgroup v1에서는 100 m CPU(102 shares) 요청이 서브‑cgroup 간에 합리적인 CPU weight 할당을 가능하게 했습니다. 하지만 cgroup v2에서 4 라는 weight는 너무 거친 값이라 서브‑cgroup 간에 CPU 자원을 효과적으로 분배하기 어렵습니다. 이는 비특권 컨테이너용 Writable cgroups 지원이 곧 도입될 예정인(Kep #5474) 상황에서 더욱 중요한 문제입니다.

새로운 변환 공식

설명

새로운 공식은 더 복잡하지만 cgroup v1 CPU shares와 cgroup v2 CPU weight 사이를 훨씬 더 정확하게 매핑합니다:

[ \text{cpu.weight} = \Bigl\lceil 10^{\left(\frac{L^{2}}{612} + \frac{125L}{612} - \frac{7}{34}\right)} \Bigr\rceil, \qquad\text{where } L = \log_{2}(\text{cpu.shares}) ]

이는 세 가지 핵심 점을 통과하는 2차 함수입니다:

시각적으로, 새로운 함수는 다음과 같습니다:

중요한 영역을 확대하면:

이 함수는 “거의 선형”에 가깝지만, 위의 세 중요한 점이 정확히 일치하도록 정밀하게 설계되었습니다.

문제 해결 방식

더 나은 우선순위 정렬

1 CPU(1024 m)를 요청하는 컨테이너는 이제 다음과 같이 됩니다

cpu.weight = 102

이는 cgroup v2의 기본 weight인 100에 가깝습니다. 이는 Kubernetes 워크로드와 시스템 프로세스 간의 의도된 우선순위 관계를 복원합니다.

향상된 세분성

100 m CPU를 요청하는 컨테이너는 다음과 같이 됩니다

cpu.weight = 17

(여기에서 시연을 확인할 수 있습니다). 이는 컨테이너 내에서 보다 세밀한 자원 분배를 가능하게 합니다.

Source: …

채택 및 통합

이 변경은 OCI 계층에서 구현되었습니다. 즉, Kubernetes 자체에 구현된 것이 아니므로 새로운 변환 공식의 채택은 전적으로 OCI 런타임 채택에 달려 있습니다.

지원되는 런타임

기존 배포에 미치는 영향

중요: 이전 선형 변환 공식을 가정하는 일부 사용자는 영향을 받을 수 있습니다. 이전 공식에 기반해 예상 CPU‑weight 값을 직접 계산하는 애플리케이션이나 모니터링 도구는 새로운 2차 변환을 반영하도록 업데이트가 필요할 수 있습니다.

관련 시나리오에는 다음이 포함됩니다:

• CPU‑weight 값을 예측하는 맞춤형 리소스 관리 도구.
• 특정 weight 값을 검증하거나 기대하는 모니터링 시스템.
• 프로그래밍 방식으로 CPU‑weight 값을 설정하거나 확인하는 애플리케이션.

Kubernetes 프로젝트는 기존 도구와의 호환성을 보장하기 위해 OCI 런타임을 업그레이드하기 전에 비생산 환경에서 새로운 변환 공식을 테스트할 것을 권장합니다.

어디서 더 배울 수 있나요?

• Kubernetes GitHub Issue #131216 – 상세한 기술 분석 및 예시, 위 공식 선택에 대한 논의와 이유 포함.
• KEP‑2254: cgroup v2 – Kubernetes에서의 원래 cgroup v2 구현.
• Kubernetes cgroup documentation – 현재 리소스 관리 가이드라인.

어떻게 참여할 수 있나요?

Kubernetes 노드 수준 기능에 기여하고 싶다면, **Kubernetes Node Special Interest Group (SIG‑Node)**에 참여하세요.

우리는 새로운 기여자와 자원 관리 과제에 대한 다양한 관점을 환영합니다.