Coloque os nós no modo de manutenção

Quando precisar de reparar ou fazer a manutenção dos nós, deve primeiro colocá-los no modo de manutenção. Isto esgota graciosamente os pods e as cargas de trabalho existentes, excluindo os pods do sistema críticos, 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, pode trabalhar nos seus nós sem o risco de interromper o tráfego de pods.

Como funciona

O Google Distributed Cloud oferece uma forma de colocar nós no modo de manutenção. Esta abordagem permite que outros componentes do cluster saibam corretamente que o nó está no modo de manutenção. Quando coloca um nó no modo de manutenção, não é possível agendar mais pods no nó e os pods existentes são parados.

Em vez de usar o modo de manutenção, pode usar manualmente comandos do Kubernetes, como kubectl cordon e kubectl drain, num nó específico.

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

1,29

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

  • O Google Distributed Cloud usa a API de remoção para remover cada pod. Este método de esvaziamento de nós respeita os orçamentos de interrupção de pods (PDBs). Pode configurar PDBs para proteger as suas cargas de trabalho especificando um nível tolerável de interrupção para um conjunto de pods através dos campos minAvailable e maxUnavailable. A drenagem de nós desta forma oferece uma melhor proteção contra interrupções da carga de trabalho. A drenagem de nós baseada em despejo está disponível como DG para a versão 1.29.

  • É aplicado um limite de tempo de 20 minutos para garantir que os nós não ficam presos à espera que os pods parem. Os pods podem não parar se estiverem configurados para tolerar todas as falhas ou tiverem finalizadores. O Google Distributed Cloud tenta parar todos os pods, mas se o limite de tempo for excedido, o nó é colocado no modo de manutenção. Este limite de tempo impede que os pods em execução bloqueiem as atualizações.

1.28 e anterior

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

  • O Google Distributed Cloud adiciona a indicação baremetal.cluster.gke.io/maintenance:NoExecute. Ao agir sobre a contaminação NoExecute, o Google Distributed Cloud kube-scheduler para os pods e esvazia o nó. Este método de esvaziamento de nós não respeita os PDBs.

  • É aplicado um limite de tempo de 20 minutos para garantir que os nós não ficam presos à espera que os pods parem. Os pods podem não parar se estiverem configurados para tolerar todas as falhas ou tiverem finalizadores. O Google Distributed Cloud tenta parar todos os pods, mas se o limite de tempo for excedido, o nó é colocado no modo de manutenção. Este limite de tempo impede que os pods em execução bloqueiem as atualizações.

Drenagem baseada no despejo

Não existem alterações processuais associadas à mudança para a drenagem de nós baseada em despejos a partir da drenagem baseada em contaminações. A mudança afeta apenas a lógica de conciliação.

Esta capacidade não está na mesma fase de lançamento para todas as versões suportadas:

  • 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 contaminação realizada pelo Google Distributed Cloud kube-scheduler não usa um algoritmo específico para drenar pods de um nó. Com a drenagem de nós baseada na remoção, os pods são removidos numa ordem específica com base na prioridade. A prioridade de despejo está associada a critérios de pod específicos, conforme apresentado na tabela seguinte:

Ordem de drenagem Critérios do grupo (têm de 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 nenhum nome conhecido da interface de armazenamento de contentores (CSI)
  • 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 nenhum nome conhecido da interface de armazenamento de contentores (CSI)
3

Os pods que correspondem aos seguintes critérios são removidos:

  • Agrupamentos com Spec.ProrityClassName
  • Pods que não correspondem a nenhum nome conhecido da interface de armazenamento de contentores (CSI)

A ordem de despejo dos pods correspondentes baseia-se em PriorityClass.value, do valor mais baixo para o mais alto.
4

Aguarde que o CSI limpe as montagens de PV/PVC depois de todos os pods serem despejados. 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 de contentores (CSI)

Estes pods continuam a precisar de esvaziamento, porque o kubelet não oferece compatibilidade de atualização no local.

Uma vez que a drenagem de nós baseada na expulsão respeita os PDBs, as definições de PDB podem bloquear a drenagem de nós em algumas circunstâncias. Para ver informações de resolução de problemas sobre a drenagem do conjunto de nós, consulte o artigo Verifique o motivo pelo qual um nó está no estado de drenagem há muito tempo.

Desative a drenagem de nós baseada na remoção

A drenagem de nós baseada em despejo está ativada por predefinição para clusters na versão secundária 1.29 e posteriores ou clusters que estão a ser atualizados para a versão secundária 1.29 e posteriores. Se a drenagem de nós baseada na expulsão estiver a causar problemas com as atualizações ou a manutenção do cluster, pode reverter para a drenagem de nós baseada em manchas adicionando a anotação baremetal.cluster.gke.io/maintenance-mode-ignore-pdb: "" ao recurso do cluster.

Para restaurar o comportamento de esvaziamento de nós predefinido baseado na expulsão, remova completamente a anotação. Se definir a anotação como false, não volta a ativar o comportamento predefinido.

Coloque um nó no modo de manutenção

Escolha os nós que quer colocar no modo de manutenção especificando intervalos de IP para os nós selecionados em maintenanceBlocks no ficheiro de configuração do cluster. Os nós que escolher têm de estar num estado pronto e a funcionar no cluster.

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

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

    Pode editar o ficheiro de configuração com um editor à sua escolha ou pode editar o recurso personalizado do cluster diretamente executando o seguinte comando:

    kubectl -n CLUSTER_NAMESPACE edit cluster CLUSTER_NAME

    Substitua o seguinte:

    • CLUSTER_NAMESPACE: o espaço de nomes do cluster.
    • CLUSTER_NAME: o nome do cluster.

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

    O exemplo seguinte 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. Guarde e aplique a configuração do cluster atualizada.

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

  4. Execute o seguinte comando para obter o estado dos nós no cluster:

    kubectl get nodes --kubeconfig=KUBECONFIG

    O resultado é semelhante ao seguinte:

    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

    Tenha em atenção que os nós continuam a ser agendáveis, mas as restrições impedem que os pods (sem uma tolerância adequada) sejam agendados no nó.

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

    kubectl get nodepools --kubeconfig ADMIN_KUBECONFIG

    A resposta deve ter um aspeto semelhante ao seguinte exemplo:

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

    Esta coluna UNDERMAINTENANCE neste exemplo mostra que um nó está no modo de manutenção.

    O Google Distributed Cloud também adiciona as seguintes restrições aos nós quando são colocados no modo de manutenção:

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

Remova um nó do modo de manutenção

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

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

    Pode editar o ficheiro de configuração com um editor à sua escolha ou pode editar o recurso personalizado do cluster diretamente executando o seguinte comando:

    kubectl -n CLUSTER_NAMESPACE edit cluster CLUSTER_NAME

    Substitua o seguinte:

    • CLUSTER_NAMESPACE: o espaço de nomes 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 secção maintenanceBlocks para remover todos os nós do modo de manutenção.

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

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

Encerre e reinicie um cluster

Se for necessário desativar um cluster completo, use as instruções nas secções seguintes para desativar um cluster e reativá-lo em segurança.

Encerre um cluster

Se estiver a encerrar um cluster que gere clusters de utilizadores, tem de encerrar primeiro todos os clusters de utilizadores geridos. As instruções seguintes aplicam-se a todos os tipos de clusters do Google Distributed Cloud.

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

    kubectl get nodes --kubeconfig CLUSTER_KUBECONFIG

    Substitua CLUSTER_KUBECONFIG pelo caminho do ficheiro kubeconfig do cluster.

    O resultado é semelhante ao seguinte:

    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 vivamente que resolva os problemas do nó e avance apenas quando todos os nós forem Ready.

  2. Se estiver a encerrar um cluster de utilizadores, verifique o estado dos nós do cluster de administrador:

    kubectl get nodes --kubeconfig ADMIN_KUBECONFIG

    Substitua ADMIN_KUBECONFIG pelo caminho do ficheiro kubeconfig para o cluster de gestão.

    Os passos subsequentes têm uma dependência do cluster de administrador. Se o STATUS de um nó não for Ready, recomendamos vivamente que resolva os problemas do nó e só avance quando todos os nós forem Ready.

  3. Verifique o estado do cluster que quer encerrar:

    bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

    Substitua o seguinte:

    • CLUSTER_NAME: o nome do cluster que está a verificar.

    • ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig para o cluster de gestão.

    Corrija os problemas comunicados antes de continuar.

  4. Para o cluster que está a encerrar, certifique-se de que todos os etcd pods estão em execução:

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

    Substitua CLUSTER_KUBECONFIG pelo caminho do ficheiro kubeconfig do cluster.

    O resultado é semelhante ao seguinte:

    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 for Running, recomendamos vivamente que resolva os problemas do pod e só continue quando todos os pods forem Running.

  5. Faça uma cópia de segurança conforme descrito em Faça uma cópia de segurança de um cluster.

    É importante fazer uma cópia de segurança do etcd antes de encerrar o cluster para que o cluster possa ser restaurado se encontrar problemas ao reiniciar o cluster. A corrupção do etcd, as falhas de hardware dos nós, os problemas de conetividade de rede e, potencialmente, outras condições podem impedir o reinício adequado do cluster.

  6. Se estiver a encerrar um cluster com nós de trabalho, coloque os nós de trabalho no modo de manutenção.

    Este passo minimiza a quantidade de escrita para o etcd, o que reduz a probabilidade de ter de reconciliar uma grande quantidade de escritas do etcd quando o cluster é reiniciado.

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

    Este passo evita escritas danificadas para cargas de trabalho com estado durante o encerramento do nó.

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

    1. Nós trabalhadores
    2. Nós do balanceador de carga do plano de controlo

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

      Se tiver um cluster de alta disponibilidade (HA), pode encontrar o líder do etcd através do SSH para estabelecer ligação a cada nó do plano de controlo e executar 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 inclui uma coluna IS LEADER, que devolve true se o nó for o líder do etcd.

Neste ponto, o cluster está completamente encerrado. Depois de realizar a manutenção necessária, pode reiniciar o cluster conforme descrito na secção seguinte.

Reinicie o cluster

Siga estes passos para reiniciar um cluster que foi completamente desligado.

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

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

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

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

  4. Execute verificações de funcionamento do cluster para garantir que o cluster está a funcionar corretamente:

    bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

  5. Se um problema, como um ciclo de falhas do etcd, impedir o reinício correto do cluster, experimente restaurar o cluster a partir da última cópia de segurança funcional conhecida. Para ver instruções, consulte o artigo Restaurar um cluster.

Modo de faturação e manutenção

A faturação do Google Distributed Cloud baseia-se no número de vCPUs que o cluster tem para nós capazes de executar cargas de trabalho. Quando coloca um nó no modo de manutenção, são adicionadas contaminações NoExecute e NoSchedule ao nó, mas não desativam a faturação. Depois de colocar um nó no modo de manutenção, isole o nó (kubectl cordon NODE_NAME) para o marcar como não agendável. Quando um nó é marcado como não agendável, o nó e as respetivas vCPUs associadas são excluídos da faturação.

Conforme descrito na página de preços, pode usar kubectl para ver a capacidade de vCPU (usada para faturação) de cada um dos seus clusters de utilizadores. O comando não tem em consideração se o nó é agendável ou não. Apenas fornece uma contagem de vCPUs por nó.

Para identificar o número de vCPUs por nó para o cluster de utilizadores:

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

Substitua USER_KUBECONFIG pelo caminho do ficheiro kubeconfig para o seu cluster de utilizador.