Lección 2 de 314 min
Orquestación: Kubernetes, ECS, EKS y Helm
Pods, Deployments y Services, cómo empaquetar aplicaciones con Helm y las opciones gestionadas de AWS.
Con Docker ya sabes empaquetar tu API en una imagen. Pero en producción no quieres un contenedor, quieres cinco, repartidos en varias máquinas; que si uno se cuelga a las tres de la madrugada otro ocupe su lugar sin despertar a nadie; y que, al publicar una versión nueva, los usuarios no noten el cambio.
Eso es orquestar contenedores. En esta lección verás Kubernetes, el estándar de hecho; Helm, para empaquetar aplicaciones para Kubernetes, y las dos opciones de AWS: ECS, su orquestador propio, y EKS, Kubernetes gestionado.
Kubernetes
Por qué orquestar
Un sistema que reparte, vigila y actualiza tus contenedores en un grupo de máquinas.
- Ejemplos:
- Kubernetes, Amazon ECS, Nomad
Un orquestador recibe una descripción de lo que quieres («cinco copias de la API, con 512 MB cada una, detrás de un balanceador») y se encarga de conseguirlo en un grupo de máquinas: decide dónde ejecutar cada contenedor según los recursos libres y reparte las copias para que la caída de una máquina no se las lleve todas.
Después, vigila. Si un contenedor muere o deja de responder a su comprobación de salud, lo reinicia o lo sustituye (autorreparación). Ajusta el número de copias según la carga (escalado). Y publica versiones con actualizaciones progresivas (rolling updates): reemplaza las copias poco a poco y, si las nuevas fallan, se detiene.
Úsalo cuando
Cuando tienes varios servicios, necesitas alta disponibilidad o tu tráfico sube y baja. Para una app pequeña en un servidor, Docker Compose o un PaaS suelen bastar.
Ten en cuenta
Orquestar añade complejidad real: redes, permisos, observabilidad y actualizaciones del propio clúster. No adoptes Kubernetes porque «lo usa todo el mundo»; adóptalo cuando sus problemas sean los tuyos.
Kubernetes
El orquestador estándar: describes el estado deseado y el clúster trabaja para mantenerlo.
- Abreviatura:
- K8s
- Mantiene:
- CNCF
- CLI:
- kubectl
Kubernetes, abreviado K8s, nació en Google y hoy lo mantiene la Cloud Native Computing Foundation (CNCF). Un clúster tiene dos partes: el plano de control (control plane), que expone la API, guarda el estado en una base de datos llamada etcd y decide dónde va cada cosa, y los nodos, las máquinas donde se ejecutan tus contenedores, cada una con un agente llamado kubelet.
Su idea central es el estado deseado declarativo. No le das órdenes («arranca un contenedor»): le describes en archivos YAML cómo quieres que esté el sistema y lo aplicas con kubectl apply. Unos controladores comparan sin descanso lo deseado con lo real y corrigen la diferencia: si pides tres copias y hay dos, crean otra.
Úsalo cuando
Para plataformas con muchos servicios, equipos que quieren un estándar portable entre nubes o necesidades avanzadas de red, escalado y despliegue.
Ten en cuenta
La curva de aprendizaje es empinada y el clúster también hay que mantenerlo: cada versión de Kubernetes tiene un periodo de soporte limitado, así que actualizar es una tarea recurrente. Guarda tus YAML en Git: si alguien cambia algo a mano con kubectl edit, el repositorio deja de reflejar la realidad.
# Aplica todos los manifiestos de la carpeta
kubectl apply -f k8s/
# ¿Qué está pasando?
kubectl get pods
kubectl describe deployment web
kubectl logs deployment/web --follow
# Escala, o deshaz el último despliegue
kubectl scale deployment web --replicas=5
kubectl rollout undo deployment/webPods y Deployments
La unidad mínima que se ejecuta y el objeto que mantiene vivas sus copias.
- Unidad mínima:
- Pod
- Sin estado:
- Deployment
- Con estado:
- StatefulSet
Un Pod es la unidad mínima de Kubernetes: uno o varios contenedores que comparten red y almacenamiento y se ejecutan juntos en el mismo nodo; casi siempre, uno solo. Los Pods son efímeros: si mueren no resucitan, sino que se crean otros nuevos, con otra dirección IP.
Por eso no se crean a mano. Creas un Deployment, que declara qué imagen usar y cuántas réplicas quieres. El Deployment crea y vigila los Pods, sustituye los que caen y, cuando cambias la imagen, hace la actualización progresiva y guarda el historial para poder volver atrás.
Úsalo cuando
Para cualquier aplicación sin estado, como una API o un frontend. Para bases de datos y otros servicios con estado existe el StatefulSet, aunque en la nube suele ser más sencillo usar un servicio gestionado como RDS.
Ten en cuenta
Declara siempre los recursos (resources) y las sondas de salud (readinessProbe, livenessProbe). Sin ellos, Kubernetes no sabe en qué nodo cabe tu Pod ni cuándo está listo, y una actualización puede enviar usuarios a copias que aún no han arrancado.
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3
selector:
matchLabels: { app: web }
template:
metadata:
labels: { app: web }
spec:
containers:
- name: web
image: ghcr.io/mi-equipo/tienda-api:1.4.0
ports: [{ containerPort: 3000 }]
resources:
requests: { cpu: 250m, memory: 256Mi }
readinessProbe:
httpGet: { path: /salud, port: 3000 }Service, Ingress, ConfigMap y Secret
Una dirección estable para tus Pods, una puerta de entrada HTTP y la configuración aparte.
- Service:
- Nombre e IP estables
- Secret:
- base64, no cifrado
Como los Pods cambian de IP, un Service les da un nombre y una dirección estables y reparte el tráfico entre los Pods que coinciden con sus etiquetas: dentro del clúster, otro servicio llama a http://web sin saber cuántas copias hay. Un Ingress publica servicios HTTP hacia fuera con reglas por dominio y ruta (tienda.com/api → servicio api), gracias a un controlador que hace de proxy. La API Ingress sigue funcionando, pero está congelada: el proyecto apuesta por la Gateway API como sucesora.
Un ConfigMap guarda configuración (URLs, banderas) y un Secret, datos sensibles como contraseñas. Ambos se inyectan en los Pods como variables de entorno o como archivos, así que la misma imagen sirve para pruebas y para producción con distinta configuración.
Úsalo cuando
Service para toda aplicación que reciba tráfico; Ingress o Gateway API para publicar varias webs o APIs tras un mismo punto de entrada; ConfigMap y Secret para no meter la configuración dentro de la imagen.
Ten en cuenta
Un Secret solo está codificado en base64, no cifrado: cualquiera con permiso para leerlo lo ve. Activa el cifrado en reposo del clúster, limita quién puede leer Secrets y, en la nube, valora un gestor externo como AWS Secrets Manager.
apiVersion: v1
kind: Service
metadata:
name: web
spec:
selector: { app: web } # envía el tráfico a los Pods con esta etiqueta
ports: [{ port: 80, targetPort: 3000 }]
---
apiVersion: v1
kind: ConfigMap
metadata:
name: web-config
data:
API_URL: https://api.tienda.com
MODO_MANTENIMIENTO: "false"Empaquetar aplicaciones con Helm
Una aplicación real en Kubernetes son muchos YAML casi iguales en cada entorno. Copiarlos y pegarlos funciona hasta que alguien cambia uno y olvida los demás.
Helm
El gestor de paquetes de Kubernetes: plantillas, valores y versiones instaladas.
- Paquete:
- Chart
- Instalación:
- Release
Helm empaqueta tus manifiestos en un chart: una carpeta con plantillas YAML y un archivo values.yaml con los valores por defecto. En la plantilla escribes replicas: {{ .Values.replicas }}, y cada entorno aporta su propio archivo de valores con lo que cambia: el número de réplicas, el dominio, la etiqueta de la imagen.
Al instalar un chart creas una release, una instalación con nombre (tienda-prod). Helm guarda cada revisión de la release, así que helm upgrade aplica cambios y helm rollback vuelve a una revisión anterior. También puedes instalar charts de terceros: una base de datos, un panel de métricas o un controlador de Ingress con un solo comando.
Úsalo cuando
Para desplegar la misma aplicación en varios entornos o clústeres, y para instalar software de terceros en tu clúster.
Ten en cuenta
Las plantillas mezclan YAML con el lenguaje de plantillas de Go y se vuelven difíciles de leer si abusas de condiciones. Revisa lo que se va a generar (helm template, o el plugin helm diff) antes de aplicar, y no guardes secretos en texto plano en los values.yaml del repositorio.
# Instala o actualiza la release con los valores de producción
helm upgrade --install tienda-prod ./chart -f values-prod.yaml \
--set imagen.etiqueta=1.4.0
# Historial de revisiones y vuelta atrás
helm history tienda-prod
helm rollback tienda-prod 3
# Ver el YAML que se generaría, sin aplicarlo
helm template tienda-prod ./chart -f values-prod.yamlOrquestar en AWS: ECS y EKS
AWS ofrece dos caminos: su orquestador propio, más sencillo e integrado, o Kubernetes gestionado. En ambos puedes olvidarte de las máquinas con Fargate, que ejecuta cada contenedor sin que administres servidores.
Amazon ECS y Fargate
El orquestador propio de AWS: definiciones de tarea, servicios y, si quieres, sin servidores.
- Unidad:
- Tarea
- Sin servidores:
- Fargate
En ECS (Elastic Container Service) describes tu aplicación en una definición de tarea (task definition): imagen, CPU, memoria, puertos, variables y el rol de IAM que usará. Una tarea es una copia en ejecución, y un servicio mantiene el número de tareas que pides, las registra en un balanceador de carga y hace despliegues progresivos.
Las tareas pueden ejecutarse en instancias EC2 que gestionas tú o en Fargate, donde AWS pone la capacidad y tú solo indicas la CPU y la memoria de cada tarea. ECS no cobra por el plano de control: pagas lo que consumen las tareas.
Úsalo cuando
Si tu infraestructura vive en AWS y quieres orquestación sin aprender Kubernetes: equipos pequeños o medianos, APIs y procesos en segundo plano.
Ten en cuenta
Es exclusivo de AWS: tus definiciones no se llevan a otra nube. Fargate cuesta más por unidad de cómputo que una instancia EC2 bien aprovechada, a cambio de no gestionar máquinas, y no te da acceso al servidor que hay debajo.
{
"family": "tienda-api",
"requiresCompatibilities": ["FARGATE"],
"networkMode": "awsvpc",
"cpu": "512",
"memory": "1024",
"executionRoleArn": "arn:aws:iam::111122223333:role/ecsTaskExecutionRole",
"taskRoleArn": "arn:aws:iam::111122223333:role/tienda-api",
"containerDefinitions": [
{
"name": "api",
"image": "111122223333.dkr.ecr.eu-west-1.amazonaws.com/tienda-api:1.4.0",
"portMappings": [{ "containerPort": 3000 }],
"environment": [{ "name": "NODE_ENV", "value": "production" }]
}
]
}Amazon EKS
Kubernetes estándar con el plano de control gestionado por AWS.
- Plano de control:
- Gestionado por AWS
- Nodos:
- Gestionados, Fargate o Auto Mode
EKS (Elastic Kubernetes Service) te da un clúster de Kubernetes cuyo plano de control gestiona AWS, repartido entre varias zonas de disponibilidad. Usas kubectl, Helm y los mismos YAML que en cualquier otro Kubernetes, integrados con IAM, los balanceadores y los volúmenes de AWS.
Para los nodos tienes varias opciones: grupos de nodos gestionados (instancias EC2 que AWS crea y actualiza por ti), Fargate (cada Pod en su propio entorno, sin nodos a la vista) o, en las versiones recientes, EKS Auto Mode, que también decide y gestiona la capacidad de los nodos.
Úsalo cuando
Si ya usas Kubernetes o quieres su ecosistema (Helm, operadores, herramientas de la CNCF) sin mantener el plano de control, o si necesitas portabilidad entre nubes.
Ten en cuenta
EKS cobra por cada clúster y hora, además de los nodos, y sigue siendo Kubernetes: la complejidad no desaparece, solo la del plano de control. Tendrás que actualizar la versión del clúster con regularidad, porque cada versión tiene un periodo de soporte limitado.
# Crea un clúster con un grupo de nodos gestionados (herramienta eksctl)
eksctl create cluster --name tienda --region eu-west-1 \
--nodegroup-name generales --node-type t3.medium --nodes 3
# Configura kubectl para hablar con él y despliega como siempre
aws eks update-kubeconfig --name tienda --region eu-west-1
kubectl apply -f k8s/¿ECS o EKS?
Si tu equipo no tiene experiencia con Kubernetes ni necesita salir de AWS, ECS con Fargate suele ser el camino con menos piezas. Si ya habla Kubernetes, EKS le permite reutilizar todo lo que sabe, sus manifiestos y sus charts de Helm.
Interactivo
ECS, EKS y Kubernetes autogestionado
Activa o desactiva opciones para compararlas cara a cara.
| Característica | Amazon ECS | Amazon EKS | Kubernetes autogestionado |
|---|---|---|---|
| Plano de control | Lo gestiona AWS, invisible para ti | Lo gestiona AWS | Lo instalas, actualizas y vigilas tú |
| Qué aprendes | Conceptos propios de AWS: tareas y servicios | Kubernetes estándar | Kubernetes y su operación a fondo |
| Portabilidad | Solo AWS | Alta: los YAML valen en otros clústeres | Máxima: cualquier nube o tus propios servidores |
| Coste del plano de control | Sin coste adicional | Tarifa por clúster y hora | Las máquinas que dediques a él |
| Ecosistema | Integración profunda con AWS | Todo el de Kubernetes, integrado con AWS | Todo el de Kubernetes |
| Encaja con | Equipos que viven en AWS y buscan simplicidad | Equipos con experiencia en Kubernetes que usan AWS | Centros de datos propios o requisitos muy específicos |
Ponlo en práctica
Saber qué es cada cosa es la mitad del trabajo. La otra mitad es reconocer cuándo usarla.
Interactivo
¿Qué usarías?
Lee cada situación y elige la opción que mejor la resuelve. Fallar aquí no cuenta: es para practicar.
Tienes la misma aplicación en desarrollo, pruebas y producción, y mantienes tres copias casi idénticas de quince archivos YAML.
Para recordar
- Un orquestador reparte contenedores entre máquinas, sustituye los que fallan, escala y actualiza sin cortes.
- En Kubernetes describes el estado deseado en YAML y lo aplicas con
kubectl apply; los controladores se encargan del resto. - Deployment para mantener las copias, Service para darles una dirección estable, Ingress o Gateway API para entrar desde fuera y ConfigMap o Secret para la configuración.
- Helm empaqueta tus manifiestos en charts con valores por entorno y guarda revisiones para volver atrás.
- En AWS, ECS es lo más sencillo, EKS te da Kubernetes estándar y Fargate elimina los servidores en ambos.
Comprueba lo aprendido
Cuestionario
Responde las 5 preguntas para completar la lección.
1.¿Qué significa que Kubernetes sea declarativo?
2.Un Pod de tu Deployment muere. ¿Qué pasa?
3.¿Cuánto protege un Secret de Kubernetes por defecto?
4.¿Qué hace
helm rollback tienda-prod 3?5.¿Qué es Fargate?