Reparação automática de nós

A funcionalidade de reparação automática de nós monitoriza continuamente o estado de cada nó num conjunto de nós. Se um nó ficar em mau estado, a funcionalidade de autorreparação de nós repara-o automaticamente. Esta funcionalidade diminui a probabilidade de interrupções dos clusters e degradação do desempenho, e minimiza a necessidade de manutenção manual dos seus clusters.

Pode ativar a autorreparação de nós quando cria ou atualiza um conjunto de nós. Tenha em atenção que ativa ou desativa esta funcionalidade em conjuntos de nós e não em nós individuais.

Condições de nós em mau estado de funcionamento

A autorreparação de nós examina o estado de funcionamento de cada nó para determinar se requer reparação. Um nó é considerado em bom estado se comunicar um estado Ready. Caso contrário, se comunicar consecutivamente um estado não saudável durante um período específico, são iniciadas reparações.

Um estado não saudável pode surgir de um estado NotReady, detetado em verificações consecutivas durante aproximadamente 15 minutos. Em alternativa, um estado não saudável pode resultar do espaço esgotado no disco de arranque, identificado durante um período de aproximadamente 30 minutos.

Pode verificar manualmente os sinais de estado do seu nó em qualquer altura executando o comando kubectl get nodes.

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

A reparação automática de nós segue determinadas estratégias para garantir o estado geral do cluster e a disponibilidade das aplicações durante o processo de reparação. Esta secção descreve como a funcionalidade de reparação automática de nós respeita as configurações PodDisruptionBudget, respeita o Pod Termination Grace Period e toma outras medidas que minimizam a interrupção do cluster ao reparar nós.

Honor PodDisruptionBudget durante 30 minutos

Se um nó precisar de reparação, não é esvaziado e recriado instantaneamente. Em alternativa, a funcionalidade de reparação automática de nós respeita as configurações de PodDisruptionBudget (PDB) durante um máximo de 30 minutos, após os quais todos os pods no nó são eliminados. (Uma configuração de PDB define, entre outras coisas, o número mínimo de réplicas de um determinado Pod que têm de estar disponíveis em qualquer altura).

Ao respeitar o PodDisruptionBudget durante aproximadamente 30 minutos, a funcionalidade de reparação automática de nós oferece uma oportunidade para que os pods sejam reagendados e redistribuídos em segurança por outros nós em bom estado no cluster. Isto ajuda a manter o nível de disponibilidade da aplicação pretendido durante o processo de reparação.

Após o limite de tempo de 30 minutos, a reparação automática do nó prossegue com o processo de reparação, mesmo que isso signifique violar o PodDisruptionBudget. Sem um limite de tempo, o processo de reparação pode ficar parado indefinidamente se a configuração impedir as remoções necessárias para uma reparação.PodDisruptionBudget

Respeite o período de tolerância de terminação do pod

A funcionalidade de reparação automática de nós também respeita um período de tolerância de encerramento de pods de aproximadamente 30 minutos. O período de tolerância de encerramento de agrupamentos oferece aos agrupamentos um período para um encerramento controlado durante o encerramento. Durante o período de tolerância, o kubelet num nó é responsável pela execução de tarefas de limpeza e pela libertação de recursos associados aos pods nesse nó. A funcionalidade de reparação automática de nós permite que o kubelet demore até 30 minutos a concluir esta limpeza. Se os 30 minutos atribuídos expirarem, o nó é forçado a terminar, independentemente de os pods terem terminado normalmente.

Estratégias de reparação de nós adicionais

A reparação automática de nós também implementa as seguintes estratégias:

  • Se vários nós precisarem de reparação, são reparados um de cada vez para limitar a interrupção do cluster e proteger as cargas de trabalho.
  • Se desativar a autorreparação de nós durante o processo de reparação, as reparações em curso continuam até a operação de reparação ser bem-sucedida ou falhar.

Como ativar e desativar a reparação automática de nós

Pode ativar ou desativar a reparação automática de nós quando cria ou atualiza um conjunto de nós. Ativa ou desativa esta funcionalidade em conjuntos de nós e não em nós individuais.

Ative a reparação automática para um novo conjunto 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 o seguinte:

  • NODE_POOL_NAME: um nome que escolhe para o seu node pool. Para obter os nomes dos seus node pools, execute o comando gcloud container aws node-pools list --cluster CLUSTER_NAME --location GOOGLE_CLOUD_LOCATION
  • CLUSTER_NAME: o nome do cluster ao qual anexar o grupo de nós
  • INSTANCE_TYPE: o tipo de instância de máquina da AWS pretendido para este conjunto de nós, por exemplo, m5.large
  • ROOT_VOLUME_SIZE: o tamanho pretendido para o volume raiz de cada nó, em GB
  • NODEPOOL_PROFILE: o perfil de instância do IAM para VMs do node pool
  • NODE_VERSION: a versão do Kubernetes a instalar em cada nó no node pool (por exemplo, "1.32.4-gke.200")
  • MIN_NODES: o número mínimo de nós que o node pool pode conter
  • MAX_NODES: o número máximo de nós que o conjunto de nós pode conter
  • MAX_PODS_PER_NODE: o número máximo de agrupamentos que podem ser criados em qualquer nó único no conjunto
  • GOOGLE_CLOUD_LOCATION: o nome da Google Cloud localização a partir da qual este conjunto de nós vai ser gerido
  • NODEPOOL_SUBNET: o ID da sub-rede na qual o conjunto de nós vai ser executado.
    • Não pode haver sobreposição entre os intervalos de IP de pods/serviços do cluster e a rede de sub-rede do conjunto de nós. Para mais informações sobre como selecionar intervalos de IPs de pods e serviços para o seu cluster, consulte o artigo Selecione intervalos de CIDR para o seu cluster
    • Se esta sub-rede estiver fora do bloco CIDR principal da VPC, são necessários alguns passos adicionais. Para mais informações, consulte os 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 do AWS KMS que encripta os dados do utilizador

Ative a reparação automática para um conjunto de nós existente

Para ativar a reparação automática de nós num conjunto de nós existente, execute o seguinte comando:

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

Substitua o seguinte:

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

Desative a reparação automática para um conjunto de nós existente

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

Substitua o seguinte:

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

Tenha em atenção que o GKE no AWS desativa a autorreparação de nós de forma elegante. Quando desativa a autorreparação de nós para um node pool existente, o GKE no AWS inicia uma operação de atualização do node pool. A operação aguarda a conclusão de quaisquer reparações de nós existentes antes de continuar.

Verifique se a reparação automática de nós está ativada

Execute o seguinte comando para verificar se a reparação automática de nós está ativada:

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

Substitua o seguinte:

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

Histórico de reparações de nós

Pode ver o histórico de reparações realizadas num conjunto 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 o seguinte:

  • GOOGLE_CLOUD_LOCATION: a região suportada Google Cloud que gere o seu cluster, por exemplo, us-west1
  • PROJECT_ID: o seu Google Cloud projeto
  • CLUSTER_NAME: o nome do seu cluster
  • NODE_POOL_NAME: um nome exclusivo para o seu conjunto de nós, por exemplo, node-pool-1

Resumo do estado do node pool

Depois de ativar a reparação automática de nós, pode gerar um resumo do estado de funcionamento do conjunto 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 do estado de um node pool tem um aspeto semelhante a esta amostra:

{
  "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 do estado do conjunto de nós ajuda a compreender o estado atual do conjunto de nós. Neste exemplo, o resumo contém uma mensagem de erro que indica que um dos dois nós no conjunto de nós não está em bom estado. Também indica que nenhum nó está atualmente a passar pelo processo de reparação.