Kubernetes: Pods, Services y Deployments para Entrevistas Técnicas

Conseguir una posición DevOps o de ingeniería de plataformas en el mercado latinoamericano actual requiere demostrar conocimientos sólidos en Kubernetes. Las empresas tecnológicas de la región, desde startups fintech hasta grandes corporativos, evalúan candidatos con preguntas prácticas sobre la orquestación de contenedores. Este artículo cubre los conceptos fundamentales que todo profesional debe dominar: Pods, Services y Deployments, junto con ejemplos de código listos para producción.

Pods: La Unidad Fundamental de Kubernetes

Un Pod representa la unidad de ejecución más pequeña en Kubernetes. Contrario a lo que muchos candidatos responden en entrevistas, un Pod no es simplemente "un contenedor". Un Pod es una abstracción que encapsula uno o más contenedores que comparten el mismo namespace de red, almacenamiento y ciclo de vida.

En la práctica de producción, la mayoría de los Pods ejecutan un solo contenedor. Sin embargo, existen patrones válidos como el sidecar (contenedor auxiliar para logging o proxies) donde múltiples contenedores coexisten en el mismo Pod.

El siguiente manifiesto YAML ilustra un Pod configurado correctamente para un ambiente de producción, incluyendo solicitudes de recursos, límites y health checks:

# api-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: api-server
  labels:
    app: api
    version: v2
spec:
  containers:
    - name: api
      image: registry.example.com/api:3.1.0
      ports:
        - containerPort: 8080
      resources:
        requests:
          cpu: "250m"        # 0.25 CPU core reserved
          memory: "256Mi"    # 256 MB reserved
        limits:
          cpu: "500m"        # hard cap at 0.5 core
          memory: "512Mi"    # OOMKilled beyond this
      readinessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 5
        periodSeconds: 10
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 15
        periodSeconds: 20

Los labels son particularmente importantes. Funcionan como metadata clave-valor que permite a otros recursos de Kubernetes identificar y seleccionar Pods específicos. En el ejemplo, app: api será utilizado por Services y Deployments para enrutar tráfico y gestionar réplicas.

Fases del Ciclo de Vida y Políticas de Reinicio

Comprender el ciclo de vida de un Pod es esencial para diagnosticar problemas en producción y responder preguntas de entrevista. Un Pod atraviesa varias fases desde su creación hasta su terminación:

| Fase | Descripción | Siguiente acción típica | |------|-------------|-------------------------| | Pending | El Pod fue aceptado pero los contenedores no se ejecutan | Verificar scheduling, imágenes, recursos | | Running | Al menos un contenedor está ejecutándose | Monitorear health checks | | Succeeded | Todos los contenedores terminaron exitosamente | Cleanup automático según config | | Failed | Al menos un contenedor terminó con error | Revisar logs, restartPolicy | | Unknown | No se puede determinar el estado del Pod | Verificar conectividad del nodo |

La política de reinicio (restartPolicy) determina cómo Kubernetes maneja contenedores que terminan. Las opciones disponibles son:

• Always (default): Reinicia el contenedor sin importar el código de salida
• OnFailure: Reinicia solo si el contenedor termina con código diferente a cero
• Never: No reinicia el contenedor bajo ninguna circunstancia

Para trabajos batch o migraciones de datos, la configuración OnFailure es la más apropiada:

# batch-job-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: data-migration
spec:
  restartPolicy: OnFailure   # restart only on crash
  containers:
    - name: migrate
      image: registry.example.com/migrate:1.0.0
      command: ["python", "migrate.py"]
      env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: connection-string

Este ejemplo también demuestra el uso de Secrets para manejar credenciales sensibles, otro tema frecuente en entrevistas de Kubernetes.

Deployments: Gestión Declarativa de Aplicaciones

Mientras los Pods representan instancias individuales, los Deployments proporcionan la capa de abstracción necesaria para aplicaciones de producción. Un Deployment gestiona un conjunto de Pods idénticos (ReplicaSet) y garantiza que el número deseado de réplicas esté siempre disponible.

Las características principales que hacen a los Deployments indispensables incluyen:

