Os sistemas distribuídos podem ser difíceis de gerenciar porque possuem muitos elementos móveis e mutáveis que precisam funcionar corretamente para que o sistema funcione. Se um dos elementos falhar, o sistema deve detectá-lo, contorná-lo e corrigi-lo, e tudo isso deve ser feito automaticamente. Nesta série de práticas recomendadas do Kubernetes, aprenderemos como configurar testes de prontidão e atividade para testar a integridade de um cluster Kubernetes.
A verificação de integridade é uma maneira simples de informar ao sistema se a instância do seu aplicativo está em execução ou não. Se a instância do seu aplicativo estiver inativa, outros serviços não deverão acessá-la ou enviar solicitações a ela. 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 posteriormente. Além disso, o sistema deve restaurar a funcionalidade perdida do seu aplicativo.
Por padrão, o Kubernetes começará a enviar tráfego para um pod quando todos os contêineres dentro dos pods estiverem em execução e reinicializará os contêineres quando eles travarem. Esse comportamento padrão do sistema pode ser bom o suficiente para começar, mas você pode melhorar a confiabilidade da implantação do seu produto usando verificações de integridade personalizadas.
Felizmente, o Kubernetes torna isso muito fácil, então não há desculpa para ignorar essas verificações. O Kubernetes oferece dois tipos de verificações de integridade e é importante compreender as diferenças na forma como cada uma é usada.
O teste de prontidão foi projetado para informar ao Kubernetes que seu aplicativo está pronto para lidar com o tráfego. Antes de permitir que um serviço envie tráfego para um pod, o Kubernetes deve verificar se a verificação de prontidão foi bem-sucedida. Se o teste de prontidão falhar, o Kubernetes irá parar de enviar tráfego para o pod até que o teste seja aprovado.
O teste Liveness informa ao Kubernetes se seu aplicativo está ativo ou inativo. No primeiro caso, o Kubernetes irá deixá-lo sozinho, no segundo irá deletar o pod morto e substituí-lo 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 totalmente carregado e em execução, embora o fluxo de trabalho já tenha sido iniciado. Você também terá problemas se quiser ampliar essa implantação para diversas cópias, porque essas cópias não deverão receber tráfego até que estejam 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.
Ao usar o teste de prontidão, o Kubernetes aguardará até que o aplicativo esteja totalmente executado antes de permitir que o serviço envie tráfego para a nova cópia.
Vamos imaginar outro cenário em que a aplicação trava por muito tempo, parando de atender às solicitações. À medida que o processo continua em execução, por padrão, o Kubernetes presumirá que está tudo bem e continuará enviando solicitações para o pod que não está funcionando. Mas ao usar o Liveness, o Kubernetes detectará que o aplicativo não está mais atendendo solicitações e reiniciará o pod morto por padrão.
Vejamos como a prontidão e a viabilidade são testadas. Existem três métodos de teste – HTTP, Command e TCP. Você pode usar qualquer um deles para verificar. A maneira mais comum de testar um usuário é uma investigação HTTP.
Mesmo que seu aplicativo não seja um servidor HTTP, você ainda pode criar um servidor HTTP leve dentro do seu aplicativo para interagir com o teste de atividade. Depois disso, o Kubernetes começará a executar ping no pod e, se a resposta HTTP estiver na faixa de 200 ou 300 ms, indicará que o pod está íntegro. Caso contrário, o módulo será marcado como "não íntegro".
Para testes de comando, o Kubernetes executa o comando dentro do seu contêiner. Se o comando retornar com código de saída zero, o contêiner será marcado como íntegro, caso contrário, ao receber um número de status de saída de 1 a 255, o contêiner será marcado como “doente”. Este método de teste é útil se você não pode ou não deseja executar um servidor HTTP, mas consegue executar um comando que verificará 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, é considerado inviável. Este método pode ser útil se você estiver usando um cenário em que o teste com uma solicitação HTTP ou execução de comando não funciona muito bem. Por exemplo, os principais serviços para verificação usando TCP seriam gRPC ou FTP.
Os testes podem ser configurados de diversas maneiras com parâmetros diferentes. Você pode especificar com que frequência eles devem ser executados, quais são os limites de sucesso e falha e quanto tempo esperar pelas respostas. Para obter mais informações, consulte a documentação dos testes de prontidão e atividade. No entanto, há um ponto muito importante na configuração do teste de Liveness - a configuração inicial do atraso de teste inicialDelaySeconds. Como mencionei, a falha neste teste resultará na reinicialização do módulo. Portanto, você precisa ter certeza de que o teste não será iniciado até que o aplicativo esteja pronto para uso, caso contrário, ele começará a alternar entre reinicializações. Eu recomendo usar o tempo de inicialização P99 ou o tempo médio de inicialização do aplicativo no buffer. Lembre-se de ajustar esse valor conforme o tempo de inicialização do seu aplicativo ficar mais rápido ou mais lento.
A maioria dos especialistas confirmará que as verificações de saúde são uma verificação obrigatória para qualquer sistema distribuído, e o Kubernetes não é exceção. O uso de verificações de integridade de serviço garante uma operação confiável e sem problemas do Kubernetes e é fácil para os usuários.
Continuará muito em breve...
Alguns anúncios 🙂
Obrigado por ficar com a gente. Gostou dos nossos artigos? Quer ver mais conteúdos interessantes? Apoie-nos fazendo um pedido ou recomendando a amigos, , um análogo exclusivo de servidores básicos, que foi inventado por nós para você: (disponível com RAID1 e RAID10, até 24 núcleos e até 40 GB DDR4).
Dell R730xd 2x mais barato no data center Equinix Tier IV em Amsterdã? Só aqui na Holanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US$ 99! Ler sobre
Fonte: habr.com