Glossário técnico
de orquestração.

Processo que roda em cada servidor pra executar trabalho.

Processo que vive em cada servidor de um cluster e recebe ordens do plano de controle. Quando o orquestrador decide que um contêiner precisa subir num determinado nó, é o agente daquele nó que puxa a imagem, configura rede e volumes, e mantém o processo rodando. Ele também reporta de volta o estado real (saúde, uso de CPU, falhas) pra que o plano de controle possa reconciliar diferenças entre o desejado e o observado. Em arquiteturas modernas, o mesmo binário costuma operar em dois modos — servidor ou agente — definidos por configuração.

Decisão concreta de "esta cópia roda neste nó".

Uma alocação é o vínculo concreto entre uma réplica de um job e o nó físico onde ela vai (ou já está) rodando. Quando você pede 3 réplicas de uma aplicação, o orquestrador produz 3 alocações — cada uma com um identificador próprio, um nó alvo, e um ciclo de vida observável. Alocações são a unidade atômica do escalonador: nascem, falham, são reagendadas, ou terminam quando o job é removido. Distinguir job (intenção) de alocação (execução real) é o que torna failover e rolling deploy possíveis.

Sistema continua respondendo mesmo perdendo nós.

Propriedade de um sistema que continua atendendo requisições mesmo quando partes dele falham. Em orquestração de containers, HA significa duas coisas distintas e independentes: o plano de controle (quem decide) precisa sobreviver à perda de servidores, e os contêineres da aplicação precisam ter réplicas suficientes pra absorver a queda de um nó. Sistemas que dizem "HA" mas rodam o plano de controle em um único processo só estão fazendo a metade fácil — o cluster sobrevive a falhas de aplicação mas não a falhas do próprio orquestrador.

Volta sozinho pra versão anterior se o deploy quebrar.

Mecanismo que detecta automaticamente que uma versão recém-promovida está falhando — health checks vermelhos, taxa de erro alta, latência fora do envelope — e reverte pro último estado conhecido como saudável sem intervenção humana. Auto-revert depende de três pré-requisitos: deploy gradual (rolling ou canary) que não derruba a versão antiga até a nova provar valor, sinais de saúde confiáveis que não dão falso positivo, e janela de observação suficiente pra distinguir um pico de tráfego de uma quebra real. Sem auto-revert, todo deploy ruim vira incidente.

Snapshot de estado feito sem parar o sistema.

Estratégia de backup que captura o estado de um banco de dados ou de um plano de controle sem precisar pausar o serviço. No mundo de orquestração, backup quente costuma se referir ao snapshot periódico do estado replicado do cluster — quem é líder, quais jobs existem, quais segredos estão guardados — gravado em armazenamento externo. O ponto importante é que o snapshot é consistente: representa um instante coerente, não um meio-write. Sem backup quente, recuperar um cluster que perdeu disco em todos os servidores significa redeclarar todos os jobs do zero.

Sobe versão nova em paralelo, troca o tráfego de uma vez.

Estratégia em que duas frotas completas de réplicas convivem: a "azul" (versão atual servindo tráfego) e a "verde" (versão nova já saudável mas sem tráfego). Quando a verde passa em todos os health checks, o roteador troca 100% do tráfego de azul pra verde em um único corte. A azul fica de pé como rede de segurança — se algo quebrar, basta apontar o roteador de volta. Custa o dobro de recursos durante a janela de troca, mas oferece o rollback mais rápido possível: literalmente uma mudança de configuração no roteador.

Manda uma fatia do tráfego pra versão nova primeiro.

Estratégia em que a versão nova começa servindo apenas uma fração do tráfego — 1%, 5%, 10% — enquanto o restante continua na versão antiga. O nome vem dos canários usados em minas de carvão: se o canário cai, você sabe que tem gás antes de mandar todo mundo pra dentro. Se as métricas da fatia canário ficam saudáveis, a fração aumenta progressivamente até 100%. Se degradam, o tráfego volta pra zero e a versão nova é descartada. Comparado com blue-green, canary expõe menos usuários ao risco mas leva mais tempo pra concluir.

