Reparo automático de nós e verificação de integridade

Version 1.15 

• Versão mais recente
• Versão 1.16
• Versões anteriores (sem suporte)

No GKE no VMware, a verificação periódica de integridade e o reparo automático de nós são ativados por padrão.

O recurso de reparo automático de nós detecta e corrige continuamente nós não íntegros em um cluster.

As verificações de integridade periódicas são executadas a cada 15 minutos. As verificações são iguais às realizadas por gkectl diagnose cluster. Os resultados são exibidos como registros e eventos em objetos Cluster no cluster de administrador.

Certifique-se de que os clusters de administrador e de usuário têm um endereço IP extra disponível para reparo automático de nós.

Condições de nó não íntegras

As seguintes condições indicam que um nó não está íntegro:

• A condição do nó NotReady é true por aproximadamente 10 minutos.

• O estado da máquina é Unavailable por aproximadamente 10 minutos após a criação.

• O estado da máquina não é Available por aproximadamente 30 minutos após a criação da VM.

• Não há objeto de nó (nodeRef é nil) correspondente a uma máquina no estado Available por aproximadamente 10 minutos.

• A condição do nó DiskPressure é true por aproximadamente 30 minutos.

Estratégia de reparo de nós

O GKE no VMware inicia um reparo em um nó se ele atender a pelo menos uma das condições da lista anterior.

O reparo drena o nó não íntegro e cria uma nova VM. Se a diminuição do nó falhar por uma hora, o reparo força a diminuição e desconecta os discos gerenciados do Kubernetes com segurança.

Se houver vários nós não íntegros na mesma MachineDeployment, o reparo será executado em apenas um desses nós por vez.

O número de reparos por hora em um pool de nós é limitado ao máximo de:

• Três
• 10% do número de nós no pool

Como ativar o reparo de nós e a verificação de integridade em um novo cluster

No arquivo de configuração do cluster admin ou de usuário, defina autoRepair.enabled como true:

autoRepair:
  enabled: true

Continue com as etapas para criar seu cluster de admin ou usuário.

Observação: como os nós do plano de controle do cluster de usuário estão localizados no cluster de administrador, siga as instruções do cluster de administrador se quiser que o reparo automático seja ativado para os nós do plano de controle do cluster de usuário.

Como ativar o reparo de nós e a verificação de integridade em um cluster de usuário

No arquivo de configuração do cluster do usuário, defina autoRepair.enabled como true:

Atualize o cluster:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Substitua:

• ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador;

• USER_CLUSTER_CONFIG: o caminho do arquivo de configuração do cluster de usuário.

Como ativar o reparo de nós e a verificação de integridade em um cluster de administrador atual

No arquivo de configuração do cluster de administrador, defina autoRepair.enabled como true:

Atualize o cluster:

gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG

Substitua ADMIN_CLUSTER_CONFIG pelo caminho do arquivo de configuração do cluster de administrador.

Como visualizar os registros de um verificador de integridade

Liste todos os pods do verificador de integridade no cluster de administrador:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep cluster-health-controller

A saída é semelhante a esta:

kube-system       cluster-health-controller-6c7df455cf-zlfh7   2/2   Running
my-user-cluster   cluster-health-controller-5d5545bb75-rtz7c   2/2   Running

Para ver os registros de um verificador de integridade específico, acesse os registros do contêiner cluster-health-controller em um dos pods. Por exemplo, para ver os registros do my-user-cluster mostrados na saída anterior:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace my-user-cluster logs \
    cluster-health-controller-5d5545bb75-rtz7c cluster-health-controller

Como visualizar eventos de um verificador de integridade

Liste todos os objetos no cluster de administrador:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get clusters --all-namespaces

A saída é semelhante a esta:

default            gke-admin-ldxh7   2d15h
my-user-cluster    my-user-cluster   2d12h

Para visualizar os eventos de um cluster específico, execute kubectl describe cluster com a sinalização --show-events. Por exemplo, para ver os eventos de my-user-cluster mostrados na saída anterior:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace my-user-cluster \
    describe --show-events cluster my-user-cluster

Exemplo de saída:

Events:
  Type     Reason             Age   From                                 Message
  ----     ------             ----  ----                                 -------
  Warning  ValidationFailure  17s   cluster-health-periodics-controller  validator for Pod returned with status: FAILURE, reason: 1 pod error(s).

Como desativar o reparo de nós e a verificação de integridade em um cluster de usuário

No arquivo de configuração do cluster do usuário, defina autoRepair.enabled como false:

Atualize o cluster:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Como desativar o reparo de nós e a verificação de integridade em um cluster de administrador

No arquivo de configuração do cluster de administrador, defina autoRepair.enabled como false:

Atualize o cluster:

gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG

Como depurar o reparo automático de nós

É possível investigar problemas com o reparo automático de nós. Basta descrever os objetos de máquina e de nós no cluster de administração. Veja um exemplo:

Liste os objetos da máquina:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG  get machines

Exemplo de saída:

default     gke-admin-master-wcbrj
default     gke-admin-node-7458969ff8-5cg8d
default     gke-admin-node-7458969ff8-svqj7
default     xxxxxx-user-cluster-41-25j8d-567f9c848f-fwjqt

Descreva um dos objetos da máquina:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG describe machine gke-admin-master-wcbrj

Na saída, procure eventos de cluster-health-controller.

Da mesma forma, é possível listar e descrever objetos de nó. Exemplo:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes
...
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG describe node gke-admin-master-wcbrj

Reparo manual de nós

Nó do plano de controle do administrador

O nó do plano de controle do administrador tem um comando dedicado, porque o reparo manual normal não funciona para ele.

Use gkectl repair admin-master para reparar o nó do plano de controle do administrador.

Nó do plano de controle do cluster de usuário do plano de controle V2

Os nós do plano de controle do cluster de usuário do plano de controle V2 são gerenciados de forma diferente dos outros nós.

Semelhante aos clusters de usuário do kubeception, os objetos Machine do plano de controle dos clusters de usuário do Controlplane V2 estão no cluster de administrador. O reparo automático de nós é coberto pelo reparo automático de nós do cluster de administrador.

Se houver problemas de nó que não são cobertos pela lógica de reparo automático do nó do cluster de administrador ou se você não tiver ativado o reparo automático do nó do cluster de administrador, faça um reparo manual. Isso exclui e recria o nó.

1. Consiga o nome do objeto de máquina que corresponde ao nó:

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME get machines
   

   Substitua:

   • ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig de administrador.
   • USER_CLUSTER_NAME: o nome do cluster de usuário de destino.

2. Adicione a anotação repair ao objeto da máquina:

   kubectl annotate --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME machine MACHINE_NAME onprem.cluster.gke.io/repair-machine=true
   

   Substitua MACHINE_NAME pelo nome do objeto da máquina.

3. Exclua o objeto da máquina:

   kubectl delete --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME machine MACHINE_NAME
   

Recrie o nó um a um para um plano de controle de alta disponibilidade. Caso contrário, ele pode encerrar o plano de controle inesperadamente.

Observação: um cluster de usuário do plano de controle V2 tem uma cópia dos objetos de máquina do plano de controle no próprio cluster de usuário. Esses objetos Machine são apenas para fins informativos. A exclusão deles não terá efeito.

Outros nós

Aviso:isso não funciona para o objeto de máquina do plano de controle do administrador. Não use para o objeto de máquina do plano de controle do administrador.

Aviso:isso não funciona para a cópia dos objetos de máquina do plano de controle nos clusters de usuário do plano de controle V2.

Se houver problemas de nó não cobertos pela lógica de reparo automático ou se você não tiver ativado o reparo automático de nós, será possível fazer um reparo manual. Isso exclui e recria o nó.

Consiga o nome do objeto de máquina que corresponde ao nó:

kubectl --kubeconfig CLUSTER_KUBECONFIG get machines

Substitua CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig do cluster de usuário ou administrador.

Adicione a anotação repair ao objeto da máquina:

kubectl annotate --kubeconfig CLUSTER_KUBECONFIG machine MACHINE_NAME onprem.cluster.gke.io/repair-machine=true

Substitua MACHINE_NAME pelo nome do objeto da máquina.

Exclua o objeto da máquina:

kubectl delete --kubeconfig CLUSTER_KUBECONFIG machine MACHINE_NAME