Ops Insights – Kubernetes

Python GIL × CPU Limit

Thu, 06 Aug 2026 00:00:00 +0000

06 · Python GIL × CPU Limit — “1코어 런타임"은 왜 잘리는가

GIL은 성능 장치가 아니라 뮤텍스입니다. 바이트코드를 실행하는 스레드가 한 순간에 하나뿐이므로 순수 파이썬 프로세스의 CPU 소비는 정의상 코어 하나 분을 넘지 못합니다 — limit이 1코어 이상이면 바이트코드만으로는 스로틀이 성립하지 않습니다.
CFS quota는 “코어당 지분"이 아니라 시간 예산 풀입니다. 4코어 노드의 limit 1이 “코어마다 25%씩"을 뜻하지는 않습니다. 실행할 스레드가 있는 런큐만 전역 풀에서 5ms 슬라이스를 꺼내가는 구조입니다.
그런데도 실제 파이썬 컨테이너는 잘립니다. 경로는 네 갈래입니다 — 워커 프로세스 다중화 · GIL을 놓는 네이티브 스레드풀 · 1코어 미만 limit의 슬라이스 입도 · free-threading. 현행 커널의 파이썬 스로틀 사고는 전부 여기 속합니다.
잘리면 더 아픕니다. throttle은 per-CPU 단위라 GIL 홀더가 있는 코어만 잘려도 프로세스 전체가 유저스페이스에서 멈춥니다. 커널은 이 문제의 커널 락 버전을 고치는 중이지만 GIL은 유저스페이스 락이라 보호 밖입니다.
Python은 Go 1.25와 달리 cgroup을 안 봅니다. os.cpu_count()는 노드 코어 수를 돌려주고 3.13의 해법(PYTHON_CPU_COUNT)도 수동 주입입니다. 처방은 전부 배포 파이프라인의 몫입니다.

왜 이 문서가 따로 있나. 02 CPU Throttling이 “스로틀이 무엇이고, 어떻게 보이고, 무엇으로 대응하나"를 다룬다면 이 문서는 같은 문제를 언어 런타임 쪽에서 봅니다. 파이썬의 GIL은 두 개의 그럴듯한 오해를 만듭니다 — “GIL은 1코어를 갈구도록 설계된 구조다"와 “limit 1은 4코어에서 25%씩 배급받는다는 뜻이다”. 이 문서는 두 오해를 커널·CPython 소스 수준에서 바로잡고 그 위에서 “그런데 왜 실제 파이썬 컨테이너는 잘리는가"를 답합니다. 02 §4의 런타임 표(Go·JVM·Node.js)에서 비어 있던 Python 행이 이 문서입니다.

In-Place Pod Resize (1.35 GA)

Sat, 01 Aug 2026 00:00:00 +0000

01 · In-Place Pod Resize — 재시작 없이 파드 리소스를 바꾼다

