Para verificar si un contenedor en un pod está sano y listo para servir el tráfico, Kubernetes proporciona una variedad de mecanismos de verificación de salud. Los controles de estado, o sondas como se les llama en Kubernetes, se llevan a cabo por el kubelet para determinar cuándo reiniciar un contenedor (para livenessProbe) y utilizado por los servicios y despliegues para determinar si un pod debe recibir tráfico (para readinessProbe).
Nos centraremos en las comprobaciones de estado de HTTP a continuación. Tenga en cuenta que es responsabilidad del desarrollador de la aplicación exponer una URL que el kubelet puede usar para determinar si el contenedor está en buen estado (y potencialmente listo).
Hay dos tipos de healchecks
Por comandos:
Podemos configurar la ejecución de comando periódico que se ejecuta en contexto de uno de los contenedores de mi pod, u otro muy comun es que podemos ejecutar llamadas HTTP endpoint que nos responda a una url y un path que le digamos y dependiendo de la respuesta nos dirá si nuestro contenedor está funcionando correctamente.
Por último, Kubernetes distingue entre dos tipos de healthchecks: ReadinessProbe y LivenessProbe.
LivenessProbe indica si el contenedor está funcionando incorrectamente y tiene que ser recreado.
ReadinessProbe indica si está listo para recibir tráfico, por ejemplo, imaginemos que tenemos un microservicio con una cache de redis, si la cache de redis no esta lista aunque yo como contenedor estoy listo si no tengo la cache de redis no podre servir peticiones, para este tipo de situaciones utilizamos ReadinessProbe.
Nótese que no significan lo mismo, un contenedor podría estar pasando el LivenessProbe, pero no pasar el ReadinessProbe porque, por ejemplo, necesita acceder a una base de datos que en este momento no está disponible.
Creemos un pod que exponga un punto final /health, respondiendo con un código 200 de estado HTTP :
apiVersion: v1 kind: Pod metadata: name: hc spec: containers: - name: sise image: mhausenblas/simpleservice:0.5.0 ports: - containerPort: 9876 livenessProbe: initialDelaySeconds: 2 periodSeconds: 5 httpGet: path: /health port: 9876
$ kubectl apply -f pod.yaml
En la especificación del pod hemos definido lo siguiente:
livenessProbe: initialDelaySeconds: 2 periodSeconds: 5 httpGet: path: /health port: 9876
Arriba significa que Kubernetes comenzará a verificar el punto final /health, después de esperar inicialmente 2 segundos, cada 5 segundos.
Si ahora miramos el pod, podemos ver que se considera saludable:
$ kubectl describe pod hc
Ahora lanzamos un pod malo , es decir, un pod que tiene un contenedor que aleatoriamente (en el rango de tiempo de 1 a 4 segundos) no devuelve un código 200:
apiVersion: v1 kind: Pod metadata: name: badpod spec: containers: - name: sise image: mhausenblas/simpleservice:0.5.0 ports: - containerPort: 9876 env: - name: HEALTH_MIN value: "1000" - name: HEALTH_MAX value: "4000" livenessProbe: initialDelaySeconds: 2 periodSeconds: 5 httpGet: path: /health port: 9876
$ kubectl apply -f badpod.yaml
Al observar los eventos del pod malo, podemos ver que la comprobación de estado falló:
$ kubectl describe pod badpod
…
Esto también se puede verificar de la siguiente manera:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
badpod 1/1 Running 4 2m
hc 1/1 Running 0 6m
Desde arriba, puede ver que badpod ya se había reiniciado 4 veces, ya que la comprobación de estado falló.
Además de livenessProbe, también puede especificar a readinessProbe, que se puede configurar de la misma manera pero tiene un caso de uso y una semántica diferentes: se utiliza para verificar la fase de inicio de un contenedor en el pod.
Imagine un contenedor que carga algunos datos del almacenamiento externo, como S3 o una base de datos que necesita inicializar algunas tablas. En este caso, desea indicar cuándo el contenedor está listo para servir el tráfico.
Creemos un pod con un readinessProbe que se active después de 10 segundos:
apiVersion: v1 kind: Pod metadata: name: ready spec: containers: - name: sise image: mhausenblas/simpleservice:0.5.0 ports: - containerPort: 9876 readinessProbe: initialDelaySeconds: 10 httpGet: path: /health port: 9876
$ kubectl apply -f ready.yaml
Al observar los eventos del pod, podemos ver que, eventualmente, el pod está listo para servir el tráfico:
$ kubectl describe pod ready
…
Conditions:
Type Status
Initialized True
Ready True
PodScheduled True
…
Puede eliminar todos los pods creados con:
$ kubectl delete pod/hc pod/ready pod/badpod
Resumen Health Checks:
• Readiness: ¿El contenedor esta listo para recibir trafico?
• Liveness: ¿El contenedor sigue vivo?
El flujo es el siguiente:
• Si Readiness falla
o Kubernetes detiene el trafico hacia el “pod” que falla de la aplicación
• Si Liveness falla
o Kubernetes reinicia el pod de la aplicación
• Si Readiness funciona
o Kubernetes restablece el tráfico hacia el pod de la aplicación nuevamente
