O recurso de reparo automático de nós monitora continuamente a integridade de cada nó em um pool de nós. Se um nó apresentar problemas de integridade, o recurso de reparo automático de nós o reparará automaticamente. Esse recurso diminui a probabilidade de interrupções do cluster e degradação do desempenho, além de minimizar a necessidade de manutenção manual dos seus clusters.
Você pode habilitar o reparo automático de nós ao criar ou atualizar um pool de nós. Observe que esse recurso é habilitado ou desabilitado em pools de nós, e não em nós individuais.
Condições de nódulos prejudiciais
O reparo automático de nós examina o status de integridade de cada nó para determinar se ele precisa de reparo. Um nó é considerado íntegro se reportar o status Ready . Caso contrário, se reportar consecutivamente um status não íntegro por um período específico, os reparos serão iniciados.
Um status não íntegro pode surgir de um estado NotReady , detectado em verificações consecutivas ao longo de aproximadamente 15 minutos. Alternativamente, um status não íntegro pode resultar de espaço em disco de inicialização esgotado, identificado ao longo de um período de aproximadamente 30 minutos.
Você pode verificar manualmente os sinais de integridade do seu 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. Esta seção descreve como o recurso de reparo automático de nós respeita as configurações PodDisruptionBudget , o Pod Termination Grace Period e outras medidas que minimizam a interrupção do cluster ao reparar nós.
Honor PodDisruptionBudget por 30 minutos
Se um nó precisar de reparo, ele não será esvaziado e recriado instantaneamente. Em vez disso, o recurso de reparo automático do nó respeita as configurações do PodDisruptionBudget (PDB) por até 30 minutos, após os quais todos os Pods no nó serã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 devem estar disponíveis 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 com segurança e redistribuídos entre outros nós saudáveis no cluster. Isso ajuda a manter o nível desejado de disponibilidade do aplicativo durante o processo de reparo.
Após o limite de 30 minutos, o reparo automático do nó prossegue com o processo de reparo, mesmo que isso signifique violar o PodDisruptionBudget . Sem um limite de tempo, o processo de reparo pode ser interrompido indefinidamente se a configuração PodDisruptionBudget impedir as remoções necessárias para um reparo.
Respeite o período de carência para término do Pod
O recurso de reparo automático do nó também respeita um Período de Carência de Encerramento de Pod de aproximadamente 30 minutos. O Período de Carência de Encerramento de Pod fornece aos Pods uma janela de tempo para um desligamento normal durante o encerramento. 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 naquele nó. O recurso de reparo automático do nó permite até 30 minutos para que o kubelet conclua essa limpeza. Se os 30 minutos estipulados se esgotarem, o nó será forçado a encerrar, independentemente de os pods terem sido encerrados normalmente.
Estratégias adicionais de reparo de nós
O Node Auto Repair 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ê desabilitar o reparo automático do nó durante o processo de reparo, os reparos em andamento continuarão até que a operação de reparo seja bem-sucedida ou falhe.
Como habilitar e desabilitar o reparo automático de nós
Você pode habilitar ou desabilitar o reparo automático de nós ao criar ou atualizar um pool de nós. Você habilita ou desabilita esse recurso em pools de nós, e não em nós individuais.
Habilitar reparo automático para 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 o seguinte:
-
NODE_POOL_NAME: um nome escolhido para o seu pool de nós. Para obter os nomes dos seus pools de nós, execute o comandogcloud 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 da máquina AWS desejada 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 do 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.31.4-gke.500") -
MIN_NODES: o número mínimo de nós que o pool de nós pode conter -
MAX_NODES: o número máximo de nós que o pool de nós pode conter -
MAX_PODS_PER_NODE: o número máximo de pods que podem ser criados em qualquer nó do pool -
GOOGLE_CLOUD_LOCATION: o nome do Google Cloudlocal de onde este pool de nós será gerenciado -
NODEPOOL_SUBNET: o ID da sub-rede na qual o pool de nós será executado.- Não deve haver sobreposição entre os intervalos de IP do pod/serviço do cluster e a rede da sub-rede do pool de nós. Para obter mais informações sobre como selecionar intervalos de IP do pod e do serviço para o seu cluster, consulte Selecionar intervalos CIDR para o seu cluster.
- Se esta sub-rede estiver fora do bloco CIDR primário da VPC, serão necessárias algumas etapas adicionais. 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 do recurso da Amazon (ARN) da chave AWS KMS que criptografa os dados do usuário
Habilitar reparo automático para um pool de nós existente
Para habilitar o reparo automático de nós em um pool 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 seu pool de nós — por exemplo,node-pool-1 -
CLUSTER_NAME: o nome do seu cluster -
GOOGLE_CLOUD_LOCATION: o Google Cloud região que gerencia seu cluster
Desabilitar reparo automático para um pool 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 seu pool de nós — por exemplo,node-pool-1 -
CLUSTER_NAME: o nome do seu cluster -
GOOGLE_CLOUD_LOCATION: o Google Cloud região que gerencia seu cluster
Observe que o GKE na AWS executa a desativação gradual do reparo automático de nós. Ao desativar o reparo automático de nós para um pool de nós existente, o GKE na AWS inicia uma operação de atualização do pool de nós. A operação aguarda a conclusão de quaisquer reparos de nós existentes antes de prosseguir.
Verifique se o reparo automático do nó está habilitado
Execute o seguinte comando para verificar se o reparo automático do nó está habilitado ou não:
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 seu pool de nós — por exemplo,node-pool-1 -
CLUSTER_NAME: o nome do seu cluster -
GOOGLE_CLOUD_LOCATION: o Google Cloud região que gerencia seu cluster
Histórico de reparo do nó
Você pode visualizar 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 o seguinte:
-
GOOGLE_CLOUD_LOCATION: o suportado Google Cloud região que gerencia seu cluster — por exemplo,us-west1 -
PROJECT_ID: seu Google Cloud projeto -
CLUSTER_NAME: o nome do seu cluster -
NODE_POOL_NAME: um nome exclusivo para seu pool de nós — por exemplo,node-pool-1
Resumo da integridade do pool de nós
Depois de habilitar o reparo automático do nó, você pode gerar 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 de integridade 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 de integridade do pool de nós ajuda você a entender o estado atual do pool de nós. Neste exemplo, o resumo contém uma mensagem de erro informando que um dos dois nós no pool de nós não está íntegro. Ele também informa que nenhum nó está passando pelo processo de reparo.