Um ponto importante no funcionamento de sistemas distribuídos é o tratamento de falhas. O Kubernetes ajuda nisso, utilizando controladores que monitoram o estado do seu sistema e reiniciam serviços que pararam de funcionar. No entanto, o Kubernetes pode interromper forçadamente suas aplicações para garantir a viabilidade geral do sistema. Nesta série, vamos explorar como ajudar o Kubernetes a realizar seu trabalho de forma mais eficaz e reduzir o tempo de inatividade das aplicações.
Antes da introdução dos contêineres, a maioria das aplicações funcionava em máquinas virtuais ou físicas. Se uma aplicação falhasse ou travasse, era necessário muito tempo para interromper a tarefa em execução e reiniciar o programa. No pior dos casos, alguém tinha que resolver esse problema manualmente durante a noite, no pior horário possível. Se uma tarefa importante fosse executada por apenas 1-2 máquinas, essa falha era completamente inaceitável.
Por isso, em vez de reinicialização manual, começou-se a usar monitoramento a nível de processos para reiniciar automaticamente a aplicação em caso de falha. Se o programa falhasse, o processo de monitoramento capturava o código de saída e reiniciava o servidor. Com sistemas como o Kubernetes, esse tipo de resposta a falhas foi simplesmente integrado à infraestrutura.
O Kubernetes utiliza um loop de eventos de "observação – registro de diferenças – ação" para garantir que os recursos permaneçam 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 o monitoramento de processos. Se um recurso falhar na verificação de integridade, o Kubernetes simplesmente fornecerá automaticamente uma substituição. Neste processo, o Kubernetes faz muito mais do que simplesmente monitorar as falhas de suas aplicações. Ele pode criar mais cópias da aplicação para funcionar em várias máquinas, atualizar a aplicação ou executar simultaneamente várias versões da sua aplicação.
Portanto, existem várias razões pelas quais o Kubernetes pode interromper um contêiner que está perfeitamente saudável. Por exemplo, se você atualizar seu deployment, o Kubernetes começará a parar os pods antigos lentamente, enquanto inicia novos. Se você desativar um nó, o Kubernetes interromperá todos os pods nesse nó. Finalmente, se um nó ficar sem recursos, o Kubernetes desligará todos os pods para liberar esses recursos.
Por isso, é muito importante que seu aplicativo pare com o mínimo de impacto para o usuário final e um tempo de recuperação reduzido. Isso significa que, antes de desligar, ele deve salvar todos os dados que precisam ser salvos, fechar todas as conexões de rede, concluir qualquer trabalho restante e realizar outras tarefas urgentes.
Na prática, isso significa que seu aplicativo deve ser capaz de lidar com a mensagem SIGTERM – um sinal de término de processo, que é o sinal padrão para a utilidade kill em sistemas operacionais da família Unix. Ao receber essa mensagem, o aplicativo deve se desligar.
Depois que o Kubernetes decide encerrar um pod, uma série de eventos ocorre. Vamos analisar cada passo que o Kubernetes realiza ao interromper um contêiner ou pod.
Suponha que queiramos encerrar um dos pods. Nesse momento, ele deixará de receber novo tráfego – os contêineres em execução no pod não serão afetados, mas todo o novo tráfego será bloqueado.
Vamos considerar o hook preStop – é um comando especial ou uma solicitação HTTP que é enviada para os contêineres no pod. Se seu aplicativo não se desliga corretamente ao receber SIGTERM, você pode usar o preStop para garantir um desligamento adequado.
A maioria dos programas responde ao sinal SIGTERM encerrando corretamente suas operações, mas se você estiver usando código de terceiros ou algum sistema que não pode controlar totalmente, o hook preStop serve como uma excelente maneira de facilitar um desligamento elegante sem modificar o aplicativo.
Após a execução desse hook, o Kubernetes enviará um sinal SIGTERM para os contêineres no pod, avisando-os de que em breve serão desligados. Ao receber esse sinal, seu código entrará no processo de desligamento. Esse processo pode incluir a interrupção de quaisquer conexões de longa duração, como a conexão com o banco de dados ou um fluxo WebSocket, além da preservação do estado atual e assim por diante.
Mesmo que você use o hook preStop, é muito importante verificar o que exatamente acontece com seu aplicativo quando você envia o sinal SIGTERM e como ele se comporta nesse momento, para que eventos ou mudanças no funcionamento do sistema ocasionados pelo desligamento do pod não sejam uma surpresa para você.
Nesse momento, antes de tomar qualquer ação adicional, o Kubernetes aguardará durante um tempo especificado, chamado terminationGracePeriodSecond, ou período para desligamento adequado ao receber o sinal SIGTERM.
Por padrão, esse período é de 30 segundos. É importante notar que ele ocorre em paralelo com o hook preStop e o sinal SIGTERM. O Kubernetes não aguardará a finalização do hook preStop e do SIGTERM — se seu aplicativo encerrar antes do término do período TerminationGracePeriod, o Kubernetes passará imediatamente para o próximo passo. Portanto, verifique se o valor desse período em segundos não é menor do que o tempo necessário para um desligamento adequado do pod e, se exceder 30 segundos, aumente o período para o tamanho desejado no YAML. No exemplo dado, ele é de 60 segundos.
E, finalmente, o último passo — se os contêineres ainda continuarem funcionando após o término do terminationGracePeriod, eles enviarão um sinal SIGKILL e serão removidos à força. Nesse momento, o Kubernetes também limpará todos os outros objetos do pod.
O Kubernetes interrompe pods por vários motivos, portanto, certifique-se de que, em qualquer situação, seu aplicativo seja encerrado adequadamente para garantir a estabilidade do serviço.
Um pouco de publicidade 🙂
Obrigado por permanecer conosco. Você gosta dos nossos artigos? Quer ver mais materiais interessantes? Apoie-nos fazendo um pedido ou recomendando para conhecidos. , uma alternativa única aos servidores entry-level, que criamos para você: (disponíveis opções com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).
Dell R730xd por 2 vezes mais barato no datacenter Equinix Tier IV em Amsterdã? Somente conosco na Holanda! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — a partir de $99! Leia sobre
Fonte: habr.com
