View a markdown version of this page

클러스터 버전 롤백 모범 사례 - Amazon EKS
공동 책임 모델을 롤백에 적용하는 방법 이해롤백을 염두에 두고 업그레이드 계획롤백 전에 롤백 준비 인사이트 검토롤백을 위한 비 자동 모드 노드 준비롤백을 위한 Amazon EKS Auto Mode 중단 제어 관리롤백 진행 상황 모니터링코드형 인프라(IaC) 관리형 클러스터 처리롤백을 일상적인 워크플로가 아닌 안전망으로 사용롤백으로 블루-그린 업그레이드 필요성 감소관련 리소스

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

클러스터 버전 롤백 모범 사례

Amazon Elastic Kubernetes Service(Amazon EKS) 버전 롤백을 사용하면 현재 위치 업그레이드 후 7일 이내에 클러스터의 Kubernetes 컨트롤 플레인을 이전 마이너 버전으로 되돌릴 수 있습니다. 이 페이지에서는 업그레이드 워크플로의 일부로 롤백을 계획, 실행 및 운영하기 위한 모범 사례를 설명합니다.

사전 조건 세부 정보, step-by-step 절차 및 API 참조는 이전 Kubernetes 버전으로 클러스터 롤백을 참조하세요.

공동 책임 모델을 롤백에 적용하는 방법 이해

클러스터 버전 롤백을 시작하면 Amazon EKS가 컨트롤 플레인 롤백을 관리합니다. 데이터 영역, 추가 기능 및 애플리케이션 호환성에 대한 책임은 사용자에게 있습니다. 다음은 책임을 간략하게 설명합니다.

  • Amazon EKS 관리: Kubernetes API 서버 및 컨트롤 플레인 구성 요소를 롤백합니다. Auto Mode 클러스터의 경우 Amazon EKS는 작업자 노드 롤백도 관리합니다.

  • 관리형 노드 그룹, 자체 관리형 노드 및 하이브리드 노드 롤백은 사용자의 책임입니다. 또한 추가 기능 호환성을 검증하고 애플리케이션, 사용자 지정 컨트롤러 및 타사 도구가 이전 버전과 올바르게 작동하는지 확인해야 합니다.

업그레이드를 위한 공동 책임 모델에 대한 자세한 내용은 공동 책임 모델이 클러스터 업그레이드에 적용되는 방식 이해를 참조하세요.

롤백을 염두에 두고 업그레이드 계획

버전 롤백은 업그레이드 워크플로가 롤백 기간을 열어 두도록 설계된 경우에 가장 적합합니다.

  • 별도의 컨트롤 플레인 및 데이터 플레인 업그레이드(비자동 모드 클러스터). 관리형 노드 그룹 또는 자체 관리형 노드를 사용하는 클러스터의 경우 작업자 노드를 업그레이드하기 전에 먼저 컨트롤 플레인을 업그레이드하고 베이크 기간을 허용하는 것이 좋습니다. 노드가 N-1에 있는 동안 kubelet 버전 스큐 인사이트는 PASSING 상태로 유지됩니다. 이렇게 하면 노드를 먼저 롤백할 필요 없이 롤백 경로가 명확해집니다.

  • 추가 기능을 교차 호환 버전으로 업그레이드합니다. 컨트롤 플레인을 업그레이드하기 전에 모든 추가 기능(관리형 및 자체 관리형)이 현재 및 대상 Kubernetes 버전과 호환되는지 확인합니다. 이렇게 하면 업그레이드와 롤백 모두에 대한 추가 기능 호환성 인사이트가 명확하게 유지됩니다.

    • Amazon EKS 관리형 추가 기능을 사용하면 추가 기능 버전 호환성을 자동으로 확인하는 롤백 준비 인사이트의 이점을 누릴 수 있습니다.

    • 관리형 추가 기능을 자체 관리하지 마세요(예: EKS 추가 기능 수명 주기 외부에서 버전 재정의). 롤백 중에 인사이트는 관리형 추가 기능 구성을 실제 소스로 취급하며 도입한 버전 드리프트를 감지하지 못합니다.

  • 베이크 기간 중에는 버전별 APIs를 사용하지 마세요. 7일 기간 동안 새 버전에서만 사용할 수 있는 APIs 또는 기능을 사용하는 리소스를 생성하는 경우 롤백하기 전에 리소스를 제거해야 합니다. 업그레이드가 안정적이라고 확신할 때까지 new-version-only APIs의 채택을 제한합니다.

  • 나중에가 아니라 더 빨리 업그레이드합니다. 롤백을 사용하면 추가 지원 기한까지 기다리는 대신 새 버전 릴리스 직후 자신 있게 업그레이드할 수 있습니다. 이전에 업그레이드하면 검증에 더 많은 시간을 할애하고 추가 지원 요금을 줄일 수 있습니다.

  • 확장 지원 롤백 제한에 유의하세요. 추가 지원이 끝날 때 클러스터가 자동으로 업그레이드된 경우 이전 버전으로 롤백할 수 없습니다. 표준 지원이 끝날 때 자동 업그레이드된 경우 롤백할 수 있지만 먼저 업그레이드 정책을 로 변경해야 합니다EXTENDED.

