AWS EKS 의 경우, Kubernetes 버전이 정식 Release 이후 약 1년 동안 Support 해준다.
위와 같이 Extended support 라 하여 기존 Support 에 Extended Support 기간 1년을 지원해준다. 하지만, 안정적으로 Standard Support 받기 위해서는 기한 내에 Cluster의 Kubernetes 버전을 최신으로 업데이트 하는 것이 좋다.
마이너 버전은 출시 후 처음 14개월 동안은 표준 지원(Standard Support) 하에서 저렴한 비용(클러스터 하나에 시간당 $0.10)으로 이용이 가능하다. 그러나 해당 버전의 표준 지원이 종료된 이후에는 자동으로 다음 12개월 동안 추가 지원(Extended Support)을 받게 되는데, 이때는 더욱 비싼 비용으로 클러스터 하나에 시간당 $0.60, 한화 약 826원)을 지불해야 한다. 그리고 추가 지원마저 종료된 다음에는 클러스터가 현재 추가 지원되는 버전 중 가장 오래된 버전으로 자동 업그레이드 된다.
클러스터의 버전이 자동으로 업그레이드되면 기업에서 운영하는 서비스가 일시적으로 중단될 위험이 있기 때문에 이러한 강제 버전 업그레이드 혹은 비싼 추가 지원을 피하기 위해서는 표준 지원 종료일을 미리 파악하고 버전 업그레이드를 위한 준비 작업을 할 필요가 있다.
지금부터 EKS 1.31v에서 1.32v로 Upgrade하는 과정과 겪었던 이슈를 기록하려고 한다. 빼먹은 부분과 실수한 부분이 있을수도 있으니 참고만 하길 바란다.
작업은 총 세가지로 분류하였다. Add-ons 업데이트, 클러스터 업데이트, 노드 업데이트 이렇게 진행하였다.
1. Add-ons
추가 기능탭에서 간단하게 진행할 수 있다. Add ons 버전이 맞지 않으면 대시보드 클러스터 업그레이드 인사이트에 경고 또는 Error를 볼 수 있다.
Add ons 버전업을 하는 경우 각 클러스터 버전에 맞는 버전으로 진행해야한다. 예를 들어 VPC CNI 의경우 해당 v1.19-2의 버전을 따라야한다. AWS 공식 문서에 포함되어 있으니 Add-ons에 맞게 확인하여 진행해야 한다.
VPC CNI https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/managing-vpc-cni.html\
Kube Proxy https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/managing-kube-proxy.html
CoreDNS https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/managing-coredns.html
다음 처럼 버전을 지정하여 저장하면 Upgrade가 진행된다.
각 Add-ons들에 대해 작업이 만료되었다면 EKS Cluster Upgrade를 진행하도록 하자.
Cluster 는 한번에 여러 단계를 업데이트 하지 못하며, 한 단계 씩 업데이트 해야 한다. 업데이트 버튼을 누르면 업데이트가 진행되고 이 프로세스는 약 25분 정도 소요된다 . Control Plane 업그레이드 프로세스 중에 클러스터를 계속 사용할 수 있어, 기존 서비스는 계속 사용 가능하지만, 사소한 서비스 중단이 발생할 수 있음을 인지하자.
참고로 클러스터 버전 업그레이드는 취소할 수 없으며 이전 버전을 원하는 경우 새 클러스터를 생성해야한다는 것도 인지하면 좋을 것 같다.
다음은 노드 그룹 버전을 올린다.
콘솔에서 업데이트 버튼을 통해 진행하는 것이 가장 간단하지만 노드를 순차적으로 업데이트하면서 서비스 중단이 발생하기 때문에 필자는 새로운 노드 그룹을 만들고 기존 파드를 모두 추출하여 새 노드 그룹으로 이사시키는 방향으로 진행했다.
노드 그룹에 베이스가 되는 시작 템플릿을 생성할 때 AWS Community AMI에서 공식적으로 제공되는 AMI 릴리즈 버전을 사용하여도 상관없다.
하지만 필자의 경우는 시작 템플릿에 인스턴스 유형, 키 페어, Securiy Group 정도만 설정하고 빈 템플릿을 만들었다. 이 과정에서 사실 실수가 있었기에 확인하는 과정을 거치면서 시작 템플릿을 다음 처럼 만든것이였다.
처음 작업할때는 amazon-eks-node에 대한 최신 AMI를 지정하여 시작 템플릿을 구성하였는데, CA(Cluster Autoscaler )Pod 배포가 계속 실패하는 과정을 겪었다.
Cluster Autoscaler pod fails with error "MissingRegion"
다음과 같은 오류가 떨어지면서 실패하여 다양한 방법을 시도하였다. 리전 설정이 되어있지 않은 것인가 해서 CA yaml 설정 파일에 명시적으로 지정하는 작업도 진행했다. 하지만 오류는 동일했다.
Cluster Autoscaler github issue로 올라온 동일한 이슈 글이 있었고 이를 참고하여 해결할 수 있었다.
https://github.com/kubernetes/autoscaler/issues/7389
원인은 아직 파악이 되지 않지만 단순히 AMI type을 AL2_x86_64으로 지정했다.
기본으로 AL2023_x86_64_STANDARD로 선택되니 주의하도록 하자.
이렇게 노드 그룹 생성이 완료되었다면 파드를 이관하는 작업을 진행 해야한다.
작업은 간단히 Cordon과 Drain, 노드 라벨링 등을 활용하였다.
Cordon
- 특정 노드를 스케줄러에서 제외시켜 파드가 할당되지 않도록 함
- 기존에 노드에 배포된 파드는 그대로 남아있음
- 적용
kubectl cordon [노드_이름]- 해제
kubectl uncordon [노드_이름]
Drain
- 특정 노드를 스케줄러에서 제외시켜 파드가 할당되지 않도록 하고, 기존에 배포된 파드를 다른 노드로 이동시킴
- 노드를 업데이트하는 경우 활용 가능
- 적용
-
kubectl drain [노드_이름] --delete-emptydir-data --ignore-daemonsets --force
필자의 경우는 Cordon으로 파드 배포를 막고 노드의 라벨링을 추가하여 새로 배포하는 방향으로 진행하였다.
이 과정에서 aws-load-balancer-controller 파드 배포가 다음과 같이 실패하는 과정을 겪었다.
해결은 단순히 vpc id를 지정해주고 aws-load-balancer helm repo를 최신으로 업데이트하여 upgrade를 진행하였다.
helm list -n kube-system
helm repo update
helm upgrade aws-load-balancer-controller eks/aws-load-balancer-controller -n kube-system --set clusterName={cluster-name} --set serviceAccount.create=false --set serviceAccount.name=aws-load-balancer-controller --set region=ap-northeast-2 --set vpcId={vpc id}
위와 같이 클러스터 및 노드, 애드온 업그레이드 작업을 진행하였지만 무중단으로 EKS 클러스터 버전을 어떻게 자연스럽고 매끄럽게 진행할 수 있을까 고민이 되었다.
무중단으로 EKS 클러스터 버전 업그레이드하기 - 블럭스 매거진
성공적인 업그레이드를 위한 단계별 가이드 | 기술 이야기
blog.blux.ai
해당 포스팅에서는 새로운 클러스터를 만들고 트래픽을 신규 클러스터로 점진적으로 전환하는 단계를 거치는 방법을 설명해주고 있다. 이를 참고하여 내가 가진 환경에서 어떻게 블루그린 방향으로 업그레이드를 진행할 수 있을지 고려해보면 좋을 것 같다.
'IT' 카테고리의 다른 글
| 쿠버네티스 파드 네트워킹 (0) | 2025.02.26 |
|---|---|
| 쿠버네티스[EKS] gp2, gp3 마이그레이션 (0) | 2025.02.25 |
| 쿠버네티스[EKS] SecurityGroupPolicy (0) | 2025.02.20 |
| 쿠버네티스[EKS] IRSA(IAM for ServiceAccount) (0) | 2025.02.20 |
| 스프링부트 Virtual Thread, Spring Data Redis(Lettuce) 도입기 (0) | 2025.01.09 |
