A partir da versão 1.26, o GKE na AWS habilita automaticamente o Encerramento Gracioso de Nós . Esse recurso gerencia o encerramento gracioso de Pods durante o encerramento de nós. O encerramento gracioso permite que os Pods salvem seu estado e liberem recursos antes que o nó seja encerrado. Esse método de encerramento de Pods minimiza o risco de perda de dados. Também minimiza o risco de interrupções em outros Pods e serviços que dependem ou interagem com os Pods sendo encerrados, aumentando assim a resiliência dos seus clusters.
Como funciona
Um evento como manutenção programada, dimensionamento de nós ou um problema de hardware aciona o desligamento do nó. O componente kubelet detecta o evento e inicia o processo de encerramento normal do nó, instruindo systemd a atrasar o desligamento do sistema por um período especificado. Esse atraso dá tempo ao nó para drenar e remover os pods em execução nele.
O objetivo do encerramento elegante de nós é encerrar elegantemente tanto pods críticos quanto não relacionados ao sistema antes que o nó seja desligado. As seguintes configurações padrão são usadas:
-
ShutdownGracePeriod: 30 segundos -
ShutdownGracePeriodCriticalPods: 15 segundos
Essas configurações dão aos Pods que não são do sistema 15 segundos para encerrarem normalmente antes de serem interrompidos à força. Os Pods críticos do sistema têm 15 segundos para desligar após o encerramento dos Pods que não são do sistema. No entanto, como o recurso opera com base no melhor esforço, existe a possibilidade de um nó não conseguir desligar normalmente dentro do período designado de 30 segundos.
Gatilhos e limitações
Os eventos que acionam o desligamento normal do nó incluem eventos planejados, como os seguintes:
- Desligamentos comandados pelo usuário
- Término de instâncias
- Manutenção programada
- Reduzindo a escala de um cluster
Nesses cenários, o kubelet detecta o evento de desligamento do nó e inicia o processo normal de desligamento do nó.
Por outro lado, o desligamento normal do nó não pode ser ativado quando o comando shutdown não aciona o mecanismo de bloqueio do inibidor systemd do qual o componente kubelet depende. Exemplos desse tipo de situação incluem o seguinte:
- Desconexões de rede
- Mau funcionamento de hardware
- Recursos insuficientes, como memória ou CPU
- Quedas de energia inesperadas.
Nesses casos, o nó pode desligar abruptamente, o que pode causar interrupções ou perda de dados.