Colocar nós no modo de manutenção

Quando você precisar reparar ou manter os nós, primeiro coloque-os no modo de manutenção. Isso drena normalmente os pods e as cargas de trabalho existentes, excluindo pods críticos do sistema, como o servidor da API. O modo de manutenção também impede que o nó receba novas atribuições de pods. No modo de manutenção, é possível trabalhar nos nós sem o risco de interromper o tráfego dos pods.

Observação: ao fazer upgrade de um cluster, o Google Distributed Cloud usa o fluxo do modo de manutenção descrito nesta página para drenar os nós antes do upgrade. Para mais informações sobre o processo de upgrade, consulte Ciclo de vida e etapas dos upgrades de cluster.

Como funciona

O Google Distributed Cloud oferece uma maneira de colocar nós no modo de manutenção. Essa abordagem permite que outros componentes do cluster saibam corretamente que o nó está no modo de manutenção. Ao colocar um nó no modo de manutenção, nenhum pod adicional pode ser programado no nó, e os pods existentes são interrompidos.

Em vez de usar o modo de manutenção, é possível usar manualmente os comandos do Kubernetes, como kubectl cordon e kubectl drain, em um nó específico.

Quando você usa o processo do modo de manutenção, o Google Distributed Cloud faz isto:

1,29

• O Google Distributed Cloud adiciona o taint baremetal.cluster.gke.io/maintenance:NoSchedule aos nós especificados para impedir a programação de novos pods no nó.

• O Google Distributed Cloud usa a API Eviction para remover cada pod. Esse método de drenagem de nós respeita os PodDisruptionBudgets (PDBs). É possível configurar PDBs para proteger suas cargas de trabalho especificando um nível tolerável de interrupção para um conjunto de pods com os campos minAvailable e maxUnavailable. Dessa forma, a drenagem de nós oferece uma proteção melhor contra interrupções de carga de trabalho. A drenagem de nós baseada em remoção está disponível como GA para a versão 1.29.

• É aplicado um tempo limite de 20 minutos para garantir que os nós não fiquem travados enquanto os pods são interrompidos. Os pods não serão encerrados se estiverem configurados para tolerar todos os taints ou tiverem finalizadores. O Google Distributed Cloud tenta interromper todos os pods, mas, se o tempo limite for excedido, o nó será colocado no modo de manutenção. Esse tempo limite impede que os pods em execução bloqueiem os upgrades.

1.28 e versões anteriores

• O Google Distributed Cloud adiciona o taint baremetal.cluster.gke.io/maintenance:NoSchedule aos nós especificados para impedir a programação de novos pods no nó.

• O Google Distributed Cloud adiciona o taint baremetal.cluster.gke.io/maintenance:NoExecute. Agindo com o taint NoExecute, o kube-scheduler do Google Distributed Cloud interrompe os pods e drena o nó. Esse método de drenagem de nós não respeita os PDBs.

• É aplicado um tempo limite de 20 minutos para garantir que os nós não fiquem travados enquanto os pods são interrompidos. Os pods não serão encerrados se estiverem configurados para tolerar todos os taints ou tiverem finalizadores. O Google Distributed Cloud tenta interromper todos os pods, mas, se o tempo limite for excedido, o nó será colocado no modo de manutenção. Esse tempo limite impede que os pods em execução bloqueiem os upgrades.

Drenagem baseada em remoção

Não há mudanças procedurais associadas à troca da drenagem baseada em taint pela drenagem de nós baseada em remoção. A troca afeta apenas a lógica de reconciliação.

Esse recurso não está na mesma fase de lançamento para todas as versões compatíveis:

• 1.29: GA
• 1.28: não disponível
• 1.16: não disponível

Ordem de drenagem

Antes da versão 1.29, a drenagem de nós baseada em taint realizada pelo kube-scheduler do Google Distributed Cloud não usava um algoritmo específico para drenar pods de um nó. Com a drenagem de nós baseada em remoção, os pods são removidos em uma ordem específica com base na prioridade. A prioridade de remoção é associada a critérios específicos de pods, conforme mostrado na tabela a seguir:

