Ops Insights – EKS 버전 업그레이드

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

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

레이어 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이 갖습니다.

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

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

배경 — 왜 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 +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은 그대로 쓸 수 있습니다.

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

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

레이어 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이 다룹니다.

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

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

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

목표 버전 — 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 +0000

용량 축 — 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 +0000

클러스터 설정 — 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이 이어받습니다.

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

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

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

레이어 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종을 전제로 그 여집합을 다룹니다. 무엇을 못 하는가, 못 하는 부분을 클러스터 안에서 어떻게 메우는가. 질문은 이 둘입니다.

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

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

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 +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)로 올리기를 권합니다.

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

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

부트스트랩 오케스트레이션 — 순서·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 재바인딩을 여기서 단일 소유합니다.

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

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

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

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

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

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