TLS emitido e renovado sem ninguém abrir terminal.

Certificados TLS — o cadeado verde do navegador — tradicionalmente eram comprados anualmente e instalados manualmente. Let's Encrypt mudou isso oferecendo certificados gratuitos válidos por 90 dias, emitidos via um protocolo chamado ACME que prova posse de domínio automaticamente. Um orquestrador maduro embute essa lógica: detecta domínios novos em jobs, dispara o desafio (HTTP ou DNS), recebe o certificado, distribui pra todos os roteadores do cluster, e renova antes de expirar. O operador nunca toca um arquivo .pem.

Conjunto de servidores que se comporta como um só.

Conjunto de servidores que cooperam pra apresentar uma interface única ao operador. Em vez de pensar "qual nó tem capacidade?", você diz "rode 3 réplicas desta aplicação" e o cluster decide. Por trás da abstração existem três camadas: o plano de controle (quem decide), o plano de dados (onde os contêineres rodam), e o plano de rede (como os contêineres conversam entre si e com o mundo externo). Um cluster bem desenhado é resiliente — perde nós sem perder serviço — e elástico — adiciona nós sem reconfiguração manual.

Algoritmo que faz vários nós concordarem com a verdade.

Família de algoritmos que permite a um grupo de servidores chegar a uma decisão consistente mesmo na presença de falhas de rede e de processo. O problema parece banal — "todos concordem com X" — mas é não-trivial porque mensagens podem se perder, atrasar, ou chegar fora de ordem, e nós podem cair a qualquer momento. Algoritmos de consenso (Paxos, Raft, Viewstamped Replication) resolvem isso elegendo um coordenador, replicando um log de decisões com confirmação majoritária, e tendo regras precisas pra recuperação após falhas. É a base de qualquer plano de controle replicado.

Processo isolado com seu próprio sistema de arquivos e rede.

Forma de empacotar uma aplicação junto com todas as suas dependências — bibliotecas, binários, arquivos de configuração — em uma imagem imutável que roda como um processo isolado em qualquer host Linux compatível. Diferente de máquinas virtuais, contêineres compartilham o mesmo kernel do host, o que os torna leves (megabytes, não gigabytes) e rápidos pra iniciar (milissegundos, não minutos). O isolamento vem de mecanismos do próprio kernel: namespaces (visão isolada de processos, rede, filesystem) e cgroups (limites de CPU e memória). Toda orquestração moderna assume contêineres como unidade básica.

Processo que escolhe um nó pra mandar nos outros.

Procedimento pelo qual um conjunto de servidores escolhe entre si um coordenador (também chamado de líder) responsável por sequenciar decisões. Centralizar decisões em um líder único simplifica muita coisa — escrita ordenada, ausência de conflitos — mas exige que, quando esse líder cai, os outros consigam eleger um substituto rapidamente sem cisma. A eleição usa termos numerados, votos majoritários, e regras de "quem viu o último log mais recente vence" pra garantir que o novo coordenador conhece todas as decisões já confirmadas. Tudo isso é uma especialização de consenso distribuído.

Trocar pra um substituto quando o titular falha.

Transição automática de carga ou responsabilidade de um componente que falhou pra um substituto saudável. Em orquestração, failover acontece em várias camadas: o coordenador caiu, outro assume; o nó morreu, suas alocações renascem em nós vivos; o roteador parou de responder, o DNS aponta pra um peer. O que separa um bom failover de um ruim é o tempo de detecção (quanto demora pra perceber que o titular morreu — TCP timeouts mal tunados podem custar minutos) e o tempo de promoção (quanto demora pra o substituto começar a servir).

Sonda periódica que pergunta "você ainda funciona?".

Verificação automática e periódica que diz se um processo, contêiner ou nó está saudável. Tipicamente é um endpoint HTTP que devolve 200 OK quando tudo está bem, mas pode ser um TCP connect, um comando shell, ou uma checagem custom. Há duas modalidades importantes: liveness check (está vivo? se não, mate e reinicie) e readiness check (está pronto pra receber tráfego? se não, tire do load balancer mas não mate). Um sistema sem health checks bons descobre falhas pelos clientes — o que é tarde demais — e tende a depender de reinicializações manuais.

