Optimización de Kubernetes para Alta Disponibilidad

La alta disponibilidad (HA) es un requisito indispensable en entornos de producción modernos. Si tu stack se basa en Kubernetes, la optimización de la orquestación no es un lujo, es una necesidad. Un clúster mal configurado puede traducirse en downtime, pérdida de datos y degradación del servicio.

En este artículo, exploraremos las estrategias clave para optimizar Kubernetes para alta disponibilidad. Abordaremos desde el plano de control hasta las aplicaciones, pasando por el almacenamiento y la red. Si gestionas contenedores a escala, esto te interesa.

Fundamentos del Plano de Control HA

El corazón de Kubernetes es el plano de control (control plane). Si cae, el clúster deja de responder a cambios de estado. Para garantizar la continuidad, debemos optimizar su arquitectura.

Etcd: El almacén de estado crítico

etcd es la base de datos distribuida que almacena todo el estado del clúster. Su alta disponibilidad es prioritaria.

• Implementación multi-nodo: Despliega un número impar de miembros etcd (3, 5 o 7). El número impar permite que el algoritmo Raft (consenso) funcione correctamente incluso si falla un nodo.
• Aislamiento de recursos: No ejecutes etcd en nodos que alojen cargas de trabajo de aplicaciones pesadas. El I/O de disco y la latencia de red son críticos para etcd.
• Discos rápidos: Usa discos SSD con alto IOPS. etcd es sensible a la latencia de escritura.

[WARNING] Evita clústeres etcd con un número par de miembros. En caso de split-brain, el consenso puede romperse, dejando el clúster inoperativo.

API Server y Scheduler Multi-instancia

El API Server es el frontend del plano de control. Para hacerlo tolerante a fallos:

1. Balanceo de carga: Coloca un balanceador de carga (como HAProxy o un Cloud Load Balancer) delante de las réplicas del API Server.
2. Múltiples réplicas: Despliega al menos 2 o 3 copias del API Server, Scheduler y Controller Manager en diferentes nodos.
3. Leader Election: El Scheduler y el Controller Manager utilizan líder-elección. Solo una instancia está activa a la vez. Esto es normal y deseable.

# Ejemplo de configuración de alta disponibilidad para kube-scheduler
apiVersion: apps/v1
kind: Deployment
metadata:
  name: kube-scheduler
  namespace: kube-system
spec:
  replicas: 3  # Múltiples réplicas para HA
  strategy:
    type: RollingUpdate
  template:
    spec:
      containers:
      - command:
        - kube-scheduler
        - --leader-elect=true  # Habilita la elección de líder
        ...

Optimización de la Capa de Red y Almacenamiento

Una vez asegurado el plano de control, toca optimizar la capa de datos.

Red: CNI y Service Mesh

La red es el pegamento de los contenedores. Un fallo en la red puede aislar nodos enteros.

• CNI (Container Network Interface) robusto: Elige un plugin CNI con soporte HA nativo. Calico con BGP o Cilium con eBPF son excelentes opciones. Ambos permiten rutas redundantes y failover rápido.
• Topology Aware Routing: Configura este feature para que el tráfico se quede dentro de la misma zona de disponibilidad si es posible. Reduce latencia y dependencia de enlaces entre zonas.
• Service Mesh (opcional pero potente): Herramientas como Istio o Linkerd añaden resiliencia a nivel de aplicación: retries, circuit breakers y timeouts. Esto mejora la alta disponibilidad del servicio frente a fallos parciales.

Almacenamiento Persistente HA

Las aplicaciones stateful (bases de datos, colas) necesitan almacenamiento que sobreviva a la muerte de un Pod.

• CSI Drivers con soporte HA: Usa drivers CSI (Container Storage Interface) que soporten volúmenes en modo ReadWriteMany (RWX) o que repliquen datos entre zonas. Ejemplos: Rook/Ceph, Longhorn, Portworx.
• Topology Constraints: Asegura que los Pods que usan un volumen se programen en el mismo nodo o zona que el volumen. Usa nodeAffinity y topologySpreadConstraints para ello.

[TIP] Para bases de datos críticas, no confíes solo en la replicación del storage. Implementa replicación a nivel de aplicación (por ejemplo, PostgreSQL con Patroni) para una alta disponibilidad real.

Estrategias de Programación y Escalado

La orquestación inteligente de Pods es clave para la optimización.

Pod Disruption Budgets (PDBs)

Los PDBs limitan cuántos Pods de una aplicación pueden estar caídos al mismo tiempo. Son esenciales para operaciones de mantenimiento (drenado de nodos).

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: mi-app-pdb
spec:
  minAvailable: 2  # Al menos 2 réplicas deben estar siempre operativas
  selector:
    matchLabels:
      app: mi-app

Topology Spread Constraints

Distribuye tus Pods entre nodos, zonas o regiones para evitar que un fallo a nivel de rack o datacenter tumbe toda la aplicación.

spec:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        app: mi-app

Anti-Afinidad de Pods

Evita que dos réplicas del mismo servicio se ejecuten en el mismo nodo.

spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - mi-app
        topologyKey: "kubernetes.io/hostname"

Monitoreo y Auto-Recuperación

No hay alta disponibilidad sin visibilidad. La optimización continua requiere datos.

Probes: Liveness, Readiness y Startup

Configura correctamente los tres tipos de probes:

• livenessProbe: Reinicia el contenedor si la aplicación se cuelga.
• readinessProbe: Indica si el Pod está listo para recibir tráfico. Si falla, el Service quita el Pod del balanceo.
• startupProbe: Útil para aplicaciones que tardan en arrancar. Retrasa las otras probes.

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 3
  periodSeconds: 3
readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5

Cluster Autoscaler y HPA

• Cluster Autoscaler: Añade o elimina nodos del clúster según la demanda. Crítico para picos de tráfico.
• Horizontal Pod Autoscaler (HPA): Escala el número de réplicas de un Deployment basándose en métricas (CPU, memoria o métricas personalizadas).

[INFO] El HPA combinado con un PDB bien configurado permite escalar sin downtime. El autoscaler espera a que el nuevo Pod esté listo antes de terminar el viejo (RollingUpdate).

Pruebas de Resiliencia: Chaos Engineering

La teoría no basta. Debes probar tu alta disponibilidad de forma activa.

• Simula fallos: Usa herramientas como Chaos Mesh o Litmus para matar Pods, nodos o inyectar latencia de red.
• Prueba el failover: Apaga un nodo maestro y verifica que el plano de control sigue operativo.
• Verifica PDBs: Drena un nodo y comprueba que el PDB impide que se terminen demasiados Pods.

Conclusión: La Optimización es un Proceso Continuo

Optimizar Kubernetes para alta disponibilidad no es un proyecto de un fin de semana. Es un proceso iterativo que abarca:

1. Plano de control: etcd multi-nodo, API Server balanceado.
2. Red y almacenamiento: CNI robusto, storage HA con CSI.
3. Orquestación de Pods: PDBs, anti-afinidad, topology spread.
4. Monitoreo y auto-recuperación: Probes, autoscalers.
5. Pruebas constantes: Chaos Engineering.

Cada capa que fortalezcas reducirá el riesgo de downtime. Empieza por lo crítico (etcd y plano de control) y ve subiendo en la pila. La alta disponibilidad en contenedores no es un estado, es una disciplina.

[TIP] Documenta cada cambio y establece SLIs (Service Level Indicators) y SLOs (Service Level Objectives). Sin métricas, no sabrás si realmente estás mejorando la alta disponibilidad de tu clúster.