Início e desligamento de um nó

Inicie e desligue os nós com segurança no Automation Suite, cobrindo o comportamento de inicialização e desligamento manual e automático.

Esta página explica o comportamento de inicialização e desligamento manual e automático do Automation Suite.

Importante:

Você deve sempre prosseguir desativando um nó, executando a operação necessária, aguardando até que o nó esteja íntegro e, então, desativando o outro nó para executar a mesma operação.

A tabela a seguir descreve diferentes cenários que você pode enfrentar ao desligar serviços ou nós do cluster. A tabela fornece ações detalhadas que você deve realizar para cada situação, juntamente com orientações sobre a compreensão do comportamento esperado em resposta a essas ações.

Cenário	Ação	Comportamento esperado
Desligar os serviços de cluster em um nó sem desligar o nó, para manutenção ou por qualquer outro motivo.	Execute manualmente as etapas de desligamento. Reinicie os serviços usando a inicialização manual ou reiniciando a máquina.	Em um cenário de HA, a maioria dos serviços permanecerá ativa. O nó deve ser inicializado sem nenhum problema e qualquer serviço inoperante deve ser reiniciado.
Desligamento de todos os serviços de cluster sem desabilitar os nós, para manutenção ou por qualquer outro motivo.	Em todos os nós, começando com os nós do agente, execute manualmente as etapas de desligamento. Reinicie os serviços usando a inicialização manual ou reiniciando as máquinas, a partir dos nós do servidor.	Os serviços ficarão indisponíveis. Os nós devem ser inicializados sem problemas.
Desligando todos os nós.	Se seu portal de gerenciamento de hipervisor (como VMware, AWS) permitir que os serviços façam o desligamento normal sem forçar a terminação da máquina, realize um desligamento normal. Por padrão, o subsistema systemd permite um período de tolerância para que os serviços sejam desligados antes de serem encerrados à força. No entanto, se seu sistema substituir os tempos de desligamento configurados, isso poderá interferir com um desligamento normal. Por exemplo, no AWS, a plataforma pode forçar o encerramento de uma VM após dois minutos. Dessa forma, os serviços devem ser desligados manualmente, pois uma drenagem de nó pode levar até 5 minutos (esse é um requisito para um desligamento normal).	Se o desligamento for normal, os nós devem ser inicializados sem problemas. Se o cluster tiver sido desligado por mais de seis horas e a autenticação do Kerberos estiver configurada, pode ser necessário renovar os tíquetes do Kerberos após a reinicialização. Para obter detalhes, consulte Recuperar a autenticação do Kerberos após o reinício da VM.
Desligamento de um nó individual.	Se seu portal de gerenciamento de hipervisor (como VMware, AWS) permitir que os serviços façam o desligamento normal sem forçar a terminação da máquina, realize um desligamento normal. Por padrão, o subsistema systemd permite um período de tolerância para que os serviços sejam desligados antes de serem encerrados à força. No entanto, se seu sistema sobrescrever os tempos de desligamento configurados, isso poderá interferir com um desligamento normal. Por exemplo, no AWS, a plataforma pode forçar o encerramento de uma VM após dois minutos. Dessa forma, os serviços devem ser desligados manualmente, pois uma drenagem de nó pode levar até 5 minutos (esse é um requisito para um desligamento normal).	Se o processo de desligamento não forçar, o nó deve reinicializar sem problemas.
Encerrando de forma forçada um nó do servidor.	Não aplicável.	Na maioria dos casos, o nó será inicializado, mas pode haver problemas com alguns serviços que usam dados persistentes. Embora esses problemas normalmente sejam recuperáveis, a configuração de backups é altamente recomendável. O pod do Insights não será reiniciado até que o nó original esteja novamente online, para evitar a possível perda de dados. Se o nó não for recuperável, entre em contato com a equipe de suporte.

Comportamento de Desligamento

Durante o desligamento, systemd interrompe os serviços na ordem em que foram iniciados. Como o serviço node-drain tem a diretiva After=rke2-server.service ou After=rke2-agent.service, ele executa sua sequência de desligamento antes do desligamento de rke2-service.Isso significa que em um sistema devidamente configurado, desligar o nó de forma correta é uma operação segura.

Reinicialização manual

Se você planeja interromper o serviço do rke2 e reinicializar a máquina, execute os seguintes comandos:

1. Para garantir que o cluster esteja íntegro enquanto executa a atividade de manutenção do nó, você deve drenar as cargas de trabalho em execução nesse nó para outros nós.Para drenar o nó, execute o seguinte comando:

   systemctl stop node-drain.service
   

2. Interrompa o processo do Kubernetes no nó, dependendo do tipo de nó:

   • Em um nó servidor:

     systemctl stop rke2-server
     

   • Em um nó agente:

     systemctl stop rke2-agent
     

3. Encerre os serviços e o containerd do rke2 e todos os processos filhos:

   rke2-killall.sh
   

Para baixar o script rke2-killall.sh , consulte Links de download de pacotes de instalação.

Comportamento de inicialização

Os rke2-service inicia e é seguido por node-drainer e node-uncordon. node-drainer não faz nenhuma ação na inicialização, apenas retorna a confirmação de que o serviço está ativo.

O node-uncordon é executado apenas uma vez e inicia /opt/node-drain.sh nodestart, que libera o nó. Durante o procedimento de drenagem que ocorre no desligamento, isso isola o nó, tornando-o não programável. Esse estado persiste quando o serviço do rke2 é iniciado. Portanto, o nó deve ser liberado após a reinicialização de rke2-service.

Inicialização manual

O serviço é iniciado automaticamente com o Automation Suite. Contudo, se rke2-service foi interrompido manualmente, inicie o serviço novamente executando os seguintes comandos:

