EKS Upgrade 1.22 -> 1.23 version

고객이 현재 데브옵스가 없는 상태에서 eks 업그레이드를 해야하는 상황이라 도움을 요청했다.
 
요청이 들어온김에 겸사겸사 정리한다.
EKS Upgrade는 생각보다 간단하며 심지어 무중단이다.
 
EKS Upgrade는 총 2가지 방법이 있다.
 
1. 싱글 클러스터
2. 멀티 클러스터
 
싱글 클러스터 특징
 

1. 하나의 클러스터를 롤링 업데이트 처럼 업그레이드
2. 버전을 한번에 하나씩만 업그레이 가능 (1.22 -> 1.24 -> 1.25)
3. 무중단이며 따로 생성할게 없어 기존 시스템을 크게 변경하지 않아도 된다.
4. 노드 그룹과 cordon,drain,asg로 무중단 업그레이드 가능 하다
5. 생각보다 쉽지만 롤백은 불가능

 
멀티 클러스터

1. 블루/그린과 같이 구/신 버전 생성 후 트래픽을 한번에 신 버전으로 변경
2. 버전을 한번에 여러 단계를 넘어 업그레이드 가능하다.
3. 앞단에 트래픽 조절을 위한 시스템은 필수고 트래픽 조절만 잘하면 무중단도 가능하다.
4. 기존의 내부 시스템 버전도 한번에 업그레이 가능하다.
5. 롤백가능 하지만 업그레이드 시 2배의 리소스, 비용이 사용된다.

필자의 고객은 현재 데브옵스가 없으므로 싱글클러스터로 진행했다.
 
주의 사항은 버전마다 호환성을 체크해야한다
아래와 같이 1.23부터는 ebs csi가 설치어 있지않다면 pv들은 마운트가 되지 않는 오류가 생길것이다.
이러한 버전마다 바뀌는 주의 사항들을 꼭 확인해야한다

 
Control Plane 업그레이드는 aws 매니지드에서 관리 해주는 서비스이기 떄문에 딱히 해줄게 없다 .
그냥 AWS EKS 콘솔 상에서 업그레이드 하기를 클릭하면 끝이다.
 
다음은 worker node upgrade이다.
 

위에서 언급했듯이 worker node upgrade 전에 1.22 -> 1.23 같은 경우는 ebs csi controller가 필수로 설치되어야한다.

ebs csi controller는 add-on에서 쉽게 설치 가능하지만 irsa는 따로 생성해줘야한다

 

아래 공식 문서를 확인하면 쉽게 irsa 생성 가능하며 정책 또한 기존에 있기 때문에 그대로 사용하면된다.

https://docs.aws.amazon.com/eks/latest/userguide/csi-iam-role.html

 

eksctl create iamserviceaccount \
  --name ebs-csi-controller-sa \
  --namespace kube-system \
  --cluster my-cluster \
  --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
  --approve \
  --role-only \
  --role-name AmazonEKS_EBS_CSI_DriverRole

 

 csi가 제대로 설치 되었다면 worker node upgrade 또한 eksctl 명령어로 간단하게 업그레이 가능하다.

해당 명령어로 노드그룹 이름 확인
eksctl get nodegroup --cluster <cluster name>

해당 명령어로 Worker node 업그레이드
eksctl upgrade nodegroup \
    --name=<node-group-name> \
    --cluster=<cluster-name> \
    --kubernetes-version=1.23

 
해당 명령어를 통해 업그레이드 되는 과정은 아래와 같다.

1. 노드 그룹과 연결된 Auto Scaling 그룹의 새 Amazon EC2 시작 템플릿 버전을 생성
2. EC2 시작 템플릿으로 Auto Scaling 그룹 업데이트
3. NodeGroup의 최대 크기 또는 원하는 크기 중 더 큰 값으로 증가
4.  pods를 drain하고 60초 동안 컨트롤러가 이 노드에 새 요청을 보내지 않고 활성 노드 목록에서 이 노드를 제거
5. 노드를 하나씩 줄여 업데이트가 시작되기 전의 값으로 돌아갑니다.

 
 
