Conceito e mecanismo
Kubernetes mantém objetos que descrevem a intenção da equipa. Um controlador observa diferenças e tenta aproximar o estado real do desejado. Se um Deployment pretende três réplicas, eliminar um Pod não altera essa intenção; pode surgir um substituto. O novo objeto não tem de preservar o UID nem o endereço do anterior. O plano de controlo coordena estado e colocação, enquanto os nodes executam workloads. Uma falha temporária da API não implica que todos os processos parem imediatamente, mas compromete gestão e reconciliação. Durante um incidente, distingue falha de controlo, falha de execução e falha funcional da aplicação antes de escolher uma intervenção.
Aplicação guiada
Um Pod junta containers que partilham contexto de rede. Um processo que escuta em localhost pode comunicar com outro container no mesmo Pod, sem um Service externo. Isso não significa que qualquer container noutro Pod partilhe esse localhost. Para releases reproduzíveis, fixa o conteúdo aprovado por digest e verifica que o registry o disponibiliza; uma tag pode mudar. Namespaces organizam nomes e permitem controlos com âmbito, mas não são por si uma firewall. Num handover APS, regista o controlador responsável, a referência do artefacto, o namespace e os sinais de saúde. Assim, a equipa sabe que configuração deve alterar e que efeitos precisa de observar.
Se um Pod eliminado reaparece, consulta o workload que o controla antes de repetir a eliminação. Para reduzir réplicas, altera a intenção pelo processo aprovado.
Armadilhas comuns
Objeto substituto como o mesmo Pod; API saudável como aplicação saudável; tag como conteúdo imutável; namespace como isolamento total.
Tópicos relacionados: Capacidade, scheduling e tipos de workload · Services, DNS e políticas de rede
Observa a diferença entre intenção declarada, estado do cluster e resultado do serviço.
Referência: Controllers · KCNA current four-domain curriculum; edition date unconfirmed