Readiness, Liveness y Startup Probes
Algunos materiales ya tenemos en el CKA.
Siga el siguiente orden.
Antes de hablar sobre los tópicos abajo vamos a entender el life cycle de un pod.
Un pod posee sus status que puede ser visto con el comando kubectl describe. Luego que el pod es creado él queda en Pending. Eso significa que el scheduler precisa definir un node para él que atienda las condiciones necesarias. Si el scheduler no consigue encontrar un node adecuado él quedará en el estado de pending.
Cuando un pod él entra en el estado de Container Creating el scheduler ya definió un node. En ese momento el pull de las imágenes de los containers de ese pod serán iniciados.
Una vez iniciado los container él entra en el estado de Running.
Para que estas etapas sean marcadas podemos ver con el comando kubectl describe en 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 # <<< VEAS LAS CONDICIONES
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 a hablar específicamente del bloque abajo.
Conditions:
Type Status
PodReadyToStartContainers True
Initialized True
Ready True
ContainersReady True
PodScheduled True
Ready true y ContainersReady quieren decir que las aplicaciones dentro de los pods entonces funcionando y listas para recibir tráfico. Algunas aplicaciones demoran más que otras para quedar listas. Algunas llevan milisegundos para iniciar y otras pueden demorar 30 segundos para terminar el proceso de start. En ese momento el pod está en estado de Running lo que no es necesariamente verdad.
El kubernetes por padrón entiende que un pod así que es iniciado ya está listo para recibir tráfico y el service que apunta para ese pod ya irá distribuir tráfico para él.
Lo que podemos es testar la aplicación de alguna manera que solamente si el test for bien sucedido este estado sea alterado para true. Es ahí que entra los probes. Si fuese una aplicación web, como desarrollador, podríamos endpoint de healthcheck que responda ok. Podríamos ejecutar un script dentro del contenedor para conferir si ya está todo listo.
Cuando tenemos un bloque readinessProbe, la condición no es definida inmediatamente para true.
Una vez teniendo el readiness acontecería eso.
Ahora que ya entendemos un poco vamos a hablar sobre el liveness. Cuando un contenedor para de funcionar Y EL KUBERNETES DETECTA él automáticamente reinicia el pod, pero existen casos que el contenedor queda en loop infinito y la aplicación no para. Es para eso que sirve el liveness, testar la aplicación constantemente para ver si está respondiendo. Caso no responda es alterado forzadamente las condiciones para que ese pod pueda sufrir un restart.
Las definiciones de ese bloque son las mismas del readiness.
Vale la pena mencionar que el readiness y el liveness pueden sufrir condiciones de corrida. Imagine definimos un liveness para testar a cada 5 segundos un endpoint de healthcheck y definimos que si testar 3 veces y no responder invalida el pod, pero la aplicación demora 1 minuto para quedar lista. Obviamente que el pod nunca irá subir pues él siempre sufrirá un restart antes mismo de quedar listo.