¿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?

7 minutos de lectura
0

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)

OFICIAL DE AWS
OFICIAL DE AWSActualizada hace un año