기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 클러스터 버전 롤백 모범 사례
Amazon Elastic Kubernetes Service(Amazon EKS) 버전 롤백을 사용하면 현재 위치 업그레이드 후 7일 이내에 클러스터의 Kubernetes 컨트롤 플레인을 이전 마이너 버전으로 되돌릴 수 있습니다. 이 페이지에서는 업그레이드 워크플로의 일부로 롤백을 계획, 실행 및 운영하기 위한 모범 사례를 설명합니다.
사전 조건 세부 정보, step-by-step 절차 및 API 참조는 [이전 Kubernetes 버전으로 클러스터 롤백을](https://docs.aws.amazon.com/eks/latest/userguide/rollback-cluster.html) 참조하세요.
## 공동 책임 모델을 롤백에 적용하는 방법 이해
클러스터 버전 롤백을 시작하면 Amazon EKS가 컨트롤 플레인 롤백을 관리합니다. 데이터 영역, 추가 기능 및 애플리케이션 호환성에 대한 책임은 사용자에게 있습니다. 다음은 책임을 간략하게 설명합니다.
+ **Amazon EKS 관리: Kubernetes API 서버 및 컨트롤 플레인 구성 요소를** 롤백합니다. Auto Mode 클러스터의 경우 Amazon EKS는 작업자 노드 롤백도 관리합니다.
+ 관리형 노드 그룹, 자체 관리형 노드 및 하이브리드 노드 롤백**은 사용자의 책임입니다**. 또한 추가 기능 호환성을 검증하고 애플리케이션, 사용자 지정 컨트롤러 및 타사 도구가 이전 버전과 올바르게 작동하는지 확인해야 합니다.
업그레이드를 위한 공동 책임 모델에 대한 자세한 내용은 [공동 책임 모델이 클러스터 업그레이드에 적용되는 방식 이해를 참조하세요](cluster-upgrades.md).
## 롤백을 염두에 두고 업그레이드 계획
버전 롤백은 업그레이드 워크플로가 롤백 기간을 열어 두도록 설계된 경우에 가장 적합합니다.
+ **별도의 컨트롤 플레인 및 데이터 플레인 업그레이드(비자동 모드 클러스터).** 관리형 노드 그룹 또는 자체 관리형 노드를 사용하는 클러스터의 경우 작업자 노드를 업그레이드하기 전에 먼저 컨트롤 플레인을 업그레이드하고 베이크 기간을 허용하는 것이 좋습니다. 노드가 N-1에 있는 동안 kubelet 버전 스큐 인사이트는 PASSING 상태로 유지됩니다. 이렇게 하면 노드를 먼저 롤백할 필요 없이 롤백 경로가 명확해집니다.
+ **추가 기능을 교차 호환 버전으로 업그레이드합니다.** 컨트롤 플레인을 업그레이드하기 전에 모든 추가 기능(관리형 및 자체 관리형)이 현재 및 대상 Kubernetes 버전과 호환되는지 확인합니다. 이렇게 하면 업그레이드와 롤백 모두에 대한 추가 기능 호환성 인사이트가 명확하게 유지됩니다.
+ Amazon EKS 관리형 추가 기능을 사용하면 추가 기능 버전 호환성을 자동으로 확인하는 롤백 준비 인사이트의 이점을 누릴 수 있습니다.
+ 관리형 추가 기능을 자체 관리하지 마세요(예: EKS 추가 기능 수명 주기 외부에서 버전 재정의). 롤백 중에 인사이트는 관리형 추가 기능 구성을 실제 소스로 취급하며 도입한 버전 드리프트를 감지하지 못합니다.
+ **베이크 기간 중에는 버전별 APIs를 사용하지 마세요.** 7일 기간 동안 새 버전에서만 사용할 수 있는 APIs 또는 기능을 사용하는 리소스를 생성하는 경우 롤백하기 전에 리소스를 제거해야 합니다. 업그레이드가 안정적이라고 확신할 때까지 new-version-only APIs의 채택을 제한합니다.
+ **나중에가 아니라 더 빨리 업그레이드합니다.** 롤백을 사용하면 추가 지원 기한까지 기다리는 대신 새 버전 릴리스 직후 자신 있게 업그레이드할 수 있습니다. 이전에 업그레이드하면 검증에 더 많은 시간을 할애하고 추가 지원 요금을 줄일 수 있습니다.
+ **확장 지원 롤백 제한에 유의하세요.** 추가 지원이 끝날 때 클러스터가 자동으로 업그레이드된 경우 이전 버전으로 롤백할 수 없습니다. 표준 지원이 끝날 때 자동 업그레이드된 경우 롤백할 수 있지만 먼저 업그레이드 정책을 로 변경해야 합니다`EXTENDED`.
사용 중단 정책, 릴리스 정보 및 추가 기능 호환성을 포함한 일반적인 업그레이드 계획 지침은 [클러스터 업그레이드 모범 사례를 참조하세요](cluster-upgrades.md).
## 롤백 전에 롤백 준비 인사이트 검토
Amazon EKS는 클러스터 인사이트의 `ROLLBACK_READINESS` 범주 아래에 point-in-time 롤백 준비 인사이트를 표시합니다. 이러한 검사는 롤백 안전성을 평가하기 위한 기본 도구입니다.
+ **업그레이드 직후 인사이트를 검토합니다.** 문제가 발생할 때까지 기다리지 마세요. 업그레이드 후 롤백 준비 인사이트를 확인하여 현재 롤백 상태를 파악합니다.
+ **ERROR 인사이트를 사전에 해결합니다.** 업그레이드 직후 인사이트에 ERROR 상태가 표시되면 7일 기간이 열려 있는 동안 조기에 해결합니다. 대기 시간이 길어질수록 클러스터 상태가 발산되고 새 차단기가 나타날 가능성이 높아집니다.
+ **어떤 인사이트가 다루고 어떤 인사이트를 다루지 않는지 이해합니다.** 인사이트는 Amazon EKS 관리형 추가 기능 버전, API 사용량, 버전 스큐 및 클러스터 상태를 확인합니다. 자체 관리형 추가 기능, 사용자 지정 컨트롤러 또는 애플리케이션 수준 호환성은 확인하지 않습니다. 자체 관리형 추가 기능(예: cluster-autoscaler, 수신 컨트롤러, 사용자 지정 연산자, 모니터링 에이전트)에 대한 자체 호환성 검증을 유지 관리합니다.
인사이트 검사 및 상태 동작의 전체 목록은 [이전 Kubernetes 버전으로 클러스터 롤백을](https://docs.aws.amazon.com/eks/latest/userguide/rollback-cluster.html) 참조하세요.
## 롤백을 위한 비 자동 모드 노드 준비
관리형 노드 그룹, 자체 관리형 노드 또는 AWS Fargate를 사용하는 클러스터의 경우 작업자 노드가 대상 롤백 버전과 호환되는지 확인해야 합니다.
+ **관리형 노드 그룹.** 컨트롤 플레인을 롤백하기 전에 관리형 노드 그룹을 이전 버전으로 롤백해야 합니다. 이전 Kubernetes 버전에서 `UpdateNodegroupVersion` 작업을 사용합니다. 롤백은 구성된 업데이트 설정(`maxUnavailable`, 업데이트 전략)을 준수합니다.
+ **자체 관리형 및 하이브리드 노드.** 컨트롤 플레인을 롤백하기 전에 이전 Kubernetes 버전을 사용하도록 노드 AMIs 또는 구성을 업데이트합니다.
+ **Fargate.** Fargate 작업자 노드에는 버전 롤백이 지원되지 않습니다. 롤백을 시작하기 전에 컨트롤 플레인과 동일한 버전을 실행하는 Fargate 포드를 삭제하거나 `--force`를 사용하여 버전 스큐 인사이트를 우회합니다(포드가 교체될 때까지 예기치 않은 동작이 발생할 수 있음).
노드 업데이트 중에 워크로드 가용성을 보장하기 위한 PodDisruptionBudget 및 토폴로지 분산 구성 지침은 [클러스터 업그레이드 모범 사례를 참조하세요](cluster-upgrades.md).
## 롤백을 위한 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= -o wide`를 사용하여 이전 버전 AMI로 대체된 노드를 모니터링합니다.
+ **필요한 경우 CancelUpdate를 사용합니다.** 롤백이 너무 오래 걸리거나 해결된 것보다 더 많은 문제를 일으키는 경우 롤백을 취소합니다. 취소 후 노드는 현재 버전으로 다시 수렴되므로 다른 접근 방식을 취할 수 있습니다.
+ **적절한 제한 시간을 설정합니다.** 의 `timeoutMinutes` 파라미터를 사용하여 운영 기대치`rollbackConfig`에 맞게 조정합니다. 기본값은 720분(12시간)입니다. 예산이 보수적인 클러스터의 경우 예산을 늘리는 것이 좋습니다. IaC 관리형 클러스터의 경우 도구의 제한 시간에 맞게 조정합니다.
전체 Auto Mode 롤백 절차 및 `CancelUpdate` 작업은 [Amazon EKS Auto Mode 클러스터 롤백을 참조하세요](https://docs.aws.amazon.com/eks/latest/userguide/rollback-automode-nodes.html).
## 롤백 진행 상황 모니터링
롤백 중에 다음을 사용하여 상태를 추적하고 문제를 감지합니다.
+ **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)) 및 더 간단한 작업을 제공합니다.
블루-그린은 한 번에 여러 버전을 변경하거나, 워크로드 마이그레이션을 광범위하게 테스트하거나, 검증 중에 전체 트래픽 격리를 유지해야 하는 경우에도 여전히 선호될 수 있습니다. 자세한 내용은 [클러스터 업그레이드 모범 사례의 블루/그린 클러스터 평가를 참조하세요](cluster-upgrades.md).
## 관련 리소스
+ [클러스터를 이전 Kubernetes 버전으로 롤백](https://docs.aws.amazon.com/eks/latest/userguide/rollback-cluster.html)
+ [Amazon EKS Auto Mode 클러스터 롤백](https://docs.aws.amazon.com/eks/latest/userguide/rollback-automode-nodes.html)
+ [클러스터 업그레이드 모범 사례](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html)
+ [클러스터 인사이트](https://docs.aws.amazon.com/eks/latest/userguide/cluster-insights.html)
+ [EKS의 Kubernetes 버전 수명 주기](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)