eks 클러스터 업그레이드

 

베스천 서버에서 EKS 1.33 → 1.34 업그레이드 하기

EKS 업그레이드를 콘솔이 아니라 베스천 서버에서 AWS CLI로 직접 올린 기록이다. 클러스터 이름은 예시로 k8s-yong, 노드그룹은 ng-al2023, 리전은 서울(ap-northeast-2)로 적었다. 자기 환경 값으로 바꿔 쓰면 된다.

전체 흐름은 간단하다. 사전 점검(특히 DNS) → 컨트롤 플레인 올리기 → 노드그룹 올리기 → 확인. 컨트롤 플레인은 한 번에 한 마이너 버전만 올라가고, 노드는 컨트롤 플레인보다 높을 수 없으니 반드시 컨트롤 플레인을 먼저 올린다.

 

1. 업그레이드 전 상태 점검

제일 먼저 지금 클러스터가 멀쩡한지부터 본다. 특히 DNS(CoreDNS)는 업그레이드 후 제일 잘 터지는 부분이라 미리 확인해두면 나중에 문제가 생겨도 "원래 그랬나?"를 안 헤매게 된다.

CoreDNS 파드가 잘 떠 있는지 확인한다.

kubectl get pods -n kube-system -l k8s-app=kube-dns

 

비정상(Running이 아닌) 파드가 있는지 본다. 업그레이드 전에 이미 죽어 있는 게 있으면 먼저 정리하고 가는 게 좋다.

kubectl get pods -A --field-selector status.phase!=Running

 

CoreDNS 애드온의 현재 상태와 버전을 확인한다.

aws eks describe-addon \
  --cluster-name k8s-yong \
  --region ap-northeast-2 \
  --addon-name coredns \
  --query 'addon.{status:status,version:addonVersion}' \
  --output json

 

그리고 실제로 DNS 해석이 되는지 테스트 파드를 하나 띄워서 확인한다. 이게 되면 클러스터 내부 DNS는 정상이다.

kubectl run dnstest --image=busybox:1.28 --rm -it --restart=Never -- nslookup kubernetes.default

 

 

2. 애드온 호환 버전 확인 (VPC CNI)

컨트롤 플레인을 올리면 VPC CNI 같은 네트워킹 애드온이 새 버전과 안 맞을 수 있다. 올릴 버전(1.34) 기준으로 어떤 vpc-cni 버전을 써야 하는지 미리 조회해둔다.

aws eks describe-addon-versions \
  --region ap-northeast-2 \
  --addon-name vpc-cni \
  --kubernetes-version 1.34 \
  --query 'addons[0].addonVersions[0].addonVersion' \
  --output text

여기서 나온 버전이 1.34에서 권장되는 vpc-cni 버전이다. 현재 버전과 차이가 크면 업그레이드 후 이 버전으로 애드온도 올려주면 된다.

 

3. VPC CNI 설정 점검 (aws-node)

VPC CNI(aws-node)가 IRSA(IAM 역할)나 환경 변수 설정을 쓰고 있는 경우, 업그레이드 과정에서 이 설정이 유지되는지 확인해두면 안전하다. 혹시 나중에 애드온을 재설치하거나 덮어쓸 때 이 값들을 다시 넣어야 할 수도 있어서, 미리 기록해두는 용도다.

aws-node 서비스어카운트의 annotation(IRSA 역할 연결)을 확인한다.

 

kubectl get serviceaccount aws-node -n kube-system -o yaml | grep -A3 annotations

aws-node 데몬셋에 어떤 환경 변수가 설정돼 있는지 이름만 뽑아본다.

 

kubectl get daemonset aws-node -n kube-system -o jsonpath='{.spec.template.spec.containers[0].env[*].name}'

여기 나온 env 이름들(예: 커스텀 네트워킹, prefix 위임 관련 설정 등)을 기록해두면, 나중에 설정이 초기화돼도 그대로 복원할 수 있다.

 

4. 컨트롤 플레인 업그레이드 (1.33 → 1.34)