여기서 중요한점은 Add on 기능들은 워커노드 업그레이드가 아닌 따로 업그레이드 해야하며 업그레이드 중 drain을 과정에서 업그레이드 가 실패하는경우가 있다.
 
업그레이드 해야할 Add on 기능 - VPC CNI Plugin, CoreDNS, KubeProxy
아래와 같은 명령어로 Add on까지 업그레이드 해줘야한다.

kube-proxy 업그레이드
eksctl get addon --name kube-proxy --cluster eks-demo

eksctl update addon \
  --name kube-proxy \
  --version v1.23.13-eksbuild.2 \
  --cluster eks-demo \
  --force
  
 CoreDNS 업그레이드
 eksctl get addon --name coredns --cluster eks-demo
 
 eksctl update addon \
  --name coredns \
  --version v1.23.13-eksbuild.x \
  --cluster eks-demo \
  --force
  
 VPC CNI Plugin 업그레이드
 eksctl get addon --name vpc-cni --cluster
 
 eksctl update addon \
  --name vpc-cni \
  --version 1.11.4-eksbuild.1 \
  --cluster eks-demo \
  --force

 
업그레이드 중 drain을 과정에서 업그레이드 가 실패하는경우 공식문서에서는 아래와 같이 설명했다.
 

1. Aggressive PDB(PodDisruptionBudget)
   PDB의 minAvailable필드 값이 0보다 큰 경우처럼 Healthy한 POD 개수가 반드시 보장되어야 하기 때문에 Eviction이 실패할 수 있게 된다.
2. 모든 Taint를 허용하는 Deployment tolerating
   이전 Worker Node는 Taint 되었기 때문에 POD가 스케줄링 될 수 없습니다.
   하지만 어떤 Deployment의 Tolerations이 모든 Taint를 허용하는 경우, 이전 Worker Node에 스케줄링 되어  노드가 비어 있지 않을 가능성이 높아져 포드 제거 실패로 이어진다.

 ---

필자가 맡은 고객은 업그레이드 시 ebs csi와 irsa가 제대로 생성했음에도 파드가 정상적으로 생성되지 않는 오류가 발생했었다.

Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 2m58s default-scheduler Successfully assigned kasten-io/catalog-svc-7ff7779b75-kmvsr to tkg-wld-01-md-0-54598b8d99-rpqjf
Warning FailedMount 55s kubelet Unable to attach or mount volumes: unmounted volumes=[catalog-persistent-storage], unattached volumes=[k10-k10-token-lbqpw catalog-persistent-storage]: timed out waiting for the condition

 

위와 같은 에러가 발생했었고 찾아보니 볼륨이 2개의 파드에 연결되어 파드를 삭제해보면 된다했지만 해결하지 못했다.

 

그래서 볼륨에 스냅샷을 뜨고 재생성하려 스냅샷 crd, 컨트롤러를 생성했지만 아래처럼 정상적으로 생성 안되고

readytouse에 상태가 없이 생성됐다

 kubectl get volumesnapshot imported-aws-snapshot
NAME                    READYTOUSE   SOURCEPVC   SOURCESNAPSHOTCONTENT           RESTORESIZE   SNAPSHOTCLASS   SNAPSHOTCONTENT                 CREATIONTIME   AGE
imported-aws-snapshot   true                     imported-aws-snapshot-content   1Gi           ebs-csi-aws     imported-aws-snapshot-content   33m            60s

파드에 로그를 보니 권한이 없다는 문제를 확인하고 ebs-csi 로그 또한 확인해보니 detach 되었다는 로그를 발견하고 csi를 rollout 시키니 그제서야 볼륨과 스냅샷 모두 정상적으로 작동 되었다.

 

즉 irsa를 연결해서 권한 설정을해도 ebs-csi에 제대로 연결되었는지 확인할 필요가 있다.

 

참조
https://docs.aws.amazon.com/eks/latest/userguide/update-managed-node-group.html
https://jonnung.dev/kubernetes/2022/12/18/upgrade-aws-eks-kubernetes-version/#gsc.tab=0