Início e desligamento de um nó

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.
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 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 em execução no nó do servidor:

   systemctl start rke2-server
   

2. Inicie o processo do Kubernetes em execução no nó do servidor:

   systemctl start rke2-agent
   

3. 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
   

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

   systemctl start node-drain.service
   

   Importante:

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

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 em execução no nó do servidor:

   systemctl stop rke2-server
   

3. Interrompa o processo do Kubernetes em execução no nó do agente.

   systemctl stop rke2-agent
   

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

   rke2-killall.sh
   

   Isso já deve estar no caminho, mas está localizado em /bin/rke2-killall.sh.

Arquivos criados durante a instalação

1. Os seguintes arquivos de unidade são criados durante a instalação:
   • rke2-server.service (somente servidor). Inicia o rke2-server, que inicia o nó do servidor.
   • rke2-agent.service (apenas agente). Inicia o rke2-agent, o que inicia o nó do 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. Autogerado pelo gerador fstab.
   • var-lib-rancher-rke2-server-db.mount. Autogerado pelo gerador fstab.
   • var-lib-rancher.mount. Autogerado 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-service.