Ordem de drenagem	Critérios do pod (precisam corresponder a todos) e
1	Os pods que correspondem aos seguintes critérios são removidos: Pods sem spec.prorityClassName Pods que não correspondem a qualquer nome conhecido da Interface de armazenamento em contêineres (CSI, na sigla em inglês) Pods que não pertencem a um DaemonSet
2	Os pods que correspondem aos seguintes critérios são removidos: Pods que pertencem a um DaemonSet Os pods não têm PriorityClass Pods que não correspondem a qualquer nome conhecido da Interface de armazenamento em contêineres (CSI, na sigla em inglês)
3	Os pods que correspondem aos seguintes critérios são removidos: Pods com Spec.ProrityClassName Pods que não correspondem a qualquer nome conhecido da Interface de armazenamento em contêineres (CSI, na sigla em inglês) A ordem de remoção de pods correspondentes é baseada em PriorityClass.value, do menor para o maior.
4	Aguarde a CSI limpar as montagens de PV/PVC depois que todos os pods forem removidos. Use Node.Status.VolumesInUse para indicar que todos os volumes foram limpos.
5	Os pods que correspondem aos seguintes critérios são removidos: Pods que correspondem a um nome conhecido da interface de armazenamento em contêineres (CSI) Esses pods ainda precisam ser drenados, porque o kubelet não oferece a compatibilidade de upgrade no local.

Como a drenagem de nós baseada em remoção respeita os PDBs, as configurações de PDB podem bloquear a drenagem de nós em algumas situações. Para informações sobre solução de problemas de drenagem de pools de nós, consulte Verificar por que um nó está no status de drenagem há muito tempo.

Desativar a drenagem de nós baseada em remoção

A drenagem de nós baseada em remoção é ativada por padrão para clusters na versão secundária 1.29 ou clusters que farão upgrade para a versão secundária 1.29. Se a drenagem de nós baseada em remoção estiver causando problemas com upgrades ou manutenção de clusters, reverta para a drenagem de nós baseada em taint adicionando a anotação baremetal.cluster.gke.io/maintenance-mode-ignore-pdb: true ao seu recurso de cluster.

Colocar um nó no modo de manutenção

Escolha os nós que você quer colocar no modo de manutenção especificando os intervalos de IPs dos nós selecionados em maintenanceBlocks no arquivo de configuração do cluster. Os nós escolhidos precisam estar prontos e funcionando no cluster.

Para colocar nós no modo de manutenção:

1. Edite o arquivo de configuração do cluster para selecionar os nós que você quer colocar no modo de manutenção.

   É possível editar o arquivo de configuração com um editor de sua preferência ou editar o recurso personalizado do cluster diretamente executando o seguinte comando:

   kubectl -n CLUSTER_NAMESPACE edit cluster CLUSTER_NAME

   Substitua:

   • CLUSTER_NAMESPACE: o namespace do cluster.
   • CLUSTER_NAME: o nome do cluster.

2. Adicione a seção maintenanceBlocks ao arquivo de configuração do cluster para especificar um único endereço IP ou um intervalo de endereços para os nós que você quer colocar no modo de manutenção.

   O exemplo a seguir mostra como selecionar vários nós especificando um intervalo de endereços IP:

   metadata:
     name: my-cluster
     namespace: cluster-my-cluster
   spec:
     maintenanceBlocks:
       cidrBlocks:
       - 172.16.128.1-172.16.128.64
   

3. Salve e aplique a configuração atualizada do cluster.

   O Google Distributed Cloud começa a colocar os nós no modo de manutenção.

4. Execute o seguinte comando para ver o status dos nós no cluster:

   kubectl get nodes --kubeconfig=KUBECONFIG

   O resultado será assim:

   NAME                STATUS   ROLES           AGE     VERSION
   user-baremetal-01   Ready    control-plane   2d22h   v1.27.4-gke.1600
   user-baremetal-04   Ready    worker          2d22h   v1.27.4-gke.1600
   user-baremetal-05   Ready    worker          2d22h   v1.27.4-gke.1600
   user-baremetal-06   Ready    worker          2d22h   v1.27.4-gke.1600
   

   Os nós ainda são programáveis, mas os taints impedem a programação de qualquer pod (sem uma tolerância adequada).

5. Execute o seguinte comando para ver o número de nós no modo de manutenção:

   kubectl get nodepools --kubeconfig ADMIN_KUBECONFIG 
   

   A resposta será semelhante a esta:

   NAME   READY   RECONCILING   STALLED   UNDERMAINTENANCE   UNKNOWN
   np1    3       0             0         1                  0
   

   Na coluna UNDERMAINTENANCE neste exemplo, vemos que um nó está no modo de manutenção.

   O Google Distributed Cloud também adiciona os seguintes taints aos nós quando eles são colocados no modo de manutenção:

   • baremetal.cluster.gke.io/maintenance:NoExecute
   • baremetal.cluster.gke.io/maintenance:NoSchedule