사용 중단 정책, 릴리스 정보 및 추가 기능 호환성을 포함한 일반적인 업그레이드 계획 지침은 클러스터 업그레이드 모범 사례를 참조하세요.

롤백 전에 롤백 준비 인사이트 검토

Amazon EKS는 클러스터 인사이트의 ROLLBACK_READINESS 범주 아래에 point-in-time 롤백 준비 인사이트를 표시합니다. 이러한 검사는 롤백 안전성을 평가하기 위한 기본 도구입니다.

  • 업그레이드 직후 인사이트를 검토합니다. 문제가 발생할 때까지 기다리지 마세요. 업그레이드 후 롤백 준비 인사이트를 확인하여 현재 롤백 상태를 파악합니다.

  • ERROR 인사이트를 사전에 해결합니다. 업그레이드 직후 인사이트에 ERROR 상태가 표시되면 7일 기간이 열려 있는 동안 조기에 해결합니다. 대기 시간이 길어질수록 클러스터 상태가 발산되고 새 차단기가 나타날 가능성이 높아집니다.

  • 어떤 인사이트가 다루고 어떤 인사이트를 다루지 않는지 이해합니다. 인사이트는 Amazon EKS 관리형 추가 기능 버전, API 사용량, 버전 스큐 및 클러스터 상태를 확인합니다. 자체 관리형 추가 기능, 사용자 지정 컨트롤러 또는 애플리케이션 수준 호환성은 확인하지 않습니다. 자체 관리형 추가 기능(예: cluster-autoscaler, 수신 컨트롤러, 사용자 지정 연산자, 모니터링 에이전트)에 대한 자체 호환성 검증을 유지 관리합니다.

인사이트 검사 및 상태 동작의 전체 목록은 이전 Kubernetes 버전으로 클러스터 롤백을 참조하세요.

롤백을 위한 비 자동 모드 노드 준비

관리형 노드 그룹, 자체 관리형 노드 또는 AWS Fargate를 사용하는 클러스터의 경우 작업자 노드가 대상 롤백 버전과 호환되는지 확인해야 합니다.

  • 관리형 노드 그룹. 컨트롤 플레인을 롤백하기 전에 관리형 노드 그룹을 이전 버전으로 롤백해야 합니다. 이전 Kubernetes 버전에서 UpdateNodegroupVersion 작업을 사용합니다. 롤백은 구성된 업데이트 설정(maxUnavailable, 업데이트 전략)을 준수합니다.

  • 자체 관리형 및 하이브리드 노드. 컨트롤 플레인을 롤백하기 전에 이전 Kubernetes 버전을 사용하도록 노드 AMIs 또는 구성을 업데이트합니다.

  • Fargate. Fargate 작업자 노드에는 버전 롤백이 지원되지 않습니다. 롤백을 시작하기 전에 컨트롤 플레인과 동일한 버전을 실행하는 Fargate 포드를 삭제하거나 --force를 사용하여 버전 스큐 인사이트를 우회합니다(포드가 교체될 때까지 예기치 않은 동작이 발생할 수 있음).

