La mejor prueba de Kubernetes para contratar SRE y DevOps

Por qué fallan los tests de Kubernetes estándar

La mayoría de las evaluaciones de Kubernetes preguntan: «¿Qué es un StatefulSet?» o «explica taints y tolerations». Eso mide memoria, no si alguien sabe diseñar un cluster que sobreviva a un fallo de nodo, detectar cuándo una app oscila o depurar por qué un deployment nunca se estabiliza.

Una persona SRE o DevOps con experiencia profunda en Kubernetes sabe que las preguntas reales son sobre estabilidad operativa, coste y depuración de problemas en producción bajo presión.

Esto es lo que parece una evaluación con señal real.

Habilidades clave a evaluar

1. Diseño y resiliencia de cluster

¿Sabe diseñar un cluster que sobreviva a fallos de zona?

Pregunta:

«Tienes una carga de producción que debe estar arriba durante fallos de zona. Tienes un cluster de 3 nodos en una sola AZ. ¿Qué cambias? ¿Cuáles son los trade-offs?»

Buena respuesta:

• Distribuir nodos en al menos 3 AZ
• Usar PodDisruptionBudgets para evitar fallos en cascada
• Usar node affinity para no concentrar réplicas en una zona
• Configurar health checks para los nodos
• Entender el trade-off de coste (3× la infraestructura)

Respuesta débil:

• «Solo añade más réplicas» (no aborda el fallo de zona)
• «Usa anti-affinity» (sin entender pod topology spread constraints)

2. Configuración y depuración de cargas

¿Sabe configurar para producción y depurar cuando falla?

Pregunta:

«Has desplegado un nuevo microservicio. El deployment muestra 3 réplicas corriendo, pero solo 2 reciben tráfico. Los readiness checks pasan. ¿Por qué puede estar pasando?»

Buena respuesta considera (en orden):

• ¿Falta el endpoint del selector del servicio? (kubectl get endpoints)
• ¿La network policy está bloqueando tráfico?
• ¿La interfaz de red del pod está mal configurada?
• ¿El health check del balanceador difiere del readiness check?

Esto evalúa depuración sistemática, no datos de Kubernetes.

3. Almacenamiento y estado

¿Entiende cuándo usar StatefulSet frente a Deployment? ¿Almacenamiento local frente a persistente?

Pregunta:

«Corremos Elasticsearch en Kubernetes. ¿StatefulSet o Deployment? ¿Y el almacenamiento?»

Buena respuesta:

• StatefulSet para identidad estable y orden
• Persistent volumes para durabilidad
• Anti-affinity para distribuir entre nodos
• Estrategia de upgrade cuidadosa (rolling restarts pueden romper el quorum)

Respuesta débil:

• «Usa Deployment, es más simple»
• Sin mención de persistencia ni quorum

4. Escalado y optimización de coste

¿Sabe cuándo escalar frente a optimizar?

Pregunta:

«Tu cluster está al 85 % de CPU. Coste 10 k$/mes. Dos opciones: añadir nodos u optimizar requests. ¿Qué revisas primero?»

Buena respuesta:

• Comprueba si los pods sobre-piden recursos (requests demasiado altos)
• Comprueba ruido de vecinos (un pod consumiendo más de lo esperado)
• Comprueba si el patrón es de pico (¿reorganizar tráfico?)
• Solo entonces añadir nodos si es restricción real

Esto evalúa juicio operativo.

5. Observabilidad y depuración en producción

¿Sabe diseñar monitorización? ¿Sabe diagnosticar una app inestable?

Pregunta:

«Tu app tiene picos de error del 0,1 % que duran 30 segundos y se recuperan. Pasa una vez al día a horas aleatorias. ¿Cómo investigas?»

Buena respuesta menciona:

• Eventos de pod restart (logs de nodo y kubelet)
• Agotamiento de recursos (memoria y CPU)
• Timeouts de red (endpoints y DNS)
• Reintentos a nivel de app (¿se recupera de errores transitorios?)

Estructura de evaluación

Parte 1: ejercicio take-home de diseño (2 horas)

Escenario:

«Diseña un cluster Kubernetes de producción para una app SaaS con:

• SLA de 99,9 % de uptime
• Frontend stateless, backend con estado (DB)
• 50–500 usuarias concurrentes (carga variable)
• Presupuesto: 5.000 $/mes máximo
• Debe sobrevivir a fallo de zona
• El escalado debe ser automático»

Debe entregar:

• Arquitectura de nodos (cuántos, tipos, zonas)
• Configuración de cargas (deployments, requests, políticas de escalado)
• Estrategia de almacenamiento (PV, backups)
• Plan de monitorización y alerta
• Desglose de coste

Esto evalúa si ha construido sistemas a escala.

Parte 2: revisión de configuración (30 minutos)

Dale un manifest con problemas intencionales:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  replicas: 1  # Issue: should be 3 for HA
  selector:
    matchLabels:
      app: api-server
  template:
    metadata:
      labels:
        app: api-server
    spec:
      containers:
      - name: api
        image: api:latest  # Issue: should use semantic versioning
        resources:
          requests:
            cpu: 100m  # Issue: too low; app will be CPU throttled
            memory: 64Mi  # Issue: too low; will OOM
      # Issue: no readiness probe, no liveness probe
      # Issue: no node affinity; could run on same node
---
apiVersion: v1
kind: Service
metadata:
  name: api-server
spec:
  selector:
    app: api-server
  ports:
  - port: 80
    targetPort: 8080

Pídele que identifique todos los problemas y explique los arreglos. Una candidata fuerte detecta 8+; una débil 1–2 obvios.

Parte 3: conversación de troubleshooting (30 minutos)

Escenario:

«Has desplegado un nuevo servicio en Kubernetes. Llega tráfico, pero la latencia es 10× la normal. Prometheus muestra CPU y memoria normales. Cuéntame cómo lo depurarías».

Debe preguntar:

• ¿El endpoint del servicio está al día? (kubectl get endpoints)
• ¿Los pods reciben tráfico de forma equilibrada o uno es lento?
• ¿El problema está en la red (kube-proxy, CNI)?
• ¿La app se bloquea en algo (API externa, DB)?
• ¿El deploy incluyó código no optimizado?

Esto evalúa pensamiento sistemático.

Rúbrica de evaluación Kubernetes

Qué NO evaluar

No pidas:

• Escribir un Operator desde cero (eso es systems programming, no SRE)
• Memorizar versiones de la API (en producción usarán los docs)
• Montar un cluster desde cero en la entrevista (es una operación, no un juicio)

Pídele:

• Diseñar un cluster con restricciones realistas
• Depurar un deployment que falla
• Explicar trade-offs entre opciones
• Configurar cargas para producción

Para equipos sin Kubernetes aún

Si contratas DevOps o SRE pero aún no usas Kubernetes, evalúa containerización y orquestación sin requerir Kubernetes. Muchos equipos sobre-pesan Kubernetes cuando lo que necesitan es pensamiento de sistemas.

Para equipos que ya usan Kubernetes en producción, usa esta estructura para evaluar profundidad operativa antes de contratar. Quien pase esta evaluación será productiva el primer día.

Siguiente: entiende cómo interpretar los resultados de tu evaluación DevOps.