클러스터 업그레이드가 실패할 때 EKS Anywhere 클러스터를 작동 상태로 되돌리려면 어떻게 해야 하나요?

해결 방법

Amazon EKS Anywhere 관리 클러스터를 업그레이드할 때 확인 단계와 업그레이드 단계의 두 단계가 프로세스에 포함됩니다. 실패한 업그레이드의 복구 단계는 업그레이드가 중단된 단계에 따라 달라집니다.

확인 단계

EKS Anywhere 클러스터를 업그레이드할 때 eksctl은 일련의 실행 전 검사를 수행하여 클러스터가 준비되었는지 확인합니다. 이는 업그레이드 전에 발생하며 eksctl은 업데이트된 사양에 맞게 클러스터를 수정합니다.

eksctl이 이러한 검사를 수행하면 다음 예와 유사한 메시지가 표시됩니다.

Performing setup and validations
   Connected to server
   Authenticated to vSphere
   Datacenter validated
   Network validated
Creating template. This might take a while.
   Datastore validated
   Folder validated
   Resource pool validated
   Datastore validated
   Folder validated
   Resource pool validated
   Datastore validated
   Folder validated
   Resource pool validated
   Machine config tags validated
   Control plane and Workload templates validated
   Vsphere provider validation
   Validate certificate for registry mirror
   Control plane ready
   Worker nodes ready
   Nodes ready
   Cluster CRDs ready
   Cluster object present on workload cluster
   Upgrade cluster kubernetes version increment
   Validate authentication for git provider
   Validate immutable fields
   Upgrade preflight validations pass

다음으로 eksctl은 관리 클러스터에서 실행되는 CAPI 컨트롤러를 계속 확인합니다. 이러한 컨트롤러 중 업그레이드해야 하는 컨트롤러가 있으면 eksctl이 해당 컨트롤러도 업그레이드합니다. 이 과정에서 eksctl은 KinD 부트스트랩 클러스터도 생성하여 관리 클러스터를 업그레이드합니다. 이 프로세스를 반영하는 메시지가 표시됩니다.

Ensuring etcd CAPI providers exist on management cluster before
Pausing EKS-A cluster controller reconcile
Pausing GitOps cluster resources reconcile
Upgrading core components
Creating bootstrap cluster
Provider specific pre-capi-install-setup on bootstrap cluster
Provider specific post-setup
Installing cluster-api providers on bootstrap cluster

이러한 검사 또는 작업 중 하나라도 실패하면 업그레이드가 중지되고 관리 클러스터는 동일한 원래 버전으로 유지됩니다.

실패한 특정 검사에 대한 자세한 내용은 eksctl 로그를 확인하세요.

확인 단계 중 문제

이 단계에서 장애를 복구하려면 다음 단계를 완료하세요.

1.확인 실패의 원인이 된 문제를 해결하고 수정합니다.

2.eksctl anywhere 클러스터 업그레이드 명령을 다시 실행합니다. -v9 플래그를 사용하는 것이 가장 좋습니다.

업그레이드 단계

업그레이드 단계에서 eksctl은 다음과 같은 주요 작업을 수행합니다.

• 관리 클러스터 CAPI 개체(예: 머신, KubeadmControlPlane, EtcdadmCluster)를 부트스트랩 클러스터로 이동합니다.
• etcd 및 컨트롤 플레인 구성 요소를 업그레이드합니다.
• 워커 노드 구성 요소를 업그레이드합니다.

이 단계에서 다음 예와 유사한 메시지가 표시됩니다.

Moving cluster management from bootstrap to workload cluster
Applying new EKS-A cluster resource
Resuming EKS-A controller reconcile
Updating Git Repo with new EKS-A cluster spec
GitOps field not specified, update git repo skipped
Forcing reconcile Git repo with latest commit
GitOps not configured, force reconcile flux git repo skipped
Resuming GitOps cluster resources kustomization
Writing cluster config file
    Cluster upgraded!

