La implementación de aplicaciones en Kubernetes va más allá de un simple despliegue. Para garantizar una alta disponibilidad real y prevenir incidentes, es fundamental construir una arquitectura de defensa en profundidad, donde cada capa añade una capacidad de resiliencia adicional. A continuación, exploraremos las estrategias clave para lograrlo, desde la autorreparación básica hasta la gestión avanzada del tráfico.

1. Cimientos Sólidos: Despliegues y Probes de Salud

Un primer paso crítico es asegurar que nuestras aplicaciones se mantengan operativas y accesibles. Kubernetes, a través de sus objetos Deployment, facilita la gestión de un número deseado de réplicas de una aplicación. El controlador de Deployment trabaja en conjunto con los ReplicaSets, un mecanismo que garantiza que el número de Pods en ejecución siempre coincida con la configuración deseada.

Consideremos un ejemplo básico de un Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: servicio-web
spec:
  replicas: 4 # Queremos 4 instancias de nuestra app
  selector:
    matchLabels:
      app: mi-aplicacion
  template:
    metadata:
      labels:
        app: mi-aplicacion
    spec:
      containers:
      - name: contenedor-web
        image: imagen-app:v1.0
        ports:
        - containerPort: 8080

Si un Pod falla o se detiene inesperadamente, el ReplicaSet detectará la discrepancia y automáticamente iniciará un nuevo Pod para restaurar el número deseado de réplicas. Sin embargo, un Pod "en ejecución" no siempre significa que la aplicación dentro de él esté "lista" para servir tráfico.

Probes de Salud: La Visión Interna de la Aplicación

Para una resiliencia genuina, Kubernetes necesita entender el estado interno de nuestras aplicaciones. Esto se logra mediante los Probes de Salud:

• Readiness Probe (Sonda de Preparación): Indica si la aplicación está lista para recibir solicitudes. Si una sonda de preparación falla, Kubernetes (específicamente el Endpoint Controller) elimina la IP del Pod de los Service Endpoints, impidiendo que el tráfico sea dirigido a él. Esto es crucial durante actualizaciones, ya que evita que el tráfico se envíe a Pods que aún están inicializándose.
• Liveness Probe (Sonda de Vida): Determina si la aplicación está operativa. Si esta sonda falla, el kubelet reinicia el Pod. Esto ayuda a recuperar aplicaciones que pueden haber caído en un estado de bloqueo o error interno.

Integrando sondas en el Deployment:

# ... spec.template.spec.containers ...
      - name: contenedor-web
        image: imagen-app:v1.0
        ports:
        - containerPort: 8080
        readinessProbe: # Sonda de preparación
          httpGet:
            path: /salud/preparado # Ruta de nuestro endpoint de salud
            port: 8080
          initialDelaySeconds: 10 # Retraso inicial antes de la primera comprobación
          periodSeconds: 3      # Frecuencia de la comprobación
        livenessProbe: # Sonda de vida
          httpGet:
            path: /salud/vivo
            port: 8080
          initialDelaySeconds: 20
          periodSeconds: 5

Las sondas de salud transforman la autocuración básica de Kubernetes en un mecanismo mucho más inteligente y efectivo, asegurando que el tráfico solo se dirija a instancias verdaderamente funcionales.

2. Protección Ante Interrupciones Voluntarias: PodDisruptionBudget (PDB)

Mientras que los Deployment y los Probes manejan fallos inesperados y estados de la aplicación, ¿qué sucede cuando la infraestructura subyacente necesita mantenimiento? Operaciones como el vaciado de nodos (kubectl drain) o la reducción de clústeres son interrupciones voluntarias que, si no se gestionan correctamente, pueden afectar la disponibilidad del servicio.

El PodDisruptionBudget (PDB) es un "contrato" entre los propietarios de la aplicación y los operadores del clúster. Permite especificar un límite sobre cuántos Pods de un Deployment (o de otros controladores de replicación) pueden estar inactivos simultáneamente durante una interrupción voluntaria.

Un PDB puede definir:

• minAvailable: El número mínimo (o porcentaje) de Pods que deben estar disponibles en todo momento.
• maxUnavailable: El número máximo (o porcentaje) de Pods que pueden estar no disponibles simultáneamente.