• Escalamiento horizontal: Ajustar el número de réplicas según demanda
• Actualizaciones rolling: Desplegar nuevas versiones sin downtime
• Rollback automático: Revertir a versiones anteriores cuando se detectan problemas
• Self-healing: Recrear Pods fallidos automáticamente

El siguiente manifiesto configura un Deployment con estrategia rolling update:

# api-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
  labels:
    app: api
spec:
  replicas: 3                    # run 3 identical Pods
  revisionHistoryLimit: 5        # keep 5 old ReplicaSets for rollback
  selector:
    matchLabels:
      app: api                   # must match Pod template labels
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1          # at most 1 Pod down during update
      maxSurge: 1                # at most 1 extra Pod during update
  template:
    metadata:
      labels:
        app: api
        version: v2
    spec:
      containers:
        - name: api
          image: registry.example.com/api:3.1.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10

La configuración maxUnavailable: 1 y maxSurge: 1 significa que durante una actualización, Kubernetes mantendrá al menos 2 de 3 Pods disponibles mientras crea temporalmente hasta 4 Pods en total.

Rollback de Deployments

Una de las preguntas favoritas de los entrevistadores es cómo revertir un deployment problemático. Kubernetes mantiene un historial de revisiones que permite volver a estados anteriores:

# Check rollout status
kubectl rollout status deployment/api-server

# View revision history
kubectl rollout history deployment/api-server

# Roll back to previous version
kubectl rollout undo deployment/api-server

# Roll back to specific revision
kubectl rollout undo deployment/api-server --to-revision=3

El campo revisionHistoryLimit: 5 en el manifiesto determina cuántas revisiones anteriores conserva Kubernetes para rollback.

Services: Abstracción de Red y Descubrimiento

Los Pods son efímeros por naturaleza: sus direcciones IP cambian cada vez que se recrean. Los Services resuelven este problema proporcionando una dirección IP virtual estable y un nombre DNS que persiste independientemente del ciclo de vida de los Pods individuales.

Un Service utiliza selectores de labels para identificar qué Pods deben recibir tráfico. Esta abstracción permite escalar Pods horizontalmente sin modificar la configuración de los clientes:

# api-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  type: ClusterIP               # internal-only by default
  selector:
    app: api                     # routes to Pods with this label
  ports:
    - name: http
      port: 80                   # Service port (what clients use)
      targetPort: 8080           # Pod port (where container listens)
      protocol: TCP

Dentro del cluster, otros Pods pueden acceder a este Service usando el nombre DNS api-service o api-service.<namespace>.svc.cluster.local. Esta es la forma recomendada de comunicación entre microservicios en Kubernetes.

Tipos de Service y Casos de Uso

Kubernetes ofrece diferentes tipos de Service según los requisitos de exposición:

| Tipo | Alcance | Caso de uso | |------|---------|-------------| | ClusterIP | Solo interno | Comunicación entre microservicios | | NodePort | Nodo externo (puerto 30000-32767) | Desarrollo, testing | | LoadBalancer | Balanceador cloud externo | Producción con tráfico público | | ExternalName | Alias DNS a servicio externo | Integración con servicios legacy |

Para exponer una aplicación a internet en un ambiente cloud, LoadBalancer es la opción estándar:

# api-loadbalancer.yaml
apiVersion: v1
kind: Service
metadata:
  name: api-public
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"  # AWS NLB
spec:
  type: LoadBalancer
  selector:
    app: api
  ports:
    - name: https
      port: 443
      targetPort: 8080
      protocol: TCP

Las anotaciones específicas del proveedor cloud permiten configurar características avanzadas del balanceador de carga.

Conexión entre Deployments y Services

La verdadera potencia de Kubernetes emerge cuando Deployments y Services trabajan en conjunto. El Service actúa como balanceador de carga interno, distribuyendo automáticamente el tráfico entre todos los Pods que coinciden con su selector.

Este patrón permite implementar estrategias de despliegue avanzadas como canary releases. Al crear un segundo Deployment con el mismo label app: api, el Service automáticamente incluye los nuevos Pods en la rotación de tráfico:

# canary-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: api                   # same label as main Deployment
  template:
    metadata:
      labels:
        app: api                 # Service picks this up automatically
        version: v3-canary
    spec:
      containers:
        - name: api
          image: registry.example.com/api:3.2.0-rc1
          ports:
            - containerPort: 8080

Con 3 Pods del Deployment principal y 1 Pod canary, aproximadamente el 25% del tráfico llegará a la nueva versión. Esta proporción se ajusta modificando el número de réplicas de cada Deployment.

Horizontal Pod Autoscaler (HPA)

El autoescalamiento es un tema recurrente en entrevistas porque demuestra comprensión de operaciones a escala. El Horizontal Pod Autoscaler ajusta automáticamente el número de réplicas basándose en métricas observadas:

# api-hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70   # scale up above 70% CPU
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300  # wait 5 min before scaling down

El campo stabilizationWindowSeconds evita fluctuaciones rápidas (flapping) al requerir que las métricas permanezcan bajas durante 5 minutos antes de reducir réplicas.

Para que el HPA funcione correctamente, los Pods deben declarar requests de recursos. Sin requests definidos, Kubernetes no puede calcular el porcentaje de utilización.

Preguntas Frecuentes en Entrevistas de Kubernetes

Las siguientes preguntas aparecen consistentemente en entrevistas técnicas para posiciones DevOps y SRE en empresas latinoamericanas:

¿Cuál es la diferencia entre un Pod y un contenedor? Un Pod es una abstracción de Kubernetes que puede contener uno o más contenedores. Los contenedores dentro del mismo Pod comparten namespace de red (misma IP), almacenamiento y ciclo de vida.

¿Por qué no se deben crear Pods directamente en producción? Los Pods creados directamente no tienen controller que los gestione. Si el Pod falla o el nodo donde corre se cae, el Pod no se recrea automáticamente. Los Deployments resuelven esto manteniendo el estado deseado.

¿Qué sucede durante un rolling update? Kubernetes crea Pods nuevos con la nueva configuración mientras termina gradualmente los Pods antiguos. Los parámetros maxUnavailable y maxSurge controlan la velocidad y capacidad durante la transición.

¿Cómo un Service descubre los Pods disponibles? El Service utiliza selectores de labels para identificar Pods elegibles. Kubernetes mantiene un objeto Endpoints (o EndpointSlice) que lista las IPs de todos los Pods saludables que coinciden con el selector.

¿Cuál es la diferencia entre readinessProbe y livenessProbe? ReadinessProbe determina si el Pod puede recibir tráfico (se remueve del Service si falla). LivenessProbe determina si el contenedor está vivo (se reinicia si falla). Un Pod puede estar vivo pero no listo para recibir tráfico.

¿Cómo se implementa un despliegue blue-green en Kubernetes? Se crean dos Deployments completos (blue y green) y se cambia el selector del Service para apuntar a uno u otro. Esto permite switchover instantáneo y rollback inmediato.

Para practicar estas y otras preguntas de Kubernetes, se recomienda utilizar recursos especializados como las preguntas de entrevista DevOps disponibles en SharpSkill.

Conclusión

Dominar Kubernetes para entrevistas técnicas requiere comprender tanto los conceptos teóricos como su aplicación práctica. Los puntos clave cubiertos en este artículo incluyen:

• Pods son la unidad mínima de ejecución, pero no deben crearse directamente en producción
• Labels y selectores son el mecanismo fundamental de conexión entre recursos
• Deployments gestionan el ciclo de vida de aplicaciones con rolling updates y rollback
• Services proporcionan descubrimiento y balanceo de carga interno
• HPA permite autoescalamiento basado en métricas de utilización
• Los health checks (readiness y liveness) son esenciales para aplicaciones robustas

La clave para destacar en entrevistas de Kubernetes no es memorizar comandos, sino comprender cómo estos recursos interactúan para mantener aplicaciones disponibles y escalables. Practicar con manifiestos YAML reales y explicar el razonamiento detrás de cada configuración demuestra la profundidad de conocimiento que los entrevistadores buscan.