Totalize a CPU e a memória do Kubernetes de relance.

Um millicore (o sufixo m, como em 250m) é um milésimo de um núcleo de CPU, então 1000m equivale a uma vCPU / hyperthread. O Kubernetes mede a CPU nessas unidades fracionárias porque um Pod raramente precisa de um núcleo inteiro — 250m significa um quarto de um núcleo de fatia garantida. Um número simples como 0.5 é o mesmo que 500m; a calculadora normaliza tudo para millicores para que as requests e os totais batam.

Mi é um mebibyte — 1024 × 1024 = 1.048.576 bytes — enquanto MB normalmente significa um megabyte de 1.000.000 de bytes. Os sufixos de memória do Kubernetes Ki / Mi / Gi são binários (potências de 1024); os sufixos sem essa partícula K / M / G são decimais (potências de 1000). Eles são próximos, mas não iguais: 1 Gi é cerca de 1,074 GB. Misturá-los provoca silenciosamente um provisionamento insuficiente, então a calculadora mantém as duas famílias separadas e converte ambas para bytes exatos.

Uma request é o que o scheduler reserva para um contêiner — ela garante aquela quantidade de CPU e memória e é o que o bin-packing usa para alocar o Pod em um nó. Um limit é o teto absoluto: a CPU acima do limit sofre throttling, e a memória acima do limit faz o contêiner receber um OOM-kill. As requests guiam o planejamento de capacidade; os limits limitam o raio de impacto. A calculadora soma os dois para que você possa dimensionar um node pool conforme as requests e vigiar o teto conforme os limits.

É inválido — o API server do Kubernetes rejeita um contêiner cujo limit seja menor que sua request, porque você não pode limitar um recurso abaixo da quantidade que já garantiu. A calculadora sinaliza qualquer linha em que o limit normalizado fique abaixo da request normalizada, para que você detecte o erro aqui em vez de em um apply que falha ou na rejeição de um admission webhook.

Não. Cada quantidade é parseada, normalizada e totalizada 100% no lado do cliente na sua aba — não há servidor, não há conta e não há registros. Você pode colar com segurança blocos de recursos de manifestos internos; nada é enviado.

A request e o limit totais de um pod são a soma dos valores individuais de todos os seus contêineres. Multiplique esse total por pod pelo número de réplicas para obter o que o deployment inteiro reserva. Por exemplo, 3 réplicas com 250m de CPU e 256Mi de memória cada uma somam 750m de CPU e 768Mi. Informe os valores por contêiner e o número de réplicas na calculadora e ela calcula os totais da carga de trabalho na hora.

Mi (mebibytes) e Gi (gibibytes) são unidades binárias em que 1024Mi equivale a 1Gi. Divida Mi por 1024 para obter Gi, e multiplique Gi por 1024 para obter Mi. Um Gi equivale a 1.073.741.824 bytes, que é ligeiramente maior que 1G (1.000.000.000 de bytes). A calculadora normaliza internamente todos os valores de memória para bytes exatos, então as entradas em Mi e Gi se comparam e se totalizam corretamente sem nenhuma conversão manual.

Sim, a calculadora é totalmente gratuita. Ela roda inteiramente no seu navegador, sem servidor, sem conta e sem envio de dados — você não precisa se cadastrar nem fazer login. Você pode colar com segurança valores de recursos de manifestos internos porque nada sai do seu dispositivo.

Baseie as requests no uso observado em p95 ou p99 coletado com kubectl top durante um período representativo de 24 horas, e então defina os limits em aproximadamente duas a cinco vezes o valor da request. Requests altas demais desperdiçam capacidade de nó alocável; baixas demais deixam o pod sem recursos sob carga e provocam throttling de CPU ou OOMKills. Use a calculadora para totalizar os valores por contêiner considerando as réplicas antes de fixar números em um manifesto.