Ops Insights – 컴포넌트별 마이그레이션

karpenter — 0.36.2 → 1.14.0, v1beta1→v1 CRD

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

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은 그대로 쓸 수 있습니다.

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

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

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 가 들어옵니다.

GitOps — argocd·argo-rollouts

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

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를 배포하는 주체이므로 허브 버전 미확인은 리스크로 남습니다.

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

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

시크릿·오토스케일링 — 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 버전을 운영하는 정책 트레이드오프는 팀 결정 사항으로 남았습니다.

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

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

네트워킹·인그레스 — 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)로 올리기를 권합니다.

관측성 — VM-stack·metrics-server

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

관측성 — 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)로 함께 대점프합니다.