점검이 끝났으면 컨트롤 플레인부터 올린다. 이건 AWS가 알아서 처리하고, 실행 중인 앱에는 영향이 없다. 다만 완료까지 10~15분쯤 걸리니 그동안 새 배포는 피하는 게 좋다.

aws eks update-cluster-version \
  --name k8s-yong \
  --region ap-northeast-2 \
  --kubernetes-version 1.34

 

명령을 넣으면 업그레이드가 시작된다. 진행 상태와 버전을 확인한다. status가 ACTIVE, version이 1.34로 바뀌면 컨트롤 플레인은 끝이다.

aws eks describe-cluster --name k8s-yong --region ap-northeast-2 --query 'cluster.{version:version,status:status}' --output json

상태가 UPDATING이면 아직 진행 중이니 ACTIVE가 될 때까지 기다렸다가 다음 단계로 간다.

 

5. 노드그룹 업그레이드 (1.33 → 1.34)

컨트롤 플레인이 1.34 ACTIVE가 됐으면 이제 노드를 같은 버전으로 맞춘다. 관리형 노드그룹이라 AWS가 롤링 방식으로 새 노드를 띄우고, 파드를 옮긴 뒤 옛 노드를 종료한다. 이 과정에서 노드가 새 인스턴스로 통째로 교체된다.

aws eks update-nodegroup-version \
  --cluster-name k8s-yong \
  --nodegroup-name ng-al2023 \
  --region ap-northeast-2 \
  --kubernetes-version 1.34 \
  --force

여기서 --force 옵션을 붙였는데, 이건 PodDisruptionBudget(PDB) 때문에 파드가 잘 안 빠져서(drain 실패) 업그레이드가 멈추는 걸 방지하려고 강제로 진행하는 옵션이다. PDB가 빡빡하게 걸린 워크로드가 있으면 --force 없이는 노드그룹 업데이트가 중간에 멈출 수 있다. 다만 강제로 파드를 내리는 만큼, 순단이 민감한 서비스가 있으면 이 옵션 사용은 신중히 판단한다.

 

6. 노드 확인

노드그룹 업데이트가 끝나면 노드가 새 버전으로 올라왔는지 확인한다.

kubectl get nodes

VERSION 열이 전부 v1.34로 바뀌었고 STATUS가 Ready면 업그레이드 성공이다. 노드 수와 인스턴스 타입에 따라 교체에 몇 분에서 수십 분 걸리니, 아직 옛 버전 노드가 보이면 조금 더 기다렸다가 다시 확인하면 된다.

 

 

업그레이드 끝난 뒤 꼭 챙길 것

노드가 새 인스턴스로 교체되면서 몇 가지 뒷정리가 필요하다. 이걸 놓치면 업그레이드는 됐는데 접속이 안 되는 상황이 생긴다.

노드에 고정 IP(탄력적 IP)를 쓰고 있었다면 교체되면서 떨어져 나가니, 새 노드의 primary ENI(디바이스 인덱스 0)에 다시 연결한다. 노드 on/off 자동화(Lambda 등)가 인스턴스 ID나 ASG 이름을 참조하고 있으면 새 값으로 갱신한다. 그리고 옛 노드에 있던 파드가 Error나 Completed로 남는데, 이건 앱 문제가 아니라 잔재이니 아래 명령으로 정리하면 된다.

 

kubectl delete po --field-selector status.phase=Failed
kubectl delete po --field-selector status.phase=Succeeded

 

 

정리

베스천에서 CLI로 올릴 때 핵심은 세 줄이다. update-cluster-version으로 컨트롤 플레인, update-nodegroup-version으로 노드그룹, 그리고 kubectl get nodes로 확인. 나머지는 전부 이 세 줄을 안전하게 감싸는 사전 점검과 사후 정리다. 특히 DNS 테스트는 업그레이드 전에 꼭 한 번 돌려두자. 나중에 문제가 생겼을 때 "원래 되던 거였는지"를 알 수 있는 기준점이 된다.