Melhores práticas do Kubernetes. Teste de viabilidade Kubernetes com testes de prontidão e vida

Melhores práticas do Kubernetes. Criando
práticas recomendadas para Kubernetes de contêineres pequenos. Organização do Kubernetes com um espaço para nome



É difícil gerenciar sistemas distribuídos devido ao fato de terem muitos elementos mutáveis ​​móveis e todos eles devem funcionar adequadamente para garantir a funcionalidade do sistema. Se um dos elementos falhar, o sistema deverá detectá-lo, ignorá-lo e corrigi-lo, e tudo isso deve ser feito automaticamente. Nesta série de práticas recomendadas do Kubernetes, aprenderemos como configurar os testes de prontidão e resistência para testar a viabilidade de um cluster Kubernetes.

Verificação de integridade O Health Check é uma maneira fácil de informar ao sistema se a instância do aplicativo está em execução ou não. Se uma instância do seu aplicativo não funcionar, outros serviços não deverão acessá-lo ou enviar solicitações a ele. Em vez disso, a solicitação deve ser enviada para outra instância do aplicativo que já esteja em execução ou que será iniciada mais tarde. Além disso, o sistema deve retornar seu aplicativo à funcionalidade perdida.

Por padrão, o Kubernetes começará a enviar tráfego para o pod quando todos os contêineres dentro das lareiras estiverem em execução e recarregará os contêineres quando eles travarem. Para iniciantes, esse comportamento padrão do sistema pode ser bastante bom, mas você pode aumentar a confiabilidade da implantação do produto usando verificações de integridade personalizadas.



Felizmente, o Kubernetes permite que você faça isso de maneira simples, portanto não há desculpas para ignorar essas verificações. O Kubernetes fornece dois tipos de testes de verificação de integridade e é importante entender as diferenças em cada aplicativo.

O teste de prontidão para preparação foi desenvolvido para informar ao Kubernetes que seu aplicativo está pronto para servir o tráfego. Antes de permitir que o serviço envie tráfego para o pod, o Kubernetes deve verificar se a verificação de disponibilidade foi bem-sucedida. Se o teste de prontidão falhar, o Kubernetes deixará de enviar tráfego para o pod até que o teste seja bem-sucedido.

O Teste de Viabilidade de Liveness informa ao Kubernetes se seu aplicativo está vivo ou morto. No primeiro caso, Kubernetes o deixará em paz; no segundo, ele removerá a cápsula morta e a substituirá por uma nova.

Vamos imaginar um cenário em que seu aplicativo precise de 1 minuto para "aquecer" e executar. Seu serviço não começará a funcionar até que o aplicativo seja carregado e iniciado completamente, embora o fluxo de trabalho já tenha começado. E você também terá problemas se desejar aumentar a escala dessa implantação para várias cópias, porque essas cópias não devem receber tráfego até que estejam completamente prontas. No entanto, por padrão, o Kubernetes começará a enviar tráfego imediatamente após o início dos processos dentro do contêiner.

Ao usar o teste de prontidão, o Kubernetes aguardará até que o aplicativo seja totalmente iniciado e somente depois disso permitirá que o serviço envie tráfego para uma nova cópia.



Vamos imaginar outro cenário em que um aplicativo congele por muito tempo, parando as solicitações de serviço. Como o processo continua em execução, por padrão, o Kubernetes considerará que tudo está em ordem e continuará enviando solicitações para o pod que não está funcionando. Porém, ao usar o Liveness, o Kubernetes detectará que o aplicativo não está mais atendendo solicitações e, por padrão, reiniciará um pod que não está funcionando.



Considere como testar a prontidão e a vitalidade. Existem três métodos de teste - HTTP, comando e TCP. Você pode usar qualquer um deles para verificação. O método de teste do usuário mais comum é uma análise HTTP.

Mesmo se seu aplicativo não for um servidor HTTP, você ainda poderá criar um servidor HTTP leve dentro do aplicativo para interagir com o teste de Liveness. Depois disso, o Kubernetes começará a executar ping no pod e, se a resposta HTTP estiver no intervalo de 200 ou 300 ms, isso significa que o pod está "íntegro". Caso contrário, o módulo será marcado como "não íntegro".



Para testes usando o Command, o Kubernetes executa o comando dentro do seu contêiner. Se o comando retornar com um código de saída zero, o contêiner será marcado como íntegro; caso contrário, quando o número de status de saída for de 1 a 255, o contêiner será marcado como "inválido". Este método de teste é útil se você não pode ou não deseja iniciar o servidor HTTP, mas é capaz de executar um comando que verifica a integridade do seu aplicativo.



O mecanismo de verificação final é o teste TCP. O Kubernetes tentará estabelecer uma conexão TCP na porta especificada. Se isso puder ser feito, o contêiner é considerado íntegro; caso contrário, não é viável. Esse método pode ser útil se você usar um script no qual o teste com uma solicitação HTTP ou execução de comando não funcione 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 vários parâmetros. Você pode especificar com que frequência eles devem ser executados, quais são os limites para o sucesso e o fracasso e quanto tempo esperar pelas respostas. Consulte a documentação do teste de prontidão e vida útil para obter mais informações. No entanto, há um ponto muito importante na configuração do teste de Liveness - a configuração inicial do atraso do teste initialDelaySeconds. Como mencionei, falhar neste teste reiniciará o módulo. Portanto, você precisa garantir que o teste não seja iniciado até que o aplicativo esteja pronto para uso, caso contrário, ele começará a circular. Eu recomendo usar o tempo de inicialização do P99 ou o tempo médio de inicialização do aplicativo a partir do buffer. Não se esqueça de ajustar esse valor comopois o tempo de inicialização do seu aplicativo está ficando mais rápido ou mais lento.

A maioria dos especialistas confirmará que o Health Check é uma verificação obrigatória para qualquer sistema distribuído, e o Kubernetes não é uma exceção. O uso da verificação de "integridade" dos serviços garante o Kubernetes confiável e em tempo de atividade e não faz nenhum trabalho para os usuários.

Para continuar em breve ...

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 US $ 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?