Conceito e mecanismo
O scheduler precisa de encontrar um node que satisfaça os requests e as restantes restrições do Pod. Uso instantâneo baixo não elimina capacidade já reservada por requests. Num node com quatro CPUs allocatable e uma CPU já pedida por outros Pods, restam 3000m; cabem dois novos Pods de 1500m pela CPU, se nada mais impedir a colocação. Memória disponível fragmentada entre nodes também não se soma para alojar um único Pod. Depois do arranque, requests e limits continuam a ter funções diferentes. OOMKilled exige investigar consumo de memória, limites e perfil da aplicação, em vez de aumentar CPU ou apagar reservas sem evidência.
Aplicação guiada
Escolhe o controlador pelo ciclo de vida do trabalho. Um DaemonSet representa um agente nos nodes elegíveis, com seleção e tolerations apropriadas. Um Job representa trabalho finito, mas a aplicação continua a precisar de tolerar repetição. Num batch financeiro, uma completion não garante um único lançamento externo: usa uma chave estável e um mecanismo que reconheça efeitos já confirmados. Antes de qualquer mudança, confirma cluster, identidade, namespace e objeto. Num ensaio de capacidade, guarda eventos de scheduling, requests, limites e resultado funcional. A decisão do gestor técnico deve considerar prazo do batch, custo adicional e impacto nos serviços online que partilham o cluster.
Dois nodes com 1024Mi de margem cada não alojam um Pod de 1536Mi. Precisas de margem suficiente num node compatível.
Armadilhas comuns
Uso observado como reserva; somar memória de nodes; limits como requests; uma completion como exatamente um efeito; contexto presumido.
Tópicos relacionados: Services, DNS e políticas de rede · Dados persistentes e acessos proporcionais
A unidade de colocação, o ciclo de vida e a semântica dos efeitos orientam o desenho.
Referência: Resource management · KCNA current four-domain curriculum; edition date unconfirmed