Como faço para retornar um cluster EKS Anywhere a um estado de funcionamento quando a atualização do cluster falha?
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
O livro da API Cluster (no site do Kubernetes)
Conteúdo relevante
- AWS OFICIALAtualizada há um ano
- AWS OFICIALAtualizada há 2 anos
- AWS OFICIALAtualizada há 3 meses
- AWS OFICIALAtualizada há um ano