Compreendendo as sondagens do Kubernetes: melhore as verificações de integridade dos aplicativos.
📌 Introdução:
Explorando o conceito de sondagens no Kubernetes, este artigo se dedica a explicar como essas ferramentas são vitais para manter aplicações saudáveis em ambientes de contêineres.
As sondagens, divididas em liveness (vida), readiness (prontidão) e startup (inicialização), são instrumentos fundamentais para que o Kubernetes possa avaliar e reagir ao estado das aplicações, garantindo assim uma operação eficiente.
Este texto visa aprofundar o entendimento sobre a relevância dessas sondagens, detalhando seu funcionamento e impacto na robustez das aplicações em contêineres.
Índice:
. Avaliação de Saúde
· Kubernetes probes
· Kubernetes probe types
· Sequence of health probes
. Startup probes
. Readiness probes
. Liveness probes
Avaliação de Saúde:
A funcionalidade de avaliação de saúde é uma estratégia direta para comunicar ao sistema o estado operacional de uma aplicação. Se uma instância da aplicação falhar, ela deve ser isolada, evitando o envio de requisições para ela e redirecionando-as para instâncias operacionais.
O Kubernetes é projetado para restaurar aplicações a um estado funcional. Normalmente, o tráfego é encaminhado para um pod assim que seus contêineres são iniciados, e o Kubernetes reinicia contêineres que apresentam falhas. Essa abordagem inicial é adequada para a maioria dos casos, mas implementações mais complexas podem se beneficiar de verificações de saúde personalizadas.
Kubernetes Probes:
As sondagens no Kubernetes servem para informar o plano de controle do sistema sobre a condição interna das aplicações. Elas são cruciais para identificar pods que não estão funcionando corretamente.
Existem três métodos principais para realizar estas sondagens:
ExecAction: Consiste em executar um comando; se ele terminar com o status 0, o teste é considerado bem-sucedido.
TCPSocketAction: Verifica se uma porta TCP está aberta; se estiver, é um sucesso.
HTTPGetAction: Realiza uma solicitação HTTP e espera por um código de status dentro da faixa de 200 a 400.
Configurações comuns para cada sondagem incluem:
initialDelaySeconds: Tempo de espera antes de iniciar a sondagem após o contêiner ser ativado.
periodSeconds: Intervalo entre cada sondagem.
timeoutSeconds: Tempo máximo permitido para cada sondagem.
successThreshold: Quantidade de sondagens bem-sucedidas necessárias para considerar o contêiner como saudável ou pronto.
failureThreshold: Número de tentativas antes de considerar a sondagem como falha.
É importante ajustar esses parâmetros de acordo com as necessidades específicas de cada aplicação.
Kubernetes Probes Types:
As sondagens no Kubernetes são categorizadas em três tipos principais:
Sequence of Health Probes:
A ilustração a seguir demonstra o processo das sondagens de saúde no Kubernetes e como elas afetam a vida útil de um contêiner.
O ciclo inicia com a implantação do contêiner, seguido pela sondagem de inicialização para verificar a prontidão da aplicação. Se a sondagem de inicialização for bem-sucedida, a sondagem de prontidão é acionada. Se falhar, o contêiner é reiniciado. Após o sucesso da sondagem de inicialização, a de prontidão verifica se o contêiner pode processar tráfego. Se passar, a sondagem de vida é iniciada. Caso a sondagem de prontidão falhe, o tráfego é interrompido e a sondagem é repetida até o sucesso ou até que o limite de falhas seja atingido, levando a um reinício do contêiner.
Uma vez que as sondagens de inicialização e prontidão são bem-sucedidas, o Kubernetes monitora continuamente a saúde do contêiner. Se a sondagem de vida falhar, o contêiner é reiniciado, recomeçando o processo.
Startup Probes:
Recomenda-se utilizar sondagens de inicialização para aplicações que demoram mais tempo para atingir um estado operacional estável. Elas são essenciais para prevenir ciclos de reinício em aplicações que podem falhar durante as sondagens de vida ou prontidão na fase de inicialização.
Criando uma Startup Probes:
Para criar uma sondagem de inicialização, adiciona-se um campo startupProbe na seção spec.containers do manifesto de um pod.
Exec Probe:
A Exec Probe executa um comando dentro do contêiner para verificar sua saúde. O código de saída do comando é o que determina se o teste foi bem-sucedido ou não.
Exemplo de configuração de Exec Probe:
startupProbe:
initialDelaySeconds: 1
periodSeconds: 5
timeoutSeconds: 1
successThreshold: 1
failureThreshold: 1
exec:
command:
- cat
- /etc/nginx/nginx.conf
TCP Probe:
A TCP Probe verifica se uma porta específica está aberta. Uma porta aberta indica que o teste foi bem-sucedido.
Configuração de exemplo para a TCP Probe:
startupProbe:
initialDelaySeconds: 1
periodSeconds: 5
timeoutSeconds: 1
successThreshold: 1
failureThreshold: 1
tcpSocket:
host:
port: 80
HTTP Probe:
A HTTP Probe realiza uma solicitação GET, utilizando parâmetros definidos.
Opções adicionais para a configuração da HTTP Probe:
Recomendados pelo LinkedIn
Dica: O cabeçalho Host deve ser definido em httpHeaders.
Exemplo de configuração para HTTP Probe:
startupProbe:
initialDelaySeconds: 1
periodSeconds: 2
timeoutSeconds: 1
successThreshold: 1
failureThreshold: 1
httpGet:
host:
scheme: HTTP
path: /
httpHeaders:
- name: Host
value: myapplication1.com
port: 80
initialDelaySeconds: 5
periodSeconds: 5
Readiness Probes:
Semelhantes às outras sondagens, as sondas de prontidão verificam se o contêiner está pronto para receber tráfego. Enquanto a sonda de vida confirma se o sistema continua operacional, a sonda de prontidão assegura que as condições são adequadas para iniciar o fluxo de tráfego.
Isso é aplicado no nível do pod, o que significa que todos os contêineres devem estar prontos antes de qualquer tráfego ser encaminhado ao serviço. A sonda de inicialização, embora também semelhante, opera no nível da aplicação. Ela é ativada antes das sondas de vida ou prontidão.
Configurando uma Readiness Probes:
Para criar uma sonda de prontidão, inclui-se um campo readinessProbe na seção spec.containers do manifesto de um pod.
Exemplo de Exec Probe:
A ação Exec possui apenas um campo: command. O status de saída do comando é verificado; um status de saída zero (0) indica saúde, enquanto outro valor indica problema.
Configuração de exemplo para Exec Probe:
readinessProbe:
initialDelaySeconds: 1
periodSeconds: 5
timeoutSeconds: 1
successThreshold: 1
failureThreshold: 1
exec:
command:
- cat
- /etc/nginx/nginx.conf
Exemplo de TCP Probe:
É necessário definir os parâmetros host e port; o parâmetro host é predefinido para o IP interno do pod no cluster.
Configuração de exemplo para TCP Probe:
readinessProbe:
initialDelaySeconds: 1
periodSeconds: 5
timeoutSeconds: 1
successThreshold: 1
failureThreshold: 1
tcpSocket:
host:
port: 80
Exemplo de HTTP Probe:
A HTTP Probe oferece opções adicionais de configuração:
Dica: Se precisar definir o cabeçalho Host do HTTP, faça-o em httpHeaders, em vez do parâmetro host.
Configuração de exemplo para HTTP Probe:
readinessProbe:
initialDelaySeconds: 1
periodSeconds: 2
timeoutSeconds: 1
successThreshold: 1
failureThreshold: 1
httpGet:
host:
scheme: HTTP
path: /
httpHeaders:
- name: Host
value: myapplication1.com
port: 80
initialDelaySeconds: 5
periodSeconds: 5
Liveness probes:
As sondas de vida aprimoram a capacidade do Kubernetes de gerenciar cargas de trabalho automaticamente. Sem essas sondas, seria necessário monitorar manualmente os pods para identificar quais instâncias da aplicação estão saudáveis ou não. Em ambientes com centenas ou milhares de pods, essa tarefa se torna tediosa e suscetível a erros.
Permitir que pods não saudáveis continuem operando sem detecção pode prejudicar a estabilidade do serviço ao longo do tempo. Pods que falham silenciosamente ao longo do tempo, seja por condições de corrida, deadlocks ou caches corrompidos, podem diminuir gradualmente a capacidade do seu serviço de atender a novas requisições. Eventualmente, toda a frota de pods pode ser afetada, mesmo que todos os contêineres sejam reportados como ativos.
Configurando uma Liveness Probe:
As sondas de vida são especificadas no campo spec.containers.livenessProbe do manifesto de um pod.
Existem três tipos de ações que o kubelet pode realizar em um pod:
Exemplo de definição de um comando para sonda de vida:
Define a liveness command:
livenessProbe:
exec:
command:
- sh
- /tmp/status_check.sh
initialDelaySeconds: 10
periodSeconds: 5
Define a liveness HTTP request:
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 5
periodSeconds: 3
Define a TCP liveness probe:
---
initialDelaySeconds: 15
livenessProbe: ~
periodSeconds: 20
port: 8080
tcpSocket: ~
Conclusão:
Resumindo, as sondagens do Kubernetes são fundamentais para garantir a saúde e a resiliência de suas aplicações.
Elas proporcionam uma abordagem mais eficiente e baseada em dados para o monitoramento, o que facilita a tomada de decisões informadas e ajustes rápidos diante de mudanças nos padrões de uso da sua aplicação.
Utilizando essas verificações de saúde, é possível aprimorar a disponibilidade da aplicação, reduzir o esforço de manutenção e assegurar que sua aplicação não esteja apenas em execução, mas também acessível aos seus usuários.
Até a próxima 🤜🤛🎉