Remover um nó do modo de manutenção

Para remover nós do modo de manutenção:

1. Edite o arquivo de configuração do cluster para limpar os nós que você quer remover do modo de manutenção.

   É possível editar o arquivo de configuração com um editor de sua preferência ou editar o recurso personalizado do cluster diretamente executando o seguinte comando:

   kubectl -n CLUSTER_NAMESPACE edit cluster CLUSTER_NAME

   Substitua:

   • CLUSTER_NAMESPACE: o namespace do cluster.
   • CLUSTER_NAME: o nome do cluster.

2. Edite os endereços IP para remover nós específicos do modo de manutenção ou remova a seção maintenanceBlocks para remover todos os nós do modo de manutenção.

3. Salve e aplique a configuração atualizada do cluster.

4. Use comandos kubectl para verificar o status dos nós.

Desligar e reiniciar um cluster

Se for necessário desativar um cluster completo, use as instruções nas próximas seções para desligar um cluster e reativá-lo com segurança.

Desligar um cluster

Se você estiver desativando um cluster que gerencia clusters de usuários, primeiro desative todos esses clusters gerenciados. As instruções a seguir se aplicam a todos os tipos de cluster do Google Distributed Cloud.

1. Verifique o status de todos os nós do cluster:

   kubectl get nodes --kubeconfig CLUSTER_KUBECONFIG
   

   Substitua CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig do cluster.

   O resultado será assim:

   NAME        STATUS   ROLES           AGE    VERSION
   control-0   Ready    control-plane   202d   v1.27.4-gke.1600
   control-1   Ready    control-plane   202d   v1.27.4-gke.1600
   control-2   Ready    control-plane   202d   v1.27.4-gke.1600
   worker-0    Ready    worker          202d   v1.27.4-gke.1600
   worker-1    Ready    worker          202d   v1.27.4-gke.1600
   worker-2    Ready    worker          202d   v1.27.4-gke.1600
   worker-3    Ready    worker          202d   v1.27.4-gke.1600
   worker-4    Ready    worker          154d   v1.27.4-gke.1600
   worker-5    Ready    worker          154d   v1.27.4-gke.1600
   worker-6    Ready    worker          154d   v1.27.4-gke.1600
   worker-7    Ready    worker          154d   v1.27.4-gke.1600
   worker-8    Ready    worker          154d   v1.27.4-gke.1600
   worker-9    Ready    worker          154d   v1.27.4-gke.1600
   

   Se o STATUS de um nó não for Ready, recomendamos que você resolva o problema e continue apenas quando todos os nós estiverem prontos (Ready).

2. Se você estiver desativando um cluster de usuário, verifique o status dos nós do cluster de administrador:

   kubectl get nodes --kubeconfig ADMIN_KUBECONFIG
   

   Substitua ADMIN_KUBECONFIG pelo caminho do arquivo kubeconfig do cluster gerenciado.

   As etapas seguintes dependem do cluster de administrador. Se o STATUS de um nó não for Ready, recomendamos que você resolva o problema e continue apenas quando todos os nós estiverem prontos (Ready).

3. Verifique a integridade do cluster que você quer desligar:

   bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
   

   Substitua:

   • CLUSTER_NAME: o nome do cluster que você está verificando.

   • ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster gerenciado.

   Corrija todos os problemas relatados antes de continuar.

4. No cluster que você desligará, verifique se todos os pods etcd estão em execução:

   kubectl get pods --kubeconfig CLUSTER_KUBECONFIG -A \
       -l component=etcd
   

   Substitua CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig do cluster.

   O resultado será assim:

   NAMESPACE     NAME                   READY   STATUS    RESTARTS   AGE
   kube-system   etcd-control-0-admin   1/1     Running   0          2d22h
   kube-system   etcd-control-1-admin   1/1     Running   0          2d22h
   kube-system   etcd-control-2-admin   1/1     Running   0          2d22h
   

   Se o STATUS de um pod não estiver Running, recomendamos que você resolva o problema e continue apenas quando todos os pods estiverem em execução (Running).

