makgol's note – Kubernetes

01 GPU 조합이 성능을 바꾸는 조건

Wed, 21 Oct 2026 00:00:00 +0900

01 · GPU 조합이 성능을 바꾸는 조건

같은 네 장이어도 연결은 다를 수 있습니다

파드에 nvidia.com/gpu: 4를 요청하면 GPU 네 장을 받습니다. 이 요청에는 어느 GPU끼리 연결돼 있어야 하는지까지 담겨 있지 않습니다. 노드 안의 GPU 쌍이 모두 같은 경로로 통신한다면 선택에 따른 차이는 작겠지만, PCIe 스위치나 CPU 소켓을 건너야 하는 쌍이 섞여 있다면 조합에 따라 지연과 대역폭이 달라질 수 있습니다.

02 요청한 GPU는 누가 골라 주는가

Wed, 21 Oct 2026 00:00:00 +0900

02 · 요청한 GPU는 누가 골라 주는가

노드 선택과 GPU 선택은 다른 단계입니다

nvidia.com/gpu: 4는 GPU 네 장을 요청하는 문법입니다. NVLink로 이어진 네 장을 지정하는 문법은 아닙니다. 01편의 PCIe 서버처럼 GPU 쌍마다 연결 경로가 다르다면, 개수를 충족한 뒤에도 어느 조합을 줄지 결정해야 합니다.

03 GPU 할당에 DRA가 필요한 때 — 개수는 device plugin, 노드 간 NVLink는 ComputeDomain

Wed, 21 Oct 2026 00:00:00 +0900

03 · GPU 할당에 DRA가 필요한 때

GPU를 개수로 요청해 쓰고 있다면 DRA(Dynamic Resource Allocation)가 GA(정식 제공)가 됐다는 이유만으로 할당 방식을 옮길 필요는 없습니다. 2026-10-21에 확인한 설치 문서와 운영 예시에서는 device plugin과 GPU Operator가 여전히 기본 경로입니다. 장치의 메모리·모델·위치까지 선택해야 하거나, GB200처럼 NVLink가 노드를 넘어 연결되는 환경에서는 DRA가 맡는 일이 달라집니다.

04 학습 잡을 가까운 노드에 모으려면 — 토폴로지 라벨과 Kueue TAS

Wed, 21 Oct 2026 00:00:00 +0900

04 · 학습 잡을 가까운 노드에 모으려면

노드 사이에서 어떤 경계를 넘는지가 중요합니다

분산 학습 잡이 GPU를 충분히 확보했어도 파드들이 혼잡한 링크를 사이에 두고 흩어지면 성능이 떨어질 수 있습니다. 01편의 노드 안 NVLink·PCIe 경로와 02편·03편의 GPU 할당을 확인한 뒤에는, 한 잡의 파드들이 노드 사이에서 어느 네트워크 경계를 넘는지 살펴야 합니다.

05 노드 간 스케줄링 2부 — Volcano·KAI·Slurm 비교

Wed, 21 Oct 2026 00:00:00 +0900

05 · 노드 간 스케줄링 2부 — Volcano·KAI·Slurm 비교

1. 배치 요구와 토폴로지 정보의 공급자를 정한다

여러 노드의 GPU를 가까이 배치하려면 스케줄러에 물리적 위치를 알려 주어야 합니다. 클라우드의 CCM(클라우드 컨트롤러 매니저)이 라벨을 붙일지, Topograph가 정보를 수집할지, Volcano의 자동 발견을 쓸지부터 정해야 합니다. 04편에서는 노드 라벨로 토폴로지를 알리고 Kueue TAS(토폴로지 인지 스케줄링)에 연결했습니다. 여기서는 그 정보를 다른 스케줄러가 어떻게 배치 규칙으로 바꾸는지 비교합니다.

06 GPUDirect RDMA 1부 — 파드의 NIC이 GPU 메모리에 닿는 조건과 준비

Wed, 21 Oct 2026 00:00:00 +0900

06 · GPUDirect RDMA 1부 — 파드의 NIC이 GPU 메모리에 닿는 조건과 준비

1. GPU에서 NIC까지의 경로를 확인한다

GPU를 할당받은 파드가 노드 밖으로 데이터를 보내려면 NIC(네트워크 인터페이스 카드)까지 데이터를 전달해야 합니다. 일반 경로에서는 GPU 메모리의 데이터를 호스트의 고정 메모리로 복사하고 NIC이 그 버퍼를 읽습니다. GPUDirect RDMA는 NIC이 GPU 메모리를 직접 읽고 쓰게 하는 PCIe 기능입니다. 파드가 GPU를 할당받는 것만으로 이 직접 경로까지 준비되지는 않습니다. 장치 할당의 일반 원리는 03편에서 다뤘습니다.

07 GPUDirect RDMA가 실제로 쓰이는지 확인하고 클라우드별 차이를 읽기

Wed, 21 Oct 2026 00:00:00 +0900

07 · GPUDirect RDMA가 실제로 쓰이는지 확인하고 클라우드별 차이를 읽기

1. NCCL 채널 로그에서 직접 전송을 확인한다

06편의 호스트와 파드 구성을 마쳤어도 통신이 호스트 메모리를 경유할 수 있습니다. NIC(네트워크 인터페이스 카드)이 GPU 메모리에 직접 접근할 수 있도록 준비하는 일과 NCCL(GPU 간 통신 라이브러리)이 그 경로를 사용하는 일은 구분해야 합니다. 실제 선택은 NCCL_DEBUG=INFO의 채널 연결 로그에서 확인합니다.

08 스토리지 — GDS와 NVMe-oF의 CPU 우회 범위

Wed, 21 Oct 2026 00:00:00 +0900

08 · 스토리지 — GDS와 NVMe-oF의 CPU 우회 범위

1. GDS가 줄이는 복사와 CPU에 남는 일

스토리지의 데이터를 GPU로 읽는 일반 경로에서는 CPU 시스템 메모리에 바운스 버퍼를 두고, 여기에 받은 데이터를 GPU 메모리로 다시 복사합니다. NVIDIA GDS 개요 가이드는 이 중간 복사가 지연을 늘리고 유효 대역폭을 낮춘다고 설명합니다.

09 스토리지 — 학습·추론의 GDS 활용과 패브릭 분리

Wed, 21 Oct 2026 00:00:00 +0900

09 · 스토리지 — 학습·추론의 GDS 활용과 패브릭 분리

1. GDS를 켜기 전에 애플리케이션의 I/O를 본다

노드가 GDS(GPUDirect Storage)를 지원해도 학습 프레임워크가 데이터를 CPU 메모리에 받아 처리한다면 GPU로 바로 읽는 경로를 쓰지 않습니다. 08편의 드라이버·파일시스템 조건을 갖춘 뒤에는 데이터셋 리더, 체크포인트 writer, 추론 로더와 KV 캐시가 각각 어떤 API와 메모리를 사용하는지 확인해야 합니다.

10 제공자가 GPU 파드보다 먼저 맞추는 NVLink·패브릭 설정

Wed, 21 Oct 2026 00:00:00 +0900

10 · 제공자가 GPU 파드보다 먼저 맞추는 NVLink·패브릭 설정

1. GPU 세대에 맞춰 Fabric Manager를 구성한다

GPU 파드가 NVLink를 사용하려면 제공자가 먼저 노드의 패브릭을 구성해야 합니다. NVSwitch 노드에서는 Fabric Manager(FM)가, NVL72에서는 랙의 NMX와 컴퓨트 트레이의 IMEX가 각각 맡는 일이 있습니다. 그 상태를 확인한 뒤 노드 간 InfiniBand·RoCE 연결과 혼잡 제어를 맞추는 순서로 살펴봅니다.

11 GPU 클러스터를 사용자에게 내주기 위한 조건

Wed, 21 Oct 2026 00:00:00 +0900

11 · GPU 클러스터를 사용자에게 내주기 위한 조건

10편에서 FM·IMEX와 노드 간 패브릭을 구성했다면, 이제 사용자에게 제공할 범위를 정하고 그 구성으로 검증해야 합니다. 배선과 토폴로지 정보를 Kubernetes에 전달하고, 테넌트 경계와 NCCL 경로를 맞춘 뒤, 하드웨어별 합격선을 측정합니다. 운영 중에는 관측 결과가 어느 조건에서 격리로 이어질지도 정해야 합니다.

OpenStack on Kubernetes — 컨트롤 플레인은 파드로, VM은 여전히 베어메탈의 KVM으로

Mon, 05 Oct 2026 00:00:00 +0900