eksctl은 Kubernetes 배포와 마찬가지로 롤링 프로세스를 사용하여 업그레이드를 수행할 수 있습니다. 또한 이 업그레이드를 통해 새 가상 머신(VM)을 만든 다음, 이전 VM을 제거합니다. 이 프로세스는 컨트롤 플레인 구성 요소가 모두 업그레이드될 때까지 각 구성 요소에 한 번에 하나씩 적용됩니다.

VM이 실행되지 않으면 업그레이드가 실패하고 설정된 시간 초과 간격 후에 중지됩니다. 롤링 프로세스는 클러스터가 준비 상태로 유지되도록 이전 VM을 계속 실행합니다.

업그레이드 단계 중 문제

이 단계에서 장애를 복구하려면 다음 단계를 완료하세요.

1.업그레이드 실패의 원인이 된 문제를 해결하고 수정합니다. eksctl 로그에서 실패에 대한 세부 정보를 확인하세요.

2.복구 프로세스를 쉽게 수행하려면 환경 변수를 설정합니다.

• **CLUSTER_NAME:**클러스터의 이름
• **CLITOOLS_CONT:**업그레이드 중단 후 사용자 환경에 남아 있는 이미지 cli-tools를 실행하는 컨테이너의 이름
• **KINDKUBE:**KinD 부트스트랩 클러스터에 액세스하는 데 사용하는 Kubeconfig 파일
• **MGMTKUBE:**관리 클러스터에 액세스하는 데 사용하는 Kubeconfig 파일
• EKSA_VSPHERE_USERNAME 및 **EKSA_VSPHERE_PASSWORD:**vCenter에 액세스하기 위한 보안 인증

이러한 변수에 대한 다음 예를 참조하세요.

CLUSTER_NAME=cluster3
CLITOOLS_CONT=eksa_1681572481616591501
KINDKUBE=$CLUSTER_NAME/generated/${CLUSTER_NAME}.kind.kubeconfig
MGMTKUBE=$CLUSTER_NAME/$CLUSTER_NAME-eks-a-cluster.kubeconfig
EKSA_VSPHERE_USERNAME=xxxxx
EKSA_VSPHERE_PASSWORD=yyyyy

3.관리 클러스터 CAPI 구성 요소(예: 머신 및 클러스터)가 준비 상태인지 확인합니다. 또한 관리 클러스터의 kubeApi-server가 응답하는지 확인합니다. 이 작업을 수행하려면 다음 명령을 실행하세요.

kubectl --kubeconfig $KINDKUBE -n eksa-system get machines
docker exec -i $CLITOOLS_CONT clusterctl describe cluster cluster3  --kubeconfig $KINDKUBE -n eksa-system
kubectl --kubeconfig $MGMTKUBE -n kube-system get node

다음 예와 유사한 출력이 표시됩니다.

NAME                            CLUSTER    NODENAME                        PROVIDERID                                       PHASE     AGE     VERSION
cluster3-2snw8                  cluster3   cluster3-2snw8                  vsphere://4230efe1-e1f5-c8e5-9bff-12eca320f5db   Running   3m13s   v1.23.17-eks-1-23-19
cluster3-etcd-chkc5             cluster3                                   vsphere://4230826c-b25d-937a-4728-3e607e6af579   Running   4m14s
cluster3-md-0-854976576-tw6hr   cluster3   cluster3-md-0-854976576-tw6hr   vsphere://4230f2e5-0a4b-374c-f06b-41ac1f80e41f   Running   4m30s   v1.22.17-eks-1-22-24

