Os clusters do Anthos no VMware agora são o Google Distributed Cloud (somente software) para VMware. Para mais informações, consulte a visão geral do produto.

Esta página foi traduzida pela API Cloud Translation.

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

No Google Distributed Cloud, 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.

Se o cluster avançado estiver ativado, as verificações periódicas de integridade não serão executadas como parte do reparo automático.

Condições de nó não íntegras quando o cluster avançado não está ativado

As condições a seguir indicam que um nó não está íntegro quando enableAdvanceCluster é false.

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.

Condições de nó não íntegras quando o cluster avançado está ativado

As condições a seguir são indicações de que um nó não está íntegro quando enableAdvanceCluster é true.

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

Estratégia de reparo de nós

O Google Distributed Cloud inicia um reparo em um nó se ele 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 com segurança os discos gerenciados do Kubernetes anexados.

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 de administrador ou de usuário, defina autoRepair.enabled como true:

autoRepair:
  enabled: true

Continue com as etapas para criar seu cluster de administrador ou 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 de usuários, 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 de usuários, 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 quando o cluster avançado não está ativado

É 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

Como depurar o reparo automático de nós quando o cluster avançado está ativado

É 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 e no cluster correspondente, respectivamente. Veja um exemplo:

Liste os objetos da máquina:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG  get machines

Exemplo de saída:

NAMESPACE                            NAME          NODEPOOL
ci-1f6861fe28cac8fb390bc798927c717b  10.251.172.47 ci-1f6861fe28cac8fb390bc798927c717b-np
ci-1f6861fe28cac8fb390bc798927c717b  10.251.173.64 ci-1f6861fe28cac8fb390bc798927c717b-cp
ci-1f6861fe28cac8fb390bc798927c717b  10.251.173.66 ci-1f6861fe28cac8fb390bc798927c717b-cp
ci-1f6861fe28cac8fb390bc798927c717b  10.251.174.19 ci-1f6861fe28cac8fb390bc798927c717b-np
ci-1f6861fe28cac8fb390bc798927c717b  10.251.175.15 ci-1f6861fe28cac8fb390bc798927c717b-np
ci-1f6861fe28cac8fb390bc798927c717b  10.251.175.30 ci-1f6861fe28cac8fb390bc798927c717b-cp
kube-system                          10.251.172.239   gke-admin-bnbp9-cp
kube-system                          10.251.173.39    gke-admin-bnbp9-cp
kube-system                          10.251.173.6     gke-admin-bnbp9-cp

Descreva a máquina correspondente ao objeto:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG describe machine -n ci-1f6861fe28cac8fb390bc798927c717b 10.251.172.47

Na saída, procure eventos de auto-repair-controller.

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

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes
...
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe node ci-1f6861fe28cac8fb390bc798927c717b-np

Reparo manual de nós quando o cluster avançado não está ativado

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 Controlplane 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ó.

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 do cluster de administrador.
- USER_CLUSTER_NAME: o nome do cluster de usuário de destino.

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.

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.

Outros 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 administrador ou de usuário.

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

Reparo manual de nós quando o cluster avançado está ativado

Nó do plano de controle do administrador

O reparo manual do nó do plano de controle do administrador não é aceito

Nó do plano de controle do cluster de usuários / nós de trabalho

Conseguir o nome do objeto de máquina de inventário que corresponde ao nó usando o IP do nó para corresponder aos objetos:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME get inventorymachines

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

Adicione a anotação force-remove ao objeto Inventory Machine:

kubectl annotate --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME inventorymachine MACHINE_NAME baremetal.cluster.gke.io/force-remove=true

Substitua MACHINE_NAME pelo nome do objeto da máquina.

Exclua o objeto Inventory Machine:

kubectl delete --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME inventorymachine 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.