Sondas

En Kubernetes, las sondas (probes) son mecanismos que se utilizan para verificar el estado y la disponibilidad de los contenedores dentro de un pod. Kubernetes tiene tres tipos principales de sondas que ayudan a asegurar que las aplicaciones se mantengan en buen estado y que el tráfico no se redirija a servicios no disponibles. Los tipos de sondas son:

1. Liveness Probe (Sonda de Vida)

Objetivo: Detecta si un contenedor está en un estado saludable o si necesita ser reiniciado.
Funcionamiento: Si esta sonda falla, Kubernetes considera que el contenedor está en un estado no saludable y lo reiniciará automáticamente.
Uso común: Ideal para aplicaciones que pueden quedar bloqueadas o colgadas y que necesitan reiniciarse para volver a la normalidad.

2. Readiness Probe (Sonda de Preparación)

Objetivo: Indica si el contenedor está listo para recibir tráfico.
Funcionamiento: Si la sonda falla, el contenedor es retirado del balanceador de carga, y el tráfico no se dirigirá a él hasta que se recupere y esté listo nuevamente.
Uso común: Ideal para aplicaciones que necesitan cierto tiempo para inicializarse o cargar dependencias antes de empezar a recibir tráfico.

3. Startup Probe (Sonda de Inicio)

Objetivo: Verifica si un contenedor ha arrancado correctamente.
Funcionamiento: Kubernetes usa esta sonda para saber si la aplicación inicializó correctamente. Mientras esta sonda esté configurada, las otras (liveness y readiness) no se ejecutarán hasta que esta pase exitosamente.
Uso común: Útil para aplicaciones que tienen tiempos de inicio prolongados. Evita reinicios prematuros de contenedores durante el arranque.

Cómo Funcionan las Sondas

Las sondas pueden configurarse de varias maneras:

HTTP: Verifica una URL en el contenedor. Si recibe un código de respuesta exitoso (como 200), la sonda pasa.
Exec: Ejecuta un comando dentro del contenedor. Si el comando regresa un código de salida 0, la sonda pasa.
TCP Socket: Intenta conectarse a un puerto en el contenedor. Si la conexión es exitosa, la sonda pasa.

Ejemplo de Configuración de Sondas

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

startupProbe:
  httpGet:
    path: /startup
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 15
  failureThreshold: 30

Resumen

Las sondas son esenciales para asegurar la disponibilidad de las aplicaciones en Kubernetes, permitiendo que se mantengan funcionando correctamente y asegurando una experiencia estable para los usuarios.

Liveness tipo COMMAND

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: your-image:latest
    livenessProbe:
      exec:
        command:
          - cat
          - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 10

Liveness con HTTP

Ejemplo de Configuración de una Liveness Probe con HTTP

Esto podria ser un deploy con un service

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: your-image:latest
    livenessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10

Explicación del Ejemplo

httpGet: Configura la sonda para hacer una solicitud HTTP al contenedor.
- path: Especifica el endpoint que debe verificarse. En este caso, es /health. Se asume que el servicio expone un endpoint en esta ruta para verificar su salud.
- port: Especifica el puerto en el que el servicio está escuchando (aquí, el puerto 8080).
initialDelaySeconds: Espera 5 segundos después de que el contenedor inicia antes de ejecutar la primera comprobación de estado. Esto le da tiempo al contenedor para inicializarse.
periodSeconds: La sonda se ejecutará cada 10 segundos para comprobar el estado del servicio web.

¿Cómo Funciona en la Práctica?

Si el contenedor responde con un código de estado HTTP exitoso (por ejemplo, 200) en el endpoint /health, Kubernetes considera que el contenedor está en buen estado.
Si la solicitud HTTP falla (por ejemplo, porque el contenedor no responde, o porque responde con un código de error como 500), Kubernetes considera que el contenedor está en un estado no saludable y lo reiniciará.

Ejemplo Real

Muchos servicios web implementan un endpoint /health o /status que devuelve 200 OK cuando el servicio funciona bien, o un código de error si hay un problema. Esta configuración permite a Kubernetes reiniciar el contenedor automáticamente cuando el servicio web no esté disponible o esté en un estado no saludable.

Readliness de tipo SOCKET

Ejemplo de Configuración de una Readiness Probe con Socket TCP

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: your-image:latest
    readinessProbe:
      tcpSocket:
        port: 3306
      initialDelaySeconds: 5
      periodSeconds: 10

Explicación del Ejemplo

tcpSocket: Configura la sonda para intentar abrir una conexión TCP en un puerto específico.
- port: Especifica el puerto en el que se realiza la comprobación (en este ejemplo, el puerto 3306). Este puerto podría ser el de un servicio que requiera tiempo para inicializarse, como una base de datos.
initialDelaySeconds: Espera 5 segundos después de que el contenedor inicia antes de ejecutar la primera comprobación de estado. Esto permite que el servicio dentro del contenedor tenga tiempo de arrancar.
periodSeconds: La sonda intentará la conexión cada 10 segundos para comprobar si el contenedor está listo.

¿Cómo Funciona en la Práctica?

Si el contenedor acepta la conexión en el puerto especificado (3306 en este caso), Kubernetes considera que el contenedor está listo para recibir tráfico y lo incluirá en el balanceo de carga.
Si el puerto no responde, Kubernetes considera que el contenedor no está listo y lo excluirá del balanceo de carga hasta que pase la verificación.

Ejemplo Real

Este tipo de sonda es útil para servicios como bases de datos o aplicaciones que necesitan más tiempo para estar listas antes de recibir solicitudes. Usando un puerto TCP en lugar de una solicitud HTTP, es posible verificar la disponibilidad de servicios sin un endpoint HTTP, ideal para aplicaciones que funcionan a nivel de red (como servicios de bases de datos, servicios de mensajería, etc.).