Skip to main content

Liveness, Readiness y Startup Probes

Startup Probe​

El startup probe verifica si la aplicación dentro del pod terminó la inicialización. Esto es útil para aplicaciones que tienen un tiempo de inicialización más largo y pueden necesitar un tiempo adicional para quedar listas para recibir tráfico.

El Kubelet usa el startup probe para saber cuándo una aplicación contenedor fue iniciada. Si startup probe estuviera configurada, los readiness probe y liveness probe no serán iniciados hasta que el startup probe sea atendido, garantizando que esas sondas no interfieran en la inicialización de la aplicación. Esto puede ser usado para adoptar verificaciones de actividad en contenedores de inicialización lenta, evitando que sean eliminados por el Kubelet antes de estar en funcionamiento.

Readiness Probe​

La readiness probe es usada para indicar cuándo un pod está listo para servir el tráfico. Ella es usada para garantizar que el pod está listo para recibir conexiones y tráfico de red. Un balanceador de carga solamente debe enviar el tráfico para un pod que esté listo para procesar, o sea, ya inicializó completamente.

Un patrón común para sondas de actividad es usar un endpoint HTTP de bajo costo (healthcheck), pero con un failThreshold más alto. Eso garantiza que el pod sea observado como no listo por algún período de tiempo antes de ser eliminado forzadamente.

El Kubelet usa pruebas de readiness probe para saber cuándo un contenedor está listo para comenzar a aceptar tráfico. Un pod es considerado listo cuando todos sus contenedores están listos. Un uso de esa señal es controlar cuáles pods son usados como backends para servicios. Cuando un pod no está listo, él es removido de los balanceadores de carga de servicio.

Liveness Probe​

Ya la liveness probe es responsable por verificar si el pod está vivo y saludable. Si la liveness probe falla, el Kubernetes reinicia el pod para restaurar el estado saludable.

El Kubelet usa el liveness probe para saber cuándo reiniciar un contenedor. Por ejemplo, los liveness probe pueden detectar un deadlock, donde una aplicación está en ejecución, pero no consigue progresar. Reiniciar un contenedor en ese estado puede ayudar a tornar la aplicación más disponible, a pesar de los bugs.

Resumiendo, la readiness probe verifica si el pod está listo para aceptar tráfico, mientras la liveness probe verifica si el pod está vivo y funcional, pero solamente son usados después del startup probe.

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5
      failureThreshold: 1 # Número de intentos antes de eliminar el pod. El default es 3.
EOF