Lo que las entrevistas de trabajo me enseñaron sobre Kubernetes

La pregunta más frecuente en una entrevista técnica de Kubernetes es "¿qué es un Pod?". La segunda es "¿qué diferencia hay entre un Deployment y un StatefulSet?". Las dos son correctas. Las dos son casi irrelevantes para el 80% de los problemas que rompen un clúster en producción.

Eso me pareció raro durante mucho tiempo. Hasta que entendí que las entrevistas no miden lo que uno sabe usar: miden lo que uno puede definir rápido bajo presión. Y eso crea un mapa de Kubernetes muy distorsionado — lleno de objetos API que casi nunca se tocan y casi sin espacio para las decisiones operativas que sí importan.

Mi tesis es esta: el gap entre lo que se pregunta en entrevistas y lo que se usa en producción es una señal técnica valiosa. No sobre Kubernetes en sí, sino sobre qué partes del sistema vale la pena dominar primero y cuáles podés postergar sin drama.

El problema real que señalan las entrevistas sobre Kubernetes

Kubernetes tiene más de 50 tipos de objetos en la API. Una entrevista promedio cubre entre 8 y 12. El problema no es la cobertura — es la selección.

Los objetos más preguntados tienden a ser los más fáciles de definir con una oración:

• Pod: unidad mínima ejecutable
• Service: abstracción de red sobre Pods
• ConfigMap / Secret: configuración externa
• Ingress: routing HTTP

Lo que casi nunca aparece en entrevistas pero sí aparece en postmortems reales:

• PodDisruptionBudget: cuántos Pods pueden caer simultáneamente durante un rolling update
• ResourceQuota / LimitRange: qué pasa cuando un namespace consume más memoria de la esperada
• HorizontalPodAutoscaler con métricas custom (no CPU): cómo escalar por cola de mensajes o latencia P95
• Affinity y Tolerations: por qué tu workload de machine learning termina corriendo en el nodo más pequeño si no configurás nodeSelector

La distancia entre esas dos listas es el mapa que me faltaba cuando empecé a mirar Kubernetes en serio.

Lo que sí conviene dominar primero (y qué mirar antes de cualquier otra cosa)

Partamos de algo concreto. Antes de tocar un clúster productivo — o de preparar una entrevista seria — hay un subconjunto de conceptos que tienen el mayor ratio impacto/complejidad:

Checklist de prioridad real

# Verificar que un Deployment aplicó correctamente
kubectl rollout status deployment/mi-api

# Ver eventos recientes en un namespace (primer lugar donde buscar si algo falla)
kubectl get events -n produccion --sort-by='.lastTimestamp'

# Ver límites y requests configurados en los pods de un deployment
kubectl get pods -n produccion -o jsonpath='{.items[*].spec.containers[*].resources}'

# Revisar si un HPA está activo y qué métricas usa
kubectl get hpa -n produccion

# Validar que no hay pods en estado CrashLoopBackOff o Pending
kubectl get pods -n produccion --field-selector=status.phase!=Running

Estos cinco comandos cubren el 70% de los diagnósticos iniciales que cualquier equipo hace el primer día que algo falla. No son los más sofisticados. Son los más útiles.

Qué entender antes de configurar cualquier cosa

Antes de tocar kubectl apply, vale la pena tener claro:

1. Requests vs Limits: requests es lo que el scheduler usa para decidir en qué nodo vive el Pod. limits es el techo de uso. Si no configurás requests, el scheduler trabaja a ciegas. Si configurás limits demasiado ajustados, el OOMKiller va a matar el proceso sin aviso.

2. liveness vs readiness probes: livenessProbe mata y reinicia el container si falla. readinessProbe lo saca del Service sin matarlo. Confundirlas es el error más silencioso que existe — el Pod se reinicia en loop o el tráfico llega a un container que no está listo.

