Ops Insights – Karpenter

0.36 → 1.6 — v1 전환과 그 직후

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

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가 필수가 됩니다.

1.7 → 1.14 — 운영에 쓸 기능들

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

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를 나눠 판정합니다.

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

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

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 쪽 우주를 안 본 데 있습니다. 이 문서는 키워드별 레퍼런스이면서 그 교집합 모델을 축으로 삼습니다.

인스턴스는 누가 고르는가

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

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가 인스턴스를 띄우는 순간까지 선택이 실제로 일어나는 곳을 코드로 하나씩 지워 갑니다. 흔한 오해 하나(절단이 세대를 자른다)도 명시적으로 깹니다.

세대 선호 만들기

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

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. 남은 두 우회로를 코드까지 비교하고 복붙용 매니페스트 전문을 내놓습니다.

consolidation이 되돌리는 것

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

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(로컬 체크아웃).

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

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

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 +0000

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 +0000

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 +0000

먼저 결론

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 +0000

먼저 결론

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 +0000

이 문서의 범위

16 · MultiNode upstream 이슈 조사

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

먼저 결론

이 문제는 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 +0000

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

한눈에