Kubernetes dejó de ser una tecnología emergente: el 82% de quienes usan contenedores ya lo corren en producción. Eso lo convierte en conocimiento base, no en diferencial. Esta guía explica qué es en términos concretos, qué problema resuelve, cuáles son los seis objetos que hay que entender para trabajar con él, y una ruta de aprendizaje realista según si venís de desarrollo o de infraestructura.

La confusión más frecuente es tratarlo como si fuera una alternativa a Docker. No lo es. Docker construye y corre contenedores; Kubernetes decide en qué máquina corre cada contenedor, cuántas copias tiene que haber, qué hacer cuando uno se cae y cómo enrutar el tráfico hacia ellos. Uno es la caja, el otro es el sistema que administra miles de cajas.

Qué es Kubernetes

Kubernetes es un orquestador de contenedores: un sistema que gestiona automáticamente el ciclo de vida de aplicaciones empaquetadas en contenedores a través de un conjunto de máquinas.

La idea central es el estado declarativo. En lugar de decirle al sistema qué pasos ejecutar, le describís el resultado que querés: "quiero tres copias de esta aplicación, con este límite de memoria, accesibles en este puerto". Kubernetes compara continuamente ese estado deseado con el estado real y actúa para cerrar la diferencia. Si un contenedor se muere, lo reemplaza. Si una máquina se cae, redistribuye la carga. Nadie tiene que despertarse a las 3 de la mañana para reiniciar un servicio.

Nació en Google, se donó a la Cloud Native Computing Foundation en 2015 y hoy es el proyecto de infraestructura de código abierto con mayor adopción empresarial del mundo.

Para qué sirve: el problema real que resuelve

Imaginá una aplicación con seis servicios que atiende tráfico variable. Sin orquestador, alguien tiene que decidir manualmente en qué servidor corre cada servicio, monitorearlos, reiniciar los que fallan, agregar capacidad cuando sube el tráfico y quitarla cuando baja. Y hacer todo eso sin cortar el servicio durante un despliegue.

Kubernetes automatiza exactamente eso:

• Autorecuperación. Si un contenedor deja de responder al health check, lo termina y lanza uno nuevo.

• Escalado. Horizontal automático según CPU, memoria o métricas propias.

• Despliegues sin caída. Rolling updates que reemplazan versiones de a poco, con rollback en un comando si algo sale mal.

• Descubrimiento de servicios. Los servicios se encuentran por nombre, sin IPs hardcodeadas.

• Distribución inteligente. Coloca cada contenedor en la máquina con recursos disponibles, respetando reglas de afinidad.

• Gestión de configuración y secretos. Separados del código de la aplicación.

Los seis objetos que hay que entender

Kubernetes tiene decenas de tipos de objetos, pero con seis alcanza para trabajar de forma productiva.

Si entendés bien Deployment y Service, y sabés cómo se conectan a través de labels y selectors, tenés el 70% de lo que se usa en el día a día.

El concepto que más cuesta: labels y selectors

Kubernetes no conecta objetos por referencia directa sino por etiquetas. Un Service dice "enviá tráfico a cualquier Pod que tenga la etiqueta app: api" y un Deployment crea Pods con esa etiqueta. Si las etiquetas no coinciden, el Service existe, no da error, y no llega tráfico a ningún lado. Es la causa número uno de horas perdidas entre quienes recién empiezan.

Cómo aprenderlo si sos developer

Como developer, tu objetivo no es administrar clusters: es poder desplegar y debuggear tu propia aplicación sin depender de otro equipo. Eso acorta muchísimo el camino.

• Semana 1 y 2 — Docker sólido. Escribir Dockerfiles eficientes, entender capas, multi-stage builds, variables de entorno, docker-compose. Si esto no está firme, Kubernetes va a ser memorización.

• Semana 3 — Cluster local. Levantá minikube o kind. Desplegá una aplicación tuya: Deployment, Service, Ingress.

• Semana 4 — Debugging. kubectl logs, kubectl describe, kubectl exec, kubectl port-forward. Esto es lo que vas a usar realmente en el trabajo cuando algo falle.

• Semana 5 y 6 — Configuración y salud. ConfigMaps, Secrets, liveness y readiness probes, requests y limits de recursos.

• Semana 7 y 8 — Deploy real. Un cluster gestionado en la nube y un pipeline de CI/CD que despliegue automáticamente.

Con dos meses de trabajo sostenido llegás a un nivel funcional. La base de contenedores está desarrollada en Docker y Kubernetes: qué son, para qué sirven y cómo aprenderlos si sos desarrollador junior.

Cómo aprenderlo si vas hacia DevOps o SRE

Acá el alcance es otro: tenés que poder operar el cluster, no solo usarlo.

• Arquitectura interna. Control plane, API server, etcd, scheduler, controller manager, kubelet. Entender el flujo completo de qué pasa cuando aplicás un manifiesto.

• Redes. El modelo de red de Kubernetes, CNI, cómo funciona kube-proxy, políticas de red para aislar tráfico.

• Almacenamiento. PersistentVolumes, StorageClasses, StatefulSets para aplicaciones con estado.

• Seguridad. RBAC, ServiceAccounts, security contexts, admission controllers.

