Prácticas de Probes en Kubernetes: Triple Garantía de Vida, Preparación e Inicio

Kubernetes proporciona tres tipos de probes para el manejo granular del ciclo de vida, estado de preparación y proceso de inicio de los contenedores. Estos mecanismos son cruciales para lograr alta disponibilidad y elasticidad del servicio. La siguiente tabla compara los aspectos fundamentales de cada tipo de probe:

Estos tres tipos de probes son componentes esenciales en la gestión del ciclo de vida de los Pods, trabajando juntos para garantizar que el servicio permanezca controlado desde el inicio hasta la terminación.

Tipos de Probes (Mecanismos de Detección)

Cada probe puede utilizar tres diferentes "mecanismos de detección" (es decir, handler) para ejecutar la lógica específica de verificación de salud:

1. Probe HTTP GET

Envía una solicitud HTTP GET a una dirección IP, puerto y ruta específicos dentro del contenedor. Códigos de estado HTTP entre 200 y 399 se consideran éxito, mientras que otros códigos o fallos de conexión se consideran fallos.

# Ejemplo: Configuración de un probe de vida usando HTTP GET
apiVersion: v1
kind: Pod
metadata:
  name: probe-salud-http
spec:
  containers:
  - name: servicio-web
    image: mi-repo/imagen-salud:latest
    ports:
    - containerPort: 8080
    livenessProbe:
      httpGet:
        path: /estado-salud
        port: 8080
        httpHeaders:
        - name: Cabecera-Personalizada
          value: Excelente
      initialDelaySeconds: 5
      periodSeconds: 10
      timeoutSeconds: 2
      failureThreshold: 4

Este método es adecuado para cualquier aplicación que ofrezca servicios HTTP, siendo la forma más común y conveniente de verificación.

2. Probe TCP Socket

Intenta establecer una conexión TCP con un puerto específico del contenedor. Si la conexión se establece correctamente, se considera un éxito; si falla, se considera un fracaso.

# Ejemplo: Configuración de un probe de preparación usando TCP Socket
apiVersion: v1
kind: Pod
metadata:
  name: probe-preparacion-tcp
spec:
  containers:
  - name: servicio-datos
    image: base-datos:estable
    readinessProbe:
      tcpSocket:
        port: 5432 # Puerto de la base de datos
      initialDelaySeconds: 15
      periodSeconds: 20
      failureThreshold: 3

Este método es ideal para aplicaciones que no ofrecen servicios HTTP pero tienen puertos de red abiertos, como bases de datos, sistemas de caché o servicios TCP personalizados.

3. Probe Exec

Ejecuta un comando personalizado dentro del contenedor para realizar la verificación. Si el código de salida del comando es 0, se considera un éxito; de lo contrario, un fracaso.

# Ejemplo: Configuración de un probe de vida usando Exec, verificando archivo de estado
apiVersion: v1
kind: Pod
metadata:
  name: probe-salud-ejecucion
spec:
  containers:
  - name: monitoreo-app
    image: sistema-base
    args:
    - /bin/sh
    - -c
    - while true; do echo "servicio activo" > /tmp/estado; sleep 60; done
    livenessProbe:
      exec:
        command:
        - grep
        - "activo"
        - /tmp/estado
      initialDelaySeconds: 10
      periodSeconds: 30

Este método es el más flexible, permitiendo ejecutar cualquier script o comando para verificar el estado interno de la aplicación, como verificar la existencia de procesos específicos, contenido de archivos de registro o espacio en disco.

Preguntas de Entrevista Detalladas

A continuación se presentan varias preguntas típicas sobre probes en Kubernetes junto con sus respuestas:

1. Pregunta: ¿Cuáles son las diferencias principales entre un probe de vida (Liveness Probe) y un probe de preparación (Readiness Probe) en Kubernetes? ¿En qué escenarios se debe utilizar cada uno?

Diferencias clave: La principal diferencia radica en la acción que se toma cuando la detección falla. Un probe de vida fallante provoca que el contenedor sea reiniciado, con el objetivo de recuperar la instancia fallida. Un probe de preparación fallante resulta en que el Pod sea eliminado del pool de balanceo de carga del Service, evitando que el tráfico sea dirigido a instancias que aún no están listas o temporalmente no pueden servir.

Ejemplos de escenarios:

• Uso de probe de vida: Un servidor web que gradualmente se bloquea debido a una fuga de memoria, dejando de responder a las solicitudes. El probe de vida (por ejemplo, una verificación HTTP a /health) falla continuamente, lo que hace que kubelet reinicie el contenedor, intentando restaurar el servicio.
• Uso de probe de preparación: Una aplicación que necesita 30 segundos después del inicio para cargar configuraciones desde la base de datos o establecer conexiones en el pool. Durante este tiempo, el probe de preparación fallará, y Kubernetes no enrutará solicitudes externas hacia él. Una vez completada la carga, el probe de preparación tendrá éxito y el Pod se agregará a los endpoints del servicio.

2. Pregunta: ¿Qué problema resuelve el probe de inicio (Startup Probe)? ¿Cuál es su relación con el probe de vida?

Problema resuelto: El probe de inicio aborda específicamente el problema de las aplicaciones con arranque lento. Para estas aplicaciones, si se configura un probe de vida con un retraso inicial (initialDelaySeconds) corto, la aplicación podría ser declarada como fallida y reiniciada antes de completar su proceso de inicio, entrando en un ciclo "inicio → eliminación → reinicio".

Relación con el probe de vida: El probe de inicio asume temporalmente la verificación de salud durante el inicio del contenedor. Antes de que el probe de inicio tenga éxito por primera vez, ni el probe de vida ni el de preparación se activarán. Esto proporciona una ventana de inicio protegida para las aplicaciones lentas. Una vez que el probe de inicio tiene éxito, su tarea se completa y las verificaciones posteriores se delegan completamente a los probes de vida y preparación. Si el probe de inicio falla persistentemente (supera failureThreshold), el contenedor también será reiniciado.

3. Pregunta: ¿Cómo configurar los probes para una aplicación Java recién desplegada que necesita 2 minutos para iniciarce, asegurando que no sea eliminada incorrectamente durante el inicio y solo reciba tráfico cuando esté completamente lista?

Este es un escenario típico que requiere el uso combinado de los tres tipos de probes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: aplicacion-java-lenta
spec:
  template:
    spec:
      containers:
      - name: servidor-java
        image: mi-aplicacion-java:ultima
        ports:
        - containerPort: 8080
        startupProbe:
          httpGet:
            path: /actuator/health
            port: 8080
          failureThreshold: 24 # 24 intentos
          periodSeconds: 5 # Cada 5 segundos, proporcionando 24*5=120 segundos (2 minutos) de tiempo
        livenessProbe:
          httpGet:
            path: /actuator/health
            port: 8080
          initialDelaySeconds: 130 # Esperar a que el probe de inicio termine
          periodSeconds: 15
          failureThreshold: 2
        readinessProbe:
          httpGet:
            path: /actuator/listo
            port: 8080
          initialDelaySeconds: 130
          periodSeconds: 10
          failureThreshold: 1

Lógica de configuración: Se utiliza startupProbe para proteger el período de inicio de 2 minutos. Los valores de initialDelaySeconds para livenessProbe y readinessProbe se establecen al menos en el tiempo máximo posible del probe de inicio (failureThreshold * periodSeconds), asegurando que solo comiencen a trabajar después de que la aplicación se haya iniciado por completo. El readinessProbe puede tener una verificación más estricta (como verificar servicios externos dependientes), asegurando que el tráfico solo ingrese cuando la aplicación esté completamente lista.

4. Pregunta: ¿Qué significan los parámetros initialDelaySeconds, periodSeconds, timeoutSeconds y failureThreshold en la configuración de probes?

• initialDelaySeconds: Número de segundos a esperar después del inicio del contenedor antes de ejecutar la primera verificación. Es crucial para aplicaciones con arranque lento.
• periodSeconds: Intervalo en segundos entre ejecuciones consecutivas de verifciación, es decir, la frecuencia de verificación.
• timeoutSeconds: Tiempo de espera para una sola verificación. Si la verificación no devuelve resultados dentro de este tiempo, se considera un fallo.
• failureThreshold: Número de fallos consecutivos después de los cuales Kubernetes declara finalmente que la verificación ha fallado (para el probe de vida significa reinicio, para el probe de preparación significa marcar como no listo). Este parámetro proporciona tolerancia a fallos transitorios.