Readiness, Liveness e Startup Probes
Alguns materiais já temos no CKA.
Siga a seguinte ordem.
Antes de falar sobre os topicos abaixo vamos entender o life cycle de um pod.
Um pod possui seus status que pode ser visto com o comando kubectl describe. Logo que o pod é criado ele fica em Pending. Isso significa que o scheduler precisa definir um node para ele que atenda as condições necessárias. Se o scheduler não conseguir encontrar um node adequado ele ficará no estado de pending.
Quando um pod ele entra no estado de Container Creatingo scheduler já definiu um node. Nesse momento o pull das imagens dos contaienrs desse pod serão iniciados.
Uma vez inicado os container ele entra no estado de Running.
Para que estas etapas sejam marcadas podemos ver com o comando kubectl describe em conditions.
❯ k run nginx --image nginx
pod/nginx created
❯ k describe pod nginx
Name: nginx
Namespace: kube-system
Priority: 0
Service Account: default
Node: cka-cluster-worker/172.18.0.5
Start Time: Wed, 01 May 2024 22:55:01 -0300
Labels: run=nginx
Annotations: <none>
Status: Running
IP: 10.42.0.1
IPs:
IP: 10.42.0.1
Containers:
nginx:
Container ID: containerd://3711ea86007c956593e6bf9f1db3e9859057f9d120163466b3f3d3500fd3155e
Image: nginx
Image ID: docker.io/library/nginx@sha256:ed6d2c43c8fbcd3eaa44c9dab6d94cb346234476230dc1681227aa72d07181ee
Port: <none>
Host Port: <none>
State: Running
Started: Wed, 01 May 2024 22:55:08 -0300
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-z4x92 (ro)
Conditions:
Type Status
PodReadyToStartContainers True # <<< VEJAS AS CONDIÇÕES
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
kube-api-access-z4x92:
Type: Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds: 3607
ConfigMapName: kube-root-ca.crt
ConfigMapOptional: <nil>
DownwardAPI: true
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 8s default-scheduler Successfully assigned kube-system/nginx to cka-cluster-worker
Normal Pulling 8s kubelet Pulling image "nginx"
Normal Pulled 2s kubelet Successfully pulled image "nginx" in 5.718s (5.718s including waiting)
Normal Created 2s kubelet Created container nginx
Normal Started 2s kubelet Started container nginx
Vamos falar especificamente do bloco abaixo.
Conditions:
Type Status
PodReadyToStartContainers True
Initialized True
Ready True
ContainersReady True
PodScheduled True
Ready true e ContainersReadyquerem dizer quer as aplicações dentro dos pods então funcionando e prontas para receber tráfego. Algumas aplicações demoram mais que outras para ficar prontas. Algumas levem milisegundos para iniciar e outras podem demorar 30 segundos para terminar o processo de start. Nesse momento o pod está em estado de Running o que não é necessariamente verdade.
O kubernetes po padrão entende que um pod assim que é iniciado já está pronto para receber tráfego e o service que aponta para esse pod já irá distribuir tráfego para ele.
O que podemos é testar a aplicação de alguma maneira que somente se o teste for bem sucedido este estado seja alterado para true. É ai que entra os probes. Se fosse uma aplicação web, como desenvolvedor, poderíamos endpoint de healthcheck que responda ok. Poderíamos executar um script dentro do container para conferir se já esta tudo pronto.
Quando temos um bloco readinessProbe, a condição não é definida imediatamente para true.
Uma vez tendo o readiness aconteceria isso.
Agora que já entendemos um pouco vamos falar sobre o liveness. Quando um container para de funcionar E O KUBERNETES DETECTA ele automaticamente reinicia o pod, mas existem casos que o container fica em loop infinito e a aplicação não para. É para isso que serve o liveness, testar a aplicação constantemente para ver se está respondendo. Caso não responda é alterado forçadamente as condições para que esse pod possa sofrer um restart.
As definições desse bloco são as mesmas do readiness.
Vale a pena mencionar que o readiness e o liveness podem sofrer condições de corrida. Imagine definimos um liveness para testar a cada 5 segundos um endpoint de healthcheck e definimos que se testar 3 vezes e não responder invalida o pod, mas a aplicação demora 1 minuto para ficar pronta. Obviamente que o pod nunca irá subir pois ele sempre sofrerá um restart antes mesmo de ficar pronto.