1. Inicie o processo do Kubernetes no nó, dependendo do tipo de nó:

   • Em um nó servidor:

     systemctl start rke2-server
     

   • Em um nó agente:

     systemctl start rke2-agent
     

2. Depois que o serviço rke2 for iniciado, libere o nó para garantir que o Kubernetes possa agendar cargas de trabalho neste nó:

   systemctl restart node-uncordon
   

3. Depois que o nó for iniciado, você deve drenar o nó:

   systemctl start node-drain.service
   

   Importante:

   Ignorar essa etapa pode fazer com que o serviço Kubelet seja desligado de maneira inadequada se o sistema for reiniciado.

Patch de nós do cluster

Ao corrigir ou reiniciar nós do servidor, a ordem na qual você aplica as mudanças afeta diretamente a estabilidade do cluster.

Verificações pré-patch

Antes de tocar em qualquer nó, confirme se o cluster está íntegro:

1. Confirme que todos os três membros do etcd estejam íntegros:

   ETCD_CONTAINER="$(/var/lib/rancher/rke2/bin/crictl ps --name etcd --state Running -q | head -n1)"
   /var/lib/rancher/rke2/bin/crictl exec "$ETCD_CONTAINER" etcdctl \
     --endpoints=https://127.0.0.1:2379 \
     --cacert=/var/lib/rancher/rke2/server/tls/etcd/server-ca.crt \
     --cert=/var/lib/rancher/rke2/server/tls/etcd/server-client.crt \
     --key=/var/lib/rancher/rke2/server/tls/etcd/server-client.key \
     endpoint health --cluster
   

2. Verifique se há loops de falha em qualquer nó:

   journalctl -u rke2-server --since "2 hours ago" | grep -i "FAILURE\|left-over\|unclean"
   

3. Verifique se existe um instantâneo recente etcd:

   ls -lth /var/lib/rancher/rke2/server/db/snapshots/ | head -5
   

Importante:

Não inicie o patch se algum nó já estiver com loop de falha ou se as verificações de integridade do etcd falharem. Resolva a instabilidade antes de prosseguir.

Identificar o nó de inicialização

O nó de inicialização é normalmente o líder atual do etcd. Para identificá-lo, execute o seguinte comando e IS LEADER: true:

ETCD_CONTAINER="$(/var/lib/rancher/rke2/bin/crictl ps --name etcd --state Running -q | head -n1)"
/var/lib/rancher/rke2/bin/crictl exec "$ETCD_CONTAINER" etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/var/lib/rancher/rke2/server/tls/etcd/server-ca.crt \
  --cert=/var/lib/rancher/rke2/server/tls/etcd/server-client.crt \
  --key=/var/lib/rancher/rke2/server/tls/etcd/server-client.key \
  endpoint status --cluster

Ordem do patch

Sempre corrija o nó de inicialização primeiro, depois os nós secundários, um de cada vez.

Importante:

Aplicar patch ao nó de inicialização primeiro garante que, quando ele ficar inativo, os dois nós secundários mantenham o quorum e elejam um novo líder. O nó de inicialização então retorna como seguidor em um estado limpo. Corrigir os nós secundários primeiro e deixar o nó de inicialização para o último pode causar uma instabilidade mais ampla se o nó de inicialização falhar ao se reingressar corretamente.

Após cada nó corrigir e reiniciar, confirme que ele está totalmente de volta antes de prosseguir para o próximo nó:

1. Verifique se o status do nó é Ready:

   kubectl get nodes
   

2. Confirme que todos os três membros do etcd estejam íntegros:

   ETCD_CONTAINER="$(/var/lib/rancher/rke2/bin/crictl ps --name etcd --state Running -q | head -n1)"
   /var/lib/rancher/rke2/bin/crictl exec "$ETCD_CONTAINER" etcdctl \
     --endpoints=https://127.0.0.1:2379 \
     --cacert=/var/lib/rancher/rke2/server/tls/etcd/server-ca.crt \
     --cert=/var/lib/rancher/rke2/server/tls/etcd/server-client.crt \
     --key=/var/lib/rancher/rke2/server/tls/etcd/server-client.key \
     endpoint health --cluster
   

3. Verifique se há erros nos logs do servidor RKE2:

   journalctl -u rke2-server -n 30
   

Atualizações do kernel

Ao executar uma atualização do kernel, limpe o armazenamento de instantâneo em contêiner após executar rke2-killall.sh e antes de aplicar a atualização do kernel. Isso evita a corrupção do estado do contêiner em qualquer nó, independentemente da ordem de correção.

Arquivos criados durante a instalação

Os seguintes arquivos de unidade são criados durante a instalação:

• (somente servidor) - Inicia o rke2-server.service , que inicia o nó rke2-server servidor.
• (apenas agente) - Inicia o rke2-agent.service , o que inicia o nó rke2-agent agente.
• node-drain.service - Usado no momento do desligamento. Executado antes de desligar rke2-agent ou rke2-server e executa uma drenagem. Tem um tempo limite de 300 segundos.
• node-uncordon.service - Usado na inicialização para liberar um nó.
• var-lib-kubelet.mount Gerado automaticamente pelo gerador fstab.
• var-lib-rancher-rke2-server-db.mount Gerado automaticamente pelo gerador fstab.
• var-lib-rancher.mount Gerado automaticamente pelo gerador fstab.

Não há dependências fortes entre os arquivos da unidade. No entanto, node-drain e node-uncordon têm a diretiva After=rke2-server.service ou After=rke2-agent.service. Isso significa que esses serviços começarão após o rke2-server.service.