Gerenciar sistemas distribuídos pode ser difícil devido à presença de muitos elementos móveis e mutáveis, todos os quais devem funcionar corretamente para garantir a funcionalidade do sistema. Se um dos elementos falhar, o sistema deve detectá-lo, contorná-lo e corrigir o problema, tudo isso automaticamente. Nesta série de "Melhores Práticas do Kubernetes", aprenderemos a configurar testes de Readiness e Liveness para verificar a viabilidade do cluster Kubernetes.
A verificação de saúde Health Check é uma maneira simples de informar ao sistema se a instância do seu aplicativo está funcionando ou não. Se a instância do seu aplicativo não estiver em funcionamento, outros serviços não devem chamá-la ou enviar solicitações a ela. Em vez disso, a solicitação deve ser enviada a outra instância do aplicativo que já está em execução ou que será iniciada posteriormente. Além disso, o sistema deve retornar a funcionalidade perdida ao seu aplicativo.
Por padrão, o Kubernetes começará a enviar tráfego para o pod quando todos os contêineres dentro dos pods estiverem em execução e reiniciará os contêineres quando eles falharem. Inicialmente, esse comportamento padrão do sistema pode ser suficientemente bom, no entanto, você pode aumentar a confiabilidade da implantação do seu produto usando verificações de integridade personalizadas.
Felizmente, o Kubernetes permite que você faça isso de maneira bastante simples, portanto, não há desculpas para ignorar essas verificações. O Kubernetes fornece dois tipos de testes de Health Check, sendo importante entender as diferenças na aplicação de cada um deles.
O teste de Readiness destina-se a informar ao Kubernetes se o seu aplicativo está pronto para servir tráfego. Antes de permitir que o serviço envie tráfego para o pod, o Kubernetes deve garantir o sucesso da verificação de Readiness. Se o teste de Readiness falhar, o Kubernetes interromperá o envio de tráfego para o pod até que o teste seja bem-sucedido.
O teste de Liveness informa ao Kubernetes se o seu aplicativo está vivo ou morto. No primeiro caso, o Kubernetes o deixará em paz; no segundo, eliminará o pod morto e o substituirá por um novo.
Vamos imaginar um cenário em que seu aplicativo leva 1 minuto para "aquecer" e iniciar. Seu serviço não começará a funcionar até que o aplicativo esteja completamente carregado e em execução, embora o fluxo de trabalho já tenha começado. Além disso, você também terá problemas se desejar escalar essa implantação para várias cópias, pois essas cópias não devem receber tráfego até estarem totalmente prontas. No entanto, por padrão, o Kubernetes começará a enviar tráfego assim que os processos dentro do contêiner forem iniciados.
Usando o teste de prontidão Readiness, o Kubernetes esperará até que o aplicativo esteja completamente iniciado e, somente após isso, permitirá que o serviço envie tráfego para a nova cópia.
Vamos imaginar outro cenário, onde o aplicativo fica travado por um longo período, parando de atender solicitações. Como o processo continua a ser executado, por padrão, o Kubernetes considerará que tudo está bem e continuará enviando solicitações para o pod que não está funcionando. Mas, usando o Liveness, o Kubernetes descobrirá que o aplicativo não está mais atendendo solicitações e, por padrão, reiniciará o pod não funcional.
Vamos considerar as maneiras de testar a prontidão e a viabilidade. Existem três métodos de teste — HTTP, Command e TCP. Você pode usar qualquer um deles para a verificação. O método de teste mais comum é o HTTP probe.
Mesmo que seu aplicativo não seja um servidor HTTP, você ainda pode criar um leve servidor HTTP dentro do seu aplicativo para interagir com o teste de Liveness. Após isso, o Kubernetes começará a pingar o pod, e se a resposta HTTP estiver na faixa de 200 ou 300 ms, isso indicará que o pod está "saudável". Caso contrário, o módulo será marcado como "não saudável".
Para os testes através do Command, o Kubernetes executa um comando dentro do seu contêiner. Se o comando retornar um código de saída zero, o contêiner será marcado como saudável; caso contrário, ao obter um número de status de saída de 1 a 255, o contêiner será anotado como "doente". Esse método de teste é útil se você não pode ou não quer executar um servidor HTTP, mas é capaz de executar um comando que verifique a "saúde" do seu aplicativo.
O último mecanismo de verificação é o teste TCP. O Kubernetes tentará estabelecer uma conexão TCP na porta especificada. Se conseguir, o contêiner é considerado saudável; caso contrário, ele é considerado não viável. Esse método pode ser útil se você estiver usando um script onde o teste via solicitação HTTP ou execução de comando não funciona muito bem. Por exemplo, os principais serviços para verificação com TCP serão gRPC ou FTP.
Os testes podem ser configurados de várias maneiras com diferentes parâmetros. Você pode especificar com que frequência devem ser executados, quais são os limites de sucesso e falha e quanto tempo esperar por respostas. Mais informações detalhadas estão documentadas nos testes de Readiness e Liveness. No entanto, há um ponto muito importante na configuração do teste de Liveness – o atraso inicial na execução do teste, initialDelaySeconds. Como mencionamos, a falha neste teste resultará na reinicialização do módulo. Portanto, você precisa garantir que os testes não comecem até que o aplicativo esteja pronto para ser executado, caso contrário, ele começará a reiniciar ciclicamente. Recomendo usar o tempo de inicialização P99 ou o tempo médio de inicialização do aplicativo do buffer. Não se esqueça de ajustar este valor à medida que o tempo de inicialização do seu aplicativo se torna mais rápido ou mais lento.
A maioria dos especialistas concorda que o Health Check é uma verificação obrigatória para qualquer sistema distribuído, e o Kubernetes não é exceção. O uso da verificação de 'saúde' dos serviços garante uma operação confiável e ininterrupta do Kubernetes e não representa um esforço para os usuários.
A continuação virá em breve…
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
