Kubernetes es un orquestador de contenedores: un sistema que decide dónde y cómo correr tus aplicaciones, las reinicia cuando fallan y las escala cuando aumenta el tráfico. Es la pieza central del DevOps moderno y, para muchos developers, la puerta de entrada a roles de infraestructura mejor pagos.

Esta guía explica qué problema resuelve realmente, los cuatro conceptos que necesitás para no perderte (pods, deployments, services e ingress) y un camino de aprendizaje que no requiere una tarjeta de crédito ni un cluster de producción.

El problema que Kubernetes vino a resolver

Imaginá una aplicación con tres servicios: una API, un frontend y un procesador de tareas en segundo plano. Sin orquestación, alguien tiene que responder estas preguntas todos los días:

• ¿En qué servidor corre cada servicio?

• ¿Qué pasa si un servidor se cae a las 3 de la mañana?

• ¿Cómo despliego una versión nueva sin cortar el servicio?

• ¿Cómo agrego capacidad cuando el tráfico se triplica un lunes?

• ¿Cómo se encuentran los servicios entre sí si las direcciones cambian?

Kubernetes responde todas esas preguntas de forma automática. Vos declarás el estado deseado ("quiero tres copias de esta API funcionando") y el sistema se encarga de que ese estado se cumpla, incluso cuando algo falla.

La documentación oficial de Kubernetes lo define justamente así: una plataforma portable y extensible para gestionar cargas de trabajo en contenedores de forma declarativa.

Ese es el cambio mental más importante: pasás de dar órdenes paso a paso a declarar un resultado. Se llama modelo declarativo, y es lo que hace que Kubernetes parezca raro al principio.

Antes de Kubernetes: contenedores

No se puede entender Kubernetes sin entender contenedores. Un contenedor empaqueta tu aplicación junto con todo lo que necesita para correr: dependencias, librerías, configuración. El resultado es una unidad que funciona igual en tu notebook y en un servidor.

Docker popularizó esta idea. El problema apareció después: cuando tenés cincuenta contenedores en diez servidores, gestionarlos a mano es imposible. Ahí entra el orquestador.

Según el reporte State of Cloud Native Development de la CNCF, ya hay más de 15 millones de developers con habilidades cloud native en el mundo, de los cuales alrededor de 9 millones se concentran en servicios de backend. Es un ecosistema enorme y con demanda sostenida.

Los cuatro conceptos que tenés que dominar

1. Pod: la unidad mínima

Un pod es la unidad más pequeña que Kubernetes puede desplegar. Contiene uno o (más raramente) varios contenedores que comparten red y almacenamiento.

Lo importante: los pods son descartables. Nacen, mueren y son reemplazados constantemente. Nunca dependas de que un pod específico siga existiendo, ni guardes datos importantes dentro de uno.

2. Deployment: quién mantiene el orden

Un deployment declara cuántas réplicas de un pod querés y con qué imagen. Si uno muere, el deployment crea otro. Si querés actualizar a una versión nueva, el deployment reemplaza los pods de a poco, sin cortar el servicio.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mi-api
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: api
        image: mi-api:v2

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mi-api
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: api
        image: mi-api:v2

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mi-api
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: api
        image: mi-api:v2

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mi-api
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: api
        image: mi-api:v2

Eso es todo lo que necesitás escribir para tener tres copias de tu API corriendo con recuperación automática ante fallos. Cambiar v2 por v3 y aplicar el archivo dispara un despliegue progresivo.

3. Service: la dirección estable

Como los pods aparecen y desaparecen, sus direcciones IP cambian. Un service es un nombre fijo que apunta al conjunto de pods que estén vivos en ese momento, y reparte el tráfico entre ellos.

Sin services, tus servicios internos no podrían encontrarse. Con services, tu frontend le habla a mi-api y no le importa cuántos pods hay detrás ni dónde están.

4. Ingress: la puerta de entrada

El ingress define cómo entra el tráfico desde internet: qué dominio va a qué service, cómo se maneja HTTPS, qué rutas existen. Es el equivalente a la configuración de un servidor web, pero declarativo.

