Reparação automática de nós e verificação do estado de funcionamento

No Google Distributed Cloud, a verificação periódica do estado de funcionamento e a reparação automática de nós estão ativadas por predefinição.

A funcionalidade de reparação automática de nós deteta e repara continuamente nós não íntegros num cluster.

As verificações de funcionamento periódicas são executadas a cada quinze minutos. As verificações são iguais às realizadas pela gkectl diagnose cluster. Os resultados são apresentados como registos e eventos em objetos de cluster no cluster de administrador.

Certifique-se de que os clusters de administrador e de utilizador têm cada um um endereço IP adicional disponível para a reparação automática de nós.

Se o cluster avançado estiver ativado, as verificações de estado periódicas não são executadas como parte da reparação automática.

Condições de nós não saudáveis quando o cluster avançado não está ativado

As seguintes condições são indicações de que um nó não está em bom estado de funcionamento quando enableAdvanceCluster é false.

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

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

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

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

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

Condições de nós não saudáveis quando o cluster avançado está ativado

As seguintes condições são indicações de que um nó não está em bom estado quando enableAdvanceCluster é true.

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

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

Estratégia de reparação de nós

O Google Distributed Cloud inicia uma reparação num nó se o nó cumprir, pelo menos, uma das condições na lista anterior.

A reparação esgota o nó não saudável e cria uma nova VM. Se a drenagem do nó não for bem-sucedida durante uma hora, a reparação força a drenagem e desanexa em segurança os discos geridos do Kubernetes anexados.

Se existirem vários nós não íntegros na mesma implementação de máquina, a reparação é realizada apenas num desses nós de cada vez.

O número de reparações por hora para um conjunto de nós está limitado ao máximo de:

  • Três
  • Dez por cento do número de nós no conjunto de nós

Ativar a reparação de nós e a verificação de funcionamento para um novo cluster

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

autoRepair:
  enabled: true

Continue com os passos para criar o cluster de administrador ou utilizador.

Ativar a reparação de nós e a verificação do estado de um cluster de utilizadores existente

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

Atualize o cluster:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Substitua o seguinte:

  • ADMIN_CLUSTER_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador

  • USER_CLUSTER_CONFIG: o caminho do ficheiro de configuração do cluster de utilizadores

Ativar a reparação de nós e a verificação de funcionamento para um cluster de administrador existente

No ficheiro 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 ficheiro de configuração do cluster de administrador.

Ver registos de um verificador de saúde

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

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

O resultado é semelhante a este:

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

Para ver os registos de um verificador de estado específico, aceda aos registos do contentor cluster-health-controller num dos pods. Por exemplo, para obter os registos de my-user-cluster apresentados na saída anterior:

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

Visualizar eventos de um verificador de estado

Liste todos os objetos Cluster no cluster de administrador:

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

O resultado é semelhante a este:

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

Para ver os eventos de um cluster específico, execute kubectl describe cluster com a flag --show-events. Por exemplo, para ver os eventos de my-user-cluster apresentados 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).

Desativar a reparação de nós e a verificação de funcionamento para um cluster de utilizadores

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

Atualize o cluster:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Desativar a reparação de nós e a verificação de funcionamento para um cluster de administrador

No ficheiro 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

Depuração da reparação automática de nós quando o cluster avançado não está ativado

Pode investigar problemas com a reparação automática de nós descrevendo os objetos de máquina e de nó no cluster de administrador. Segue-se um exemplo:

Indique 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 Machine:

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

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

Da mesma forma, pode listar e descrever objetos de nós. Por exemplo:

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

Depuração da reparação automática de nós quando o cluster avançado está ativado

Pode investigar problemas com a autorreparação de nós descrevendo os objetos Machine e Node no cluster de administração e no cluster correspondente, respetivamente. Segue-se um exemplo:

Indique 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 Machine:

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, pode listar e descrever objetos de nós. Por exemplo:

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

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

Nó do plano de controlo do administrador

O nó do plano de controlo do administrador tem um comando de reparação dedicado, porque a reparação manual normal não funciona para este.

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

Nó do plano de controlo do cluster de utilizadores do plano de controlo V2

Os nós do plano de controlo do cluster de utilizadores do Controlplane V2 são geridos de forma diferente dos outros nós.

Semelhante aos clusters de utilizadores do kubeception, os objetos de máquinas do plano de controlo dos clusters de utilizadores do plano de controlo V2 estão no cluster de administrador. Além disso, a autorreparação de nós é coberta pela autorreparação de nós do cluster de administrador.

Caso existam problemas de nós que não sejam abrangidos pela lógica de autorreparação de nós do cluster de administrador ou não tenha ativado a autorreparação de nós do cluster de administrador, pode fazer uma reparação manual. Esta ação elimina e recria o nó.

  1. Obtenha o nome do objeto Machine que corresponde ao nó:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME get machines

    Substitua o seguinte:

    • ADMIN_CLUSTER_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.
    • USER_CLUSTER_NAME: o nome do cluster de utilizadores de destino.

  2. Adicione a anotação repair ao objeto Machine:

    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 Machine.

  3. Elimine o objeto Machine:

    kubectl delete --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME machine MACHINE_NAME

Recrie o nó um a um para um plano de controlo de HA ou, caso contrário, pode desativar o plano de controlo inesperadamente.

Outros nós

Caso existam problemas de nós que não sejam abrangidos pela lógica de reparação automática ou não tenha ativado a reparação automática de nós, pode fazer uma reparação manual. Esta ação elimina e recria o nó.

Obtenha o nome do objeto Machine que corresponde ao nó:

kubectl --kubeconfig CLUSTER_KUBECONFIG get machines

Substitua CLUSTER_KUBECONFIG pelo caminho do ficheiro kubeconfig do cluster de administrador ou de utilizador.

Adicione a anotação repair ao objeto Machine:

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

Substitua MACHINE_NAME pelo nome do objeto Machine.

Elimine o objeto Machine:

kubectl delete --kubeconfig CLUSTER_KUBECONFIG machine MACHINE_NAME

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

Nó do plano de controlo do administrador

A reparação manual do nó do plano de controlo do administrador não é suportada

Nó do plano de controlo do cluster de utilizadores / nós trabalhadores

Obtenha o nome do objeto Inventory Machine que corresponde ao nó através do IP do nó para fazer corresponder os objetos:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME get inventorymachines

Substitua o seguinte: ADMIN_CLUSTER_KUBECONFIG: o caminho do seu ficheiro kubeconfig de administrador. USER_CLUSTER_NAME: o nome do cluster de utilizadores 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 Machine.

Elimine 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 controlo de HA ou, caso contrário, pode desativar o plano de controlo inesperadamente.