Anúncios incomodam? Ir Sem anúncios Hoje 

Calculadora de Recursos de Contêineres Docker

DadosDesenvolvedor

ANÚNCIO · REMOVER?

ENTRADA

Processo Automático

SAÍDA

Lado cliente

Propriedade	Valor
Solicitação de CPU	-
Limite de CPU	-
Solicitação de CPU (millicores)	-
Limite de CPU (millicores)	-
Solicitação de Memória	-
Limite de Memória	-
CPU Total (todos os contêineres)	-
Memória Total (todos os contêineres)	-

Comando Docker Run

Flags --memory e --cpus do Docker

YAML do Kubernetes

Recursos do Kubernetes.requests / limits

ANÚNCIO · REMOVER?

Guia

Calculadora de Recursos de Contêineres Docker

Calcule limites ideais de recursos de CPU e memória para contêineres Docker e pods Kubernetes com base na capacidade do seu host e no tipo de carga de trabalho. Insira a CPU e a RAM disponíveis, selecione um preset de tipo de carga de trabalho e prepare-se para usar flags Docker run, YAML de recursos Kubernetes e snippets Docker Compose com botões de cópia. Lida com cenários de múltiplos contêineres com proporções de overcommit configuráveis e reserva do SO host.

Como usar

Insira os núcleos de CPU do host e a RAM disponível em GB, em seguida, selecione um preset de tipo de carga de trabalho ou defina proporções de recursos personalizadas. Defina o número de contêineres, ajuste a porcentagem de reserva do SO host e configure a proporção de overcommit. A calculadora gera flags Docker run, YAML de recursos Kubernetes e snippets Docker Compose para cada contêiner. Avisos aparecem se sua alocação total de recursos exceder a capacidade do host.

Características

7 Presets de Carga de Trabalho – Servidor Web, Servidor de Aplicações, Worker de Fundo, Banco de Dados, Cache, Inferência de ML e Personalizado com proporções recomendadas de CPU e memória
Suporte a Múltiplos Contêineres – Divida recursos entre múltiplos contêineres com distribuição uniforme
Flags Docker Run – Flags –memory, –memory-reservation, –cpus e –cpu-shares prontas para copiar
YAML do Kubernetes – Bloco de recursos completo com solicitações e limites em millicores e Mi/Gi
Snippet Docker Compose – Bloco deploy.resources formatado para docker-compose.yml
Proporção de Overcommit – Configure a proporção de solicitações vs limites (1.0x sem overcommit a 2.0x agressivo)
Reserva do SO Host – Porcentagem ajustável reservada para o sistema operacional do host (padrão 10-15%)
Avisos de Capacidade – Alertas visuais quando as alocações excedem os recursos disponíveis do host

ANÚNCIO · REMOVER?

 Perguntas frequentes

Qual é a diferença entre limites de memória Docker e solicitações de recursos Kubernetes?

Os limites de memória Docker (--memory flag) definem um limite rígido para o uso de memória do contêiner. Se um contêiner exceder esse limite, o Docker o encerrará com um erro OOM. O Kubernetes tem duas configurações: solicitações de recursos e limites de recursos. As solicitações são os recursos mínimos garantidos que o agendador usa para o posicionamento do pod. Os limites são o máximo que um contêiner pode usar. Definir solicitações menores que os limites permite o overcommitting de recursos entre os pods, o que melhora a utilização do cluster, mas corre o risco de contenção sob carga.
O que são millicores Kubernetes e como funcionam?

O Kubernetes mede a CPU em millicores, onde 1 núcleo de CPU é igual a 1000 millicores (1000m). Isso permite uma alocação de CPU de grão fino. Por exemplo, 250m significa 25% de um núcleo de CPU, 1500m significa 1.5 núcleos. Você também pode especificar a CPU como valores decimais como 0.25 ou 1.5. Millicores são particularmente úteis para contêineres pequenos que precisam apenas de uma fração de um núcleo de CPU, e eles mapeiam para as configurações de quota do Linux CFS (Completely Fair Scheduler) nos bastidores.
Quais recursos do host devo reservar para o sistema operacional?

Uma recomendação típica é reservar 10-15% de CPU e memória para o sistema operacional do host, serviços do sistema e sobrecarga do tempo de execução do contêiner. Para nós de produção Kubernetes, o kubelet tem flags internas (--system-reserved e --kube-reserved) para reservar recursos. Em um host de 16 GB, reservar 10% significa 1.6 GB para o SO, deixando 14.4 GB para contêineres. Sub-reservar pode levar à instabilidade do sistema, enquanto super-reservar desperdiça capacidade.
O que é overcommitting de recursos e quando devo usá-lo?

Overcommitting de recursos significa definir solicitações de recursos menores que os limites, permitindo que o agendador empacote mais pods em um nó do que o nó poderia suportar se todos os pods usassem seus recursos máximos simultaneamente. Uma proporção de overcommit de 1.5x significa que as solicitações são definidas como 67% dos limites. Isso funciona bem para cargas de trabalho intermitentes, como servidores web, que raramente atingem o pico de uso simultaneamente. Evite o overcommitting para bancos de dados e serviços com estado onde o desempenho consistente é crítico. Comece com 1.0x (sem overcommit) para produção e aumente com cautela.