EKS 운영 노트

청사진
검증Before plan

EKS로 옮기면 무엇이 좋아지는가?

비용 절감 가설보다 운영 선택지 가설을 먼저 세운다

근원 질문 ECS Fargate 대비 Karpenter 가설 운영 증명

여기서 틀어지면 뒤의 모든 구현이 "그럴듯한 도구 붙이기"가 된다. EKS의 이득은 단순 비용보다 GitOps, 보안 경계, 스케줄링, 관측성, 장애 실험을 직접 설계할 수 있다는 점에 있다.

ECS Fargate 대비 EKS가 진짜 해결한 것 정리 중

가설Fargate보다 싸서가 아니라 운영 정책을 직접 설계하고 증명하기 위해 EKS를 쓴다.

비용 절감운영 선택지플랫폼 역량

주의RDS 커넥션, DB 병목, 컨트롤플레인 고정비는 EKS가 자동으로 해결하지 않는다.

비용 분석 노드 경제학 Phase3 전체상

Karpenter는 비용 절감 도구인가 정책 실행기인가? 정리됨

가설Spot 80%로 싸게 쓰자는 말은 반만 맞다. 실제 핵심은 워크로드 등급별 배치 정책이다.

스팟 절감운영등급 배치피크 대응

주의Monitoring, controller, mesh는 앱과 같은 Spot 풀에 태우면 운영 도구가 먼저 흔들릴 수 있다.

Karpenter 현실 보정 Karpenter intake Spot 흐름

Karpenter controller 위치는 왜 중요한가? 코드 보강

가설controller는 노드 공급자이므로, Karpenter가 만든 app/spot 노드 위에 올리면 자기 자신을 관리하는 구조가 된다.

아무 노드app Spotmanaged system node

교훈평소엔 멀쩡해 보여도 spot 회수, consolidation, controller 재시작 때 복구 주체가 같이 흔들릴 수 있다.

Karpenter 현실 보정 Karpenter intake 책임 경계

Karpenter 한계를 넘으면 무엇이 병목인가? 검증 필요

가설노드가 늘어도 RDS 커넥션, DB 처리량, 결제/주문 직렬화 구간은 자동으로 해결되지 않는다.

노드 증설DB scale-up대기열/백프레셔

교훈Karpenter는 피크를 흡수하는 좋은 도구지만, 비용 상한과 외부 병목을 넘는 순간 서비스 정책이 필요하다.

노드 경제학 Karpenter 보정

preflight · 가설이 약하면 구현보다 질문을 먼저 고치기

현실
소유권terraform plan

코드가 같은 현실을 보고 있는가?

state, backend, VPC tag 같은 "실행 전 검산" 영역

실수성 이슈 state / backend VPC tag 변경량 검산

이 단계 문제는 난이도보다 파괴력이 크다. 해결은 어렵지 않아도, 놓치면 Terraform이 현실을 다르게 해석한다.

기존 EKS/VPC를 새로 만들려 함 해결됨

등급중요한 운영 난제라기보다 preflight 실수. 하지만 apply 전에 못 잡으면 위험하다.

로컬 stateremote backend 수정import

선택S3 backend bucket/key를 팀 state에 맞추고 state list로 검산.

State 경계 VPC 구조

Public subnet discovery tag 누락 해결됨

증상LBC가 internet-facing ALB용 subnet을 못 찾을 수 있음.

수동 태그Terraform subnet tagsALB 직접 생성

교훈Ingress 문제처럼 보여도 씨앗은 VPC 태그 설계에 있다.

VPC 구조 책임 경계

검산 · 변경량이 이상하면 여기서 멈추기

접근과
권한terraform apply

팀이 같은 클러스터를 운영할 수 있는가?

RBAC, EKS access entry, IRSA, Secret 원본의 경계

팀 blocker EKS access IAM / IRSA Secrets

권한은 문제 원인이면서 해결 경로다. 빠른 CLI 수습과 Terraform 영속 조치 중 무엇을 선택했는지가 팀 운영 원칙을 드러낸다.

kubectl 접근 실패 해결됨

증상클러스터는 떠 있는데 팀원이 조회/수정 불가.

aws cli 즉시 부여Terraform access entryaws-auth 수동 수정

선택팀 단위 재현성이 중요해서 IaC로 관리.

EKS Access 도구 책임

보안 강화가 적용 지점을 늘림 일부 정리

증상SA, role, trust policy, ExternalSecret 중 하나라도 빠지면 앱 설정 실패.

K8s Secret민감도별 ESO전면 Secrets Manager

교훈오버헤드가 아니라 체크리스트지만 도입 시점은 판단해야 함.

IRSA Secret Tradeoff

공개 레포 보안과 팀 사용성이 충돌함 기준 필요

증상AWS 계정 ID, role ARN, bucket 이름을 숨기면 안전하지만 팀원이 그대로 쓰기 어려워짐.

전부 변수화전부 하드코딩민감도 기준 분리