07 · OpenStack on Kubernetes — 컨트롤 플레인은 파드로, VM은 여전히 베어메탈의 KVM으로

OpenStack on Kubernetes에서 Kubernetes가 배포하는 대상은 VM을 관리하는 OpenStack 서비스입니다. OpenStack-Helm에서는 API·scheduler·conductor와 MariaDB·RabbitMQ가 파드로 실행되고, VM은 컴퓨트 노드의 libvirt와 QEMU/KVM이 실행합니다. VM 하나를 호스트의 QEMU 프로세스 하나에 대응시킨 설명은 libvirt 문서를 바탕으로 한 이 글의 정리입니다.

Python GIL × CPU Limit

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

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 행이 이 문서입니다.

레이어 1 — 클러스터 파라미터와 가변성 3분류

Sat, 15 Aug 2026 00:00:00 +0900

레이어 1 — 클러스터 파라미터와 가변성 3분류

finance blue를 만들 때 정해둘 것 셋 — upgradePolicy.supportType = STANDARD(기본값이 EXTENDED입니다), deletionProtection = true, 그리고 serviceIpv4Cidr·ipFamily·bootstrapClusterCreatorAdminPermissions. 뒤 셋은 지금 틀리면 재생성뿐입니다.
최상위 29개 파라미터는 create-only 8 · 단방향 불가역 6 · day-2 가변 15로 갈립니다(§1).
upgradePolicy.supportType 기본값은 EXTENDED입니다. 명시하지 않으면 표준지원 종료일부터 시간당 $0.60이 자동으로 붙고 확장지원에 실제로 진입한 뒤에는 STANDARD로 못 돌아옵니다(§4).
되돌릴 수 없는 문 넷 — controlPlaneEgressMode(CUSTOMER_ROUTED 진입), encryptionConfig(DisassociateEncryptionConfig API가 아예 없습니다), authenticationMode(전진만), ipFamily(생성 시 영구 고정)(§2).
Terraform은 되돌리기를 클러스터 재생성으로 모델링합니다 — plan에 뜨는 # forces replacement는 버그가 아니라 안전장치입니다(§3).
버전은 2026-07부터 되돌릴 수 있습니다(7일 창·마이너 1단계·컨트롤 플레인만). 단 --force는 PDB도 어드미션 웹훅도 우회하지 않습니다(§5).

이 페이지가 다루는 범위는 CreateCluster·UpdateClusterConfig·UpdateClusterVersion이 받는 클러스터 레벨 최상위 필드입니다. 판정하는 것은 하나뿐입니다. 그 값을 언제 정할 수 있고 정한 뒤에 되돌릴 수 있는가. 2026-08에 새로 열린 컨트롤 플레인 컴포넌트 파라미터의 내부 동작과 튜닝 판단은 레이어 2, 용량 축인 Provisioned Control Plane 티어는 용량 축, 애초에 손댈 수 없는 영역은 레이어 3이 갖습니다.

0.36 → 1.6 — v1 전환과 그 직후

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

01 · 0.36 → 1.6 — v1이 바꾼 것은 API가 아니라 동작이다