노드 업데이트 중에 워크로드 가용성을 보장하기 위한 PodDisruptionBudget 및 토폴로지 분산 구성 지침은 클러스터 업그레이드 모범 사례를 참조하세요.

롤백을 위한 Amazon EKS Auto Mode 중단 제어 관리

Amazon EKS Auto Mode를 실행하는 클러스터의 경우 노드 롤백 단계가 작업의 가장 긴 부분일 수 있습니다. 중단 제어는 롤백이 완료되는 속도를 직접 결정합니다.

  • 롤백을 시작하기 전에 중단 예산을 검토합니다. Amazon EKS는 NodePool 중단 예산에 대한 롤백 준비 인사이트를 제공합니다. 예산이 0으로 설정되면 ERROR 인사이트가 트리거되어 롤백이 무기한 차단됩니다. 제한된 예산 및 PodDisruptionBudgets(PDBs WARNING 인사이트를 트리거하여 롤백 속도를 늦추지만 진행 상황을 허용할 수 있습니다. 롤백을 시작하기 전에 ERROR 인사이트를 해결합니다.

  • 롤백 중에 예산을 조정할 준비를 합니다. 롤백이 예상보다 오래 걸리는 경우 롤백이 진행되는 kubectl 동안 NodePool 중단 예산 및 PDBs 조정할 수 있습니다. 예산을 늘리면 더 많은 동시 노드 교체가 가능합니다.

  • 차단 노드에서 do-not-disrupt 주석을 제거합니다. 노드의 karpenter.sh/do-not-disrupt 주석은 롤백을 무기한 차단합니다. 교체해야 하는 노드에서 제거합니다.

  • 노드 롤백 진행 상황을 추적합니다. kubectl get nodes -l karpenter.sh/nodepool=<nodepool-name> -o wide를 사용하여 이전 버전 AMI로 대체된 노드를 모니터링합니다.

  • 필요한 경우 CancelUpdate를 사용합니다. 롤백이 너무 오래 걸리거나 해결된 것보다 더 많은 문제를 일으키는 경우 롤백을 취소합니다. 취소 후 노드는 현재 버전으로 다시 수렴되므로 다른 접근 방식을 취할 수 있습니다.

  • 적절한 제한 시간을 설정합니다. 의 timeoutMinutes 파라미터를 사용하여 운영 기대치rollbackConfig에 맞게 조정합니다. 기본값은 720분(12시간)입니다. 예산이 보수적인 클러스터의 경우 예산을 늘리는 것이 좋습니다. IaC 관리형 클러스터의 경우 도구의 제한 시간에 맞게 조정합니다.

전체 Auto Mode 롤백 절차 및 CancelUpdate 작업은 Amazon EKS Auto Mode 클러스터 롤백을 참조하세요.

롤백 진행 상황 모니터링

롤백 중에 다음을 사용하여 상태를 추적하고 문제를 감지합니다.

  • DescribeUpdate 작업. describe-update를 사용하여 롤백 작업(InProgress, Successful, Failed, Cancelled)의 현재 상태를 확인합니다. 취소 진행 상황을 추적하려면 응답에서 cancellation 객체를 확인합니다.

  • 클러스터 인사이트. Amazon EKS는 컨트롤 플레인 롤백을 진행하기 전에(자동 모드에서 노드 롤백이 완료된 후) 인사이트를 다시 확인합니다. 표시되었을 수 있는 새로운 ERROR 인사이트를 모니터링합니다.

  • 클러스터 상태입니다. Auto Mode 클러스터의 경우 클러스터 상태는 노드 롤백 ACTIVE 중에도 유지되고 컨트롤 플레인 롤백 중에UPDATING만 로 변경됩니다. 롤백이 진행 중임을 알기 위해 클러스터 상태에만 의존하지 말고를 사용합니다DescribeUpdate.

  • 노드 버전. 자동 모드에서 노드 Kubernetes 버전을 확인하여 노드 교체 진행 상황을 추적합니다. 관리형 노드 그룹의 경우 노드 그룹 업데이트 상태를 모니터링합니다.

코드형 인프라(IaC) 관리형 클러스터 처리

코드형 인프라(IaC) 도구에는 Auto Mode 롤백 기간과 충돌할 수 있는 제한 시간이 있습니다.

  • AWS CloudFormation은 리소스당 최대 36시간을 지원합니다. 롤백이이 값을 초과하면 CloudFormation은 이를 no-op로 취급하여 템플릿이 실제 클러스터 버전을 반영하지 않는 드리프트된 상태로 클러스터를 떠날 수 있습니다. 기본 롤백 제한 시간은 720분(12시간)입니다.

  • Terraform Enterprise/Cloud의 제한 시간은 클라이언트 측 제한 시간은 다양하지만 약 24시간입니다.

  • IaC 도구의 제한 시간에 timeoutMinutes 맞춰 Amazon EKS가 롤백을 완료하기 전에 IaC 도구의 제한 시간이 초과되지 않도록 합니다.

  • IaC를 통하지 않고 제한적인 예산으로 CLI/API for Auto Mode 클러스터를 통해 롤백을 시작하는 것이 좋습니다. IaC 계층 시간이 초과되면 CancelUpdate를 직접 사용합니다.

  • AWS CloudFormation 스택 롤백은 버전 롤백을 트리거하지 않습니다. AWS CloudFormation 스택 업데이트에 실패하면 자동 스택이 이전 템플릿 버전으로 되돌려지더라도 클러스터 버전 롤백이 시작되지 않습니다. 버전 롤백을 명시적으로 시작해야 합니다.

롤백을 일상적인 워크플로가 아닌 안전망으로 사용

버전 롤백은 업그레이드 후 문제를 복구하는 데 도움이 되도록 설계되었습니다. 기존 업그레이드 관행과 결합할 때 가장 효과적입니다.

  • 롤백은 테스트를 보완하며 이를 대체하지 않습니다. 클러스터 인사이트, 비프로덕션 환경에서의 사전 업그레이드 테스트 및 단계적 롤아웃을 계속 사용합니다. 롤백은 테스트가 포착할 수 없는 사례, 즉 프로덕션에서만 나타나는 문제를 처리합니다.

  • 롤백을 사용하면 수동 백업 및 스냅샷 프로시저가 기본 안전 메커니즘으로 필요하지 않습니다. 기본 롤백을 사용할 수 있으므로 업그레이드 중에 재해 복구를 위해 더 이상 etcd 스냅샷 또는 사용자 지정 롤백 스크립트에만 의존할 필요가 없습니다.

  • 인사이트는 최선의 노력과 point-in-time입니다. Amazon EKS는 롤백을 트리거할 때 이를 평가합니다. 확인 후 변경한 내용(예: 새 APIs를 사용하여 리소스 생성)은 캡처되지 않으며 롤백이 완료된 후 문제가 발생할 수 있습니다.

  • 롤백은 애플리케이션 복구를 보장하지 않습니다. Amazon EKS는 컨트롤 플레인을 안전하게 되돌리지만 애플리케이션, 구성 및 종속성을 이전 버전과 비교하여 검증하는 것은 사용자의 책임입니다.

롤백으로 블루-그린 업그레이드 필요성 감소

이전에 블루-그린 클러스터 업그레이드를 주로 사용하여 "역방향 경로"를 갖는 조직은 이제 버전 롤백을 사용하는 인플레이스 업그레이드를 대안으로 고려할 수 있습니다. 롤백을 사용한 현재 위치 업그레이드는 인프라 비용 절감(중복 클러스터 없음), 일관된 클러스터 자격 증명(동일한 API 엔드포인트, OpenID Connect(OIDC) 공급자, 탄력적 네트워크 인터페이스(ENIs)) 및 더 간단한 작업을 제공합니다.

블루-그린은 한 번에 여러 버전을 변경하거나, 워크로드 마이그레이션을 광범위하게 테스트하거나, 검증 중에 전체 트래픽 격리를 유지해야 하는 경우에도 여전히 선호될 수 있습니다. 자세한 내용은 클러스터 업그레이드 모범 사례의 블루/그린 클러스터 평가를 참조하세요.