Busque em todas as páginas da documentação
Um único contêiner rodando em uma única máquina não tem opinião sobre o que acontece quando essa máquina morre, quando o tráfego dobra, ou quando uma nova versão precisa substituir a antiga sem perder requisições.
Um orquestrador - Kubernetes, ECS, Cloud Run - existe especificamente para ter essas opiniões em seu nome, continuamente, sem um humano reexecutando um script de deploy toda vez que a realidade se desvia do que você pediu.
Noções Básicas de Implantação de Plataforma mostra as práticas e manifestos de 12 fatores que tornam um serviço Node amigável ao orquestrador; esta página é o modelo subjacente - o que um orquestrador realmente faz entre o momento em que você envia uma especificação e o momento em que seu serviço está rodando, saudável e permanecendo assim.
docker run.Um comando docker run inicia um contêiner, uma vez, em uma máquina, e não faz mais nada - se essa máquina reiniciar ou o processo travar, nada o trará de volta, a menos que uma pessoa ou um script separado intervenha.
Isso é aceitável para um único experimento; desmorona no momento em que um serviço precisa de múltiplas réplicas em múltiplas máquinas, precisa sobreviver a uma falha completa de uma máquina, ou precisa de uma nova versão implantada sem uma lacuna onde nenhuma réplica esteja servindo tráfego.
A ideia central de um orquestrador é o estado desejado: em vez de emitir comandos imperativos ("inicie este contêiner agora"), você declara o que deve ser verdade - "3 réplicas da imagem X devem estar rodando, expondo a porta 3000" - e entrega essa declaração a um plano de controle, um conjunto de componentes do orquestrador que trabalham continuamente para torná-la real.
O mecanismo que faz o trabalho real é um loop de reconciliação: o plano de controle compara repetidamente o estado desejado com o estado real observado, e sempre que eles divergem - uma réplica travou, um nó ficou offline, alguém editou a contagem desejada - ele toma qualquer ação que feche a lacuna.
Uma analogia útil: um termostato não "liga o aquecimento uma vez" - ele compara continuamente a temperatura real da sala com a meta e age sempre que elas diferem, enquanto estiver funcionando.
Um orquestrador faz a mesma coisa para réplicas de contêineres em vez de temperatura, executando essa comparação indefinidamente em vez de como uma etapa de implantação única.
Três preocupações do orquestrador se mapeiam em três perguntas diferentes, e mantê-las separadas esclarece o que realmente está acontecendo durante uma implantação ou uma falha.
O agendador responde onde: dada um conjunto de máquinas (nós) com CPU e memória disponíveis, ele decide qual nó deve executar cada nova réplica, levando em conta as requisições de recursos e restrições.
As verificações de saúde respondem se: uma verificação de prontidão informa ao plano de controle se uma réplica deve receber tráfego a qualquer momento, enquanto uma verificação de vivacidade informa se a réplica precisa ser morta e substituída porque está travada ou sem resposta - essas são perguntas diferentes com consequências diferentes, é por isso que as plataformas as expõem como probes separadas em vez de uma única.
Contagem de réplicas responde quantas: a declaração de estado desejado inclui uma contagem de réplicas alvo, e o trabalho do loop de reconciliação inclui notar quando as réplicas em execução reais ficam aquém (uma falha) ou precisam mudar (uma decisão de escalonamento) e corrigi-lo.
Estado desejado: 3 réplicas de api:sha-abc123
|
loop de reconciliação do plano de controle
|
observa estado real -> compara -> age se diferente
- réplica travou? -> agenda uma substituição
- nó ficou offline? -> reagenda suas réplicas em outro lugar
- contagem desejada mudou? -> cria ou remove réplicas
|
loop repete, continuamente, para sempre
Uma atualização contínua é este mesmo modelo de reconciliação aplicado a uma mudança de versão: o orquestrador não para todas as réplicas antigas e inicia novas de uma vez, ele incrementa novas réplicas, espera cada uma passar em sua verificação de prontidão, então remove uma réplica antiga - repetindo até que a nova versão substitua completamente a antiga, com capacidade mantida durante todo o processo.
Essa sequência é exatamente o motivo pelo qual as verificações de prontidão importam para implantações sem tempo de inatividade: uma nova réplica que ainda não passou em sua verificação de prontidão não deve receber tráfego, ou a implantação direcionaria requisições reais para uma réplica que não está realmente pronta para lidar com elas, produzindo erros durante cada implantação em vez de nenhum.
O orquestrador também não tem como saber que sua aplicação lidou com um sinal de desligamento de forma limpa, a menos que seu código coopere - ele envia um sinal de terminação e espera um período de graça, mas um processo Node que não drena requisições em andamento antes de sair ainda as perderá, independentemente de quão bem a camada de orquestração se comportou.
Diferentes orquestradores se situam em diferentes pontos de um espectro de controle versus simplicidade, e escolher um é realmente escolher quanta dessa maquinaria de reconciliação você quer operar.
O Kubernetes expõe o modelo completo diretamente - Deployments, Services, recursos personalizados, seu próprio agendador que você pode ajustar - o que dá controle máximo ao custo de executar (ou pagar alguém para executar) o plano de controle e aprender seus conceitos em profundidade.
O ECS Fargate mantém a mesma ideia de estado desejado/reconciliação, mas a escopa para a AWS, trocando parte da flexibilidade do Kubernetes (sem recursos personalizados, sem portabilidade multi-cloud) por uma superfície operacional significativamente menor para gerenciar.
O Cloud Run vai mais longe em direção à simplicidade, escondendo quase todo o modelo atrás de uma abstração de requisição HTTP - você ainda obtém escalonamento e recuperação automáticos, mas renuncia ao controle direto sobre agendamento, posicionamento de nó e fontes de eventos não-HTTP em troca de configuração de orquestração quase zero.
O escalonamento automático estende a mesma ideia de reconciliação mais um nível: um Horizontal Pod Autoscaler (ou equivalente) não apenas mantém a contagem de réplicas declarada em execução, ele muda a contagem declarada em si com base em métricas observadas como CPU ou taxa de requisições, tornando o estado desejado um alvo móvel que o loop persegue continuamente em vez de um número fixo.
Domínios de falha importam mais à medida que a orquestração escala: uma garantia de estilo PodDisruptionBudget existe porque um agendador que reagenda réplicas durante a drenagem de um nó poderia, de outra forma, tirar um serviço inteiro offline se ele remover muitas réplicas de uma vez - o loop de reconciliação precisa de salvaguardas, não apenas de metas.
| Orquestrador | Força | Fraqueza | Melhor Ajuste |
|---|---|---|---|
| Kubernetes | Controle total; portátil entre nuvens; ecossistema rico | Sobrecarga operacional real; curva de aprendizado íngreme | Plataformas multi-serviço, equipes com capacidade de plataforma dedicada |
| ECS Fargate | Nativo da AWS; menos YAML e gerenciamento de cluster que o K8s | Bloqueado na AWS; menos pontos de extensibilidade | Lojas apenas AWS que desejam menos carga operacional que o K8s |
| Cloud Run | Configuração quase zero; escala cargas de trabalho HTTP automaticamente | Menos controle; apenas cargas de trabalho em formato de requisição HTTP | APIs HTTP simples e sem estado com tráfego imprevisível |
É uma declaração do que deve ser verdade - por exemplo, "3 réplicas desta imagem devem estar rodando" - em vez de um comando imperativo para executar uma vez. O plano de controle do orquestrador é responsável por tornar continuamente essa declaração real.
Através do loop de reconciliação: o plano de controle compara continuamente o estado desejado (a contagem de réplicas declarada) com o estado real observado, e quando uma falha faz com que eles diverjam, ele agenda uma substituição para fechar a lacuna.
O agendador responde a uma pergunta específica - qual nó deve executar uma determinada réplica - com base nos recursos disponíveis. O loop de reconciliação é o processo contínuo mais amplo que percebe que o estado divergiu e decide, entre outras coisas, quando o agendador precisa agir.
Elas respondem a perguntas diferentes com consequências diferentes: a prontidão controla o tráfego para uma réplica, enquanto a vivacidade decide se uma réplica está travada e precisa ser morta e substituída. Tratá-las como uma única verificação arrisca tanto rotear tráfego para uma réplica não pronta quanto matar uma réplica que estava apenas temporariamente ocupada.
Ela substitui réplicas antigas por novas incrementalmente, removendo uma réplica antiga apenas depois que sua substituição passou em sua verificação de prontidão - assim, há sempre um número suficiente de réplicas prontas servindo tráfego durante toda a implantação, nunca uma lacuna onde nenhuma está.
Sim - o orquestrador envia um sinal de terminação e espera um período de graça, mas é trabalho da aplicação parar de aceitar novo trabalho e finalizar requisições em andamento durante essa janela. Uma aplicação que ignora o sinal ainda perderá requisições, independentemente de quão bem o orquestrador se comportou.
Eles se situam em um espectro de controle versus simplicidade operacional: o Kubernetes oferece o máximo de controle com o maior custo operacional, o Cloud Run oferece o mínimo de controle, mas requer quase nenhuma configuração de orquestração, e o ECS Fargate fica entre os dois, nativo da AWS, mas mais simples que o Kubernetes.
O escalonamento automático muda a contagem de réplicas desejada em si, com base em métricas observadas como CPU ou taxa de requisições, e o mesmo loop de reconciliação que lida com falhas então trabalha para realizar esse novo alvo móvel - é uma política sobre o modelo base, não um sistema separado.
Porque o loop de reconciliação está continuamente comparando o estado real com o estado desejado declarado na configuração - uma mudança manual que não é refletida nesse estado declarado é, da perspectiva do plano de controle, uma divergência a ser corrigida, não uma atualização permanente.
Ele impede que as próprias ações de manutenção do loop de reconciliação - como reagendar réplicas de um nó que está sendo drenado - acidentalmente tirem muitas réplicas do mesmo serviço offline de uma vez, o que o agendador sozinho não impediria de outra forma.
Não - ECS Fargate e Cloud Run implementam o mesmo modelo central de estado desejado e reconciliação com menos superfície operacional para gerenciar, abrindo mão de parte da flexibilidade e portabilidade do Kubernetes em troca.
Não - ela também cobre o agendamento de réplicas entre máquinas, implantações de versão sem tempo de inatividade e escalonamento automático, tudo impulsionado pelo mesmo loop de reconciliação subjacente que compara o estado desejado com o estado real.
Versões da Stack: Esta página é conceitual e não está vinculada a uma versão específica da stack.
Revisado por Chris St. John·Última atualização: 15 de jul. de 2026