v1beta1→v1을 “필드 이름이 바뀐 일"로 읽으면 사고가 납니다. changelog에서 위험한 절은 Behavior Changes이고 그중 둘은 옵트아웃이 없습니다 — drift는 Stable 승격과 함께 feature gate가 삭제됐고(core#1311), expiration은 forceful로 되돌아갔습니다(core#1333).
forceful expiration이 무시하는 건 PodDisruptionBudget(PDB)이 아닙니다. 무시하는 것은 “대체 노드가 Initialized가 될 때까지 드레인을 시작하지 않는다"는 사전 안전장치와 disruption budget입니다. nodeclaim.expiration 컨트롤러는 후보 평가 없이 NodeClaim을 바로 Delete합니다(controllers/nodeclaim/expiration/controller.go:82).
consolidateAfter가 v1에서 필수 필드입니다. v1beta1의 WhenUnderutilized에서는 설정조차 불가능했던 값이라 기존 동작을 유지하려면 0s를 명시해야 합니다. Never는 그 NodePool의 consolidation을 통째로 끕니다.
terminationGracePeriod(core#916)가 최종 승자입니다. 만료되면 PDB·do-not-disrupt 무관하게 남은 파드가 강제 삭제됩니다. 반대로 TGP를 걸면 drift가 “PDB·do-not-disrupt 파드가 있는 노드"까지 후보로 채택합니다 — 안전장치를 스스로 꺼주는 대가로 CVE 패치를 밀 수 있게 됩니다. 노드 최대 수명 = expireAfter(기본 720h, 상한이지 하한이 아닙니다) + TGP.
disruption budgets가 Drifted/Underutilized/Empty reason별로 나뉘었습니다(core#991, core#1377). 삭제된 drift feature gate의 자리를 reason별 budget이 메웁니다 — 업스트림이 제시하는 유일한 drift 통제 수단입니다.
1.1.0이 v1beta1 서빙을 끝냈습니다. nodeClassRef.group/kind가 강제 필수가 되고 kubelet 호환 어노테이션이 사라집니다. 같은 릴리스의 Bottlerocket + instanceStorePolicy: RAID0은 v1.22.0 미만 이미지에서 노드가 join하지 못합니다.
1.2.0의 메트릭 reason 라벨 snake_case 전환은 CI가 못 잡는 알람 무효화입니다. reason="Drifted" 쿼리는 에러 없이 결과가 0이 됩니다. 같은 릴리스에서 nodeclass.status·nodeclass.termination이 nodeclass로 합쳐졌습니다(aws#7597).
1.6.0에서 native On-Demand Capacity Reservation(ODCR)이 beta·기본 활성화됐습니다(core#2365). open eligibility ODCR을 capacityReservationSelectorTerms에 등재하지 않고 올리면 예약을 안 쓰면서 요금은 계속 나갑니다 — 이 구간에서 가장 비싼 회귀입니다.
MinValuesPolicy(1.6, core#2299·aws#8250)는 전역 옵션이고 기본값은 Strict입니다. minValues 자체는 v0.35.0(core#963)부터 있던 API로 0.36 운영자에게 새 기능이 아닙니다.

v1 마이그레이션 가이드 763줄의 절반은 “필드가 어디로 갔다"는 표라 kubectl apply 실패로 바로 드러납니다. 진짜 위험한 건 매니페스트가 그대로 통과하는데 클러스터가 다르게 행동하는 항목입니다 — 만료된 노드가 대체 없이 드레인을 시작하고, 끄고 있던 drift가 켜지고, 쓴 적 없는 consolidateAfter가 필수가 됩니다.

In-Place Pod Resize (1.35 GA)

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

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이 실제로 하는 일 · 열린 버그 · 케이스별 득실까지 내려갑니다.

배경 — 왜 CAPI in-place를 버리고 blue-green인가

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

배경 — 왜 CAPI in-place를 버리고 blue-green인가

finance EKS 클러스터는 원래 CAPI GitOps로 관리하도록 설계돼 있었습니다. 그런데 조사 시점(2026-07)에 그 설계는 이미 반쯤 무너져 있었습니다. 최초 계획은 CAPI GitOps in-place 업그레이드였지만, 조사 과정에서 진단이 두 번 뒤집힌 끝에 신규 blue 클러스터를 Terraform으로 생성하는 blue-green으로 방향이 굳었습니다. 랜딩이 요약한 이 전환의 근거를 아래 네 포인트로 풀어냅니다.

karpenter — 0.36.2 → 1.14.0, v1beta1→v1 CRD

Tue, 21 Jul 2026 00:00:00 +0900

karpenter — 0.36.2 → 1.14.0, v1beta1→v1 CRD

컨트롤러를 0.36.2에서 최신 stable 1.14.0(2026-07-11 릴리스)로 올립니다. 목표 k8s 1.35를 지원하는 최소가 1.9이고 1.14는 1.30~1.36을 커버하니 “가능한 최신 stable” 방침에 맞습니다 — 1.36으로 재검토할 때도 하한이 1.13이라 1.14.0이 그대로 유효합니다 ✓
넘을 스키마 경계는 v1beta1 → v1 하나뿐입니다. finance의 0.36.2는 이미 v1beta1(karpenter.sh/v1beta1 NodePool·karpenter.k8s.aws/v1beta1 EC2NodeClass)입니다. v1alpha5의 Provisioner·AWSNodeTemplate은 v0.33에서 졸업해 애초에 없습니다 ✓
v1에서 amiSelectorTerms가 필수가 됩니다. 빠뜨리면 EC2NodeClass와 이를 참조하는 모든 NodePool이 통째로 NotReady가 됩니다 ✓
v1은 drift를 GA로 승격시키면서 끄는 수단을 없앱니다. finance가 명시한 featureGates.drift: false는 무효가 되고 drift가 강제로 켜집니다 ✓
blue-green 신규 클러스터라 conversion 웹훅을 왕복하지 않습니다. 기존 클러스터를 in-place로 올릴 때만 밟아야 하는 0.36 → 0.36.9 → 1.0.x → 1.1+ 순차 경로를 건너뛰고 v1 CRD와 v1 매니페스트로 1.14.0을 처음부터 세웁니다 ✓

1. 왜 1.14.0인가

목표 클러스터가 k8s 1.35라서 버전은 거의 정해집니다. karpenter 호환 매트릭스에서 1.35를 받는 최소 버전이 1.9이고 1.14는 1.30~1.36을 커버합니다. “가능한 최신 stable"이라는 방침과 하한 조건이 같은 답을 가리킵니다. 나중에 1.36으로 재검토하더라도 그때의 하한이 1.13이라 1.14.0은 그대로 쓸 수 있습니다.

레이어 2 — 2026-08 열린 4종과 karpenter 가중치

Sat, 15 Aug 2026 00:00:00 +0900

레이어 2 — 2026-08 열린 4종과 karpenter 가중치

실제 후보는 MostAllocated 하나뿐이고 그것도 blue 안정화 이후 별건입니다. create 시점에는 4개 전부 기본값으로 둡니다(§8).
4개가 열렸고 그중 3개는 추가 과금이 없습니다. scoringStrategy·eventTtl·serviceNodePortRange는 k8s 1.31+ 전 리전에서 무료로 쓸 수 있고 HPA syncPeriod만 Provisioned Control Plane(월 증분 +$1,204.50)이 전제입니다.
완전 개방이 아니라 검증된 범위 안의 개방입니다. 범위 폭(HPA 5초 · eventTtl 축소 방향만 · 스케줄러 전략 2종만)이 그대로 AWS의 책임 경계 선언입니다 — 업스트림 kube-controller-manager에는 sync period validation이 아예 없습니다(§2).
karpenter는 이 설정을 읽지 않습니다. karpenter-core v1.14.0 전체에서 scoringStrategy 관련 심볼이 grep 0건입니다. 점수 공식이 각 항을 그 노드 자신의 allocatable로 나누므로 “노드의 cpu/memory 비율에 맞춰 가중치를 조정한다"는 작업은 애초에 필요하지 않습니다(§4).
AWS 문서와 실제가 어긋납니다. User Guide는 Terraform을 “coming soon"이라 쓰지만 provider v6.59.0(발표 당일)에 이미 들어왔고 eksctl·CDK는 반대로 과대 서술입니다(§6).

2026-08-12, EKS가 관리형 컨트롤 플레인 3개 컴포넌트의 파라미터 4종을 고객 설정 대상으로 열었습니다. 지금까지 kube-scheduler·kube-apiserver·kube-controller-manager 설정은 손댈 수 없는 영역이었습니다. 노드를 채워 써서 컴퓨트 비용을 줄이고 싶어도 관리형 스케줄러의 전략을 바꿀 방법이 없었습니다. 목표버전에서 확정한 blue의 목표는 1.35이고 이 4종의 하한은 1.31입니다. blue는 4개를 전부 쓸 수 있는 상태로 태어납니다. 이 페이지는 **“써야 하나”**를 판정합니다. “쓸 수 있나"는 이미 답이 나와 있습니다. 클러스터 레벨 파라미터와 가변성 3분류는 레이어 1, HPA syncPeriod가 요구하는 용량 축은 Provisioned Control Plane, 이번에도 여전히 닫혀 있는 플래그들은 레이어 3이 다룹니다.

CPU Throttling

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

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 사용률 그래프에 나타나지 않아서 몇 시간씩 엉뚱한 곳을 파게 만듭니다. 그래서 이 문서를 따로 두었습니다. 그 상태가 어떻게 만들어지는지, 어떤 지표를 겹쳐 봐야 보이는지, 대응 선택지가 각각 무엇을 대가로 치르는지를 정리합니다.

1.7 → 1.14 — 운영에 쓸 기능들

Thu, 30 Jul 2026 00:00:00 +0900

02 · 1.7 → 1.14 — 지금 켤 만한 것과 미룰 것

1.7 이후 8개 마이너에서 API breaking은 사실상 없습니다. 대신 켜야 비로소 쓸 수 있는 기능이 라벨·feature gate·신규 CRD·IAM 네 층으로 쌓였습니다.
flex 배제는 라벨 한 줄입니다 — karpenter.k8s.aws/instance-capability-flex를 In ["false"]로. DoesNotExist로 쓰면 모든 인스턴스 타입이 배제되어 노드가 하나도 안 뜹니다(§2.2).
기존 NodePool에 배제를 추가하면 떠 있는 flex 노드가 전부 RequirementsDrifted로 교체됩니다. “다음부터"가 아니라 “지금 있는 걸 몰아낸다"입니다.
알람이 에러 없이 깨진 곳이 둘입니다(1.7): karpenter_pods_pods_drained_total → karpenter_pods_drained_total, disrupted_total의 reason liveness → registration_timeout(§3).
업그레이드 자체가 노드를 교체하는 버전도 있습니다 — 1.12는 CA bundle이 drift 해시에 들어가면서 전 노드를 일괄 drifted로 만듭니다(§6.1). 1.8.4는 건너뜁니다(TopologySpreadConstraint(TSC) 회귀, 업스트림이 업그레이드 금지 명시).
1.14 Balanced consolidation은 게이트가 없습니다 — consolidationPolicy: Balanced 한 줄이면 됩니다(§7.2). Capacity Buffers는 alpha 게이트에 신규 CRD까지 필요하고 업스트림 문서가 코드보다 낡았습니다(§7.1).
IAM 권한은 세 번 늘었습니다 — 1.7 iam:ListInstanceProfiles, 1.11 ec2:DescribePlacementGroups, 1.12 ec2:DescribeInstanceStatus(§9).
우리 기준(blue-green으로 0.36.2 → 1.14.0 직행) 판정은 §8.

왜 이 문서인가. 릴리스노트는 “무엇이 머지됐냐"까지만 말합니다. 필요한 구분은 셋 — ① 켜면 이득인 것, ② 설정·권한·CRD를 건드릴 것, ③ 업그레이드 자체가 노드를 교체하는 것. 이 문서는 그 셋으로 1.7~1.14를 나눠 판정합니다.

istio — →1.30.3, sidecar 유지·ambient 금지

Tue, 21 Jul 2026 00:00:00 +0900

istio — →1.30.3, sidecar 유지·ambient 금지

제약(변경 불가): data plane 은 sidecar 유지가 전제입니다. ztunnel/waypoint 기반 ambient mesh 전환은 범위 밖이고 어떤 단계에서도 시도하지 않습니다 ✓
경로는 A(1.35 신규 클러스터 직행)로 확정됐다 — 2026-08-05 의 EKS 1.35 · istio 1.30 결정이 근거입니다. 아래 경로 B 서술은 “왜 안 되는가"의 근거로만 남깁니다 ✓
라이브 버전은 여전히 미확인이지만 경로 A 확정으로 성격이 바뀌었다 — 홉 산정용 blocking 은 아니고 green↔blue values·EnvoyFilter 설정 parity 확인용입니다. 그래도 컷오버 전에 istioctl version 으로 실측은 남깁니다 ?
목표 1.30.3(2026-07-16 릴리스)은 istio.io 최신 stable 이고 지원 k8s 가 1.32~1.36 이라 목표 클러스터 1.35 를 포함합니다 ✓
경로 B(기존 green in-place)로는 1.30.3 에 도달할 수 없다 — istio 1.30 의 k8s 하한이 1.32 인데 green 은 1.31 입니다. green 이 1.31 인 동안 올릴 수 있는 상한은 istio 1.29(지원 1.31~1.35)이고 그마저 EOL 이 ~2026-08 입니다. 1.30.3 은 1.35 신규 클러스터 직행(경로 A)에서만 성립합니다 ✓
native sidecar 전환 시점은 istio 버전이 아니라 노드 kubelet 버전이 정한다 — 기본값은 true 가 아닌 "auto" 이고 전 노드 kubelet ≥1.33 일 때만 켜집니다. 목표 1.35 노드에서는 처음부터 ON 이고 green(1.31)에서는 끝까지 OFF 입니다 ✓
1.29 차트 통합의 리소스 rename 은 우리에게 해당 없을 가능성이 크다 — 코드 대조 결과 istiod 차트는 1.22.0 부터 이미 신 이름(istiod-clusterrole)입니다. 대응은 rename 추적 대신 구 이름 orphan 탐색입니다 ✓
blue-green 신규 클러스터라면 canary 홉 체인 없이 1.30.3 을 처음부터 직행 설치할 수 있습니다 ✓

1. 왜 1.30.3인가

목표 버전은 남은 선택지가 좁아서 사실상 정해집니다. istio 1.24 계열이 지원하는 k8s 는 1.28~1.31 까지라 목표 1.35 에서는 아예 지원 대상 밖입니다. 1.35 를 지원하는 비-EOL 라인은 1.29(k8s 1.31~1.35)와 1.30(k8s 1.32~1.36) 둘뿐인데 그중 1.29 는 EOL 전망이 ~2026-08 입니다. 남는 건 1.30.3 하나입니다. 2026-07-16 릴리스이자 istio.io 최신 stable 이고, 지원 k8s 범위 안에 목표 클러스터 1.35 가 들어옵니다.

목표 버전 — 1.35 판정과 1.36 차단 6종

Tue, 21 Jul 2026 00:00:00 +0900

목표 버전 — 1.35 판정과 1.36 차단 6종

green은 아직 절벽이 아닙니다. 조사 도중 1.31로 in-place가 이미 끝나 있었고 확장지원 종료가 2026-11-26이라 약 4개월 런웨이가 남았습니다.
1.36을 막는 건 6종입니다. Argo CD·argo-rollouts·aws-load-balancer-controller·external-secrets·KEDA·kube-state-metrics가 아직 1.36 지원 릴리스를 내지 않았습니다.
1.35는 유효한 판정입니다. 전 컴포넌트 세트가 공식 지원 릴리스를 갖는 최고 버전이고 ESO EOL 딜레마까지 해소합니다.
kube-proxy nftables는 opt-in 한 줄로 켤 수 있고 목표 버전과 무관합니다. 상세는 03 managed addon.

이 페이지는 finance 워크로드 클러스터가 향할 버전을 확정합니다. 근거는 2026-07-21 시점의 라이브 검증(업스트림 릴리스 노트·aws eks describe-addon-configuration·각 컴포넌트 릴리스 채널)입니다. 왜 blue-green인가는 배경이, 그 버전을 어떤 토폴로지·인프라로 짓는지는 02 클러스터 설정이 다룹니다.

용량 축 — Provisioned Control Plane 티어와 복귀 제약

Sat, 15 Aug 2026 00:00:00 +0900

용량 축 — Provisioned Control Plane 티어와 복귀 제약

finance 판정부터 — 해당 없습니다. XL 최소 증분이 월 +$1,204.50인데, 이걸 켜서 새로 얻는 파라미터는 HPA syncPeriod 하나뿐이고 그 실효마저 metrics-server 스크레이프 간격과 scaleDown stabilization이 상한을 겁니다.
신규 기능이 아닙니다 — 2025-11-21 GA. 2026-08-12 발표는 레이어 2 파라미터 개방입니다. Provisioned CP는 그 발표에서 전제조건으로 언급된 9개월 된 기존 기능입니다.
파는 것은 용량 자체가 아니라 “언제 그 용량이 되는가"입니다. Standard는 APF inflight 상한을 600에서 사후적으로 최대 2000까지 올립니다. Provisioned는 그 점진 증가를 건너뛰고 티어 값을 처음부터 고정 할당합니다.
8XL은 “스케줄링이 더 빠른 티어"가 아닙니다. 파드 스케줄링 처리율이 4XL에서 400/s로 포화하고 8XL도 400/s입니다. 8XL이 늘리는 것은 API 동시성 2배뿐입니다.
Standard 복귀를 막는 조건이 둘인데 서로 다른 문서에 하나씩만 있습니다 — etcd 8GB 초과와 horizontalPodAutoscalerSyncPeriod 비기본값. 한 문서만 읽으면 절반을 놓칩니다.
티어 수치는 보장 처리량이 아닙니다. AWS 표현은 “underlying configuration"이고 APF는 그 위에서 계속 작동합니다. 그래서 티어 선정은 계산이 아니라 측정입니다.

레이어 1이 “클러스터에 어떤 값을 넣을 수 있나"를, 레이어 2가 “컨트롤 플레인 컴포넌트의 동작을 어디까지 바꿀 수 있나"를 다룹니다. 이 페이지는 축이 다릅니다 — 컨트롤 플레인을 얼마나 크게 사느냐입니다. 파라미터 하나를 열려면 이 축을 먼저 정해야 합니다. 그래서 레이어 2의 HPA syncPeriod는 이 페이지를 반드시 거칩니다.

클러스터 설정 — Fargate+karpenter 토폴로지와 Terraform 리소스

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

클러스터 설정 — Fargate+karpenter 토폴로지와 Terraform 리소스

managed nodegroup은 0개입니다. Fargate가 CoreDNS와 karpenter 컨트롤러만 호스팅하고 나머지는 전부 karpenter NodePool(system 풀 포함)이 프로비저닝합니다.
Fargate 3제약이 토폴로지를 지배합니다 — amd64 전용 · DaemonSet 미부착 · 동적 EBS 불가.
Terraform 최대 리스크는 둘입니다. OIDC 이중등록(빠뜨리면 external-secrets 포함 cross-account IRSA 전체가 아무 에러 없이 깨집니다), 그리고 ebs-csi IRSA 롤(스펙에 필드 자체가 없어 놓치기 쉽습니다).
karpenter 인프라 전체(IRSA·노드 롤·interruption·discovery 태그)는 이 레포에 전무해 처음부터 짜야 합니다.

이 페이지는 배경의 결정과 목표버전 1.35 위에서, 클러스터가 무엇인가(토폴로지 + Terraform 리소스)를 다룹니다. “어떤 순서로 올리나"는 04 부트스트랩이, EKS managed addon 버전·설정은 03 managed addon이 이어받습니다.

키워드 레퍼런스 — NodePool로 스케줄링을 통제한다

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

03 · 키워드 레퍼런스 — NodePool 안에서 affinity를 쓴다는 것

Karpenter에는 affinity: 필드가 없습니다. NodePool spec.template.spec.requirements가 node affinity와 같은 문법(NodeSelectorRequirement) 으로 “이 풀이 만들 수 있는 노드의 집합"을 정의합니다. 파드의 nodeSelector·affinity·topologySpread는 그 집합과 교집합을 이룹니다 — 파드 요구는 NodePool 요구의 부분집합이어야 스케줄됩니다.
NodePool이 어떤 well-known 라벨에 requirement를 걸지 않으면 그 축은 클라우드가 파는 모든 값이 허용됩니다. arch·capacity-type·세대처럼 조직 차원에서 강제할 조건을 파드에만 두면 요구를 빠뜨린 워크로드가 무제한 오퍼링을 얻습니다.
연산자는 8개다 — 표준 6개 + Karpenter 확장 Gte/Lte(v1.9.0, core#2674). 이 4개 비교 연산자는 값이 1개인 음이 아닌 정수여야 합니다. 정수로 파싱되지 않는 라벨값에는 매치 자체가 안 됩니다.
preferred는 힌트가 아니다. Karpenter는 preferred affinity를 처음엔 required로 취급하고 실패하면 정해진 순서로 한 겹씩 벗깁니다. 그 순서에서 required nodeAffinity의 OR term 순회가 preferred 제거보다 먼저입니다 — “내가 원한 인스턴스가 왜 안 떴나"의 답이 §3.2다.
topologySpreadConstraint(TSC)의 topologyKey는 AWS에서 zone·hostname·capacity-type 세 개뿐이고 topology.kubernetes.io/region은 미지원입니다. DoNotSchedule은 완화 대상에서 빠집니다. 도메인이 부족하면 그대로 영구 Pending입니다. 그리고 다른 파드가 나에게 걸어둔 preferred anti-affinity는 코드가 의도적으로 추적하지 않아 전혀 반영되지 않습니다.
karpenter.k8s.aws/instance-capability-flex(1.7, aws#8315 → 개명 aws#8490)로 flex를 배제할 때 DoesNotExist를 쓰면 인스턴스 타입 전체가 배제됩니다. 정답은 In ["false"]입니다.
karpenter.sh/capacity-type은 spot/on-demand/reserved 3값이고 reserved가 최우선 소비됩니다. nodeSelector로 on-demand를 정확 일치시킨 워크로드는 On-Demand Capacity Reservation(ODCR) 노드에 절대 안 뜹니다 — nodeAffinity In [on-demand, reserved]로 바꿔야 합니다.
minValues는 NodePool 전용이고 In에서만 값 개수가 검증됩니다. 패밀리를 여러 개 나열해도 minValues가 없으면 스케줄러는 다양성을 강제하지 않습니다 — 스팟 동시 회수 리스크가 이 한 필드로 갈립니다.
교집합이 비면 실패로 끝나지 않고 파드가 Pending으로 남아 백오프 재시도됩니다. 즉 오설정과 일시적 용량 부족이 같은 겉모습을 갖습니다. 구분은 FailedScheduling(파드)·NoCompatibleInstanceTypes(NodePool) 이벤트 메시지로만 가능합니다.

왜 이 문서인가. Karpenter의 스케줄링은 kube-scheduler식 술어 평가가 아니라 “NodePool requirements ∩ 파드 요구 ∩ 클라우드 offering"의 집합 연산이다 — 교집합이 비면 노드가 안 만들어집니다. “파드에 affinity를 걸었는데 노드가 안 뜬다"의 원인은 거의 항상 파드 쪽 요구만 보고 NodePool 쪽 우주를 안 본 데 있습니다. 이 문서는 키워드별 레퍼런스이면서 그 교집합 모델을 축으로 삼습니다.

CPU Burst (커널 5.14)

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

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 커널팀). 이 글은 발표 내용에 커널 동작과 운영 판단을 덧붙여 재구성했습니다.

GitOps — argocd·argo-rollouts

Tue, 21 Jul 2026 00:00:00 +0900

GitOps — argocd·argo-rollouts

argocd(워크로드 spoke): chart 7.5.2(앱 v2.12) → chart 10.1.4(앱 v3.4.5). 현행 2.12는 애초에 목표 k8s 1.35 tested 목록 밖이고 3.4가 v1.32~1.35를 커버하므로 bump가 사실상 필수입니다 — 최대 breaking 구간은 앱 2.14→3.0(logs RBAC 강제, 리소스 추적 label→annotation)입니다 ✓
argo-rollouts: chart 2.37.2(앱 v1.7.1) → chart 2.41.1(앱 v1.9.1). k8s 지원 매트릭스가 없는 tolerant 컴포넌트라 하드 블로커는 아니지만 CVE-2026-35469(HIGH, 원격 DoS) 수정판이라 강력 권장입니다 ✓
argocd와 argo-rollouts는 finance에서 배포 구조가 다릅니다 — argocd는 독립 upstream 차트라 yo-charts 리워크가 필요 없고 argo-rollouts는 umbrella 서브차트라 cluster-bootstrap-v2 umbrella의 Chart.yaml dependency를 고쳐야 합니다 ✓
argo-rollouts는 istio canary 트래픽 라우팅만 씁니다(ALB rollout trafficRouting은 finance 템플릿에 없음) — v1.9.0의 istio DestinationRule/weight 순서 변화가 직접 관련됩니다 ✓

1. argocd(워크로드 spoke) — 7.5.2 → 10.1.4

왜 이 버전인가

대상은 staging-finance-green/prod-finance-green의 워크로드 spoke ArgoCD입니다. ring0 허브(관리) ArgoCD는 이 페이지 범위 밖이지만 허브가 spoke를 배포하는 주체이므로 허브 버전 미확인은 리스크로 남습니다.

레이어 3 — 닫힌 영역과 클러스터 내부 우회

Sat, 15 Aug 2026 00:00:00 +0900

레이어 3 — 닫힌 영역과 클러스터 내부 우회

finance가 실제로 부딪히는 닫힌 항목은 셋입니다 — HPA 스케일다운 안정화 시간, 감사 정책 파일, etcd 스냅샷. 셋 다 클러스터 내부 우회로만 처리합니다.
2026-08에 열린 것은 EKS API 필드 3개 안의 세부 값 4개뿐입니다. kubeApiServerConfig는 하위 필드가 eventTtl·serviceNodePortRange 2개입니다. “이제 apiserver 플래그를 만질 수 있다"는 서술은 이 숫자 하나로 반박됩니다.
열린 값 옆자리가 그대로 닫혀 있습니다. HPA는 --horizontal-pod-autoscaler-sync-period 하나만 열리고 같은 코드 블록의 downscale-stabilization·tolerance·cpu-initialization-period·initial-readiness-delay 4개는 닫혔습니다.
우회 창구는 사실상 3개입니다 — APF(FlowSchema·PriorityLevelConfiguration), 어드미션(웹훅·CEL·Kyverno/OPA), 자체 스케줄러 배포 + schedulerName. 나머지 대부분은 대안이 없습니다.
etcd는 전 구간 차단입니다. 엔드포인트도, compaction·defrag·quota 튜닝도, 스냅샷도 없습니다. 백업은 Velero 같은 API 레벨 도구뿐이고 원자적 시점 복구는 포기해야 합니다.
--force는 PDB·어드미션 웹훅을 우회하지 않습니다. EKS 자체 인사이트 검사만 우회합니다. 전진 업그레이드 쪽 강제는 2025-03-28 임시 롤백된 뒤 재활성화가 확인되지 않아 현재 실질적으로 거의 무효입니다.

이 페이지는 레이어 1의 클러스터 파라미터와 레이어 2의 열린 4종을 전제로 그 여집합을 다룹니다. 무엇을 못 하는가, 못 하는 부분을 클러스터 안에서 어떻게 메우는가. 질문은 이 둘입니다.

인스턴스는 누가 고르는가

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

04 · 인스턴스는 누가 고르는가 — 후보를 넘기고, EC2가 정한다

인스턴스 타입을 확정하는 주체는 Karpenter 스케줄러가 아닙니다. 후보 이름 전체를 node.kubernetes.io/instance-type In [...] 하나로 묶어 NodeClaim에 실어 보냅니다. 타입을 하나로 고정하는 Cluster Autoscaler와 여기서 달라집니다.
최종 선택자는 EC2입니다. provider-aws가 CreateFleet을 Type: instant, On-Demand 할당 전략 lowest-price로 호출합니다. “7세대가 싸서 7세대만 뜬다"의 실제 원인은 이 한 줄입니다.
“후보 절단(600/60) 때문에 8세대가 잘려 나간다"는 흔한 오해이고 사실이 아닙니다. 정렬 키가 그 타입의 최저 오퍼링 가격이라 사이즈에 대해 단조입니다. 잘려 나가는 쪽은 양 세대의 가장 큰 사이즈들입니다.
단일 NodePool 안에는 선호를 표현할 축이 없습니다. requirements 스키마는 Key/Operator/Values/MinValues 넷뿐입니다. weight는 NodePool 레벨에만 있습니다.
minValues는 우선순위 손잡이가 아니라 다양성 하한입니다. 세대 선호에 쓸 수 없을 뿐 아니라 7세대를 후보에 붙들어 두는 역효과를 냅니다.
파드의 preferred nodeAffinity도 대안이 아닙니다. Karpenter의 처리 방식은 “가장 무거운 term 하나를 hard requirement로 승격한 뒤 실패하면 벗기는” 것입니다. 파드마다 걸어야 하고 완화 순서상 네 번째입니다. 벗겨지려면 먼저 스케줄 시뮬레이션이 실패해야 합니다.

c8i/m8i/r8i와 c7i/m7i/r7i를 하나의 NodePool에 함께 선언해 두면 “8세대 우선, 없으면 7세대 폴백"을 기대하게 되는데, 실제로는 항상 7세대만 뜹니다. 범인은 절단·필터·EC2 중 하나입니다. 어느 쪽이냐에 따라 대응책이 완전히 달라지므로 “싼 걸 좋아해서"로는 넘어갈 수 없습니다. 이 문서는 파드가 pending되는 순간부터 EC2가 인스턴스를 띄우는 순간까지 선택이 실제로 일어나는 곳을 코드로 하나씩 지워 갑니다. 흔한 오해 하나(절단이 세대를 자른다)도 명시적으로 깹니다.

Node Problem Detector

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

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

EKS managed addon — 5종 버전·nftables 정정·ebs-csi 연결

Tue, 21 Jul 2026 00:00:00 +0900

EKS managed addon — 5종 버전·nftables 정정·ebs-csi 연결

managed addon은 버전 문자열만 diff합니다 — AWS가 차트를 관리하므로 워크로드 차트 리워크 대상이 아닙니다. 최종 eksbuild suffix는 작업 당일 describe-addon-versions --kubernetes-version 1.35로 확정합니다.
coredns만 하드 blocking입니다(1.35는 v1.14.x 계열만 서빙). kube-proxy는 컨트롤플레인 버전락(v1.35.x), vpc-cni·ebs-csi는 version-agnostic이라 권장 사항입니다.
ebs-csi는 IRSA 롤이 스펙에 없습니다 — 롤 자체는 02 클러스터 설정에서 만들고 여기서는 addon에 연결해 PVC로 검증합니다(최대 리스크).
vpc-cni는 노드 join 전에 반드시 먼저 설치해야 하는 유일한 hard 선행 의존입니다.

클러스터 껍데기를 02 클러스터 설정이 다뤘다면, 이 페이지는 그 위에 올라가는 EKS managed addon 5종의 버전과 성격을 다룹니다(SSOT는 CAPI 스펙의 addons[] 4종 + 콘솔 설치 이력이 있는 amazon-cloudwatch-observability). green은 in-place로 1.31까지 올라와 있지만 blue는 목표값으로 직행 create하므로 green의 현재 addon 값은 이관에 직접 쓰이지 않습니다. 아래는 목표 1.35 기준입니다.

시크릿·오토스케일링 — external-secrets·keda

Tue, 21 Jul 2026 00:00:00 +0900

시크릿·오토스케일링 — external-secrets·keda

external-secrets: 0.9.20 → 2.8.x. 원 조사는 k8s 1.33 기준으로 돌았고 그 기준에서는 EOL 판인 0.19.2가 채택안이었습니다. 상위 목표가 1.35로 상향되면서 최종 목표는 2.8.x로 바뀌었습니다 — k8s 1.35를 지원하는 최신 라인이 여기에 걸리기 때문입니다 ✓
keda: 2.10.2 → 2.20.1. 2.10의 지원 창은 v1.24–v1.26이라 목표 k8s 1.35를 애초에 지원하지 않으니 bump가 사실상 필수입니다. 2.20이 1.35를 상한으로 갖는 라인입니다 ✓
둘 다 blue-green 신규 클러스터라 마이너 체인 없이 목표 버전으로 직행 설치합니다 ✓
두 컴포넌트의 리스크 성격은 크게 다릅니다. external-secrets는 CRD v1beta1→v1 전량 재작성이 필요하고 keda는 CRD apiVersion이 전 구간 불변이라 스키마 이관 부담이 없습니다 ✓

1. external-secrets — 0.9.20 → 2.8.x

왜 이 버전인가

원 조사는 k8s 1.33을 전제로 돌았습니다. 그 전제에서 ESO 0.9.x는 지원 범위 밖입니다 — 0.9.x가 지원하는 k8s는 1.19~1.30까지입니다. 당시 1.33을 지원하는 라인은 0.17/0.18/0.19 셋뿐이었고 셋 다 이미 EOL 상태였습니다. 그래서 원 조사의 채택안은 “1.33 지원 창의 최신"인 0.19.2였습니다. EOL 버전을 운영하는 정책 트레이드오프는 팀 결정 사항으로 남았습니다.

DaemonSet 미기동 노드 격리

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

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 — 노드 단위 조치와 중단 예산

세대 선호 만들기

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

05 · 세대 선호 만들기 — weight vs NodeOverlay

GA 해법은 NodePool을 쪼개고 spec.weight를 줍니다. weight는 가격보다 먼저 적용됩니다 — NodePool을 고르는 코드 경로(scheduler.go addToNewNodeClaim)에는 가격 비교가 아예 없습니다. grep -ic price scheduler.go → 0건.
동작은 “위에서부터 순차 시도"가 아닙니다. NodeClaimTemplate들이 병렬로 시뮬레이션되고 뮤텍스 아래에서 성공한 것 중 인덱스가 가장 앞선(=weight 최고) 것만 채택됩니다.
파드 쪽에는 아무것도 걸지 않습니다. nodeSelector/affinity는 필요 없고 오히려 karpenter.sh/nodepool 셀렉터를 걸면 weight가 통째로 무시됩니다(테스트로 확인됩니다).
NodeOverlay priceAdjustment는 알파입니다. feature gate NodeOverlay가 기본 false입니다. 세대 선호를 실제로 만드는 건 provider-aws가 EC2 Fleet 전략을 prioritized로 바꾸는 지점인데 — 거기에 확인 못 한 구멍이 둘 있습니다(정수 Priority 규정, 단일 CreateFleet 내 폴백 미보장).
오버레이를 쓰지 않는 한, 8세대 복귀 장치는 gen7 풀의 expireAfter 하나뿐입니다. consolidation은 더 싼 쪽으로만 움직이므로 7→8 승격을 절대 하지 않습니다.
적용 순서를 틀리면 대량 교체가 납니다. 기존 단일 풀에서 세대를 빼는 편집은 RequirementsDrifted를 유발합니다. 두 풀을 새로 만든 뒤 기존 풀을 지우는 순서로 갑니다.

“c8i/m8i/r8i를 먼저 쓰고, 없으면 c7i/m7i/r7i로"는 Karpenter가 1급으로 제공하지 않는 요구입니다. requirements 스키마가 Key/Operator/Values/MinValues뿐이어서 선호도를 표현할 필드가 없습니다(04). 업스트림도 두 번 반려했습니다 — karpenter#1829 closed as not planned, karpenter-provider-aws#6721 closed. 남은 두 우회로를 코드까지 비교하고 복붙용 매니페스트 전문을 내놓습니다.

네트워킹·인그레스 — aws-load-balancer-controller

Tue, 21 Jul 2026 00:00:00 +0900

네트워킹·인그레스 — aws-load-balancer-controller

chart 1.8.1(앱 v2.8.x)에서 chart 3.4.2(앱 v3.4.2)로 갑니다. v3.0.0이 chartVersion=appVersion 정렬로 관례를 바꾼 탓에 차트 라인은 1.x에서 곧바로 3.x로 건너뜁니다 — 2.x 차트는 아예 존재하지 않습니다 ✓
목표 k8s 1.35에서 v2.8.x도 동작하므로 하드 블로커는 아닙니다. 그럼에도 ~2년 구버전이라 최신 stable로 올리기를 권합니다 ✓
CRD TargetGroupBinding·IngressClassParams는 storage 버전이 v1beta1로 불변이어서 기존 CR을 변환할 일이 없습니다 ✓
IAM 정책에 8개 액션이 새로 필요합니다. 빠지면 컨트롤러 reconcile 중 AccessDenied로 ALB 갱신이 실패합니다 ✓
finance는 이 컨트롤러를 cluster-bootstrap-v2 umbrella의 서브차트로 배포하므로 독립 bump가 불가능합니다 — umbrella 리워크와 ECR 재퍼블리시가 선행 조건입니다 ✓

1. 왜 chart 3.4.2인가

목표 k8s만 놓고 보면 이 컴포넌트는 급하지 않습니다. 현행 앱 v2.8.x도 1.35에서 동작하므로 하드 블로커가 아닙니다. 그럼에도 손대는 이유는 버전 나입니다 — v2.8.x는 ~2년 구버전입니다. 최신 stable인 chart 3.4.2(앱 v3.4.2)로 올리기를 권합니다.

부트스트랩 오케스트레이션 — 순서·ArgoCD 3-tier·endpoint 재바인딩

Tue, 21 Jul 2026 00:00:00 +0900

부트스트랩 오케스트레이션 — 순서·ArgoCD 3-tier·endpoint 재바인딩

ArgoCD 토폴로지는 3-tier입니다 — 허브가 워크로드 endpoint를 하드코딩해 push하는 tier-1과, 워크로드 자체 ArgoCD가 kubernetes.default.svc로 도는 tier-3은 재지정 부담이 전혀 다릅니다.
metrics-server는 cluster-bootstrap의 raw manifest, kube-state-metrics는 VM 스택 서브차트입니다 — 어떤 ArgoCD 앱 스캔에도 독립 앱으로 안 잡혀 “누락"으로 오독하기 쉽습니다.
워크로드 API endpoint가 8개 매니페스트, 총 19곳에 하드코딩돼 있어 클러스터를 세울 때마다 전량 교체 + cluster secret 재발급이 필요합니다.
부트스트랩은 Fargate 닭-달걀부터 service 배포까지 하나의 마스터 순서로 흐릅니다.

02 클러스터 설정이 클러스터가 무엇인지, 03 managed addon이 EKS addon을 다뤘다면, 이 페이지는 클러스터와 애드온을 어떤 순서로 올리고 어떻게 배선하는지 모읍니다. 여러 곳에 흩어져 있던 순서·인벤토리·endpoint 재바인딩을 여기서 단일 소유합니다.

consolidation이 되돌리는 것

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

06 · consolidation이 되돌리는 것 — 구성해 놓고 나중에 무너지는 경로들

consolidation의 교체 조건은 가격 부등식 하나뿐입니다. launchPrice < candidatePrice — strict라 동가격 교체조차 없습니다. 세대·성능·선호도라는 개념은 disruption 패키지 어디에도 인코딩돼 있지 않습니다.
disruption 패키지는 NodePool weight를 전혀 보지 않습니다. grep -rnE 'Spec\.Weight|OrderByWeight' pkg/controllers/disruption/ → 0건. 코어는 크로스 풀 교체를 막지 않고 정상 경로로 인지합니다.
크로스 풀 다운그레이드는 좁습니다. 대체안 시뮬레이션도 프로비저닝과 같은 weight 정렬 스케줄러를 씁니다. 평상시엔 gen8 풀에서 대체안이 나오고 strict 부등호에 걸려 탈락합니다. gen8 풀이 스케줄에 실패할 때만 gen7이 이깁니다. 그건 gen7을 원하는 상황입니다.
한 번 내려가면 consolidation으로는 안 돌아옵니다. “더 비싼 교체” 분기가 코드에 없습니다. 업스트림 요청도 반려됐습니다(#1829 closed as not planned). 복귀 경로는 expireAfter와 drift입니다 — 둘 다 가격 필터 없이 교체하므로 재스케줄 시 weight 100인 gen8이 다시 먼저 평가됩니다.
weight는 “보장"이 아닙니다 — 공식 문서가 명시합니다. 원인은 단일 프로비저닝 루프 내부의 빈패킹입니다. “이미 떠 있는 노드” 때문이 아닙니다. in-flight NodeClaim은 weight를 보지 않고 파드 수 오름차순으로 정렬됩니다. 거기에 파드를 채우는 시도가 새 NodeClaim 생성보다 먼저 옵니다.
drift는 값 추가엔 침묵하고 값 제거엔 폭발합니다. requirements 판정이 호환성 기반이라 세대 추가는 무해합니다. 풀을 쪼개려고 기존 풀에서 세대를 제거하면 RequirementsDrifted 대량 교체가 시작됩니다. 속도 제어 수단은 disruption.budgets 하나뿐입니다.

왜 이 문서인가. 05의 매니페스트는 적용 순간엔 의도대로 동작합니다. 문제는 그 다음입니다 — Karpenter의 재계산 루프는 “세대"라는 단어를 모릅니다. 이 문서는 며칠~몇 주에 걸쳐 알람 하나 없이 무너지는 경로를 코어 소스에서 짚습니다. 검증 기준: kubernetes-sigs/karpenter v1.14.0-6-gac7a021e(로컬 체크아웃).

관측성 — VM-stack·metrics-server

Tue, 21 Jul 2026 00:00:00 +0900

관측성 — VM-stack·metrics-server·fluentbit·descheduler

victoria-metrics-k8s-stack: chart 0.19.4 → 0.87.0, 68마이너 점프. CRD 관리 스키마가 통째로 개편됩니다. 0.85.0부터는 대시보드/룰을 sync-job이 외부에서 fetch해 적용하는 방식으로 바뀌고 VM 컴포넌트 이미지는 태그를 핀하지 않아 차트만 올려도 몇 년치가 자동으로 점프합니다 ✓
metrics-server: v0.7.2 → v0.9.0. raw manifest로 배포돼 있어 ArgoCD 앱 스캔·Helm 인벤토리 어디에도 잡히지 않습니다(누락이 아니라 배포 방식이 다릅니다) ✓
fluentbit(aws-for-fluent-bit): chart 0.1.34 → 0.2.0. 차트 diff는 사소하지만 이미지 태그를 핀하지 않아 차트 버전 하나 올리는 것이 곧 Fluent Bit 1.9.10→4.2.2·AL2→AL2023 major 점프입니다 ✓
descheduler: 0.28.0 → 0.35.x(원 조사는 1.33 기준 0.33.x). values의 strategies 블록이 v1alpha1 잔재라 지금도 무시되고 있을 가능성이 매우 높습니다 — 그대로 둘지(옵션 A) 원 의도를 복원할지(옵션 B)는 팀이 정해야 합니다 ?
네 컴포넌트 모두 tier-3(kubernetes.default.svc) 배포라 blue-green 신규 클러스터에서 endpoint를 다시 잡을 필요가 없습니다 ✓

1. victoria-metrics-k8s-stack — 0.19.4 → 0.87.0

왜 이 버전인가

chart를 0.19.4에서 0.87.0으로 올립니다. 68마이너 점프입니다. VM 코어(appVersion)는 v1.99.0에서 v1.148.0으로, operator 서브차트는 0.28.에서 0.66.(app v0.73.1)로 함께 대점프합니다.

컷오버·롤백 계약 — ALB 가중치 전환과 되돌리기

Tue, 21 Jul 2026 00:00:00 +0900

컷오버·롤백 계약 — ALB 가중치 전환과 되돌리기

트래픽 전환은 Route53 가중치가 아니라 ALB target group 가중치로 green→blue 이전합니다.
blue·green이 동일 RDS/큐를 공유하므로 트래픽 비율과 무관하게 데이터는 단일 소스입니다(스키마는 backward-compatible 전제).
롤백은 ALB 가중치를 green 100%로 즉시 복귀시키는 일입니다(클러스터 삭제·재배포 아님).
blue 100% + 안정화 관찰을 통과하기 전까지 green은 보존합니다(즉시 롤백 여지).

blue 클러스터의 부트스트랩이 끝난 지점(04 부트스트랩)에서 이어집니다. 여기서는 실제 트래픽을 어떻게 옮기고 문제가 생기면 어떻게 되돌릴지를 계약으로 정합니다. 아래 단계·관찰시간·롤백 기준은 사내 blue-green 방법론의 구조 위에서 짠 권장 기본값이자 예시입니다. 실제 값은 팀 상황에 맞춰 조정합니다.

용량이 없을 때 — ICE와 폴백 지연

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

07 · 용량이 없을 때 — ICE와 폴백 지연

폴백은 이미 공짜입니다. 8세대가 Insufficient Capacity Error(ICE, AWS 응답 코드 InsufficientInstanceCapacity)를 내는 순간 provider-aws가 그 오퍼링을 unavailable로 마킹하고 코어는 Offerings.Available()에서 그 오퍼링을 걸러 다음 루프의 후보에서 뺍니다. 손으로 만들어야 하는 건 “평소엔 8세대"라는 상향 강제뿐입니다.
코어는 ICE 난 NodeClaim을 지우고 재큐하지 않습니다. err를 반환하지도 않으니 controller-runtime 백오프도 안 붙습니다. 재시도는 파드 컨트롤러의 10초 재큐 + 배치창(idle 1s / max 10s)뿐이고 실측 기대치는 대략 11~30초입니다.
ICE 캐시는 3분입니다. 키는 <capacityType>:<instanceType>:<zone>. 부족이 지속되면 3분 주기로 실패 왕복이 반복됩니다. 거꾸로 용량이 회복되면 최대 3분 뒤 8세대가 저절로 부활합니다. 사람이 할 일은 없습니다.
가용성 판정 축은 셋입니다. IsUnavailable()이 보는 것은 오퍼링 캐시 ∨ capacity-type 전체 차단 캐시 ∨ 전 서브넷 차단 캐시의 OR입니다. 서브넷 IP 고갈은 인스턴스 타입과 무관하게 오퍼링을 죽입니다.
spot을 섞으면 세대 강제가 무력화됩니다. capacity-type 우선순위가 reserved > spot > on-demand인데다 spot Fleet은 price-capacity-optimized라 EC2가 용량 깊이로 타입을 고릅니다. 세대 선호가 목적이면 on-demand로 한정하십시오.
단일 NodePool 안에서 알파 없이 8세대를 1순위로 만드는 길은 On-Demand Capacity Reservation(ODCR)입니다. reserved 오퍼링 가격이 odPrice / 10,000,000이라 정렬·절단·Fleet 전부에서 무조건 앞섭니다. 게이트 ReservedCapacity는 기본 ON(BETA)입니다.

“8세대(c8i/m8i/r8i)가 부족하면 7세대로 폴백하고 싶다"에서 폴백 쪽은 이미 동작합니다. ICE를 오퍼링 가용성으로 환산해 스케줄링에 되먹이는 배선이 코어와 provider-aws에 완비돼 있습니다. 이 문서는 그 폴백이 어느 코드에서 몇 초 만에 일어나는지를 끝까지 내려가 01~03에서 고른 구성이 ICE 상황에서 어떻게 행동하는지 확정합니다.

언제 무엇을 멈출 것인가 — disruption 예산

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

08 · 언제 무엇을 멈출 것인가 — disruption 예산 설계

disruption 이유 셋을 나누는 기준은 파드를 옮기느냐입니다. Empty만 안 옮깁니다 — 예산 설계는 여기서 출발합니다.
reasons를 생략한 예산은 셋 모두에 적용됩니다. 피크 차단용 nodes: "0"에 reasons를 안 적으면 빈 노드 정리까지 같이 멈춥니다. 가장 흔한 오설정인데 에러 없이 침묵으로 나타나 발견이 늦습니다.
같은 이유에 예산이 여럿 활성이면 가장 제한적인 값이 이깁니다. 전역 nodes: "1" 하나로 나머지 설계가 전부 무력화될 수 있습니다.
예산이 막는 것은 graceful disruption만입니다. expireAfter 만료·인터럽션·Node Repair는 예산 밖입니다.
nodes: "0"이 막는 것은 실행만입니다. drift 판정과 마킹은 계속 쌓이므로 예산을 푸는 순간 밀린 교체가 한꺼번에 터집니다.
“노드가 안 줄어든다"의 진단 순서는 이벤트 → 예산 → requirements → topology입니다. 예산을 1순위에 두는 이유는 유일하게 시도했다는 증거를 이벤트로 남기기 때문입니다.

왜 이 문서인가. v1에서 drift는 못 끄게 되고 expiration은 forceful로 되돌아갔다(01). 그래서 남은 통제 수단이 사실상 disruption.budgets 하나인데 문법이 짧아 다 이해했다고 착각하기 쉽습니다. 생략된 필드의 기본 해석이 동작의 절반을 결정합니다.

메트릭 수집 비용 — 무엇을 버릴 것인가

Thu, 30 Jul 2026 00:00:00 +0900

10 · 메트릭 수집 비용 — 무엇을 버릴 것인가

비용을 만드는 건 메트릭 60개가 아니라 시리즈 수입니다. 60개 중 파드 단위 6개가 대부분을 차지하고 그 6개만 배포마다 전량 churn합니다.
Datadog은 OpenMetrics로 긁은 것을 전부 custom metric으로 셉니다. 공식 문서 표현이 “all metrics retrieved by the generic Prometheus check are considered custom metrics” 입니다. 아무 설정 없이 붙이면 청구가 튑니다.
OpenMetrics 체크에는 max_returned_metrics 기본 2000 상한이 있습니다. 대규모 클러스터에서는 이 선에서 경고 없이 잘립니다 — 없는 메트릭과 잘린 메트릭이 구분되지 않습니다.
VM에서는 청구가 아니라 indexdb 팽창이 비용입니다. 시리즈 총수가 같아도 churn이 크면 인덱스가 계속 자랍니다.
Prometheus의 보호 장치는 전부 기본으로 꺼져 있습니다 — sample_limit·label_limit·target_limit 기본값이 모두 0(무제한)입니다.
파드 6종을 버려도 잃는 게 거의 없습니다. 파드 단위 상태는 kube-state-metrics가 이미 더 잘 냅니다.
켜기 전에 잽니다. 엔드포인트를 직접 긁으면 백엔드에 아무것도 넣지 않고 시리즈 수를 셀 수 있습니다(§5.1). 붙였다가 줄이는 순서는 Datadog에서 그 달 청구가 이미 발생한 뒤입니다.
drop보다 keep이 낫습니다. 업스트림이 메트릭을 추가하면 blocklist는 그것을 자동으로 통과시킵니다(§4.1).

09가 “무엇이 나오나"라면 여기는 “무엇을 저장할 것인가"입니다 — 60개를 다 긁는 것 자체는 문제가 아니고 비용이 백엔드마다 다른 이름으로 나타나는 게 주제입니다. 카디널리티 폭발의 원리는 VictoriaMetrics / 카디널리티가 소유합니다. 여기서는 그 결과만 다룹니다.

13 · consolidation 후보 선별과 심사

Sun, 02 Aug 2026 00:00:00 +0900

먼저 결론

consolidation은 사용률이 낮은 노드를 골라 지우는 기능이 아닙니다. 후보 선별 → 사유 판정 → 스케줄링 시뮬레이션 → 삭제 또는 교체의 네 단계를 매 라운드 반복하고 단계마다 서로 다른 이유로 후보가 떨어져 나갑니다.
삭제냐 교체냐를 정하는 것은 시뮬레이션 결과입니다. 파드를 전부 다른 노드에 앉힐 수 있으면 삭제, 한 대가 더 필요한데 그게 더 싸면 교체, 두 대 이상 필요하면 아무것도 하지 않습니다.
Balanced는 기존 알고리즘을 대체하지 않습니다. WhenEmptyOrUnderutilized가 만들어 낸 커맨드에 승인 조건을 하나 더 거는 정책이라, 통합이 늘어나는 경우는 없습니다.
Drift는 consolidation과 별개의 disruption method입니다. 정책을 무엇으로 두든 계속 돌고 Balanced의 스코어도 받지 않습니다.
이 글은 코어 v1.14.0 기준입니다. 인용한 코드 위치는 kubernetes-sigs/karpenter 체크아웃(v1.14.0-6-gac7a021e)을 직접 열어 확인했습니다.

1. 전체 처리 흐름

1.1 Disruption Controller 안에서의 위치

consolidation에는 전용 컨트롤러가 없습니다. Disruption Controller 하나가 다섯 개의 method를 등록해 두고 순서대로 물어봅니다.

14 · MultiNode 예산과 전역 후보 탐색

Tue, 04 Aug 2026 00:00:00 +0900

먼저 결론

MultiNode의 disruption budget은 NodePool별로 계산하고 소비합니다.
하지만 후보 탐색에는 NodePool·AZ 경계가 없습니다. 모든 후보를 전역 정렬한 뒤 각 Pool의 budget만큼 남깁니다. 그렇게 섞인 목록의 prefix를 시뮬레이션합니다.
최종 validation은 선택된 커맨드의 안전성만 다시 확인합니다. 전역 prefix 탐색에서 놓친 NodePool/AZ 조합을 찾아 주지는 않습니다.
주된 위험은 budget 위반보다 탐색 누락, Pool 간 간섭, 후보 기회 편향입니다.
이 글은 코어 v1.14.0 체크아웃(v1.14.0-6-gac7a021e)을 기준으로 확인했습니다.

1. 확인하려는 질문

MultiNodeConsolidation.ComputeCommands()는 후보를 전역 정렬한 뒤 disruptionBudgetMapping[candidate.NodePool.Name]을 확인하고 차감합니다.

15 · NodePool별 MultiNode 최소 변경 계획

Tue, 04 Aug 2026 00:00:00 +0900

이 문서의 범위

16 · MultiNode upstream 이슈 조사

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

먼저 결론

이 문제는 AWS provider가 아니라 provider-neutral Karpenter core의 MultiNode 후보 탐색 알고리즘에 있습니다.
논의 장소도 aws/karpenter-provider-aws보다 kubernetes-sigs/karpenter가 맞습니다.
새 Issue는 권장하지 않습니다. 같은 문제를 직접 다룬 #853, #2434, #2814가 이미 있습니다.
현재 기준점은 열린 채 triage/accepted된 **#2434 Multinode consolidation delayed/stuck**입니다.
별도 consolidationCoverage 설정을 앞세우는 것보다 #2434에 재현 사례와 측정값을 추가하고 설정 없는 후보 compatibility 개선을 RFC에서 논의하는 쪽이 upstream 방향과 맞습니다.
조사 기준일은 2026-08-04입니다. Issue 상태와 라벨은 이후 변경될 수 있습니다.

0. 핵심 Issue 네 개를 먼저 비교

항목	NodePool별 필터링과의 거리	현재 진전	역할
#2814 ConsolidationGroup	가장 가까움	종료	구체적인 hard-grouping 해결안
PR #2871 node-group POC	매우 가까움	코드 존재, 정체	label·AZ grouping 실제 구현
#2434 Multinode delayed/stuck	문제 정의가 직접적	Accepted, 구현 없음	canonical root-cause Issue
#3141 priority-scored list	hard filter보다는 heuristic	Accepted, needs-design	가장 활발한 장기 설계

0.1 NodePool별 필터링에 가장 가까운 것

Issue만 비교하면 #2814가 가장 가깝습니다.

무엇을 봐야 하나 — 메트릭·로그·이벤트

Thu, 30 Jul 2026 00:00:00 +0900

09 · 무엇을 봐야 하나 — 메트릭·로그·이벤트

한눈에