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.