Tenha o Kubernetes ao seu lado, use Probes!



Durante a sua jornada no mundo do Kubernetes, certamente você já se deparou com algum campo desconhecido no manifesto de algum objeto. Todos os objetos que criam Pods são considerados básicos no cluster (Pod, Deployment, DaemonSet, StatefulSet, etc). Mesmo assim, todos eles possuem uma quantidade enorme de campos para personalização de nossos micros serviços. Hoje exploraremos a seção dos Probes, para dar uma breve explicação sobre suas funcionalidades e passar alguns exemplos básicos para te ajudar a usá-lo no seu cluster.



Todos os Pods que rodam nas máquinas do cluster são gerenciados pelo kubelet. Ele é o agente responsável pelo funcionamento dos Probes, podendo ser do tipo Liveness, Readiness e o Startup Probe.



Liveness Probe



O Kubelet usa o Liveness Probe para reiniciar os Pods da aplicação caso eles parem de retornar respostas de sucesso às requisições de teste. Elas podem ser simples comandos, requisições TCP, HTTP ou gRPC. Esse comportamento é desejável para reiniciar a aplicação em caso de travamentos, bugs, memory leak e outros. 



Segue um exemplo abaixo de um manifesto de Pod configurado para usar o Liveness Probe com requisições HTTP. 



apiVersion: v1

kind: Pod

metadata:

  labels:

    test: liveness

  name: liveness-http

spec:

  containers:

  - name: liveness

    image: registry.k8s.io/liveness

    args:

    - /server

    livenessProbe:

      httpGet:

        path: /healthz

        port: 8080

        httpHeaders:

        - name: Custom-Header

          value: Awesome

      initialDelaySeconds: 3

      periodSeconds: 3



A imagem usada (registry.k8s.io/liveness) foi propositalmente criada para entregar um código de retorno HTTP 200 até os dez primeiros segundos de vida do Pod. Após, ele retorna 500. Ao aplicar esse manifesto no cluster, notamos que o Pod é reiniciado logo após esse tempo mencionado, isto é, o Kubelet cumpre o seu papel reiniciando a aplicação na tentativa de solucionar o problema. Para um cenário real, essa resposta de falha pode indicar algum problema sério no Pod, sendo desejável que um novo seja provisionado no lugar.





Pelos eventos mostrados do cluster acima, evidenciamos que o probe falha e recebe o código HTTP 500. Ao falhar três vezes consecutivas, o Kubelet reinicia o Pod.



Readiness Probe



Nem sempre você quer derrubar a aplicação nesses cenários de falhas. Há a opção de apenas suspendê-la para que, por exemplo, ela termine de executar alguma rotina crítica. Nesse caso, o Kubelet usa o Readiness Probe para cessar o envio de requisições aos Pods da aplicação, caso eles parem de retornar respostas de sucesso às requisições de teste. A configuração no manifesto é semelhante ao Liveness, mudando apenas o campo inicial de livenessProbe para redinessProbe.



Usaremos a mesma imagem do exemplo anterior para avaliar o que muda no status do Pod ao usarmos o readinessProbe:



apiVersion: v1

kind: Pod

metadata:

  labels:

    test: readiness

  name: readiness-http

spec:

  containers:

  - name: readiness

    image: registry.k8s.io/liveness

    args:

    - /server

    readinessProbe:

      httpGet:

        path: /healthz

        port: 8080

        httpHeaders:

        - name: Custom-Header

          value: Awesome

      initialDelaySeconds: 3

      periodSeconds: 3



Para essa simulação, notamos que, após a subida do Pod, a coluna de status “READY” apresenta o valor “0/1”, mostrando que ele não está apto para receber requisições. Isso é útil para situações em que a aplicação está lidando com um alto volume de carga durante a sua subida e precisa aguardar para receber tráfego. 



Startup Probe



O Kubelet usa o Startup Probe para permitir a subida dos Pods da aplicação. Nesse intervalo de subida, configurado pelo administrador, o Liveness e o Readiness Probes são suspensos, para evitar ações indesejadas nesse momento que a aplicação ainda não está preparada. Vale ressaltar que, a partir do primeiro sucesso do Startup Probe, os demais Probes assumem suas responsabilidades, isto é, suspender o tráfego para o Readiness e reiniciar o Pod para o Liveness. Caso a sua aplicação não tenha um comportamento regular na subida, é interessante usar o Startup Probe com um intervalo de tempo maior para evitar suspensões ou restarts indesejados no cluster.



A seguir temos um trecho de exemplo com a combinação do livenessProbe e startupProbe:



ports:

- name: liveness-port

  containerPort: 8080

  hostPort: 8080

livenessProbe:

  httpGet:

    path: /healthz

    port: liveness-port

  failureThreshold: 1

  periodSeconds: 10

startupProbe:

  httpGet:

    path: /healthz

    port: liveness-port

  failureThreshold: 30

  periodSeconds: 10



Para esse exemplo acima, o Startup Probe prevalecerá por até 5 minutos ( 30 * 10 = 300 s). Após o primeiro sucesso, o Liveness Probe assume o controle.



Conclusão



Você que leu até aqui, coloque em prática esse conhecimento adquirido e use o potencial do Kubernetes ao seu favor para aumentar a resiliência do seu ambiente. Esses pequenos ajustes podem fazer diferença na confiabilidade geral do seu cluster.


Social

Fale conosco

Almeda Campinas 802, CJ 12, Jardim Paulista,

São Paulo - SP, 01404-001

Faça parte do time

Nossos conteúdos

Social

Fale conosco

Almeda Campinas 802, CJ 12, Jardim Paulista,

São Paulo - SP, 01404-001

Faça parte do time

Nossos conteúdos

Social

Fale conosco

Almeda Campinas 802, CJ 12, Jardim Paulista,

São Paulo - SP, 01404-001

Faça parte do time

Nossos conteúdos