Melhores práticas do Kubernetes. Desativar finalização correta

Melhores práticas do Kubernetes. Criando
práticas recomendadas para Kubernetes de contêineres pequenos. Organização Kubernetes com o namespace Kubernetes
Best Practices. Teste de viabilidade Kubernetes com testes de prontidão e vida
Práticas recomendadas de Kubernetes . Configurando Solicitações e Limites de Recursos



Um ponto importante na operação de sistemas distribuídos é o tratamento de falhas. O Kubernetes ajuda nisso, usando controladores que monitoram o estado do seu sistema e reiniciam os serviços que pararam de funcionar. No entanto, o Kubernetes pode desligar à força seus aplicativos para garantir a viabilidade geral do sistema. Nesta série, veremos como você pode ajudar o Kubernetes a realizar seu trabalho com mais eficiência e reduzir o tempo de inatividade do aplicativo.

Antes de usar contêineres, a maioria dos aplicativos era executada em máquinas virtuais ou físicas. Se o aplicativo travou ou travou, demorou muito tempo para remover a tarefa em andamento e baixar novamente o programa. Na pior das hipóteses, alguém tinha que resolver esse problema manualmente à noite, no horário mais inoportuno. Se apenas 1-2 máquinas de trabalho executassem uma tarefa importante, esse mau funcionamento seria completamente inaceitável.
Portanto, em vez de reiniciar manualmente, eles começaram a usar o monitoramento no nível do processo para reiniciar automaticamente o aplicativo no caso de sua finalização anormal. Se o programa travar, o processo de monitoramento captura o código de saída e reinicia o servidor. Com o advento de sistemas como o Kubernetes, esse tipo de resposta a falhas do sistema foi simplesmente integrado à infraestrutura.

O Kubernetes usa o loop de eventos "observar - confirmar diferenças - confirmar" para garantir que os recursos estejam operacionais ao longo do caminho, desde os contêineres até os próprios nós.



Isso significa que você não precisa mais iniciar manualmente os processos de monitoramento. Se um recurso falhar no Health Check, o Kubernetes simplesmente fornecerá uma substituição automaticamente. O Kubernetes faz muito mais do que apenas monitorar as falhas de seu aplicativo. Ele pode criar mais cópias do aplicativo para trabalhar em várias máquinas, atualizar o aplicativo ou executar simultaneamente várias versões do aplicativo.
Portanto, existem muitas razões pelas quais o Kubernetes pode interromper um recipiente perfeitamente saudável. Por exemplo, se você atualizar sua implantação, o Kubernetes interromperá lentamente os pods antigos ao lançar novos. Se você desconectar um nó, o Kubernetes encerrará todos os lares nesse nó. Por fim, se o nó ficar sem recursos, o Kubernetes desativará todos os pods para liberar esses recursos.

Portanto, é muito importante que seu aplicativo pare de funcionar com impacto mínimo no usuário final e tempo mínimo de recuperação. Isso significa que, antes de desconectar, ele deve salvar todos os dados que precisam ser salvos, fechar todas as conexões de rede, concluir o trabalho restante e ter tempo para concluir outras tarefas urgentes.

Na prática, isso significa que seu aplicativo deve poder processar a mensagem SIGTERM - o sinal de encerramento do processo, que é o sinal padrão para o utilitário kill no sistema operacional da família Unix. Depois de receber esta mensagem, o aplicativo deve se desconectar.

Depois que Kubernetes decidiu concluir o pod, toda uma série de eventos ocorreu. Vamos dar uma olhada em todas as etapas que o Kubernetes executa quando um contêiner ou lareira é concluído.

Suponha que desejemos completar uma das lareiras. Nesse momento, ele deixará de receber novo tráfego - os contêineres trabalhando na lareira não serão afetados, mas todo o novo tráfego será bloqueado.



Vejamos o gancho preStop - este é um comando especial ou solicitação HTTP enviada aos contêineres na lareira. Se o seu aplicativo não desligar corretamente quando o SIGTERM for recebido, você poderá usar o preStop para sair corretamente.



A maioria dos programas quando recebe um sinal SIGTERM termina corretamente, mas se você usar código de terceiros ou algum sistema que não possa controlar completamente, o gancho preStop é uma ótima maneira de causar um desligamento normal sem alterar o aplicativo.

Após executar este gancho, o Kubernetes enviará um sinal SIGTERM para os contêineres na lareira, o que permitirá que eles saibam que serão desconectados em breve. Após receber esse sinal, seu código continuará com o processo de desligamento. Esse processo pode incluir a interrupção de qualquer conexão de longa duração, como a conexão com um banco de dados ou um fluxo WebSocket, salvando o estado atual e similares.

Mesmo se você usar o gancho preStop, é muito importante verificar o que exatamente acontece com seu aplicativo quando você envia um sinal SIGTERM, como ele se comporta de tal maneira que eventos ou mudanças na operação do sistema causadas pelo desligamento da lareira não sejam uma surpresa para você.

Nesse momento, antes de tomar outras medidas, o Kubernetes aguardará um tempo especificado, chamado terminationGracePeriodSecond, ou o período para desligar corretamente ao receber um sinal SIGTERM.



Por padrão, esse período é de 30 segundos. É importante notar que dura em paralelo com o gancho preStop e o sinal SIGTERM. O Kubernetes não esperará o encerramento do preStop e o SIGTERM - se o seu aplicativo sair antes do término do período TerminationGracePeriod, o Kubernetes continuará imediatamente para a próxima etapa. Portanto, verifique se o valor desse período em segundos não é menor que o tempo necessário para que a lareira desligue corretamente e, se exceder 30 s, aumente o período para o valor desejado em YAML. No exemplo acima, são 60 anos.

E, finalmente, a última etapa - se os contêineres continuarem a funcionar após o término do terminationGracePeriod, eles enviarão um sinal SIGKILL e serão excluídos à força. Nesse ponto, o Kubernetes também limpará todos os outros objetos do pod.



O Kubernetes desliga as lareiras por vários motivos; portanto, verifique se seu aplicativo será concluído corretamente para garantir a operação estável do serviço.

Melhores práticas do Kubernetes. Mapeando Serviços Externos

Um pouco de publicidade :)

Obrigado por ficar com a gente. Você gosta dos nossos artigos? Deseja ver materiais mais interessantes? Ajude-nos fazendo um pedido ou recomendando aos seus amigos o VPS na nuvem para desenvolvedores a partir de US $ 4,99 , um analógico exclusivo de servidores de nível básico que foi inventado por nós para você: Toda a verdade sobre o VPS (KVM) E5-2697 v3 (6 núcleos) 10 GB DDR4 480 GB SSD 1 Gbps de US $ 19 ou como dividir o servidor? (as opções estão disponíveis com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).

Dell R730xd 2 vezes mais barato no data center Equinix Tier IV em Amsterdã? Somente nós temos 2 TVs Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV a partir de US $ 199 na Holanda!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de $ 99! Leia sobre Como criar um prédio de infraestrutura. classe c usando servidores Dell R730xd E5-2650 v4 que custam 9.000 euros por um centavo?