bj.choi - notes

[EKS] 클러스터 업그레이드 모범 사례

Updated:

Amazon EKS 업그레이드 모범사례를 정리하고 최신 Kubernetes로 안전하게 전환하고 클러스터 안정성을 높이는 전략을 확인하였습니다.

개요

해당 문서에서는 Amazon EKS 업그레이드 전략을 계획하고 실행하는 방법을 정리하였습니다.

자체 관리형 노드, 관리형 노드 그룹, Karpenter 노드 및 Fargate 노드를 업그레이드하는 방법도 설명합니다. 하지만 EKS Anywhere, 자체 관리형 Kubernetes, AWS Outposts 또는 AWS Local Zones에 대한 가이드는 포함하지 않습니다.

EKS v1.30에서 v1.31로 업데이트를 진행하며 있었던 간단한 내용 또한 추가로 정리하였습니다.

모범 사례

업그레이드 전 확인 사항

Amazon EKS에서 Kubernetes 버전을 업그레이드하려는 경우 업그레이드를 시작하기 전에 마련해야 하는 몇 가지 중요한 정책, 도구 및 절차가 있습니다.

클러스터 Up-to-date를 유지하기 위한 전략

EKS 버전 지원 정책:

  1. 지원 버전 수: Amazon EKS는 일반적으로 3개의 활성 쿠버네티스 마이너 버전을 동시에 지원합니다. (쿠버네티스 커뮤니티 정책과 유사)
  2. 지원 기간:
    • 표준 지원: 특정 마이너 버전이 EKS에 출시된 후 처음 14개월 동안 제공됩니다.
    • 연장 지원: 표준 지원(14개월)이 종료된 후 추가 12개월 동안 제공됩니다. (즉, 총 26개월의 수명 주기)
  3. 지원 종료 공지: 표준 지원 종료일 최소 60일 전에 해당 버전의 지원 중단(deprecation)이 공지됩니다.
    1. EKS 버전 수명 주기 문서를 참고하세요.

자동 업그레이드 정책:

  1. 업그레이드 권장: 사용자는 EKS 클러스터의 쿠버네티스 버전을 최신 상태로 유지하는 것이 좋습니다.
  2. 자동 업그레이드 조건: 클러스터가 실행 중인 쿠버네티스 버전이 총 지원 기간(26개월 = 표준 14개월 + 연장 12개월)을 모두 소진하면, EKS는 해당 클러스터를 다음 지원 버전으로 자동 업그레이드합니다.
    • 참고: 연장 지원은 비활성화할 수 있으며, 이 경우 표준 지원(14개월) 종료 후 자동 업그레이드 대상이 될 수 있습니다.
    • 추가 지원을 비활성화 항목을 참고하세요
  3. 자동 업그레이드 영향: 사용자가 버전 지원 종료 전에 직접 클러스터를 업그레이드하지 않으면, 자동 업그레이드가 예기치 않게 발생하여 워크로드 및 시스템 운영에 중단을 초래할 수 있습니다.

추가적인 내용은 EKS 버전 FAQs에서 확인할 수 있습니다.

ControlPlane 변경 사항을 사전에 추적하고 해결하는 방법

클러스터 인사이트

Notion Image
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 주소:

2. EKS IAM 역할:

3. AWS KMS 키 사용 권한 (조건부):

4. Smileshark Cluster 접근 권한

클러스터 업그레이드 순서