선택실제 secret은 숨기고, 팀 재현성에 필요한 식별자는 문서/변수 경계를 명확히 하는 방향.

Secrets 책임 경계

권한 확인 · kubectl, IRSA smoke test, state 확인

플랫폼
부팅bootstrap helm

YAML이 실제 동작으로 바뀌는가?

controller, CRD, 노드 용량, storage, service mesh의 운영 표면

핵심 난이도 Karpenter Monitoring Istio Ambient

이 단계부터 EKS가 어려워진다. 파일이 있어도 controller가 없으면 아무 일도 안 하고, controller가 있어도 IAM/SG/용량이 맞지 않으면 현실이 안 된다.

NodeClaim은 생기는데 Ready가 안 됨 일부 해결

증상EC2는 보이지만 클러스터 join이 안정적이지 않음.

인스턴스 확대SG 수동 수정IAM/SG/tag 순차 진단

교훈Karpenter는 AWS 권한, 네트워크, 스케줄링이 만나는 경계.

Karpenter Autoscaler

Karpenter controller가 app 노드로 갈 수 있음 보강 필요

증상 후보초기에는 managed node에 뜨지만, NodePool 생성 후 재시작되면 배치 제약이 없어 app/spot 노드로 갈 수 있다.

운 좋게 동작장애 후 발견nodeSelector로 고정

다음 조치managed node group에 system 라벨을 붙이고, Karpenter Helm values에서 controller placement를 고정한다.

Karpenter 책임 경계

Monitoring stack Pending / Timeout 일부 해결

증상kube-prometheus-stack 설치가 장시간 대기.

timeout 증가노드만 키움EBS CSI + 용량 + 권한

교훈관측성 자체도 무거운 플랫폼 워크로드다.

Observability Storage

Istio Ambient는 필수 경로인가 실험 경로인가? 검증 필요

정리Phase 3 필수 경로는 Karpenter/monitoring/ALB-TGB/ArgoCD다. Istio는 sidecar 없는 mTLS와 민감 경로 보호를 검증하는 실험 경로다.

1.35 인증서Ambient 제한 실험NetworkPolicy 축소

대전제1.35 Pod Certificates는 인증서 발급/회전 기반이고, Istio는 mTLS 실행·L7 정책·telemetry까지 맡는다. 서로 완전 대체 관계가 아니다.

교훈1.35는 방향 기준, 1.32는 검증 환경. 복잡도가 이득을 넘으면 NetworkPolicy/management port로 축소한다.

Waypoint mTLS 정책 작성법

bootstrap은 수동 1회인가 자동화 대상인가? 방향 정리

고민로컬 Mac 기준 스크립트는 빠르지만, 팀 공유와 OS 차이를 생각하면 실행 환경이 흔들릴 수 있다.

Terraform Helm provider수동 1회 bootstrapGitHub Actions

선택destroy/apply가 잦은 실습 단계에서는 수동 1회가 단순하고, 이후 표준화되면 CI 실행으로 승격.

Bootstrap 도구 책임

Karpenter 난이도가 갑자기 뛴 이유 정리됨

원인커뮤니티 모듈 없이 직접 구성했고, 여기에 Istio, IRSA, monitoring이 동시에 얹히며 경계가 겹쳤다.

모듈 사용직접 구성하며 학습스택 축소

교훈한 도구의 문제가 아니라 AWS IAM, SG, CRD, controller, workload 등급이 동시에 얽힌 복합 문제였다.

Karpenter 보정 IRSA Waypoint

operation-strix는 왜 같은 문제를 안 겪었나 분석됨

차이operation-strix는 terraform-aws-modules/eks/aws//modules/karpenter 커뮤니티 모듈을 썼다. 이 모듈은 cluster SG에 karpenter.sh/discovery 태그를 자동 부착하고, Karpenter 릴리즈와 동기화된 IAM 권한 목록을 번들로 가진다.

커뮤니티 모듈 신뢰직접 구성

직접 구성 시 함정cluster SG discovery 태그 수동 추가 (aws_ec2_tag), v1 신규 IAM 권한(Instance Profile CRUD) 별도 파악 필요.

비교 포인트operation-strix: Karpenter 0.37.0 + EKS Access Entry / pposiraegi: Karpenter v1.x + aws-auth.

Karpenter 보정 IRSA

두 AI 도구 병렬 작업 — 파일 경계가 없으면 충돌한다 메타 인사이트

상황Claude Code(Terraform·IAM)와 Codex(k8s manifests)가 같은 브랜치에서 동시 작업. waypoint.yaml을 양쪽에서 수정해 infrastructure.replicas 필드를 한쪽이 제거하고 다른 쪽이 복구하는 충돌 발생.

한 도구만 사용파일 영역 분리커밋 후 교대

원칙병렬 사용할 때는 Terraform은 A 도구, manifests는 B 도구처럼 파일 소유권을 먼저 나눠야 한다.

책임 경계