• Empaquetado y GitOps. Helm para templating, y Argo CD o Flux para desplegar desde Git como fuente de verdad.

• Observabilidad. Prometheus para métricas del cluster, alertas que importen, dashboards de Grafana.

La ruta completa del rol, con las etapas anteriores y posteriores a Kubernetes, está en la ruta de aprendizaje para DevOps Engineer. Y para el examen de referencia, el CKA es completamente práctico: se aprueba usando el cluster, no respondiendo teoría.

Los cinco errores más comunes al empezar

• Saltar Docker. El más caro. Kubernetes gestiona contenedores; sin entender contenedores estás aprendiendo abstracciones sin base.

• Empezar por un cluster en la nube. Cuesta dinero y agrega variables. Aprendé local con minikube o kind, después mové a la nube.

• Ignorar requests y limits. Sin límites de recursos, un Pod puede consumir el nodo entero y tirar abajo todo lo demás.

• Aplicar manifiestos sin versionarlos. Todo manifiesto va a Git. Si tu cluster tiene configuración que no está en un repositorio, no es reproducible.

• Meter Kubernetes donde no hace falta. Para una aplicación monolítica con tráfico estable, un servicio gestionado simple es más barato y más fácil de operar. Kubernetes tiene un costo de complejidad real.

¿Vale la pena aprenderlo en este momento?

Los números dicen que sí, con un matiz. La encuesta anual de la CNCF de 2025 ubicó el uso en producción en 82% entre quienes usan contenedores, con 77% de las empresas del Fortune 100 y un 66% de las organizaciones que adoptan IA usándolo para escalar cargas de inferencia. Ese último dato es el más relevante: Kubernetes se está convirtiendo en la capa donde corren las aplicaciones de IA, lo que extiende su vigencia bastante más allá del ciclo de las herramientas de moda.

El matiz: al estar tan adoptado, saber Kubernetes ya no te distingue. Lo que distingue es saberlo bien —diagnosticar por qué un Pod queda en CrashLoopBackOff, entender por qué el scheduler no lo asigna, ajustar recursos con criterio. Y eso, del lado de Docker, se apoya en una base que la encuesta de Stack Overflow 2025 mostró en 71% de uso, con el mayor salto interanual de todas las tecnologías relevadas.

Cursos recomendados de Coderhouse

Tres opciones que cubren distintos niveles del camino:

• Curso de DevOps & Cloud — el más directo. Trabaja contenedores, orquestación, infraestructura como código y CI/CD en un mismo recorrido, que es como se usa Kubernetes en la práctica: nunca solo.

• Curso de Cloud Computing con AWS — nivel intermedio, para entender la capa sobre la que corre el cluster: redes virtuales, IAM, storage y servicios gestionados de Kubernetes.

• Carrera de Desarrollo Backend — si sos developer y querés que Kubernetes sea la última capa de un stack que entendés completo, desde la aplicación hasta el despliegue.

Como complemento, el Curso de Python es útil para escribir las herramientas y scripts de automatización que rodean cualquier operación de cluster.

Preguntas frecuentes

¿Necesito saber Docker antes de aprender Kubernetes?

Sí, y con solidez. Kubernetes no reemplaza a Docker: lo orquesta. Si no entendés qué es una imagen, cómo funcionan las capas, cómo se pasan variables de entorno y cómo se persisten datos en un volumen, cada concepto de Kubernetes va a parecer arbitrario. Dos semanas de Docker bien invertidas ahorran meses de confusión.

¿Cuánto tiempo lleva aprender Kubernetes a nivel laboral?

Para un nivel funcional de developer —desplegar y debuggear tus propias aplicaciones—, entre 6 y 8 semanas con dedicación sostenida. Para un nivel de operación tipo DevOps o SRE, entre 4 y 6 meses, porque se suman redes, almacenamiento con estado, seguridad y observabilidad del cluster.

¿Sirve para proyectos chicos o es solo para empresas grandes?

Para proyectos chicos casi nunca vale la pena. Kubernetes tiene un costo de complejidad operativa que solo se amortiza cuando tenés varios servicios, múltiples entornos, necesidad de escalar automáticamente o un equipo que despliega seguido. Para una aplicación con tráfico estable, un servicio gestionado de contenedores es más simple y más barato. Aprenderlo, en cambio, sí vale la pena siempre: es el lenguaje común de la infraestructura moderna.

¿Qué diferencia hay entre Kubernetes y un servicio gestionado como EKS o GKE?

Es el mismo Kubernetes; la diferencia es quién administra el control plane. En un cluster autogestionado, vos mantenés el API server, etcd y los componentes de control, incluidas actualizaciones y respaldos. En un servicio gestionado, el proveedor se ocupa de eso y vos administrás solo los nodos y tus cargas de trabajo. Para aprender conviene local; para producción, casi siempre gestionado.

¿La IA va a hacer innecesario aprender Kubernetes?

Está ocurriendo lo contrario: Kubernetes se volvió la plataforma donde se ejecutan las cargas de IA, con dos tercios de las organizaciones que adoptan IA usándolo para escalar inferencia. Lo que sí está cambiando es la parte mecánica: generar manifiestos, escribir charts de Helm o interpretar logs se acelera mucho con asistentes. Eso libera tiempo para lo que no se automatiza, que es el diseño y el diagnóstico.