Reparos automáticos de nós

O recurso de reparo automático de nós monitora continuamente a integridade de cada nó em um pool. Se um nó se tornar não íntegro, o recurso de reparo automático de nó o repara automaticamente. Esse recurso diminui a probabilidade de interrupções do cluster e a degradação do desempenho, além de minimizar a necessidade de manutenção manual dos clusters.

É possível ativar o reparo automático de nós ao criar ou atualizar um pool de nós. Esse recurso é ativado ou desativado em pools de nós, e não em nós individuais.

Condições de nó não íntegras

O reparo automático de nós examina o status de integridade de cada nó para determinar se ele exige reparo. Um nó é considerado íntegro se informar um status Ready. Caso contrário, se ele relatar consecutivamente um status não íntegro por uma duração específica, os reparos serão iniciados.

Um status não íntegro pode surgir de um estado NotReady, detectado em verificações consecutivas em aproximadamente 15 minutos. Como alternativa, um status não íntegro pode resultar de espaço esgotado no disco de inicialização, identificado durante um período de aproximadamente 30 minutos.

Verifique manualmente os sinais de integridade do nó a qualquer momento executando o comando kubectl get nodes.

Estratégias de reparo de nós

O reparo automático de nós segue determinadas estratégias para garantir a integridade geral do cluster e a disponibilidade dos aplicativos durante o processo de reparo. Nesta seção, descrevemos como o recurso de reparo automático de nós respeita as configurações de PodDisruptionBudget, respeita a Pod Termination Grace Period e toma outras medidas que minimizam a interrupção do cluster ao reparar nós.

Honre PodDisruptionBudget por 30 minutos

Se um nó exigir reparo, ele não será drenado instantaneamente e recriado. Em vez disso, o recurso de reparo automático de nós atende às configurações de PodDisruptionBudget (PDB) por até 30 minutos. Após esse período, todos os pods no nó são excluídos. Uma configuração de PDB define, entre outras coisas, o número mínimo de réplicas de um pod específico que precisa estar disponível a qualquer momento.

Ao honrar o PodDisruptionBudget por aproximadamente 30 minutos, o recurso de reparo automático de nós oferece uma janela de oportunidade para que os pods sejam reprogramados e redistribuídos com segurança em outros nós íntegros no cluster. Isso ajuda a manter o nível desejado de disponibilidade do aplicativo durante o processo de reparo.

Após o limite de tempo de 30 minutos, o reparo automático de nós continuará com o processo de reparo, mesmo que isso viole a PodDisruptionBudget. Sem um limite de tempo, o processo poderá ser interrompido indefinidamente se a configuração PodDisruptionBudget impedir as remoções necessárias.

Respeitar o período de carência do encerramento do pod

O recurso de reparo automático de nós também cumpre um período de carência de encerramento de pod (link em inglês) de aproximadamente 30 minutos. O período de carência do encerramento do pod oferece aos pods uma janela de tempo para um encerramento progressivo. Durante o período de carência, o kubelet em um nó é responsável por executar tarefas de limpeza e liberar recursos associados aos pods nesse nó. O recurso de reparo automático de nós permite até 30 minutos para que o kubelet conclua essa limpeza. Se os 30 minutos alocados acabarem, o nó será forçado a ser encerrado, independentemente de os pods terem sido encerrados normalmente.

Estratégias extras de reparo de nós

O reparo automático de nós também implementa as seguintes estratégias:

  • Se vários nós precisarem de reparo, eles serão reparados um de cada vez para limitar a interrupção do cluster e proteger as cargas de trabalho.
  • Se você desativar o reparo automático de nós durante o processo, os reparos em andamento continuarão assim até que a operação de reparo seja bem-sucedida ou falhe.

Como ativar e desativar o reparo automático de nós

É possível ativar ou desativar o reparo automático de nós ao criar ou atualizar um pool de nós. Esse recurso é ativado ou desativado em pools de nós, e não em nós individuais.

Ativar o reparo automático de um novo pool de nós

gcloud container aws node-pools create NODE_POOL_NAME \
   --cluster CLUSTER_NAME \
   --instance-type INSTANCE_TYPE \
   --root-volume-size ROOT_VOLUME_SIZE \
   --iam-instance-profile NODEPOOL_PROFILE \
   --node-version NODE_VERSION \
   --min-nodes MIN_NODES \
   --max-nodes MAX_NODES \
   --max-pods-per-node MAX_PODS_PER_NODE \
   --location GOOGLE_CLOUD_LOCATION \
   --subnet-id NODEPOOL_SUBNET \
   --ssh-ec2-key-pair SSH_KEY_PAIR_NAME \
   --config-encryption-kms-key-arn CONFIG_KMS_KEY_ARN \
   --tags "Name=CLUSTER_NAME-NODE_POOL_NAME" \
   --enable-autorepair

