makgol's note – 이관 절차

배경 — 왜 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으로 방향이 굳었습니다. 랜딩이 요약한 이 전환의 근거를 아래 네 포인트로 풀어냅니다.

목표 버전 — 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 클러스터 설정이 다룹니다.

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

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 기준입니다.

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

컷오버·롤백 계약 — 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 방법론의 구조 위에서 짠 권장 기본값이자 예시입니다. 실제 값은 팀 상황에 맞춰 조정합니다.