3. Rolling update vs Recreate: la estrategia por defecto es RollingUpdate, pero si tu app no tolera dos versiones corriendo en paralelo (base de datos con migraciones sin retrocompatibilidad, por ejemplo), necesitás Recreate o una estrategia de deploy más explícita.

# estrategia de deploy que evita dos versiones simultáneas
# útil cuando las migraciones de BD no son retrocompatibles
spec:
  strategy:
    type: Recreate

Dónde se equivoca la gente (y cuál es el costo oculto)

El error más común que veo en conversaciones técnicas sobre Kubernetes es tratarlo como Docker Compose con más YAML. No es eso.

Docker Compose resuelve "cómo correr este conjunto de containers en esta máquina". Kubernetes resuelve "cómo distribuir workloads en un clúster de nodos, con scheduling, self-healing y control de recursos". Son problemas distintos con herramientas distintas.

El costo oculto de usar Kubernetes cuando Docker Compose alcanza:

• Overhead operativo real: un clúster mínimo funcional (control plane + 2 nodos worker) tiene costos fijos que no desaparecen cuando no hay tráfico.
• Curva de debugging más larga: cuando algo falla en Docker Compose, docker logs container es suficiente el 90% del tiempo. En Kubernetes, el log del container es solo el primer nivel — después vienen eventos del Pod, logs del scheduler, estado del nodo.
• Abstracciones que esconden el problema: Kubernetes puede reiniciar un container que falla en loop sin que nadie se entere si no hay alertas configuradas. El sistema "funciona" — solo que el Pod lleva 300 reinicios.

Para un stack como el de este blog — Next.js, PostgreSQL y servicios stateless en Railway — Kubernetes sería sobredimensionado. Railway ya maneja scheduling, restart policies y networking. Agregar un clúster K8s encima es agregar complejidad sin ganancia operativa visible.

La pregunta no es "¿Kubernetes es bueno?". Es "¿qué problema específico resuelve en este contexto?".

Matriz de decisión: cuándo tiene sentido y cuándo no

Antes de adoptar Kubernetes — o antes de responder preguntas de entrevista como si todo fuera K8s — conviene pasar por este árbol:

Si la mayoría de los checks cae en la columna derecha, la respuesta correcta para tu sistema probablemente no es Kubernetes. Y eso está bien.

Sobre el tema de cuándo una herramienta es la respuesta correcta aunque parezca excesiva, escribí algo parecido en el análisis de métodos formales y el futuro de la programación — el patrón de "esto parece demasiado para mi caso" aparece más seguido de lo que uno esperaría.

Los límites de lo que se puede concluir sin logs ni datos productivos

Acá quiero ser explícito: todo lo que escribí hasta acá es análisis de patrones, no medición productiva propia. Hay cosas que no se pueden concluir sin datos reales:

• Cuánto mejora el rendimiento con K8s vs Docker Compose en un caso específico: depende del número de nodos, del tipo de workload y del overhead del networking overlay. Sin un experimento reproducible, cualquier número es folklore.
• Si HPA con métricas custom funciona bien para tu caso de uso: la configuración del Metrics Server y el lag entre la métrica y el scale-out varía por implementación. Hay que medirlo.
• Cuánto cuesta operar el clúster en horas-persona: es altamente dependiente del equipo, del cloud provider y de qué tan estable es el workload. Los rangos que circulan en blogs ("2 horas por semana") son promedios de contextos muy distintos.

Lo que sí se puede afirmar con evidencia pública: la documentación oficial de Kubernetes es la fuente más actualizada para entender el ciclo de vida de los objetos. Las guías de certificación CKA/CKAD del CNCF son el mapa más honesto de lo que se considera conocimiento operativo base.

FAQ: lo que la gente pregunta sobre Kubernetes y entrevistas técnicas

¿Es necesario saber Kubernetes para conseguir trabajo como backend developer?

