Como faço para retornar um cluster EKS Anywhere a um estado de funcionamento quando a atualização do cluster falha?

7 minuto de leitura
0

Quero usar o comando eksctl para atualizar um cluster de gerenciamento do Amazon Elastic Kubernetes Service (Amazon EKS) Anywhere. No entanto, o processo de atualização falha ou é interrompido antes da conclusão.

Resolução

Quando você atualiza um cluster de gerenciamento do Amazon EKS Anywhere, o processo inclui duas fases: a fase de verificação e a fase de atualização. As etapas de recuperação de uma atualização com falha dependem de qual fase da atualização foi interrompida.

Fase de verificação

Quando você atualiza um cluster EKS Anywhere, o eksctl executa um conjunto de verificações prévias para garantir que seu cluster esteja pronto. Isso ocorre antes da atualização, e o eksctl modifica seu cluster para corresponder à especificação atualizada.

Quando o eksctl realiza essas verificações, você vê uma mensagem semelhante ao exemplo a seguir:

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

Em seguida, o eksctl continua verificando os controladores de CAPI que são executados em seu cluster de gerenciamento. Se algum desses controladores precisar de uma atualização, o eksctl também os atualiza. Durante esse processo, o eksctl também cria um cluster de bootstrap KiND para atualizar seu cluster de gerenciamento. Você vê uma mensagem que reflete esse processo:

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

Se alguma dessas verificações ou ações falhar, a atualização será interrompida e seu cluster de gerenciamento permanecerá na mesma versão original.

Para obter mais detalhes sobre a verificação específica que falhou, verifique os registros do eksctl.

Problemas durante a fase de verificação

Para se recuperar de uma falha nessa fase, conclua as seguintes etapas:

1.    Solucione e corrija o problema que causou a falha na verificação.

2.    Execute novamente o comando eksctl anywhere cluster upgrade. É uma prática recomendada usar o sinalizador -v9.

Fase de atualização

Na fase de atualização, o eksctl executa as seguintes ações principais:

  • Move os objetos CAPI do cluster de gerenciamento (como máquinas, KubeAdmControlPlane e etcDadmCluster) para o cluster bootstrap
  • Atualiza o etcd e os componentes do plano de controle
  • Atualiza os componentes do worknode

Durante essa fase, você vê uma mensagem semelhante ao exemplo a seguir:

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!

O eksctl usa um processo contínuo para realizar a atualização no local, semelhante às implantações do Kubernetes. Ele também cria uma nova máquina virtual (VM) com essa atualização e, em seguida, remove a VM antiga. Esse processo se aplica a cada componente, um por vez, até que todos os componentes do plano de controle sejam atualizados.

Se uma VM falhar na execução, a atualização falhará e será interrompida após um intervalo de tempo limite definido. O processo contínuo mantém a VM antiga em execução para garantir que seu cluster permaneça no estado Ready (Pronto).

Problemas durante a fase de atualização

Para se recuperar de uma falha durante essa fase, conclua as seguintes etapas:

1.    Solucione e corrija o problema que causou a falha na atualização. Verifique os registros do eksctl para obter detalhes sobre a falha.

2.    Para facilitar o processo de recuperação, configure uma variável de ambiente:

  • CLUSTER_NAME: O nome do seu cluster
  • CLITOOLS_CONT: O nome do contêiner que executa as ferramentas cli-de imagem deixadas em seu ambiente após a interrupção do upgrade
  • KINDKUBE: O arquivo Kubeconfig que você usa para acessar o cluster de bootstrap KiND
  • MGMTKUBE: O arquivo Kubeconfig que você usa para acessar seu cluster de gerenciamento
  • EKSA_VSPHERE_USERNAME e **EKSA_VSPHERE_PASSWORD:**Credenciais para acessar o vCenter

Veja o exemplo a seguir dessas variáveis:

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.    Verifique se de que os componentes da CAPI do cluster de gerenciamento, como máquinas e clusters, estão no estado Pronto. Além disso, verifique se o KubeAPI-server em seu cluster de gerenciamento está responsivo. Para fazer isso, execute o seguinte comando:

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

Você recebe uma saída semelhante ao exemplo a seguir:

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.    Faça backup dos componentes da CAPI do seu cluster de gerenciamento:

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

5.    Mova os componentes da CAPI do cluster de gerenciamento de volta para o seu cluster de gerenciamento:

$ 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

Você recebe uma saída semelhante ao exemplo a seguir:

$ 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.    Certifique-se de que os componentes da CAPI do cluster de gerenciamento, como máquinas e clusters, não estejam mais no cluster de bootstrap do KInD. Verifique se eles aparecem no cluster de gerenciamento. Para fazer isso, execute os seguintes comandos:

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

Você recebe uma saída semelhante ao exemplo a seguir:

$ 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.    Execute a atualização novamente. Use o sinalizador --force-cleanup -v9:

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

Informações relacionadas

Atualize o cluster vSphere, CloudStack, Nutanix ou Snow

Solução de problemas do EKS-A

O livro da API Cluster (no site do Kubernetes)

AWS OFICIAL
AWS OFICIALAtualizada há um ano