apply/bootstrap/destroy가 한 사이클이 됨 정리됨

상황Terraform destroy만 하면 끝날 줄 알았지만, ArgoCD self-heal, Karpenter replacement, PDB drain, PVC/EBS 잔여 리소스가 따로 움직였다.

수동 기억pre-destroy 루프잔여 리소스 점검

교훈EKS Day-2 운영은 생성보다 종료 순서에서 더 많은 controller 충돌이 드러난다.

Day-2 운영 루프 Karpenter 책임 경계

관측 · pod, pvc, nodeclaim, controller logs 확인

런타임
증명ArgoCD sync

선언이 실제 앱 동작으로 이어지는가?

GitOps 기준점과 앱 런타임 계약을 검증하는 단계

운영 증명 branch drift probe image/config

마지막 단계에서는 "고쳤는데 왜 안 바뀌지?"와 "떴는데 왜 죽지?"가 갈린다. 여기서부터는 배포 자동화보다 앱과 플랫폼 사이의 계약이 핵심이다.

ArgoCD branch drift 해결됨

증상main에 고쳤는데 클러스터에 반영되지 않음.

kubectl 직접 적용targetRevision 정렬임시 branch 운영

교훈GitOps에서 branch도 인프라 계약이다.

CI/CD 책임 경계

/actuator/health CrashLoop 재검증 필요

증상probe 실패로 Pod 반복 재시작.

probe 제거path만 변경앱/이미지/매니페스트 계약 정렬

교훈probe는 앱과 플랫폼 사이의 런타임 계약.

Health/Metric CI/CD

ALB 유지와 LBC 전환 사이에서 외부 트래픽 소유권이 흔들림 방향 정리

증상Terraform ALB는 있는데 Kubernetes Service와 연결할 다리가 없고, LBC Ingress를 바로 붙이면 ALB가 두 개 생긴다.

Terraform ALB 유지TargetGroupBinding조건부 LBC Ingress

교훈현재는 ALB를 유지하고 TGB로 api-gateway Service에 연결한다. Rollouts canary나 다중 path가 필요해질 때 LBC Ingress로 전환한다.

ALB vs LBC LBC intake 책임 경계

terraform destroy 완료 · 다음 배포에서 무엇을 먼저 고쳐야 하는가

미결·
복구 계획next deploy

오늘 해결 못한 것을 다음 배포에서 잠근다

destroy 후 재설계 포인트 — 코드 1줄짜리 fix부터 설계 결정까지

미해결 Karpenter node join monitoring waypoint 검증

문제를 발견하고 원인을 파악했다는 것이 이미 절반이다. 다음 terraform apply에서 아래 항목을 순서대로 잠그면 오늘의 루프가 끊긴다.

Karpenter 노드 join 실패 — cluster SG 미부착 수정 대기

원인EC2NodeClass의 securityGroupSelectorTerms가 cluster SG를 선택하지 못함. 태그가 없어서.

FixTerraform에 한 줄 추가:

resource "aws_ec2_tag" "cluster_sg_discovery" {
  resource_id = var.cluster_security_group_id
  key         = "karpenter.sh/discovery"
  value       = var.cluster_name
}

왜 충분한가EC2NodeClass selector가 tag 기반이므로 이 태그 하나로 cluster SG가 자동 포함됨. EC2NodeClass/nodepool.yaml 수정 불필요.

Karpenter

monitoring stack — EBS CSI → gp3 → 설치 순서 재설치 필요

전제 조건Karpenter 노드 join이 먼저 성공해야 PVC가 bind됨. 노드 없이 설치하면 Grafana/Prometheus PVC가 또 Pending.

노드 join 확인 후 설치--only monitoring

순서① cluster SG fix apply → ② bootstrap --from karpenter → ③ NodeClaim Ready 확인 → ④ bootstrap --only monitoring

Observability Monitoring intake

waypoint.yaml — infrastructure.replicas 실제 검증 다음 배포에서 확인

논쟁Claude Code 세션에서 제거, Codex 세션에서 복구. Gateway API v1.2.0 + Istio 1.22+ 기준 GEP-1645로 유효하다는 주장이 있다.

제거(안전)kubectl explain으로 확인 후 결정

검증 명령kubectl explain gateway.spec.infrastructure → 필드 있으면 유지, 없으면 제거.

Waypoint

다음 배포 preflight 체크리스트 정리됨

Terraform apply 전

☐ cluster SG에 karpenter.sh/discovery 태그 (aws_ec2_tag)
☐ IRSA 역할 4개: EBS CSI, LBC, ESO, Loki
☐ EBS CSI addon
☐ gp3 StorageClass (storageclass-gp3.yaml)
☐ private subnet에 karpenter.sh/discovery 태그

bootstrap 실행 전

☐ Gateway API CRD v1.2.0 설치 확인
☐ kubectl explain gateway.spec.infrastructure
☐ NodeClaim Ready 후 monitoring 진행