클러스터를 업그레이드하려면 다음 작업을 수행해야 합니다.

  1. Kubernetes 및 EKS 릴리스 정보를 검토합니다.
  2. 클러스터를 백업합니다(선택 사항).
  3. 워크로드에서 더 이상 사용되지 않거나 제거된 API 사용량을 식별하고 해결합니다.
  4. 관리형 노드 그룹을 사용하는 경우 관리형 노드 그룹이 컨트롤 플레인과 동일한 Kubernetes 버전에 있는지 확인합니다.EKS 관리형 노드 그룹 및 EKS Fargate Profiles를 통해 생성된 노드는 컨트롤 플레인과의 버전 호환성 정책을 따릅니다.예를 들어 설명하면 다음과 같습니다.
    • 컨트롤 플레인의 쿠버네티스 버전이 1.27 이하일 경우, 컨트롤 플레인 버전보다 최대 2개 낮은 마이너 버전의 노드 버전과 호환됩니다.
    • 컨트롤 플레인 버전이 1.28 이상부터는, 컨트롤 플레인 버전보다 최대 3개 낮은 마이너 버전의 노드 버전과 호환됩니다.
  1. AWS 콘솔 또는 cli를 사용하여 클러스터 컨트롤 플레인을 업그레이드합니다.
  2. 추가 기능 호환성을 검토합니다.  필요에 따라 Kubernetes 추가 기능 및 사용자 지정 컨트롤러를 업그레이드합니다.
  3. kubectl을 업데이트합니다.
  4. 클러스터 데이터 영역을 업그레이드합니다. 노드를 업그레이드된 클러스터와 동일한 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 설정을 통해 노드 업그레이드를 자동화하는 방법을 제공하며, 이는 수동 업그레이드 계획의 필요성을 줄여줍니다.

  1. 자동 만료 및 교체:
    • Karpenter 프로비저너(Provisioner) 설정에서 ttlSecondsUntilExpired 값을 초 단위로 지정하면 노드 자동 만료 기능이 활성화됩니다.
    • 노드가 설정된 수명에 도달하면, Karpenter는 해당 노드를 만료(expire)시킵니다.
    • 만료된 노드는 현재 사용 중이더라도 안전하게 파드(Pod)를 다른 노드로 이동시키는 드레이닝(draining) 과정을 거친 후 삭제됩니다.
    • 삭제된 노드를 대체하기 위해 Karpenter는 최신 EKS 최적화 AMI(Amazon Machine Image) 를 사용하는 새 노드를 자동으로 프로비저닝합니다. 이 과정을 통해 자연스럽게 노드가 최신 상태로 업그레이드됩니다.
  2. 장점:
    • 주기적인 노드 자동 교체를 통해 업그레이드를 자동화하여 관리 부담을 줄일 수 있습니다.
  3. 주의사항:
    • 동시 만료 위험: Karpenter는 만료 시간에 임의의 시간차(지터, jitter)를 자동으로 추가하지 않습니다. 따라서 여러 노드가 비슷한 시점에 생성된 경우, 동시에 만료되어 워크로드에 과도한 중단을 초래할 수 있습니다.
    • 워크로드 보호: 이러한 동시 중단을 방지하려면, Kubernetes의 포드 중단 예산(Pod Disruption Budget, PDB) 을 설정하여 애플리케이션의 최소 가용성을 보장하는 것이 중요합니다.
    • 적용 범위: 프로비저너에 ttlSecondsUntilExpired를 설정하면, 해당 프로비저너를 통해 새로 생성되는 노드뿐만 아니라 기존에 관리되던 노드들에도 이 만료 정책이 적용됩니다.

아래 Graceful Methods를 참고

Karpenter 관리형 노드에 Drift 기능 사용

Karpenter의 드리프트(Drift) 기능은 Karpenter가 관리하는 노드들이 사용하는 AMI(Amazon Machine Image) 버전이 EKS 컨트롤 플레인 버전과 달라지는 상황(드리프트)을 자동으로 감지하고 해결하여, 노드를 항상 최신 상태로 유지하도록 돕습니다.

  1. 주요 기능 및 목적:
    • EKS 컨트롤 플레인과 노드 간의 버전 불일치(드리프트)를 자동으로 감지합니다.
    • 주로 EKS 클러스터 업그레이드 후, 기존 노드들이 이전 버전의 EKS 최적화 AMI를 사용할 때 이 기능이 유용합니다.
    • 드리프트가 감지된 노드를 자동으로 최신 버전의 AMI를 사용하는 새 노드로 교체하여 동기화를 유지합니다.
  2. 작동 방식:
    • 감지: EKS 클러스터 업그레이드 완료 후, Karpenter는 이전 버전 AMI를 사용하는 노드를 식별합니다.
    • 자동 교체:
      • 해당 노드를 코딩(Cordon) 하여 더 이상 새 파드가 스케줄링되지 않도록 합니다.
      • 노드 위의 파드들을 안전하게 다른 곳으로 드레이닝(Drain) 합니다.
      • 기존 노드를 삭제하고, 현재 컨트롤 플레인 버전에 맞는 최신 EKS 최적화 AMI를 사용하는 새 노드로 교체(Replace) 합니다.
  3. 활성화:
    • 현재(제공된 정보 기준) 드리프트 기능은 기본적으로 비활성화되어 있으며, 기능 게이트(feature gate) 설정을 통해 명시적으로 활성화해야 합니다.
  4. 권장 사항 및 고려사항:
    • 파드 리소스 요청: Karpenter는 노드를 교체하기 전에 이동해야 할 파드들의 리소스 요청(requests)을 기반으로 필요한 새 노드를 미리 준비합니다. 따라서 파드의 리소스 요청을 정확하게 설정하는 것이 중요합니다.
    • 포드 중단 예산 (PDB): 노드 드레이닝은 계획된 중단이므로, Kubernetes 모범 사례에 따라 포드 중단 예산(PDB) 을 설정하여 애플리케이션의 최소 가용성을 보장해야 합니다. Karpenter는 PDB 제약 조건을 준수하며 노드를 교체합니다.

다음 문서를 참고하세요.

Reference