5. Faça um backup conforme descrito em Fazer backup de um cluster.

   É importante fazer um backup do etcd antes de desligar o cluster para que ele possa ser restaurado se você encontrar algum problema ao reiniciar o cluster. Corrupção do etcd, falhas de hardware do nó, problemas de conectividade de rede e outras condições podem impedir que o cluster seja reiniciado corretamente.

6. Se você estiver desligando um cluster com nós de trabalho, coloque-os no modo de manutenção.

   Essa etapa minimiza a quantidade de gravações no etcd, o que reduz a probabilidade de que uma grande quantidade de gravações do etcd precise ser reconciliada quando o cluster for reiniciado.

7. Coloque os nós do plano de controle no modo de manutenção.

   Essa etapa evita gravações corrompidas para cargas de trabalho com estado durante o desligamento do nó.

8. Desligue os nós do cluster na seguinte sequência:

   1. Nós de trabalho
   2. Nós do balanceador de carga do plano de controle

   3. Nós do plano de controle, começando pelos seguidores do etcd e terminando pelo líder do etcd.

      Se você tiver um cluster de alta disponibilidade (HA), encontre o líder do etcd usando o SSH para se conectar a cada nó do plano de controle e executando o seguinte comando etcdctl:

      ETCDCTL_API=3 etcdctl \
          --cacert /etc/kubernetes/pki/etcd/ca.crt \
          --cert /etc/kubernetes/pki/etcd/server.crt \
          --key /etc/kubernetes/pki/etcd/server.key \
          --write-out=table endpoint status
      

      A resposta contém uma coluna IS LEADER, que retornará true se o nó for o líder do etcd.

   Observação: o servidor da API fica inativo quando os seguidores do etcd estão inativos. Isso acontece porque o servidor da API não pode atender às solicitações quando o cluster etcd perde o quórum, que é o esperado ao desligar. O etcd recupera o quórum quando todos os nós do plano de controle voltam a ficar on-line.

Nesse momento, o cluster é completamente desligado. Depois de realizar qualquer manutenção necessária, reinicie o cluster conforme descrito na próxima seção.

Reiniciar o cluster

Siga as etapas abaixo para reiniciar um cluster que foi completamente desligado.

1. Ligue as máquinas de nó na ordem inversa da sequência de desligamento.

2. Remova do modo de manutenção os nós do plano de controle.

   Para instruções, consulte Remover um nó do modo de manutenção.

   Observação: não é necessário tirar as máquinas do modo de manutenção uma por vez, mas é recomendável começar com um único nó, verificar se ele está íntegro e aumentar lentamente o número de nós ao longo do tempo.

3. Remova do modo de manutenção os nós de trabalho.

4. Execute verificações de integridade do cluster para garantir que ele esteja funcionando corretamente:

   bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
   

5. Se um problema, como um loop de falha do etcd, impedir que o cluster seja reinicializado corretamente, tente restaurar o cluster pelo último backup válido conhecido. Para instruções, consulte Restaurar um cluster.

Modo de faturamento e manutenção

O faturamento do Google Distributed Cloud é baseado no número de vCPUs que o cluster tem para nós capazes de executar cargas de trabalho. Quando você coloca um nó no modo de manutenção, os taints NoExecute e NoSchedule são adicionados ao nó, mas não desativam o faturamento. Depois de colocar um nó no modo de manutenção, demarque o nó (kubectl cordon NODE_NAME) para marcá-lo como não programável. Depois que um nó é marcado como não programável, ele e as vCPUs associadas são excluídos do faturamento.

Importante: o desligamento de um nó não altera o status de faturamento. Para excluir um nó do faturamento, escolha uma destas opções:

• Remover um nó individual de um pool de nós
• Remover um pool de nós do cluster
• Colocar um nó no modo de manutenção e demarcá-lo para torná-lo não programável

Conforme descrito na página de preços, é possível usar kubectl para conferir a capacidade de vCPU (usada para o faturamento) de cada cluster de usuário. O comando não considera se o nó está ou não programável. Ele fornece apenas uma contagem de vCPU por nó.

Para identificar o número de vCPUs por nó do cluster de usuário:

kubectl get nodes \
    --kubeconfig USER_KUBECONFIG \
    -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"} \
    {.status.capacity.cpu}{\"\n\"}{end}"

Substitua USER_KUBECONFIG pelo caminho do arquivo kubeconfig do cluster de usuário.