AWS re:Post을(를) 사용하면 다음에 동의하게 됩니다. AWS re:Post 이용 약관
AWS re:Postre:Post

Amazon EKS 클러스터의 업그레이드 전략을 계획하려면 어떻게 해야 하나요?

7분 분량
0

Amazon Elastic Kubernetes Service(Amazon EKS) 클러스터를 업그레이드할 경우 모범 사례를 따르고 싶습니다.

간략한 설명

새로운 Kubernetes 버전은 Amazon EKS 클러스터에 중대한 변경 사항을 도입할 수 있습니다. 클러스터를 업그레이드한 후에는 다운그레이드할 수 없습니다. 최신 Kubernetes 버전으로 업그레이드할 때, 제자리 클러스터 업그레이드를 수행하는 대신 새 클러스터로 마이그레이션할 수 있습니다. 새 클러스터로 마이그레이션하기로 선택한 경우 VMware의 Velero와 같은 클러스터 백업 및 복원 도구가 마이그레이션에 도움이 될 수 있습니다. 자세한 내용을 보려면 GitHub 웹 사이트의 Velero를 참고하세요.

Amazon EKS에서 사용할 수 있는 현재 및 과거 버전의 Kubernetes를 확인하려면 Amazon EKS Kubernetes 릴리스 캘린더를 참조하세요.

해결 방법

업그레이드 준비

클러스터 업그레이드를 시작하기 전에 다음 요구 사항에 유의하세요.

Amazon EKS 및 Kubernetes에 대한 주요 업데이트 검토

업그레이드 버전에 대해 문서화된 모든 변경 사항을 검토하고 필요한 업그레이드 단계를 기록하세요. 또한, Amazon EKS 관리형 클러스터와 관련된 요구 사항이나 절차에 유의하세요.

Amazon EKS 클러스터 플랫폼 버전 및 Kubernetes 버전에 대한 주요 업데이트는 다음 리소스를 참조하세요.

Kubernetes 업스트림 버전 및 주요 업데이트에 대한 자세한 내용을 보려면 다음 문서를 참조하세요.

Kubernetes 사용 중단 정책 이해

API가 업그레이드되면 이전 API는 더 이상 사용되지 않으며 결국 제거됩니다. 최신 버전의 Kubernetes에서 API가 어떻게 사용 중단될 수 있는지 이해하려면 Kubernetes 웹 사이트에서 사용 중단 정책을 읽어보시기 바랍니다.

클러스터에서 더 이상 사용되지 않는 API 버전을 사용하고 있는지 확인하려면 GitHub 웹 사이트의 Kube No Trouble(kubent)을 사용하세요. 더 이상 사용되지 않는 API 버전을 사용하는 경우, 워크로드를 업그레이드한 후 Kubernetes 클러스터를 업그레이드하세요.

서로 다른 API 버전 간에 Kubernetes 매니페스트 파일을 변환하려면 kubectl convert 플러그인을 사용합니다. 자세한 내용을 보려면 Kubernetes 웹 사이트에서 kubectl convert 플러그인 설치를 참조합니다.

Kubernetes 업그레이드 중 예상되는 사항

클러스터를 업그레이드하면 Amazon EKS는 기존 노드를 대체하기 위해 업그레이드된 Kubernetes 버전으로 새 API 서버 노드를 시작합니다. 이러한 검사 중 하나라도 실패하면 Amazon EKS는 인프라 배포를 롤백하고 클러스터는 이전 Kubernetes 버전으로 유지됩니다. 그러나 이 롤백은 실행 중인 애플리케이션에는 영향을 미치지 않으며, 필요한 경우 클러스터를 복구할 수 있습니다. 업그레이드 프로세스 중에 사소한 서비스 중단이 발생할 수 있습니다.

컨트롤 플레인 및 데이터 영역 업그레이드

Amazon EKS 클러스터를 업그레이드하려면 두 가지 주요 구성 요소인 컨트롤 플레인과 데이터 영역을 업데이트해야 합니다. 이러한 구성 요소를 업그레이드할 때는 다음 고려 사항을 염두에 두어야 합니다.

인플레이스 Amazon EKS 클러스터 업그레이드

인플레이스 업그레이드의 경우, 그 다음으로 높은 Kubernetes 마이너 버전으로만 업그레이드할 수 있습니다. 현재 클러스터 버전과 대상 버전 사이에 여러 버전이 있는 경우 각 버전으로 순차적으로 업그레이드해야 합니다. 각 인플레이스 Kubernetes 클러스터 업그레이드에 대해 다음 작업을 완료하세요.

  • 필요에 따라 Kubernetes 매니페스트를 업데이트하고 더 이상 사용되지 않거나 제거된 API를 업데이트합니다.
  • 클러스터 컨트롤 플레인을 업그레이드합니다.
  • 클러스터의 노드를 업그레이드합니다.
  • 필요에 따라 Kubernetes 애드온 및 사용자 지정 컨트롤러를 업데이트합니다.

자세한 내용을 보려면 Amazon EKS로 Kubernetes 업그레이드 계획에서 Amazon EKS에서 Kubernetes 버전 업그레이드 계획 및 실행을 참조하세요. 또한 GitHub 웹 사이트에서 클러스터 업그레이드 모범 사례를 참조하세요.

블루/그린 또는 canary Amazon EKS 클러스터 마이그레이션

