[EKS] 클러스터 업그레이드 모범 사례
Amazon EKS 업그레이드 모범사례를 정리하고 최신 Kubernetes로 안전하게 전환하고 클러스터 안정성을 높이는 전략을 확인하였습니다.
![[EKS] 클러스터 업그레이드 모범 사례](https://images.unsplash.com/photo-1694734260233-d5dc5ae02593?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDd8fGJlc3QlMjBwcmFjdGljZXxlbnwwfHx8fDE3NDcxMzc3ODh8MA&ixlib=rb-4.1.0&q=80&w=1200)
개요
해당 문서에서는 Amazon EKS 업그레이드 전략을 계획하고 실행하는 방법을 정리하였습니다.
자체 관리형 노드, 관리형 노드 그룹, Karpenter 노드 및 Fargate 노드를 업그레이드하는 방법도 설명합니다. 하지만 EKS Anywhere, 자체 관리형 Kubernetes, AWS Outposts 또는 AWS Local Zones에 대한 가이드는 포함하지 않습니다.
EKS v1.30에서 v1.31로 업데이트를 진행하며 있었던 간단한 내용 또한 추가로 정리하였습니다.
모범 사례
업그레이드 전 확인 사항
Amazon EKS에서 Kubernetes 버전을 업그레이드하려는 경우 업그레이드를 시작하기 전에 마련해야 하는 몇 가지 중요한 정책, 도구 및 절차가 있습니다.
- 사용 중단 정책 이해 - Kubernetes 사용 중단 정책의 작동 방식을 심층적으로 이해합니다. 기존 애플리케이션에 영향을 미칠 수 있는 예정된 변경 사항에 유의하십시오. 최신 버전의 Kubernetes는 종종 특정 APIs 및 기능을 단계적으로 폐지하여 애플리케이션 실행에 문제를 일으킬 수 있습니다.
- Kubernetes 변경 로그 검토 - Amazon EKS Kubernetes 버전과 함께 Kubernetes 변경 로그를 철저히 검토하여 워크로드에 영향을 미칠 수 있는 변경 사항 중단과 같이 클러스터에 미칠 수 있는 영향을 파악합니다.
- 클러스터 추가 기능 호환성 평가 - Amazon EKS는 새 버전이 릴리스되거나 클러스터를 새 Kubernetes 마이너 버전으로 업데이트한 후 추가 기능을 자동으로 업데이트하지 않습니다. 추가 기능 업데이트를 검토하여 업그레이드하려는 클러스터 버전과 기존 클러스터 추가 기능의 호환성을 이해합니다.
- 컨트롤 플레인 로깅 활성화 - 컨트롤 플레인 로깅을 활성화하여 업그레이드 프로세스 중에 발생할 수 있는 로그, 오류 또는 문제를 캡처합니다. 이러한 로그에서 이상이 있는지 검토하는 것이 좋습니다. 비프로덕션 환경에서 클러스터 업그레이드를 테스트하거나 자동화된 테스트를 지속적 통합 워크플로에 통합하여 애플리케이션, 컨트롤러 및 사용자 지정 통합과의 버전 호환성을 평가합니다.
- 클러스터 관리를 위한 eksctl 살펴보기 - eksctl을 사용하여 EKS 클러스터를 관리하는 것이 좋습니다. 컨트롤 플레인을 업데이트하고, 추가 기능을 관리하고, 작업자 노드 업데이트를 즉시 처리할 수 있는 기능을 제공합니다. out-of-the-box
- Fargate에서 관리형 노드 그룹 또는 EKS 선택 Fargate에서 EKS 관리형 노드 그룹 또는 EKS를 사용하여 작업자 노드 업그레이드를 간소화하고 자동화합니다. 이러한 옵션은 프로세스를 간소화하고 수동 개입을 줄입니다.
- kubectl 변환 플러그인 활용 kubectl 변환 플러그인을 활용하여 다양한 API 버전 간에 Kubernetes 매니페스트 파일을 쉽게 변환할 수 있습니다. 이렇게 하면 구성이 새 Kubernetes 버전과 호환되도록 할 수 있습니다.
클러스터 Up-to-date를 유지하기 위한 전략
EKS 버전 지원 정책:
- 지원 버전 수: Amazon EKS는 일반적으로 3개의 활성 쿠버네티스 마이너 버전을 동시에 지원합니다. (쿠버네티스 커뮤니티 정책과 유사)
- 지원 기간:
- 표준 지원: 특정 마이너 버전이 EKS에 출시된 후 처음 14개월 동안 제공됩니다.
- 연장 지원: 표준 지원(14개월)이 종료된 후 추가 12개월 동안 제공됩니다. (즉, 총 26개월의 수명 주기)
- 지원 종료 공지: 표준 지원 종료일 최소 60일 전에 해당 버전의 지원 중단(deprecation)이 공지됩니다.
- EKS 버전 수명 주기 문서를 참고하세요.
자동 업그레이드 정책:
- 업그레이드 권장: 사용자는 EKS 클러스터의 쿠버네티스 버전을 최신 상태로 유지하는 것이 좋습니다.
- 자동 업그레이드 조건: 클러스터가 실행 중인 쿠버네티스 버전이 총 지원 기간(26개월 = 표준 14개월 + 연장 12개월)을 모두 소진하면, EKS는 해당 클러스터를 다음 지원 버전으로 자동 업그레이드합니다.
- 참고: 연장 지원은 비활성화할 수 있으며, 이 경우 표준 지원(14개월) 종료 후 자동 업그레이드 대상이 될 수 있습니다.
- 추가 지원을 비활성화 항목을 참고하세요
- 자동 업그레이드 영향: 사용자가 버전 지원 종료 전에 직접 클러스터를 업그레이드하지 않으면, 자동 업그레이드가 예기치 않게 발생하여 워크로드 및 시스템 운영에 중단을 초래할 수 있습니다.
추가적인 내용은 EKS 버전 FAQs에서 확인할 수 있습니다.
ControlPlane 변경 사항을 사전에 추적하고 해결하는 방법
클러스터 인사이트
aws eks list-insights --region <region-code> --cluster-name <my-cluster>
Cluster Insights는 EKS 클러스터를 최신 버전의 Kubernetes로 업그레이드하는 기능에 영향을 미칠 수 있는 문제에 대한 조사 결과를 제공하는 기능입니다.
이러한 결과는 Amazon EKS에서 큐레이션 및 관리하며 문제 해결 방법에 대한 권장 사항을 제공합니다. Cluster Insights를 활용하면 최신 Kubernetes 버전으로 업그레이드하는 데 드는 노력을 최소화할 수 있습니다.
Kube-no-trouble
Kube-no-trouble은 명령이 있는 오픈 소스 명령줄 유틸리티입니다. 현재 KubeConfig 컨텍스트를 사용하여 클러스터를 스캔하고 사용 중단 및 제거될 APIs가 포함된 보고서를 인쇄합니다.
kubent
4:17PM INF >>> Kube No Trouble `kubent` <<<
4:17PM INF version 0.7.0 (git sha d1bb4e5fd6550b533b2013671aa8419d923ee042)
4:17PM INF Initializing collectors and retrieving data
4:17PM INF Target K8s version is 1.24.8-eks-ffeb93d
4:l INF Retrieved 93 resources from collector name=Cluster
4:17PM INF Retrieved 16 resources from collector name="Helm v3"
4:17PM INF Loaded ruleset name=custom.rego.tmpl
4:17PM INF Loaded ruleset name=deprecated-1-16.rego
4:17PM INF Loaded ruleset name=deprecated-1-22.rego
4:17PM INF Loaded ruleset name=deprecated-1-25.rego
4:17PM INF Loaded ruleset name=deprecated-1-26.rego
4:17PM INF Loaded ruleset name=deprecated-future.rego
__________________________________________________________________________________________
>>> Deprecated APIs removed in 1.25 <<<
------------------------------------------------------------------------------------------
KIND NAMESPACE NAME API_VERSION REPLACE_WITH (SINCE)
PodSecurityPolicy <undefined> eks.privileged policy/v1beta1 <removed> (1.21.0)
EKS 컨트롤 플레인 업그레이드 전 필수 확인 사항:
EKS 클러스터의 컨트롤 플레인을 성공적으로 업그레이드하려면 AWS 계정에 다음과 같은 리소스 및 권한이 준비되어 있어야 합니다. 부족할 경우 업그레이드가 실패할 수 있습니다.
1. 사용 가능한 IP 주소:
- 필요: 클러스터 업데이트 과정에서 EKS가 사용할 수 있는 최대 5개의 여유 IP 주소가 클러스터에 지정된 서브넷 내에 있어야 합니다.
- 조치: 만약 IP 주소가 부족하다면, 업그레이드를 시작하기 전에 여유 IP가 있는 새 서브넷을 클러스터 설정에 추가해야 합니다.
2. EKS IAM 역할:
- 확인: 클러스터 컨트롤 플레인이 사용하는 IAM 역할이 계정에 여전히 존재해야 합니다.
- 권한: 해당 역할에 필요한 AWS 권한이 올바르게 부여되어 있는지 확인해야 합니다.
3. AWS KMS 키 사용 권한 (조건부):
- 조건: 이 항목은 클러스터에서 보안 암호 암호화(Secret Encryption) 기능을 AWS KMS를 사용하여 활성화한 경우에만 해당됩니다.
- 권한 확인: 클러스터 IAM 역할이 암호화에 사용되는 AWS KMS 키에 접근하고 사용할 수 있는 권한을 가지고 있는지 확인해야 합니다.
4. Smileshark Cluster 접근 권한
- 확인: 클러스터 컨트롤 플레인에 접근할 수 있는 권한이 필요합니다.
- EKS Access Policy 접근을 위해 EKS API를 구성하여 접근해야합니다.
- 역할을 등록하여 EKS 접근이 가능하며 해당 명령을 입력하면 context로 등록됩니다.
aws eks update-kubeconfig --region ap-northeast-2 --name my-cluster --role-arn arn:aws:iam::111122223333:role/MyEksAccessRole
클러스터 업그레이드 순서
클러스터를 업그레이드하려면 다음 작업을 수행해야 합니다.
- Kubernetes 및 EKS 릴리스 정보를 검토합니다.
- 클러스터를 백업합니다(선택 사항).
- 워크로드에서 더 이상 사용되지 않거나 제거된 API 사용량을 식별하고 해결합니다.
- 관리형 노드 그룹을 사용하는 경우 관리형 노드 그룹이 컨트롤 플레인과 동일한 Kubernetes 버전에 있는지 확인합니다.EKS 관리형 노드 그룹 및 EKS Fargate Profiles를 통해 생성된 노드는 컨트롤 플레인과의 버전 호환성 정책을 따릅니다.예를 들어 설명하면 다음과 같습니다.
- 컨트롤 플레인의 쿠버네티스 버전이 1.27 이하일 경우, 컨트롤 플레인 버전보다 최대 2개 낮은 마이너 버전의 노드 버전과 호환됩니다.
- 컨트롤 플레인 버전이 1.28 이상부터는, 컨트롤 플레인 버전보다 최대 3개 낮은 마이너 버전의 노드 버전과 호환됩니다.
- EKS 컨트롤 플레인 버전이 1.28인 경우, 노드 버전은 1.25까지 사용 가능합니다 (즉, 1.28, 1.27, 1.26, 1.25 버전 노드와 호환됩니다).
- EKS 컨트롤 플레인 버전이 1.27인 경우, 사용 가능한 가장 오래된 노드 버전은 1.25입니다 (즉, 1.27, 1.26, 1.25 버전 노드와 호환됩니다).
- AWS 콘솔 또는 cli를 사용하여 클러스터 컨트롤 플레인을 업그레이드합니다.
- 추가 기능 호환성을 검토합니다. 필요에 따라 Kubernetes 추가 기능 및 사용자 지정 컨트롤러를 업그레이드합니다.
- kubectl을 업데이트합니다.
- 클러스터 데이터 영역을 업그레이드합니다. 노드를 업그레이드된 클러스터와 동일한 Kubernetes 마이너 버전으로 업그레이드합니다.
eksctl 을 사용하는 경우
- 컨트롤 플레인을 업데이트하고, 추가 기능을 관리하고, 작업자 노드 업데이트를 즉시 처리할 수 있는 기능을 제공합니다.
https://eksctl.io/usage/nodegroup-managed/#upgrading-managed-nodegroups
eksctl get nodegroup --cluster bjchoi-seoul-eks-2025-05-01 --profile smileshark
업그레이드 전 클러스터 백업
Kubernetes의 새 버전은 Amazon EKS 클러스터에 중요한 변경 사항을 도입합니다. 클러스터를 업그레이드한 후에는 다운그레이드할 수 없습니다. 따라서 클러스터 백업을 자체적으로 진행해야하며 Velero는 이를 수행할 수 있는 오픈소스 프로젝트 입니다.
Karpenter 관리형 노드에 대한 노드 만료 활성화
Karpenter는 ttlSecondsUntilExpired 설정을 통해 노드 업그레이드를 자동화하는 방법을 제공하며, 이는 수동 업그레이드 계획의 필요성을 줄여줍니다.
- 자동 만료 및 교체:
- Karpenter 프로비저너(Provisioner) 설정에서
ttlSecondsUntilExpired값을 초 단위로 지정하면 노드 자동 만료 기능이 활성화됩니다. - 노드가 설정된 수명에 도달하면, Karpenter는 해당 노드를 만료(expire)시킵니다.
- 만료된 노드는 현재 사용 중이더라도 안전하게 파드(Pod)를 다른 노드로 이동시키는 드레이닝(draining) 과정을 거친 후 삭제됩니다.
- 삭제된 노드를 대체하기 위해 Karpenter는 최신 EKS 최적화 AMI(Amazon Machine Image) 를 사용하는 새 노드를 자동으로 프로비저닝합니다. 이 과정을 통해 자연스럽게 노드가 최신 상태로 업그레이드됩니다.
- Karpenter 프로비저너(Provisioner) 설정에서
- 장점:
- 주기적인 노드 자동 교체를 통해 업그레이드를 자동화하여 관리 부담을 줄일 수 있습니다.
- 주의사항:
- 동시 만료 위험: Karpenter는 만료 시간에 임의의 시간차(지터, jitter)를 자동으로 추가하지 않습니다. 따라서 여러 노드가 비슷한 시점에 생성된 경우, 동시에 만료되어 워크로드에 과도한 중단을 초래할 수 있습니다.
- 워크로드 보호: 이러한 동시 중단을 방지하려면, Kubernetes의 포드 중단 예산(Pod Disruption Budget, PDB) 을 설정하여 애플리케이션의 최소 가용성을 보장하는 것이 중요합니다.
- 적용 범위: 프로비저너에
ttlSecondsUntilExpired를 설정하면, 해당 프로비저너를 통해 새로 생성되는 노드뿐만 아니라 기존에 관리되던 노드들에도 이 만료 정책이 적용됩니다.
아래 Graceful Methods를 참고
Karpenter 관리형 노드에 Drift 기능 사용
Karpenter의 드리프트(Drift) 기능은 Karpenter가 관리하는 노드들이 사용하는 AMI(Amazon Machine Image) 버전이 EKS 컨트롤 플레인 버전과 달라지는 상황(드리프트)을 자동으로 감지하고 해결하여, 노드를 항상 최신 상태로 유지하도록 돕습니다.
- 주요 기능 및 목적:
- EKS 컨트롤 플레인과 노드 간의 버전 불일치(드리프트)를 자동으로 감지합니다.
- 주로 EKS 클러스터 업그레이드 후, 기존 노드들이 이전 버전의 EKS 최적화 AMI를 사용할 때 이 기능이 유용합니다.
- 드리프트가 감지된 노드를 자동으로 최신 버전의 AMI를 사용하는 새 노드로 교체하여 동기화를 유지합니다.
- 작동 방식:
- 감지: EKS 클러스터 업그레이드 완료 후, Karpenter는 이전 버전 AMI를 사용하는 노드를 식별합니다.
- 자동 교체:
- 해당 노드를 코딩(Cordon) 하여 더 이상 새 파드가 스케줄링되지 않도록 합니다.
- 노드 위의 파드들을 안전하게 다른 곳으로 드레이닝(Drain) 합니다.
- 기존 노드를 삭제하고, 현재 컨트롤 플레인 버전에 맞는 최신 EKS 최적화 AMI를 사용하는 새 노드로 교체(Replace) 합니다.
- 활성화:
- 현재(제공된 정보 기준) 드리프트 기능은 기본적으로 비활성화되어 있으며, 기능 게이트(feature gate) 설정을 통해 명시적으로 활성화해야 합니다.
- 권장 사항 및 고려사항:
- 파드 리소스 요청: Karpenter는 노드를 교체하기 전에 이동해야 할 파드들의 리소스 요청(requests)을 기반으로 필요한 새 노드를 미리 준비합니다. 따라서 파드의 리소스 요청을 정확하게 설정하는 것이 중요합니다.
- 포드 중단 예산 (PDB): 노드 드레이닝은 계획된 중단이므로, Kubernetes 모범 사례에 따라 포드 중단 예산(PDB) 을 설정하여 애플리케이션의 최소 가용성을 보장해야 합니다. Karpenter는 PDB 제약 조건을 준수하며 노드를 교체합니다.
다음 문서를 참고하세요.
- https://aws.amazon.com/ko/blogs/tech/how-to-upgrade-amazon-eks-worker-nodes-with-karpenter-drift/
- https://karpenter.sh/docs/concepts/disruption/