Busca en todas las páginas de la documentación
Un solo contenedor ejecutándose en una sola máquina no tiene opinión sobre lo que sucede cuando esa máquina muere, cuando el tráfico se duplica o cuando una nueva versión necesita reemplazar a la antigua sin perder solicitudes.
Un orquestador (Kubernetes, ECS, Cloud Run) existe específicamente para mantener esas opiniones en tu nombre, continuamente, sin que un humano tenga que volver a ejecutar un script de despliegue cada vez que la realidad se desvía de lo que solicitaste.
Conceptos Básicos de Despliegue de Plataforma muestra las prácticas de 12 factores y los manifiestos que hacen que un servicio Node sea compatible con un orquestador; esta página es el modelo subyacente: lo que un orquestador realmente hace entre el momento en que envías una especificación y el momento en que tu servicio está en ejecución, saludable y se mantiene así.
docker run.Un comando docker run inicia un contenedor, una vez, en una máquina, y no hace nada más; si esa máquina se reinicia o el proceso falla, nada lo recupera a menos que una persona o un script separado intervenga.
Eso está bien para un solo experimento; se desmorona en el momento en que un servicio necesita múltiples réplicas en múltiples máquinas, necesita sobrevivir a un fallo completo de una máquina o necesita una nueva versión desplegada sin una interrupción en la que ninguna réplica esté sirviendo tráfico.
La idea central de un orquestador es el estado deseado: en lugar de emitir comandos imperativos ("inicia este contenedor ahora"), declaras lo que debería ser cierto ("3 réplicas de la imagen X deberían estar ejecutándose, exponiendo el puerto 3000") y entregas esa declaración a un plano de control, un conjunto de componentes del orquestador que trabajan continuamente para hacerlo realidad.
El mecanismo que realiza el trabajo real es un bucle de reconciliación: el plano de control compara repetidamente el estado deseado con el estado real observado, y cada vez que divergen (una réplica falló, un nodo se desconectó, alguien editó el recuento deseado), toma las medidas necesarias para cerrar la brecha.
Una analogía útil: un termostato no "enciende la calefacción una vez"; compara continuamente la temperatura real de la habitación con el objetivo y actúa cada vez que difieren, mientras esté funcionando.
Un orquestador hace lo mismo para las réplicas de contenedores en lugar de la temperatura, ejecutando esa comparación indefinidamente en lugar de como un paso de despliegue único.
Tres preocupaciones del orquestador se corresponden con tres preguntas diferentes, y mantenerlas separadas aclara lo que realmente sucede durante un despliegue o un fallo.
El planificador responde dónde: dada un conjunto de máquinas (nodos) con CPU y memoria disponibles, decide qué nodo debe ejecutar cada nueva réplica, teniendo en cuenta las solicitudes y restricciones de recursos.
Las comprobaciones de salud responden si: una comprobación de preparación le dice al plano de control si una réplica debería recibir tráfico actualmente, mientras que una comprobación de actividad le dice si la réplica necesita ser eliminada y reemplazada porque está atascada o no responde; estas son preguntas diferentes con consecuencias diferentes, por lo que las plataformas las exponen como sondas separadas en lugar de una sola.
El recuento de réplicas responde cuántas: la declaración de estado deseado incluye un recuento de réplicas objetivo, y el trabajo del bucle de reconciliación incluye notar cuándo las réplicas en ejecución reales son insuficientes (un fallo) o necesitan cambiar (una decisión de escalado) y corregirlo.
Estado deseado: 3 réplicas de api:sha-abc123
|
bucle de reconciliación del plano de control
|
observar estado actual -> comparar -> actuar si es diferente
- ¿réplica falló? -> programar un reemplazo
- ¿nodo se desconectó? -> reprogramar sus réplicas en otro lugar
- ¿cambió el recuento deseado? -> crear o eliminar réplicas
|
el bucle se repite, continuamente, para siempre
Una actualización continua es este mismo modelo de reconciliación aplicado a un cambio de versión: el orquestador no detiene todas las réplicas antiguas e inicia las nuevas a la vez, sino que inicia incrementalmente nuevas réplicas, espera a que cada una pase su comprobación de preparación, luego elimina una réplica antigua, repitiendo hasta que la nueva versión reemplaza completamente a la antigua, manteniendo la capacidad en todo momento.
Esa secuencia es exactamente la razón por la que las comprobaciones de preparación son importantes para los despliegues sin tiempo de inactividad: una nueva réplica que aún no ha pasado su comprobación de preparación no debería recibir tráfico, o el despliegue enrutaría solicitudes reales a una réplica que en realidad no está lista para manejarlas, produciendo errores durante cada despliegue en lugar de ninguno.
El orquestador tampoco tiene forma de saber si tu aplicación manejó una señal de apagado limpiamente a menos que tu código coopere; envía una señal de terminación y espera un período de gracia, pero un proceso Node que no drena las solicitudes en curso antes de salir seguirá perdiéndolas, independientemente de lo bien que se haya comportado la capa de orquestación.
Diferentes orquestadores se sitúan en diferentes puntos de un espectro de control versus simplicidad, y elegir uno es realmente elegir cuánta de esa maquinaria de reconciliación quieres operar tú mismo.
Kubernetes expone el modelo completo directamente (Deployments, Services, recursos personalizados, su propio planificador que puedes ajustar), lo que brinda el máximo control a costa de ejecutar (o pagar a alguien para que ejecute) el plano de control y aprender sus conceptos en profundidad.
ECS Fargate mantiene la misma idea de estado deseado/reconciliación, pero la limita a AWS, intercambiando parte de la flexibilidad de Kubernetes (sin recursos personalizados, sin portabilidad multinube) por una superficie operativa significativamente menor que poseer.
Cloud Run avanza más hacia la simplicidad al ocultar casi todo el modelo detrás de una abstracción de solicitud HTTP: aún obtienes escalado y recuperación automáticos, pero renuncias al control directo sobre la programación, la ubicación de nodos y las fuentes de eventos no HTTP a cambio de una configuración de orquestación casi nula.
El autoescalado extiende la misma idea de reconciliación una capa más allá: un Horizontal Pod Autoscaler (o equivalente) no solo mantiene el recuento de réplicas declarado en ejecución, sino que cambia el recuento declarado en sí mismo en función de métricas observadas como la CPU o la tasa de solicitudes, haciendo del estado deseado un objetivo móvil que el bucle persigue continuamente en lugar de un número fijo.
Los dominios de fallo importan más a medida que escala la orquestación: una garantía de estilo PodDisruptionBudget existe porque un planificador que reprograma réplicas durante un drenaje de nodo podría, de lo contrario, dejar un servicio completo fuera de línea si elimina demasiadas réplicas a la vez; el bucle de reconciliación necesita barandillas, no solo objetivos.
| Orquestador | Fortaleza | Debilidad | Mejor Ajuste |
|---|---|---|---|
| Kubernetes | Control total; portable entre nubes; rico ecosistema | Sobrecarga operativa real; curva de aprendizaje pronunciada | Plataformas multiservicio, equipos con capacidad de plataforma dedicada |
| ECS Fargate | Nativo de AWS; menos YAML y gestión de clúster que K8s | Bloqueado en AWS; menos puntos de extensibilidad | Empresas solo de AWS que desean menos carga operativa que K8s |
| Cloud Run | Configuración casi nula; escala cargas de trabajo HTTP automáticamente | Menor control; solo cargas de trabajo con forma de solicitud HTTP | APIs HTTP simples y sin estado con tráfico impredecible |
Es una declaración de lo que debería ser cierto, por ejemplo, "3 réplicas de esta imagen deberían estar ejecutándose", en lugar de un comando imperativo para ejecutar una vez. El plano de control del orquestador es responsable de hacer que esa declaración sea real continuamente.
A través del bucle de reconciliación: el plano de control compara continuamente el estado deseado (el recuento de réplicas declarado) con el estado real observado, y cuando un fallo los hace divergir, programa un reemplazo para cerrar la brecha.
El planificador responde a una pregunta específica (qué nodo debe ejecutar una réplica determinada) en función de los recursos disponibles. El bucle de reconciliación es el proceso continuo más amplio que detecta que el estado ha divergido y decide, entre otras cosas, cuándo debe actuar el planificador.
Responden a preguntas diferentes con consecuencias diferentes: la preparación decide si una réplica debe recibir tráfico actualmente, mientras que la actividad decide si una réplica está atascada y necesita ser eliminada y reemplazada. Tratarla como una sola comprobación corre el riesgo de enrutar el tráfico a una réplica no preparada o de eliminar una réplica que solo estaba temporalmente ocupada.
Reemplaza las réplicas antiguas por otras nuevas de forma incremental, eliminando una réplica antigua solo después de que su reemplazo haya pasado su comprobación de preparación, de modo que siempre haya un número suficiente de réplicas listas sirviendo tráfico durante todo el despliegue, nunca una interrupción en la que no haya ninguna.
Sí, el orquestador envía una señal de terminación y espera un período de gracia, pero es trabajo de la aplicación dejar de aceptar nuevo trabajo y finalizar las solicitudes en curso durante esa ventana. Una aplicación que ignora la señal seguirá perdiendo solicitudes, independientemente de lo bien que se haya comportado el orquestador.
Se sitúan en un espectro de control versus simplicidad operativa: Kubernetes ofrece el mayor control con el mayor costo operativo, Cloud Run ofrece el menor control pero requiere una configuración de orquestación casi nula, y ECS Fargate se encuentra entre los dos, nativo de AWS pero más simple que Kubernetes.
El autoescalado cambia el recuento de réplicas deseado en sí mismo, en función de métricas observadas como la CPU o la tasa de solicitudes, y el mismo bucle de reconciliación que maneja los fallos luego trabaja para hacer realidad ese nuevo objetivo móvil; es una política sobre el modelo base, no un sistema separado.
Porque el bucle de reconciliación compara continuamente el estado real con el estado deseado declarado en la configuración; un cambio manual que no se refleja en ese estado declarado es, desde la perspectiva del plano de control, una desviación que debe corregirse, no una actualización permanente.
Impide que las propias acciones de mantenimiento del bucle de reconciliación, como la reprogramación de réplicas de un nodo que se está drenando, desactiven accidentalmente demasiadas réplicas del mismo servicio a la vez, lo que el planificador por sí solo no evitaría.
No, ECS Fargate y Cloud Run implementan el mismo modelo central de estado deseado y reconciliación con menos superficie operativa que poseer, sacrificando parte de la flexibilidad y portabilidad de Kubernetes a cambio.
No, también cubre la programación de réplicas en varias máquinas, los despliegues de versiones sin tiempo de inactividad y el autoescalado, todo impulsado por el mismo bucle de reconciliación subyacente que compara el estado deseado con el estado real.
Versiones de pila: Esta página es conceptual y no está vinculada a una versión de pila específica.
Revisado por Chris St. John·Última actualización: 15 jul 2026