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

Version 1.11 

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

Nos clusters do Anthos no VMware (GKE On-Prem), a verificação de integridade periódica 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 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

Os clusters do Anthos no VMware iniciam um reparo em um nó se o nó atender a pelo menos uma das condições na 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 administrador ou de usuário, defina autoRepair.enabled como true:

autoRepair:
  enabled: true

Continue com as etapas para criar seu cluster de administrador 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ó. Por exemplo:

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

Reparo manual de nós

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