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

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

我想使用 eksctl 命令升级 Amazon Elastic Kubernetes Service (Amazon EKS) Anywhere 管理集群,但升级失败或在完成之前遭到中断。
如果集群升级失败,如何将 EKS Anywhere 集群恢复到工作状态? 2023-08-17 09:26:39
如果集群升级失败,如何将 EKS Anywhere 集群恢复到工作状态? 0
如果集群升级失败,如何将 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 ``` ## 相关信息 [升级 vSphere、CloudStack、Nutanix 或 Snow 集群](https://anywhere.eks.amazonaws.com/docs/tasks/cluster/cluster-upgrades/vsphere-and-cloudstack-upgrades/?trk=cndc-detail) [EKS-A 故障排除](https://anywhere.eks.amazonaws.com/docs/tasks/troubleshoot/troubleshooting/#cluster-upgrade-fails-with-management-cluster-on-bootstrap-cluster?trk=cndc-detail) [集群 API 手册](https://cluster-api.sigs.k8s.io/introduction.html?trk=cndc-detail)(请见 Kubernetes 网站)
contact-us