Porta de entrada que decide qual contêiner recebe a requisição.

Componente que recebe o tráfego HTTP/HTTPS vindo da internet e decide, pra cada requisição, qual conjunto de contêineres deve atendê-la. A decisão se baseia em regras declarativas — "host = api.exemplo.com vai pro job api-backend"; "path começa com /admin vai pro job painel". Ingress moderno também termina TLS (cuida do cadeado), faz balanceamento entre réplicas saudáveis, redireciona www pra apex, e aplica limites de taxa. Em clusters bem desenhados, o ingress é replicado em vários nós com DNS round-robin pra que a queda de qualquer um deles não derrube o tráfego.

Declaração do que rodar, quantas réplicas, e como expor.

Em orquestradores, um job é a unidade declarativa que descreve uma carga de trabalho: qual imagem de contêiner rodar, quantas réplicas, quais portas expor, quais variáveis de ambiente, quais limites de recursos, e como o roteador deve mapear domínios públicos pra ele. Job é intenção — "eu quero 3 réplicas disso" — em contraste com alocação, que é a execução real ("a réplica 1 está rodando no nó X, criada em Y"). O orquestrador mantém o estado real convergindo pra essa intenção: se uma alocação morre, ele cria outra; se você muda o número de réplicas, ele acerta a diferença.

Mesmo cluster atende múltiplos clientes/projetos isolados.

Modelo em que um único cluster compartilhado atende cargas de trabalho de vários inquilinos (tenants) — clientes diferentes, equipes internas distintas, projetos separados — com isolamento entre eles. Isolamento real exige três coisas: separação de rede (um tenant não consegue chegar nos contêineres do outro), separação de identidade (chaves e segredos do tenant A invisíveis pro B) e cotas (tenant agressivo não consome todo o CPU). Multi-tenancy bem feito é mais barato que clusters separados e mais simples que múltiplos provedores, mas é também onde a maior parte das brechas de segurança aparece.

Cérebro do cluster — recebe ordens e decide quem faz o quê.

Camada de um cluster que recebe declarações do operador ("rode este job"), guarda o estado desejado de forma replicada e durável, e produz decisões — quais nós executam quais alocações, quando reagendar, como progredir um deploy. É o cérebro: nada é executado por ele diretamente, mas tudo passa por ele. Pra ser confiável, o plano de controle precisa ser replicado em pelo menos 3 nós com consenso distribuído, sobreviver a perdas parciais, e ter API estável o suficiente pra que CLI, painel web e integrações continuem funcionando entre versões.

Maioria mínima necessária pra o cluster decidir.

Número mínimo de servidores do plano de controle que precisam estar saudáveis e em comunicação pra que decisões possam ser tomadas. A regra é "maioria simples": em um cluster de 3 servidores, quórum é 2; em 5, é 3; em 7, é 4. Sem quórum, o cluster entra em modo só-leitura — continua servindo o tráfego das aplicações que já rodam, mas não aceita deploys novos, mudanças de configuração ou eleição de coordenador. Por isso configurações pares (2, 4, 6 servidores) são desencorajadas: oferecem a mesma tolerância a falhas que a configuração ímpar logo abaixo, com mais custo.

Substitui réplicas uma de cada vez, sem janela de queda.

Estratégia em que as réplicas da versão antiga vão sendo substituídas pelas da versão nova de forma gradual — uma, duas, ou um lote por vez — sempre mantendo um número mínimo saudável servindo tráfego. Tipicamente parametrizado por dois valores: max_surge (quantas réplicas a mais que o desejado podem existir durante a transição) e max_unavailable (quantas a menos podem ficar fora). Rolling é o default na maioria dos orquestradores porque combina três propriedades: zero downtime, custo extra mínimo de recursos durante a transição, e rollback factível parando a progressão e revertendo lote por lote.