Skip to main content

Liveness e Readness | Kubernetes

  • Liveness e Readness | Kubernetes
warning

Configuração feita dentro do POD

Liveness e Readiness Probes são funcionalidades essenciais no Kubernetes para monitorar e gerenciar a saúde de contêineres em um cluster. Elas permitem ao Kubernetes tomar decisões automatizadas sobre o ciclo de vida dos pods, garantindo que os serviços estejam sempre disponíveis e funcionando conforme o esperado.


1. Liveness Probe

A Liveness Probe verifica se o contêiner está vivo, ou seja, se ele ainda está em execução ou em um estado de funcionamento básico.

  • Objetivo:

    • Detectar falhas em contêineres.
    • Reiniciar o contêiner automaticamente caso ele entre em um estado não saudável.
  • Exemplo de uso:

    • Um serviço que trava devido a um deadlock ou problema crítico, mas o contêiner em si não é encerrado.

Como Configurar:

Você pode usar diferentes métodos para verificar a liveness:

  1. HTTP Endpoint:

    livenessProbe:
    httpGet:
    path: /healthz
    port: 8080
    initialDelaySeconds: 3
    periodSeconds: 5

    Nesse caso, o Kubernetes faz uma requisição HTTP para o endpoint /healthz no contêiner. Se o retorno não for um código HTTP 200, o contêiner é considerado inativo.

  2. Comando (exec):

    livenessProbe:
    exec:
    command:
    - cat
    - /tmp/healthy
    initialDelaySeconds: 5
    periodSeconds: 10

    O Kubernetes executa o comando especificado no contêiner. Se o retorno for diferente de 0 (código de sucesso), o contêiner é considerado inativo.

  3. TCP Socket:

    livenessProbe:
    tcpSocket:
    port: 8080
    initialDelaySeconds: 5
    periodSeconds: 10

    O Kubernetes verifica se consegue abrir uma conexão TCP no contêiner na porta especificada.


2. Readiness Probe

A Readiness Probe verifica se o contêiner está pronto para receber tráfego.

  • Objetivo:

    • Garantir que o contêiner esteja pronto antes de começar a receber solicitações.
    • Remover o pod temporariamente de um serviço se ele não estiver pronto.
  • Exemplo de uso:

    • Um contêiner pode demorar para iniciar porque precisa carregar dados ou se conectar a outro serviço antes de estar pronto.

Como Configurar:

A configuração é muito parecida com a Liveness Probe, mas a ação associada é diferente (não reinicia o contêiner, apenas o remove do tráfego do serviço).

  1. HTTP Endpoint:

    readinessProbe:
    httpGet:
    path: /readiness
    port: 8080
    initialDelaySeconds: 3
    periodSeconds: 5
  2. Comando (exec):

    readinessProbe:
    exec:
    command:
    - cat
    - /tmp/ready
    initialDelaySeconds: 5
    periodSeconds: 10
  3. TCP Socket:

    readinessProbe:
    tcpSocket:
    port: 8080
    initialDelaySeconds: 5
    periodSeconds: 10

Diferenças entre Liveness e Readiness

AspectoLiveness ProbeReadiness Probe
ObjetivoVerificar se o contêiner está vivo.Verificar se o contêiner está pronto para atender.
Ação ao falharReinicia o contêiner.Remove o pod do tráfego temporariamente.
Cenário de uso comumTravamentos ou loops infinitos.Inicializações demoradas ou dependências externas.

3. Configuração Completa no Pod

Aqui está um exemplo de configuração de um pod com ambas as probes:

apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
containers:
- name: example-container
image: my-app:1.0
ports:
- containerPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 3
periodSeconds: 5
readinessProbe:
httpGet:
path: /readiness
port: 8080
initialDelaySeconds: 3
periodSeconds: 5

Dicas:

  1. Defina os tempos corretamente:

    • initialDelaySeconds: Tempo para o Kubernetes esperar antes de começar a checar (evita falhas em processos de inicialização demorados).
    • periodSeconds: Intervalo entre as verificações.
  2. Use Liveness Probe com cautela:

    • Apenas reinicie contêineres se necessário. Para serviços críticos, uma estratégia de recuperação mais controlada pode ser preferível.
  3. Combine Liveness e Readiness:

    • Use ambas as probes para lidar com diferentes cenários de saúde e prontidão.

Essas ferramentas são fundamentais para garantir que os aplicativos em execução no Kubernetes sejam resilientes e confiáveis, mesmo em ambientes complexos. 🚀