Unidades de CPU, memória e armazenamento
No Kubernetes, a unidade é o núcleo, e o sufixo m significa milésimos.
| Valor | Significa |
|---|---|
1 ou 1000m |
Um núcleo inteiro |
500m |
Meio núcleo |
100m |
10% de um núcleo |
2 |
Dois núcleos |
CPU é compressível: passar do limite não mata o processo, ele é freado (throttling), o que aparece como latência alta sem nenhum erro.
sum by (pod) (rate(container_cpu_cfs_throttled_seconds_total[5m])) > 0O throttling acontece por período do CFS (100 ms por padrão): um processo com limite de
100m pode usar 10 ms a cada 100 ms. Aplicação com picos curtos sofre mesmo com uso médio
baixo — motivo pelo qual muitos times não definem limite de CPU em produção.
Memória
Seção intitulada “Memória”Aqui mora a confusão mais frequente: Mi não é MB.
| Sufixo | Base | Valor |
|---|---|---|
Ki |
2¹⁰ | 1.024 bytes |
Mi |
2²⁰ | 1.048.576 bytes |
Gi |
2³⁰ | 1.073.741.824 bytes |
K |
10³ | 1.000 bytes |
M |
10⁶ | 1.000.000 bytes |
G |
10⁹ | 1.000.000.000 bytes |
A diferença é de ~7% em Gi/GB — o suficiente para uma JVM configurada em -Xmx1000m
estourar um limite de 1000M no container.
Memória não é compressível: passar do limite é OOMKilled (exit 137), imediato.
kubectl describe pod <pod> -n <ns> | grep -i -A2 'last state' # OOMKilled?Regra prática: limits.memory igual a requests.memory, e o heap da aplicação
configurado abaixo do limite do container (uma JVM em container de 1Gi não deve ter
-Xmx1g; sobra runtime, threads e buffers fora do heap).
E cuidado com a métrica certa: container_memory_working_set_bytes é o que o kubelet usa
para decidir o OOM — não container_memory_usage_bytes, que inclui cache recuperável.
Armazenamento
Seção intitulada “Armazenamento”Os mesmos sufixos valem para storage:
resources: requests: storage: 20Gi # 21,47 GB| Termo | O que é |
|---|---|
| IOPS | Operações de entrada/saída por segundo |
| Throughput | MB/s de transferência |
| Latência | Tempo por operação (ms) |
| Block size | Tamanho de cada operação |
IOPS × block size ≈ throughput. Um volume com 3000 IOPS e blocos de 16 KB entrega cerca
de 48 MB/s — quem precisa de throughput e recebe IOPS acaba com o gargalo errado.
Muitos volumes de nuvem escalam IOPS com o tamanho: aumentar o disco é, às vezes, a forma mais simples de resolver lentidão de I/O.
| Unidade | Significa |
|---|---|
Mbps |
Megabits por segundo |
MB/s |
Megabytes por segundo |
1 byte = 8 bits. Um link de 1 Gbps entrega no máximo ~125 MB/s, e na prática menos por causa de overhead de protocolo. Provedores anunciam banda em bits; ferramentas de transferência mostram bytes.
Egress em fatura costuma ser cobrado em GB (10⁹), não GiB.
Tempo em configuração
Seção intitulada “Tempo em configuração”| Contexto | Formato |
|---|---|
Kubernetes (terminationGracePeriodSeconds) |
Segundos, número puro |
Prometheus ([5m], for: 2m) |
s, m, h, d, w, y |
Go / Envoy (5s, 1m30s) |
Sufixo obrigatório |
Helm (--timeout 5m) |
Duração do Go |
| cron | Campos, sem unidade |
Número sem unidade onde se espera duração é erro comum: timeout: 30 pode ser interpretado
como 30 nanossegundos em algumas configurações do Envoy.
Conversões que evitam erro
Seção intitulada “Conversões que evitam erro”1 Gi = 1024 Mi = 1.073.741.824 bytes1 GB = 1000 MB = 1.000.000.000 bytes1 Gi ≈ 1,074 GB (diferença de ~7%)1 Ti ≈ 1,1 TB1 Gbps ≈ 125 MB/s1000m CPU = 1 núcleonumfmt --to=iec 1073741824 # 1,0Gnumfmt --from=iec 1G # 1073741824Pegadinhas
Seção intitulada “Pegadinhas”1000M(1 GB) contra1000Mi(1,048 GB): o segundo é maior.1Gé diferente de1Gi— o erro aparece como OOM inexplicado.- Heap da JVM ou do Node configurado igual ao limite do container gera OOMKill.
topefreedentro do container mostram o host, não o cgroup.- Disco “cheio” pode ser inode esgotado:
df -i. - Limite de CPU baixo causa latência sem erro; procure throttling antes de culpar a rede.
- Percentual de CPU em
topé por núcleo: 200% significa dois núcleos saturados.