¿Cómo hago que un clúster de EKS Anywhere vuelva a funcionar cuando se produce un error en la actualización del clúster?
Quiero usar el comando eksctl para actualizar un clúster de administración de Amazon Elastic Kubernetes Service (Amazon EKS) Anywhere. Sin embargo, el proceso de actualización falla o se interrumpe antes de completarse.
Solución
Al actualizar un clúster de administración de Amazon EKS Anywhere, el proceso incluye dos fases: la fase de verificación y la fase de actualización. Los pasos de recuperación de una actualización que ha fallado dependen de la fase de la actualización que se haya interrumpido.
Fase de verificación
Al actualizar un clúster de EKS Anywhere, eksctl ejecuta una serie de comprobaciones previas para asegurarse de que el clúster está listo. Esto ocurre antes de la actualización y eksctl modifica el clúster para que coincida con la especificación actualizada.
Cuando eksctl realiza estas comprobaciones, aparece un mensaje similar al siguiente ejemplo:
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
Después, eksctl continúa verificando los controladores de CAPI que se ejecutan en su clúster de administración. Si alguno de estos controladores necesita una actualización, eksctl también lo actualiza. Durante este proceso, eksctl también crea un clúster de arranque KinD para actualizar su clúster de administración. Verá un mensaje que refleja este proceso:
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
Si se produce un error en alguna de estas comprobaciones o acciones, la actualización se detiene y el clúster de administración permanece en la misma versión original.
Para obtener más información sobre la comprobación específica que ha fallado, consulte los registros de eksctl.
Problemas durante la fase de verificación
Para recuperarse de un error en esta fase, siga estos pasos:
1. Solucione y corrija el problema que ha provocado el error en la verificación.
2. Vuelva a ejecutar el comando eksctl anywhere cluster upgrade. Se recomienda utilizar el indicador**-v9**.
Fase de actualización
En la fase de actualización, eksctl realiza las siguientes acciones principales:
- Mueve los objetos de CAPI del clúster de administración (como máquinas, KubeadmControlPlane y EtcdadmCluster) al clúster de arranque.
- Actualiza los componentes etcd y del plano de control.
- Actualiza los componentes del nodo de trabajo.
Durante esta fase, aparecerá un mensaje similar al siguiente ejemplo:
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 utiliza un proceso gradual para realizar la actualización in situ, similar a los despliegues de Kubernetes. También crea una nueva máquina virtual (VM) con esta actualización y, a continuación, elimina la máquina virtual anterior. Este proceso se aplica a cada componente, uno por uno, hasta que se hayan actualizado todos los componentes del plano de control.
Si una máquina virtual no se ejecuta, la actualización fallará y se detendrá después de un intervalo de tiempo de espera establecido. El proceso gradual mantiene la máquina virtual anterior en ejecución para garantizar que el clúster permanezca en estado Ready (Listo).
Problemas durante la fase de actualización
Para recuperarse de un error durante esta fase, siga estos pasos:
1. Solucione y corrija el problema que provocó el error de la actualización. Consulte los registros de eksctl para obtener detalles sobre el error.
2. Para facilitar el proceso de recuperación, configure una variable de entorno:
- CLUSTER_NAME: El nombre de su clúster
- CLITOOLS_CONT: El nombre del contenedor que ejecuta image cli-tools que permanece en su entorno tras la interrupción de la actualización
- KINDKUBE: El archivo Kubeconfig que usa para acceder al clúster de arranque KinD
- MGMTKUBE: El archivo Kubeconfig que usa para acceder a su clúster de administración
- EKSA_VSPHERE_USERNAME y EKSA_VSPHERE_PASSWORD: Credenciales para acceder a vCenter
Consulte el siguiente ejemplo de estas variables:
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. Asegúrese de que los componentes de CAPI del clúster de administración, como las máquinas y los clústeres, estén en estado Ready (Listo). Además, asegúrese de que kubeApi-server de su clúster de administración tenga capacidad de respuesta. Para ello, ejecute el comando siguiente:
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
Recibirá un resultado similar al ejemplo siguiente:
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. Realice una copia de seguridad de los componentes de CAPI del clúster de administración:
mkdir ${CLUSTER_NAME}-backup docker exec -i $CLITOOLS_CONT clusterctl move --to-directory ${CLUSTER_NAME}-backup --kubeconfig $KINDKUBE -n eksa-system
5. Vuelva a trasladar los componentes de CAPI del clúster de administración a su clúster de administración:
$ 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
Recibirá un resultado similar al ejemplo siguiente:
$ 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. Asegúrese de que los componentes de CAPI del clúster de administración, como las máquinas y los clústeres, ya no estén en el clúster de arranque de KinD. Compruebe que aparezcan en el clúster de administración. Para ello, ejecute los comandos siguientes:
kubectl --kubeconfig $KINDKUBE -n eksa-system get cluster -n eksa-system kubectl --kubeconfig $MGMTKUBE get machines -n eksa-system
Recibirá un resultado similar al ejemplo siguiente:
$ 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. Vuelva a ejecutar la actualización. Use el indicador --force-cleanup -v9:
eksctl anywhere upgrade cluster -f cluster3/cluster3-eks-a-cluster.yaml --force-cleanup -v9
Información relacionada
Actualizar el clúster de vSphere, CloudStack, Nutanix o Snow
Solución de problemas de EKS-A
El libro de API de clúster (en el sitio web de Kubernetes)
Contenido relevante
- OFICIAL DE AWSActualizada hace un año
- OFICIAL DE AWSActualizada hace 3 meses
- OFICIAL DE AWSActualizada hace un año
- OFICIAL DE AWSActualizada hace un año