Depende del rol. Para roles de backend puro en equipos con DevOps dedicado, muchas veces no. Para roles full-stack o de ingeniería de plataforma, es cada vez más esperado. El indicador más útil es leer las ofertas de trabajo del segmento que te interesa: si K8s aparece en más del 40% de las job descriptions relevantes para vos, vale la pena invertir tiempo.

¿Qué diferencia hace saber kubectl de saber Kubernetes?

kubectl es la herramienta de línea de comando. Kubernetes es el sistema. Saber kubectl sin entender el modelo de objetos (qué es un controller loop, qué hace el scheduler, cómo funciona el networking entre Pods) es como saber escribir SQL sin entender qué hace el query planner. Funciona hasta que algo falla.

¿Cuándo tiene sentido usar Kubernetes para un proyecto personal o startup early-stage?

Casi nunca en early-stage. El overhead operativo de mantener un clúster es real y constante. Para proyectos personales o startups con menos de 5 servicios, Railway, Fly.io o Render dan el 90% de los beneficios con el 10% de la complejidad. El momento de migrar a K8s es cuando el costo de no tenerlo (scaling manual, multi-tenancy, workloads especializados) supera el costo de operarlo.

¿Las certificaciones CKA/CKAD realmente enseñan lo que se usa en producción?

Más que la mayoría de las entrevistas, sí. El examen CKA es hands-on: tenés que resolver problemas reales en un clúster real en tiempo limitado. No es perfecto — hay escenarios de producción que no cubre — pero el formato es más honesto que un cuestionario de definiciones. La CKAD está más orientada a developers y cubre exactamente el subconjunto que mencioné arriba: deployments, probes, resources, ConfigMaps.

¿Qué conviene aprender primero si empezás desde cero con K8s?

En este orden: (1) entender el modelo de objetos básico — Pod, Deployment, Service, ConfigMap; (2) practicar con minikube o kind localmente; (3) leer un postmortem real de Kubernetes (el blog de Engineering de Monzo tiene varios públicos); (4) configurar liveness/readiness probes y resources en un servicio propio; (5) recién ahí mirar Ingress, HPA y PersistentVolumes. Saltear el paso 4 es el error más común.

¿Tiene sentido aprender Kubernetes si trabajo con Railway o plataformas PaaS similares?

Sí, pero con expectativas claras. Entender K8s te da el modelo mental para entender qué hace Railway por detrás. No vas a operar el clúster directamente, pero vas a entender por qué railway up reinicia el container, cómo funciona el health check o por qué un crash loop te lleva a un downtime de 30 segundos y no de 5. Es conocimiento de capa de abstracción: te ayuda a debuggear lo que la plataforma esconde.

Cierre: qué me llevo de todo esto y qué recomiendo hacer

Las entrevistas de Kubernetes son un radar ruidoso. Miden definiciones, no decisiones. Pero ese ruido es útil: te dice exactamente qué parte del sistema la industria considera "conocimiento básico esperado" versus lo que realmente se aprende operando.

Mi postura: si querés entender Kubernetes de verdad, no estudies para la entrevista — estudiá los errores. Los postmortems públicos de Google, Monzo, Cloudflare o Shopify muestran qué falla realmente y por qué. Eso te da un mapa operativo que ningún cuestionario de definiciones puede darte.

Lo que no compro: la idea de que Kubernetes es la respuesta default para cualquier sistema que "necesita escalar". El escalado tiene muchas formas. Un índice bien diseñado en PostgreSQL, una query que deja de hacer N+1 o un caché en el lugar correcto pueden resolver el problema sin agregar 300 líneas de YAML — algo que también aparece cuando hablo de decisiones técnicas verificables o de tokens de autenticación con criterio.

El próximo paso concreto si te interesa el tema: agarrá un postmortem real de Kubernetes (el de Cloudflare sobre un outage de 2019 o los de Monzo Engineering son públicos y detallados), leelo con el checklist de arriba en mano y fijate cuáles de esos comandos habrían acortado el tiempo de diagnóstico. Eso vale más que memorizar qué es un DaemonSet.