Compreendendo as sondagens do Kubernetes: melhore as verificações de integridade dos aplicativos.

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:

  • Liveness probes: Verificam a saúde de um pod através de comandos ou solicitações de rede. Contêineres que não passam neste teste são reiniciados.
  • Readiness probes: Determinam se um contêiner está pronto para receber tráfego externo. Os contêineres são incluídos em serviços apenas após passarem por esta sondagem.
  • Startup probes: Atrasam as sondagens de vida e prontidão até que o contêiner esteja preparado para elas. Sem uma sondagem de inicialização bem-sucedida, as outras sondagens não são aplicadas.

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:

  • host: Host ou IP para conexão (padrão: IP do pod)
  • scheme: Esquema usado na solicitação (padrão: HTTP)
  • path: Caminho
  • httpHeaders: Um array de cabeçalhos definidos como pares nome/valor.
  • port: Porta para a conexão

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:

  • host: Host ou IP para conexão (padrão: IP do pod)
  • scheme: Esquema usado na solicitação (padrão: HTTP)
  • path: Caminho
  • httpHeaders: Um array de cabeçalhos definidos como um mapa de nome/valor
  • port: Porta para a conexã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:

  1. Execução de um comando dentro do contêiner.
  2. Verificação do estado de uma porta específica no contêiner.
  3. Realização de uma solicitação GET no IP do contêiner.

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 🤜🤛🎉


Entre para ver ou adicionar um comentário

Outros artigos de Edilson Freitas

Outras pessoas também visualizaram

Conferir tópicos