Milicores
- Entrada
- 500m
- Resultado
- 0,5 núcleo
1000m é um núcleo. Um request de 100m significa que o escalonador reserva um décimo de núcleo.
Calculadora de recursos do Kubernetes
Converta milicores e sufixos de memória, multiplique pelas réplicas e veja a classe de QoS que o kubelet vai atribuir. A tabela de sufixos torna concreta a diferença entre Mi e M, de onde vêm o gasto silencioso e os OOMKill inesperados.
Cargas de exemplo
Classe de QoS: BurstableO limit de CPU é 5.0× o requestO limit de memória é 2.0× o request
| Por pod | × 3 réplicas | |
|---|---|---|
| CPU request | 0.1 | 0.3 |
| CPU limit | 0.5 | 1.5 |
| Memória request | 128Mi | 384Mi |
| Memória limit | 256Mi | 768Mi |
Trecho de manifesto
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 256Mi
# 3 replicas require
# cpu 0.3 cores requested, 1.5 at the limit
# memory 384Mi requested, 768Mi at the limitMi não é M
O Kubernetes aceita sufixos binários e decimais, e eles não têm o mesmo tamanho.
| Sufixo | Bytes | Sufixo | Bytes | Diferença |
|---|---|---|---|---|
| 1Ki | 1,024 | 1k | 1,000 | +2.4% |
| 1Mi | 1,048,576 | 1M | 1,000,000 | +4.9% |
| 1Gi | 1,073,741,824 | 1G | 1,000,000,000 | +7.4% |
Então 1G é 1G enquanto 1Gi é 1Gi — cerca de 7% a mais.
Tudo acontece no seu navegador. Esta página é um arquivo estático. O que você digita fica na aba, nunca é enviado a um servidor e some quando você fecha — então colar um token ou uma configuração real é seguro.
Quando você precisa disto
- Ao dimensionar um Deployment e precisar saber quanta capacidade do cluster a contagem de réplicas vai reivindicar.
- Ao descobrir por que um pod ficou Burstable quando você queria Guaranteed.
- Ao traduzir um limite de memória do docker-compose para as unidades que um manifesto espera.
Exemplos resolvidos
O sufixo que custa dinheiro
- Entrada
- 1000M vs 1Gi
- Resultado
- 1.000.000.000 vs 1.073.741.824 bytes
Escrever M onde você queria Mi dá ao contêiner cerca de 7% menos memória do que o pretendido.
QoS Guaranteed
- Entrada
- requests == limits
- Resultado
- Guaranteed
Só quando os requests de CPU e memória são exatamente iguais aos limits. Qualquer outra combinação é Burstable e é despejada mais cedo sob pressão.
Onde as pessoas erram
Escrever M quando se quer dizer Mi
512M são 512.000.000 bytes; 512Mi são 536.870.912. O manifesto é válido dos dois jeitos, então nada avisa — o pod apenas recebe menos memória do que o número sugere.
Definir um limit de CPU muito acima do request
Um limit várias vezes maior que o request deixa o pod disparar e depois ser estrangulado assim que o nó fica ocupado. Picos de latência que parecem bug de aplicação muitas vezes são throttling do CFS.
Omitir os requests por completo
Um pod sem requests é BestEffort e é a primeira coisa despejada quando um nó fica sem folga. Também não dá nada ao escalonador para planejar, então os nós enchem de forma desigual.
Perguntas frequentes
Qual a diferença entre request e limit?
O request é o que o escalonador reserva ao posicionar o pod; o limit é o teto que o kernel aplica em tempo de execução. Requests decidem onde o pod cai, limits decidem quando ele é estrangulado ou morto por memória.
Como a classe de QoS é decidida?
Guaranteed significa que todo contêiner tem requests de CPU e memória iguais aos limits. BestEffort significa nenhum request nem limit. Tudo entre os dois é Burstable, e isso importa porque o despejo segue essa ordem.
Devo definir limit de CPU?
Muitos times definem limits de memória mas deixam a CPU livre, porque estourar o limite de memória mata o contêiner enquanto estourar o de CPU apenas estrangula — muitas vezes a um custo de latência pior do que deixar o pod usar capacidade ociosa.