$ docker exec -i $CLITOOLS_CONT clusterctl describe cluster cluster3  --kubeconfig $KINDKUBE -n eksa-system
NAME                                               READY  SEVERITY  REASON  SINCE  MESSAGE
Cluster/cluster3                                   True                     49s
├─ClusterInfrastructure - VSphereCluster/cluster3  True                     4m53s
├─ControlPlane - KubeadmControlPlane/cluster3      True                     49s
│ └─Machine/cluster3-2snw8                         True                     2m51s
└─Workers
  ├─MachineDeployment/cluster3-md-0                True                     4m53s
  │ └─Machine/cluster3-md-0-854976576-tw6hr        True                     4m53s
  └─Other
    └─Machine/cluster3-etcd-chkc5                  True                     3m55s

$ kubectl --kubeconfig $MGMTKUBE -n kube-system get node
NAME                             STATUS   ROLES                  AGE   VERSION
cluster3-md-0-854976576-tw6hr    Ready    [none]                 18m   v1.22.17-eks-a51510b
cluster3-2snw8                   Ready    control-plane,master   19m   v1.23.17-eks-a51510b

4.관리 클러스터 CAPI 구성 요소를 백업합니다.

mkdir ${CLUSTER_NAME}-backup
docker exec -i $CLITOOLS_CONT clusterctl move --to-directory ${CLUSTER_NAME}-backup  --kubeconfig $KINDKUBE -n eksa-system

5.관리 클러스터 CAPI 구성 요소를 관리 클러스터로 다시 이동합니다.

$ docker exec -i $CLITOOLS_CONT clusterctl move --to-kubeconfig $MGMTKUBE  --kubeconfig $KINDKUBE -n eksa-system
Performing move...
Discovering Cluster API objects
Moving Cluster API objects Clusters=1
Moving Cluster API objects ClusterClasses=0
Creating objects in the target cluster
Deleting objects from the source cluster

다음 예와 유사한 출력이 표시됩니다.

$ docker exec -i $CLITOOLS_CONT clusterctl move --to-kubeconfig $MGMTKUBE  --kubeconfig $KINDKUBE -n eksa-system
Performing move...
Discovering Cluster API objects
Moving Cluster API objects Clusters=1
Moving Cluster API objects ClusterClasses=0
Creating objects in the target cluster
Deleting objects from the source cluster

6.관리 클러스터 CAPI 구성 요소(예: 머신 및 클러스터)가 더 이상 KinD 부트스트랩 클러스터에 있지 않은지 확인합니다. 관리 클러스터에 표시되는지 확인하세요. 이 작업을 수행하려면 다음 명령을 실행합니다.

kubectl --kubeconfig $KINDKUBE -n eksa-system get cluster -n eksa-system
kubectl --kubeconfig $MGMTKUBE get machines -n eksa-system

다음 예와 유사한 출력이 표시됩니다.

$ kubectl --kubeconfig $KINDKUBE -n eksa-system get cluster -n eksa-system
No resources found in eksa-system namespace.

$ kubectl --kubeconfig $MGMTKUBE get machines -n eksa-system
NAME                           CLUSTER    NODENAME                       PROVIDERID                                       PHASE     AGE     VERSION
cluster2-4n7qd                 cluster2   cluster2-4n7qd                 vsphere://4230fb07-2823-3474-c41f-b7223dec3089   Running   2m27s   v1.23.17-eks-1-23-19
cluster2-etcd-h4tpl            cluster2                                  vsphere://42303b36-1991-67a9-e942-dd9959760649   Running   2m27s
cluster2-md-0-fd6c558b-6cfvq   cluster2   cluster2-md-0-fd6c558b-6cfvq   vsphere://423019a3-ad3f-1743-e7a8-ec8772d3edc2   Running   2m26s   v1.22.17-eks-1-22-24

7.업그레이드를 다시 실행합니다. 플래그 --force-cleanup -v9 플래그를 사용하세요.

eksctl anywhere upgrade cluster -f cluster3/cluster3-eks-a-cluster.yaml --force-cleanup -v9

관련 정보

vSphere, CloudStack, Nutanix 또는 Snow 클러스터 업그레이드

EKS-A 문제 해결

The Cluster API Book(Kubernetes 웹 사이트 참조)