如果集群升级失败，如何将 EKS Anywhere 集群恢复到工作状态？

4 分钟阅读

我想使用 eksctl 命令升级 Amazon Elastic Kubernetes Service (Amazon 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 和控制面板组件
升级 Worker 节点组件

在这一阶段，您将会看到一条信息，信息内容类似于以下示例：

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），并随后删除旧的虚拟机。在升级所有控制面板组件之前，此过程逐一应用于每个组件。

如果虚拟机无法运行，则升级失败，系统会在设定的超时间隔后停止升级。滚动过程会让原有虚拟机保持运行，以确保您的集群保持就绪状态。

升级阶段的问题

要在此阶段出现故障后进行恢复，请完成以下步骤：

1. 排查并解决导致升级失败的问题。查看 eksctl 日志，了解有关失败的详细信息。

2. 为了简化恢复过程，请设置一个环境变量：

**CLUSTER_NAME：**您的集群的名称
**CLITOOLS_CONT：**升级中断后，运行留在您的环境中的 mage 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

如果集群升级失败，如何将 EKS Anywhere 集群恢复到工作状态？

解决方法

验证阶段

升级阶段

相关信息

相关内容