APRENDER. PRATICAR. EVOLUIR.Começa pelo serviço e pelo recurso escasso
Um serviço fictício de reconciliação recebe ficheiros, valida movimentos e grava resultados. CPU, memória, disco temporário, ligações à base de dados e chamadas pagas a terceiros são recursos diferentes. Identifica o que cada pedido pode consumir e a consequência de o esgotar. Uma quota de CPU não limita automaticamente o tamanho de um ficheiro nem o número de chamadas a um fornecedor. Na revisão de arquitetura, desenha os caminhos síncronos e as filas, define quem partilha cada recurso e identifica a unidade dos limites. Um teto agregado pode proteger o serviço e ainda permitir que uma carteira consuma toda a capacidade disponível. O objetivo é manter trabalho útil e uma recusa previsível sob pressão, com limites coerentes em várias camadas.
Distingue reserva para scheduling e limites de execução
No perfil Kubernetes consultado, requests informam a colocação dos Pods. Um contentor pode usar mais do que o request quando existe capacidade e o limite permite. CPU e memória não falham da mesma forma: limites de CPU podem originar throttling; limites de memória são aplicados de forma reativa e podem resultar em OOM termination. Não classifiques ambos como simples lentidão. O request também não é uma promessa de latência de negócio. Para uma subida de memória, relaciona reinícios, utilização, configuração e eventos antes de aumentar o teto. Um limite maior pode resolver um dimensionamento insuficiente ou apenas adiar uma fuga de memória. A aceitação deve incluir funcionamento normal, picos e comportamento quando se atinge o limite.
Calcula com allocatable e com todos os contentores
A ficha simplificada tem um nó com 6000m de CPU allocatable e 5400m já pedidos. Cada novo Pod tem dois contentores de execução normal: aplicação com request de 300m e auxiliar com 100m. Não há init containers, overhead, outras restrições ou limitação de memória neste cálculo. Restam 600m, cada Pod pede 400m e só um cabe por esta dimensão. Usar apenas a aplicação daria dois e estaria errado. Mesmo o resultado de um é apenas um teto pelo critério CPU; numa plataforma real, afinidade, taints, memória e outros requisitos também decidem a colocação. Capacidade física anunciada não substitui allocatable, que já considera recursos não disponíveis para os Pods. A ficha não executa o scheduler nem mede desempenho.
Quota não cria capacidade nem isolamento completo
No mesmo exemplo, a quota de requests.cpu do namespace é 8000m e o consumo contabilizado é 6000m. O saldo permite cinco Pods de 400m, mas o nó considerado só tem espaço para um. A admissão pela quota e a colocação pelo scheduler respondem a perguntas diferentes. Adicionar nós também não aumenta automaticamente a quota do namespace. Um objeto rejeitado por quota não é o mesmo caso que um Pod admitido e Pending por falta de recursos. Lê mensagem, recurso e etapa da falha antes de alterar limites. Uma quota pode conter consumo agregado, mas não substitui autorização, política de rede ou isolamento do kernel. O registo de aceitação deve indicar qual fronteira foi testada e que garantias continuam fora do âmbito.
Entrega limites observáveis e recuperação controlada
Se cada réplica abrir um pool de 20 ligações e a base suportar 100 para este serviço, seis réplicas podem pedir 120. Acrescentar Pods pode agravar o gargalo a jusante. Coordena pools, concorrência, filas limitadas, deadlines e políticas de repetição com a capacidade da dependência. Não convertas uma fila sem limite em promessa de absorver qualquer pico. Para RUN, regista métricas por carteira e operação, rejeições, tempo de espera, utilização, throttling e reinícios, com responsáveis e ações permitidas. O rollback deve considerar trabalho já iniciado, não apenas o número de réplicas. Resumo: autorização, admissão e capacidade são decisões distintas; cada uma precisa de evidência. Relaciona esta aula com observabilidade, mudança, resiliência e custos cloud.
FICHA FICTÍCIA, SEM CLUSTER EXECUTADO
CPU allocatable: 6000m; requests existentes: 5400m
Novo Pod: aplicação300m + auxiliar100m = 400m
Saldo600m; máximo por CPU: floor(600/400)=1
Quota namespace8000m; usado6000m; saldo2000m
Máximo por quota: floor(2000/400)=5
Outras restrições excluídas desta conta
Seis réplicas x20 ligações =120; orçamento BD100
Aumentar réplicas não aumenta automaticamente capacidade a jusante.Saldo CPU: 600m; Pod: 300m+100m=400m; cabe no máximo um por CPU. Saldo de quota: 2000m, ou cinco Pods, sem criar capacidade.
Armadilhas comuns
Somar só a aplicação; usar CPU física em vez de allocatable; quota como reserva; mais réplicas sem orçamento de ligações; request como SLA.
Tópicos relacionados: Capacidade, disponibilidade e isolamento · Autorização, repetição e aceitação operacional
Relaciona requests, limites e quotas com o trabalho admitido e com os gargalos reais do serviço.
Referência: Resource Management for Pods and Containers · CCSP examination outline effective 2026-08-01; January2026 V2 PDF