Substitua:

  • NODE_POOL_NAME: o nome escolhido para o pool de nós. Para conferir os nomes dos pools de nós, execute o comando gcloud container aws node-pools list --cluster CLUSTER_NAME --location GOOGLE_CLOUD_LOCATION.
  • CLUSTER_NAME: o nome do cluster ao qual o pool de nós será anexado
  • INSTANCE_TYPE: o tipo de instância de máquina da AWS pretendido para este pool de nós, por exemplo, m5.large;
  • ROOT_VOLUME_SIZE: o tamanho desejado para o volume raiz de cada nó, em Gb.
  • NODEPOOL_PROFILE: o perfil de instância do IAM para VMs de pool de nós
  • NODE_VERSION: a versão do Kubernetes a ser instalada em cada nó no pool de nós (por exemplo, "1.29.3-gke.600")
  • MIN_NODES: o número mínimo de nós que o pool pode conter.
  • MAX_NODES: o número máximo de nós que o pool pode conter.
  • MAX_PODS_PER_NODE: o número máximo de pods que podem ser criados em qualquer nó no pool;
  • GOOGLE_CLOUD_LOCATION: o nome do local do Google Cloud a partir do qual esse pool de nós será gerenciado;
  • NODEPOOL_SUBNET: o ID da sub-rede em que o pool de nós será executado;
    • Não pode haver nenhuma sobreposição entre os intervalos de IP de pod/serviço do cluster e a rede de sub-rede do pool de nós. Para mais informações sobre como selecionar intervalos de IP do pod e do serviço para o cluster, consulte Selecionar intervalos CIDR para o cluster.
    • Se essa sub-rede estiver fora do bloco CIDR primário de VPC, algumas etapas adicionais serão necessárias. Para mais informações, consulte grupos de segurança.
  • SSH_KEY_PAIR_NAME: o nome do par de chaves SSH da AWS criado para acesso SSH (opcional)
  • CONFIG_KMS_KEY_ARN: o nome de recurso da Amazon (ARN) da chave de KMS da AWS que criptografa os dados do usuário;

Ativar o reparo automático de um pool de nós atual

Para ativar o reparo automático de nós em um pool de nós, execute o seguinte comando:

gcloud container aws node-pools update NODE_POOL_NAME \
   --cluster CLUSTER_NAME \
   --location GOOGLE_CLOUD_LOCATION \
   --enable-autorepair

Substitua:

  • NODE_POOL_NAME: um nome exclusivo para o pool de nós, por exemplo, node-pool-1
  • CLUSTER_NAME: o nome do cluster
  • GOOGLE_CLOUD_LOCATION: a região do Google Cloud que gerencia o cluster

Desativar o reparo automático de um pool de nós

gcloud container aws node-pools update NODE_POOL_NAME \
   --cluster CLUSTER_NAME \
   --location GOOGLE_CLOUD_LOCATION \
   --no-enable-autorepair

Substitua:

  • NODE_POOL_NAME: um nome exclusivo para o pool de nós, por exemplo, node-pool-1
  • CLUSTER_NAME: o nome do cluster
  • GOOGLE_CLOUD_LOCATION: a região do Google Cloud que gerencia o cluster

Observe que o GKE na AWS desativa o reparo automático de nós. Ao desativar o reparo automático de nós em um pool de nós atual, o GKE na AWS inicia uma operação de atualização do pool de nós. A operação aguarda a reparação de qualquer nó antes de prosseguir.

Verificar se o reparo automático de nós está ativado

Execute o seguinte comando para verificar se o reparo automático de nós está ativado:

gcloud container aws node-pools describe NODE_POOL_NAME \
   --cluster CLUSTER_NAME \
   --location GOOGLE_CLOUD_LOCATION

Substitua:

  • NODE_POOL_NAME: um nome exclusivo para o pool de nós, por exemplo, node-pool-1
  • CLUSTER_NAME: o nome do cluster
  • GOOGLE_CLOUD_LOCATION: a região do Google Cloud que gerencia o cluster

Histórico de reparo de nós

É possível ver o histórico de reparos realizados em um pool de nós executando o seguinte comando:

gcloud container aws operations list \
   --location GOOGLE_CLOUD_LOCATION \
   --filter="metadata.verb=repair AND metadata.target=projects/PROJECT_ID/locations/GOOGLE_CLOUD_LOCATION/awsClusters/CLUSTER_NAME/awsNodePools/NODEPOOL_NAME

Substitua:

  • GOOGLE_CLOUD_LOCATION: a região compatível com o Google Cloud que gerencia seu cluster, por exemplo, us-west1
  • PROJECT_ID: seu projeto do Google Cloud.
  • CLUSTER_NAME: o nome do cluster
  • NODE_POOL_NAME: um nome exclusivo para o pool de nós, por exemplo, node-pool-1

Resumo da integridade do pool de nós

Depois de ativar o reparo automático de nós, gere um resumo da integridade do pool de nós executando o seguinte comando:

gcloud container aws node-pools describe NODE_POOL_NAME \
   --cluster CLUSTER_NAME \
   --location GOOGLE_CLOUD_LOCATION

Um resumo íntegro do pool de nós é semelhante a este exemplo:

{
  "name": "some-np-name",
  "version": "some-version",
  "state": "RUNNING",

  ...

  "errors": [
    {
      "message": "1 node(s) is/are identified as unhealthy among 2 total node(s) in the node pool. No node is under repair."
    }
  ],
}

O resumo da integridade do pool de nós ajuda a entender o estado atual do pool de nós. Neste exemplo, o resumo contém uma mensagem de erro que informa que um dos dois nós no pool de nós não está íntegro. Também relata que nenhum nó está passando pelo processo de reparo.