1.27 alpha → 1.33 beta → 1.35 GA. 파드를 재시작하지 않고 CPU/메모리를 바꿉니다. 반드시 resize 서브리소스로만 통합니다. 손댈 수 있는 건 cpu·memory 값뿐입니다(QoS 변경·항목 제거·GPU는 전부 거부).
수락 판정 기준은 실사용량이 아니라 “다른 파드들의 requests 합 vs node allocatable”. 노드가 붐비면 Deferred(재시도됨), 정책 위반이면 Infeasible(spec을 고치기 전까지 재평가 안 됨).
늘리는 쪽은 사실상 무위험, 줄이는 쪽만 조심. 메모리 축소에는 kubelet 사용량 체크의 TOCTOU 레이스가 남아 OOM-kill을 확실히 막지 못합니다(#135670, open). CPU 축소는 재시작이 없다는 뜻일 뿐 스로틀 비용을 낳는데 그건 사용률 그래프에 안 보입니다(throttled_periods로 봐야 합니다).
케이스가 전부입니다. 재시작이 비싼 stateful(DB·캐시·롱커넥션)에 최적이고 기동 부스트에도 좋습니다. JVM/Node 힙에는 반쪽(CPU만 in-place), VPA 자동화는 아직 이르고 static CPU manager 노드는 사실상 미지원입니다.

왜 6년이 걸렸을까요. “실행 중인 컨테이너의 cgroup 값만 바꾸면 되는 것 아닌가” 싶지만 이 기능에서는 스케줄러가 보는 값·kubelet이 약속한 값·커널에 실제 쓰인 값이 서로 다른 순간이 반드시 생깁니다. 그 셋의 정합성에 kubelet 재시작 후의 복구까지 맞추는 데 KEP-1287은 alpha에서 GA까지 6년을 썼습니다. 그래서 이 문서는 공식 문서에서 멈추지 않고 kubelet이 실제로 하는 일 · 열린 버그 · 케이스별 득실까지 내려갑니다.

CPU Throttling

Sat, 01 Aug 2026 00:00:00 +0000

02 · CPU Throttling — limit을 다 쓰지도 않았는데 잘린다

CFS는 CPU limit을 100ms period로 쪼개서 줍니다. period는 서로 독립이고 안 쓴 quota는 이월되지 않습니다. 그래서 “평균 사용률 34% + throttle 31%” 가 모순 없이 성립합니다 — 총량이 남는데 타이밍이 잘립니다.
사용률 그래프에는 이 상태가 안 보입니다. 대시보드는 내내 여유로운데 꼬리 지연만 길어집니다. container_cpu_cfs_throttled_periods_total / …periods_total을 같이 봐야 처음 보입니다.
잘린 시간은 CPU wait으로 스레드에 그대로 쌓이고 APM에는 “아무것도 안 하는 구간"으로 찍힙니다. 컨테이너 전체가 한꺼번에 멈추므로 꼬리(P99)가 평균보다 훨씬 크게 망가집니다.
코어가 많을수록 더 잘립니다. quota는 병렬도에 비례해 마르기 때문입니다 — 같은 1코어 limit이라도 4코어에서 도는 컨테이너는 period의 ¾을 멈춰 있습니다. 직관과 반대입니다.
대응은 셋 중 하나입니다: limit 제거(가장 효과적이지만 이웃을 노출), CPU Manager static(throttle이 아예 생기지 않지만 조건이 빡빡), CPU Burst(타이밍만 푸는 정답에 가깝지만 k8s 표면이 없습니다).

“CPU를 더 주면 빨라진다"는 직관은 limit이 걸린 컨테이너에서 자주 틀립니다. 총량은 남았는데 쓸 수 있는 타이밍만 잘린 상태가 있습니다. 이 상태는 CPU 사용률 그래프에 나타나지 않아서 몇 시간씩 엉뚱한 곳을 파게 만듭니다. 그래서 이 문서를 따로 두었습니다. 그 상태가 어떻게 만들어지는지, 어떤 지표를 겹쳐 봐야 보이는지, 대응 선택지가 각각 무엇을 대가로 치르는지를 정리합니다.

CPU Burst (커널 5.14)

Mon, 27 Jul 2026 00:00:00 +0000

03 · CPU Burst — CPU limit을 지키면서 불필요한 throttling만 걷어낸다

CFS bandwidth control은 period를 독립 정산하고 안 쓴 quota를 버립니다. 그래서 평균 사용률이 limit의 절반이어도 순간 수요만으로 throttle이 걸립니다. 자원이 부족해서 걸리는 게 아닙니다. 나눠주는 방식이 문제입니다.
CPU Burst는 이전 period의 미사용분을 buffer에 적립해 뒀다가 빌려 쓰게 합니다. 순간 상한만 Quota + Buffer로 늘고 누적 상한 Σ CPUTime ≤ Quota × N은 그대로입니다. limit을 올려주는 것과 근본적으로 다릅니다.
평균이 아니라 꼬리가 개선됩니다. 발표 실측에서 RT Avg는 30+ms→9.6ms(약 1/3)인데 P99는 500+ms→27.32ms(약 1/20). throttling이 망가뜨리는 건 tail이기 때문입니다.
공짜가 아닙니다. 이웃 컨테이너가 deadline을 놓칠 수 있고 그게 누적되면 unbounded fail입니다. 위험은 정량화돼 있습니다 — 평균 CPU 사용률 70% 미만이면 안전하고 직관과 반대로 컨테이너 수가 적은 노드가 더 위험합니다.
cpu.cfs_burst_us 기본값 0 = 기존 동작과 완전히 동일. 커널만 올려도 아무것도 안 바뀝니다. 도입 리스크가 낮습니다.
k8s에서 Pod spec으로 켜는 건 아직 안 됩니다(#104516). 현재는 노드에서 cgroup을 직접 만지거나 벤더 annotation을 씁니다.

출처: KubeCon + CloudNativeCon China 2021 — CPU Burst: Getting Rid of Unnecessary Throttling… (常怀鑫·丁天琛, Alibaba Cloud 커널팀). 이 글은 발표 내용에 커널 동작과 운영 판단을 덧붙여 재구성했습니다.

Node Problem Detector

Fri, 31 Jul 2026 00:00:00 +0000

04 · Node Problem Detector — 솔루션 검토

NPD는 SIG Node 산하 프로젝트(kubernetes/node-problem-detector)입니다. DaemonSet 또는 standalone 데몬으로 각 노드에서 돌면서 노드 문제를 NodeCondition 또는 Event로 API 서버에 보고합니다. kubernetes.io 공식 태스크 문서 Monitor Node Health에 수록돼 있습니다.
문제 데몬은 SystemLogMonitor · SystemStatsMonitor · CustomPluginMonitor · HealthChecker 4종입니다. 기본 설정 파일만으로 KernelDeadlock, ReadonlyFilesystem, FrequentKubeletRestart, CorruptDockerOverlay2 등을 탐지합니다.
NPD는 탐지·보고까지만 합니다. cordon·drain·교체는 별도 remedy system이 맡습니다. README는 Descheduler · mediK8S · MachineHealthCheck 3개를 나열합니다.
EKS에는 eks-node-monitoring-agent 애드온과 node auto repair 조합이 있습니다. 5개 전용 NodeCondition을 세우고 Replace/Reboot까지 수행합니다. AWS 공식 문서는 NPD와 어떤 관계인지(대체인지 보완인지) 서술하지 않습니다.

자매 문서: 챕터 개요 · 노드 단위 조치·중단 예산은 Karpenter

DaemonSet 미기동 노드 격리

Sat, 01 Aug 2026 00:00:00 +0000

05 · DaemonSet 미기동 노드 격리 — 탐지와 격리 의미론

DaemonSet 파드를 노드에 바인딩하는 주체는 1.12+에서 기본 스케줄러입니다. DS 컨트롤러는 대상 노드를 가리키는 nodeAffinity를 파드에 심는 데까지만 관여합니다. 그래서 DS 파드도 taint·리소스·이미지 같은 일반 스케줄링 실패 모드를 그대로 겪습니다.
cordon은 DS 파드를 막지 못합니다. DS 컨트롤러가 node.kubernetes.io/unschedulable:NoSchedule 톨러레이션을 자동으로 붙이기 때문입니다. 격리 관점에서는 이 동작이 오히려 맞습니다 — 워크로드 유입만 끊고, 정작 고쳐야 할 DS는 계속 재시도합니다.
노드별 갭은 kube_daemonset_status_* 로는 안 보입니다. 이 메트릭들의 라벨은 daemonset·namespace 뿐이라 “몇 개 부족"까지만 알려줍니다. “어느 노드가 빠졌는지"는 kube_pod_info 를 node 라벨로 조인해야 나옵니다.
빠른 격리 전략은 성질이 서로 다릅니다. 선제(startup taint로 준비 전까지 기본 격리)는 탐지 시간 자체를 없앱니다. 반응(탐지 → taint → drain)은 탐지 지연이 곧 장애 시간이 됩니다. 선제를 기본으로 깔고 반응을 백스톱으로 둡니다.

자매 문서: 04 Node Problem Detector — 탐지 계층의 선택지 · Karpenter — 노드 단위 조치와 중단 예산