블루/그린 또는 canary 업그레이드 전략은 더 복잡할 수 있지만, 손쉬운 롤백 기능을 사용하면 가동 중단 없이 업그레이드할 수 있습니다. 블루/그린 또는 canary 업그레이드에 대해서는 상태 비저장 ArgoCD 워크로드를 위한 블루/그린 또는 canary Amazon EKS 클러스터 마이그레이션을 참조하세요.

Amazon EKS 관리형 노드 그룹 업그레이드

중요: 노드의 kubelet은 kube-apiserver보다 최신 버전일 수 없습니다. 또한, kube-apiserver보다 두 개 이상의 마이너 버전이 이전 버전일 수 없습니다. 예를 들어, kube-apiserver가 버전 1.24라고 가정해 보겠습니다. 이 경우, kubelet은 버전 1.24, 1.23 및 1.22에서만 지원됩니다.

관리형 노드 그룹을 완전히 업그레이드하려면 다음 단계를 완료합니다.

  1. Amazon EKS 클러스터 컨트롤 플레인 구성 요소를 최신 버전으로 업그레이드합니다.
  2. 관리형 노드 그룹에서 노드를 업데이트합니다.

Amazon EKS 관리형 노드 그룹으로 마이그레이션

자체 관리형 노드 그룹을 사용하는 경우 가동 중지 시간 없이 워크로드를 Amazon EKS 관리형 노드 그룹으로 마이그레이션할 수 있습니다. 자세한 내용을 보려면 자체 관리형 노드 그룹에서 EKS 관리형 노드 그룹으로 워크로드 원활하게 마이그레이션을 참조하세요.

다운스트림 종속성(애드온) 식별 및 업그레이드

클러스터에는 종종 인그레스 컨트롤러, 지속적 전송 시스템, 모니터링 도구 및 기타 워크플로우와 같은 외부 제품이 포함되어 있습니다. Amazon EKS 클러스터를 업데이트할 때 애드온 및 타사 도구도 업데이트해야 합니다. 애드온이 클러스터에서 작동하는 방식과 애드온이 업데이트되는 방식을 이해하고 있어야 합니다.

참고: 자체 관리형 애드온 대신 관리형 애드온을 사용하는 것이 가장 좋습니다.

다음 일반적인 애드온의 예와 관련 업그레이드 설명서를 검토하세요.

AWS Fargate 노드 업그레이드

Fargate 노드를 업데이트하려면 노드가 나타내는 포드를 삭제합니다. 그런 다음 컨트롤 플레인을 업데이트한 후 포드를 다시 배포합니다. Fargate에서 실행하는 모든 새 포드는 클러스터 버전과 일치하는 kubelet 버전을 갖게 됩니다. 기존 Fargate 포드는 변경되지 않습니다.

참고: Fargate 포드를 안전하게 유지하려면 Amazon EKS에서 주기적으로 패치를 적용해야 합니다. Amazon EKS는 영향을 줄이는 방식으로 포드를 업데이트하려고 시도합니다. 그러나 포드를 성공적으로 퇴출할 수 없는 경우, Amazon EKS는 포드를 삭제합니다. 중단을 최소화하려면 Fargate OS 패치를 참조하세요.

Karpenter가 생성한 그룹리스 노드 업그레이드

ttlSecondsUntilExpired 값을 설정하면, 이 값이 노드 만료를 활성화합니다. 노드가 정의된 기간(초)에 도달하면 Amazon EKS는 노드를 삭제합니다. 이 삭제는 노드가 사용 중인 경우에도 발생합니다. 이 프로세스를 통해 노드를 새로 프로비저닝된 인스턴스로 교체하여 업그레이드할 수 있습니다. 노드가 교체되면 Karpenter는 최신 Amazon EKS에 최적화된 AMI를 사용합니다. 자세한 내용을 보려면 Karpenter 웹 사이트의 중단을 참조하세요.

다음 예제에서는 ttlSecondsUntilExpired를 사용하여 프로비저닝을 해제하고 업그레이드된 인스턴스로 교체한 노드를 보여 줍니다.

apiVersion: karpenter.sh/v1alpha5kind: Provisioner
metadata:
  name: default
spec:
  requirements:
    - key: karpenter.sh/capacity-type         # optional, set to on-demand by default, spot if both are listed
      operator: In
      values: ["spot"]
  limits:
    resources:
      cpu: 1000                               # optional, recommended to limit total provisioned CPUs
      memory: 1000Gi
  ttlSecondsAfterEmpty: 30                    # optional, but never scales down if not set
  ttlSecondsUntilExpired: 2592000             # optional, nodes are recycled after 30 days but never expires if not set
  provider:
        subnetSelector:
      karpenter.sh/discovery/CLUSTER_NAME: '*'
    securityGroupSelector:
      kubernetes.io/cluster/CLUSTER_NAME: '*'

참고: Karpenter는 이 값에 지터를 자동으로 추가하지 않습니다. 짧은 시간 내에 여러 인스턴스를 생성하면 거의 동시에 인스턴스가 만료됩니다. 과도한 워크로드 중단을 방지하려면 포드 중단 예산을 정의하세요. 자세한 내용을 보려면 Kubernetes 웹 사이트에서 애플리케이션에 대한 중단 예산 지정을 참조하세요.

주제
컨테이너
태그
Amazon Elastic Kubernetes Service
언어
한국어
AWS 공식
AWS 공식업데이트됨 3달 전
댓글 없음

관련 콘텐츠