Arquitectura del Controller Manager

En Kubernetes, el ciclo de vida de los recursos es gestionado por bucles de control que residen en el kube-controller-manager. Cuando la infraestructura se despliega en un proveedor de nube específico, se utiliza el cloud-controller-manager. Este último interactúa con las APIs nativas de la nube para administrar componentes críticos como nodos, rutas de red y balanceadores de carga.

Clasificación de Controladores de Pods

Los controladores garantizan que el estado actual del clúster coincida en todo momento con el estado deseado definido por el administrador.

• ReplicaSet: Evolución del obsoleto ReplicationController. Se encarga de mantener un número exacto de réplicas de Pods idénticos. Sus elementos fundamentales son el contador de réplicas, el selector de etiquetas y la plantilla del Pod.
• Deployment: Abstracción de alto nivel construida sobre ReplicaSet. Es el estándar para aplicaciones sin estado, ofreciendo capacidades de escalado, actualizaciones continuas y reversiones mediante configuraciones declarativas.
• DaemonSet: Garantiza la ejecución de una copia exacta de un Pod en cada nodo del clúster (o en un subconjunto de nodos seleccionados). Su cantidad de réplicas escala dinámicamente con el tamaño de la infraestructura. Es ideal para servicios del sistema como recolectores de logs o agentes de monitoreo.
• Job: Diseñado para tareas por lotes que deben ejecutarse hasta su finalización. El sistema no reinicia el Pod si la tarea concluye con éxito.
• CronJob: Extensión de Job que permite programar ejecuciones periódicas basadas en sintaxis cron.
• StatefulSet: Especializado en aplicaciones con estado. Proporciona identidades de red persistentes y almacenamiento estable. Debido a la naturaleza compleja de las aplicaciones con estado, este controlador encapsula operaciones de aprovisionamiento específicas para cada tipo de base de datos o sistema distribuido.

Administración de ReplicaSets

Un ReplicaSet asegura la alta disponibilidad de las aplicaciones. A continuación, un ejemplo de configuración básica:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend-cache
spec:
  replicas: 3
  selector:
    matchLabels:
      app: cache-service
  template:
    metadata:
      labels:
        app: cache-service
    spec:
      containers:
      - name: redis-node
        image: redis:6.2

Para realizar modificaciones en tiempo real, como alterar el dimensionamiento o actualizar la imagen (lo cual solo afectará a los nuevos Pods creados tras la modificación):

# Listar pods con sus etiquetas asociadas
$ kubectl get pods -l app=cache-service --show-labels

# Escalar dinámicamente el número de instancias
$ kubectl scale rs frontend-cache --replicas=5

# Actualizar la imagen del contenedor
$ kubectl set image rs/frontend-cache redis-node=redis:7.0

Estrategias y Operaciones en Deployments

Un Deployment orquesta múltiples ReplicaSets, manteniendo activo solo uno a la vez. Las modificaciones se aplican preferentemente mediante el comando apply para mantener un historial declarativo y predecible.

Existen dos estrategias principales de actualización:

• RollingUpdate: Estrategia por defecto. Reemplaza los Pods gradualmente. Permite disponibilidad continua del servicio, aunque temporalmente coexistirán diferentes versiones de la aplicación respondiendo peticiones.
• Recreate: Detiene todos los Pods existentes antes de iniciar los nuevos. Genera un tiempo de inactividad (downtime) durante el proceso de despliegue.

Consultando la documentación interna sobre los parámetros de actualización:

$ kubectl explain deployment.spec.strategy.type
$ kubectl explain deployment.spec.revisionHistoryLimit

Flujo de trabajo para despliegues avanzados, control de tráfico (Canary) y reversiones:

# Aplicar una nueva configuración desde un archivo YAML
$ kubectl apply -f api-server-deploy.yaml

# Revisar el historial de versiones
$ kubectl rollout history deployment/api-server-prod

# Aplicar un parche rápido para modificar la cantidad de réplicas
$ kubectl patch deployment api-server-prod -p '{"spec":{"replicas":6}}'

# Ajustar los límites de tolerancia de la estrategia RollingUpdate
$ kubectl patch deployment api-server-prod -p '{"spec":{"strategy":{"rollingUpdate":{"maxSurge":2,"maxUnavailable":1}}}}'

# Canary Deployment: Actualizar imagen y pausar el proceso para validaciones manuales
$ kubectl set image deployment/api-server-prod api-container=registry.internal/api:v2.5
$ kubectl rollout pause deployment/api-server-prod

# Tras verificar que no hay errores, reanudar el despliegue
$ kubectl rollout resume deployment/api-server-prod
$ kubectl rollout status deployment/api-server-prod

# Revertir a una versión anterior específica en caso de fallos críticos
$ kubectl rollout undo deployment/api-server-prod --to-revision=1

En situaciones donde un Pod queda bloqueado en estado Terminating debido a bloqueos a nivel de nodo o almacenamiento, se puede forzar su eliminación:

$ kubectl delete pod api-server-7d8f9b-x9k2l --force --grace-period=0

Consideraciones para DaemonSets

Al igual que los Deployments, los DaemonSets soportan actualizaciones progresivas. Para servicios que requieren acceso directo a la red del nodo subyacente, se utiliza el espacio de nombres de red del host:

$ kubectl explain pod.spec.hostNetwork

Al configurar hostNetwork: true en la especificación del Pod, el DaemonSet puede exponer puertos directamente en la interfaz de red del nodo. Esto evita la sobrecarga de red y la necesidad de crear un recurso Service adicional, un enfoque sumamente común en agentes de telemetría o sistemas de archivos distribuidos.

Extensiones y Recursos Adicionales

• CRD (Custom Resource Definitions): Permiten a los desarrolladores extender la API de Kubernetes dfeiniendo sus propios tipos de objetos nativos.
• Operadores (Operators): Patrones de diseño arquitectónico que combinan CRDs con controladores personalizados para autoamtizar tareas complejas de mantenimeinto y operación de software.
• Helm: Gestor de paquetes que facilita el empaquetado, versionado y despliegue de configuraciones complejas mediante el uso de Charts.

Comandos auxiliares fundamentales para depuración y monitoreo:

# Consultar la estructura y campos válidos de un recurso
$ kubectl explain deployments

# Monitoreo en tiempo real de los cambios de estado en los Pods
$ kubectl get pods -l app=cache-service -w