Ejemplo de un PDB para nuestro servicio web:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: pdb-mi-aplicacion
spec:
  minAvailable: 75% # Asegura que al menos el 75% de los Pods estén siempre disponibles
  selector:
    matchLabels:
      app: mi-aplicacion # Vincula este PDB con nuestro Deployment

Con este PDB, si un operador intenta vaciar un nodo donde se ejecuta nuestro servicio, Kubernetes pausará la operación de vaciado si hacerlo violaría el presupuesto de interrupción, hasta que sea seguro proceder. Esto previene interrupciones no deseadas durante tareas de mantenimiento planificadas.

3. Gestión Avanzada del Tráfico: El Poder de Istio Service Mesh

A medida que las arquitecturas evolucionan hacia microservicios, la complejidad de la comunicación entre ellos crece exponencialmente. Manejar reintentos, tiempos de espera, balanceo de carga avanzado y patrones como el lanzamiento canario dentro del código de la aplicación puede ser engorroso y acopla la lógica de negocio con la lógica de red.

Aquí es donde un Service Mesh, como Istio, se vuelve indispensable. Istio desacopla las preocupaciones de red de la aplicación, proporcionando capacidades de observabilidad, seguridad y gestión de tráfico a nivel de infraestructura.

Funciona inyectando un proxy sidecar (Envoy) junto a cada Pod de aplicación. Estos proxies interceptan todo el tráfico entrante y saliente, formando el plano de datos. El plano de control (Istiod) gestiona y configura estos proxies basándose en reglas declarativas que definimos.

Caso de Uso: Despliegues Canary con Istio

Los despliegues canary permiten lanzar nuevas versiones de una aplicación a un pequeño porcentaje de usuarios antes de un despliegue completo, minimizando el riesgo. Con Istio, esto se logra configurando reglas de enrutamiento de tráfico.

1. Definir subconjuntos (Subsets) del servicio: Primero, categorizamos las diferentes versiones de nuestra aplicación utilizando DestinationRule, basándonos en las etiquetas de los Pods.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: mi-servicio
spec:
  host: mi-servicio # Nombre del servicio de Kubernetes
  subsets:
  - name: estable
    labels:
      version: "v1" # Pods con esta etiqueta representan la versión estable
  - name: beta
    labels:
      version: "v2" # Pods con esta etiqueta representan la versión beta

2. Crear reglas de enrutamiento con VirtualService: Luego, usamos VirtualService para especificar cómo se debe distribuir el tráfico entre estos subconjuntos.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: mi-servicio
spec:
  hosts:
  - mi-servicio
  http:
  - route:
    - destination:
        host: mi-servicio
        subset: estable
      weight: 95 # 95% del tráfico a la versión estable
    - destination:
        host: mi-servicio
        subset: beta
      weight: 5 # 5% del tráfico a la nueva versión beta

Con esta configuración, solo el 5% de los usuarios experimentarán la nueva versión (beta). Si el rendimiento es el esperado, el peso de beta puede aumentarse gradualmente hasta el 100%. Este proceso es transparente para los usuarios y permite una mitigación de riesgos excepcional.

Un Enfoque Multicapa para la Alta Disponibilidad

La verdadera alta disponibilidad en Kubernetes no es una característica única, sino el resultado de una estrategia multicapa:

• Capa Base (Deployment y ReplicaSet): Garantiza el número deseado de Pods y la autocuración fundamental.
• Capa de Conciencia (Probes de Salud): Permite a Kubernetes comprender el estado interno de la aplicación y dirigir el tráfico de manera inteligente.
• Capa de Protección (PodDisruptionBudget): Protege las aplicaciones de interrupciones no planificadas durante el mantenimiento del clúster.
• Capa de Orquestación de Tráfico (Service Mesh/Istio): Ofrece capacidades avanzadas de enrutamiento, resiliencia y observabilidad para microservicios complejos.

Al construir sistemas, es crucial considerar cada una de estas capas para asegurar que la aplicación esté verdaderamente preparada para cualquier eventualidad.