Cómo aprender sin gastar dinero

1. Instalá un cluster local. Minikube, kind o k3s corren en tu máquina. Suficiente para todo lo que necesitás aprender al principio.

2. Empezá con contenedores, no con Kubernetes. Si no entendés Docker, Kubernetes va a ser incomprensible. Dedicale dos semanas antes.

3. Desplegá algo tuyo. Una API simple con base de datos. Aprender con una aplicación propia rinde diez veces más que seguir un tutorial genérico.

4. Rompé cosas a propósito. Borrá un pod y mirá cómo se recrea. Escalá a cero. Cambiá una imagen por una que no existe. Entender los errores es la mitad del trabajo.

5. Sumá YAML y Git. Todo en Kubernetes es configuración versionada. Si no manejás YAML, vas a sufrir por razones equivocadas.

Errores típicos de quien empieza

• Intentar aprender Kubernetes sin saber redes básicas ni contenedores.

• Guardar estado dentro de pods y sorprenderse cuando se pierde.

• Copiar archivos YAML sin entender cada campo.

• Saltar directo a Helm, service mesh y operadores antes de dominar lo básico.

Kubernetes en tu carrera

Kubernetes rara vez es un rol en sí mismo: es un componente de roles como DevOps Engineer, SRE, Platform Engineer o Cloud Engineer. Todos ellos comparten un piso salarial más alto que el desarrollo de aplicaciones tradicional, y una barrera de entrada más alta también.

Para llegar ahí, Kubernetes se combina con otras piezas: un proveedor cloud, infraestructura como código, CI/CD y observabilidad. Si te interesa el camino completo, revisá qué implica el rol en nuestra guía sobre qué hace un DevOps Engineer y cuánto gana. Y si venís de desarrollo y todavía te falta la base de integraciones, esta explicación de APIs REST es un buen punto previo.

Cursos recomendados de Coderhouse

• Curso de DevOps y Cloud: el camino directo. Cubre contenedores, orquestación, integración continua y trabajo con proveedores cloud, que es exactamente el stack que se pide en las búsquedas.

• Carrera de Desarrollo Backend: si todavía te falta la base. Kubernetes tiene mucho más sentido cuando ya construiste APIs, manejaste bases de datos y entendés cómo se comunican los servicios.

• Carrera de Desarrollo Full Stack: para quienes arrancan desde cero y quieren llegar a infraestructura con un panorama completo del desarrollo.

Preguntas frecuentes

¿Necesito Kubernetes para un proyecto chico?

Casi nunca. Para una aplicación con poco tráfico y un equipo pequeño, una plataforma administrada o un servidor con Docker Compose es más simple y más barato. Kubernetes empieza a justificarse cuando tenés varios servicios, necesidad de escalar de forma independiente y un equipo que sostenga la complejidad.

¿Cuánto tiempo lleva aprender Kubernetes?

Para desplegar una aplicación propia y entender pods, deployments y services: entre cuatro y ocho semanas con práctica regular. Para operar clusters en producción con confianza: bastante más, porque ahí entran redes, seguridad, almacenamiento persistente y observabilidad.

¿Hace falta saber programar para trabajar con Kubernetes?

Sí, aunque no al nivel de un desarrollador de producto. Necesitás leer código para diagnosticar problemas, escribir scripts de automatización (Bash y Python son los más comunes) y entender cómo se comporta una aplicación para configurarla bien.

¿Kubernetes está siendo reemplazado por algo más simple?

Han aparecido alternativas más livianas y plataformas serverless que abstraen la complejidad, y el propio reporte de la CNCF registra que el uso de contenedores dejó de crecer al ritmo de años anteriores. Aun así, Kubernetes sigue siendo el estándar de facto en empresas medianas y grandes, y las abstracciones que lo reemplazan suelen correr sobre él.

¿Conviene certificarse?

Las certificaciones de la CNCF, especialmente la de administrador, tienen buena reputación porque son exámenes prácticos y no de opción múltiple. No reemplazan la experiencia, pero para alguien que hace la transición desde desarrollo funcionan como prueba concreta de conocimiento.