Você está vendo a documentação do Kubernetes versão: v1.29
Kubernetes v1.29 a documentação não é mais mantida ativamente. A versão que você está visualizando no momento é uma cópia estática. Para obter a documentação atualizada, consulte última versão.
Gerenciamento de recursos para nós Windows
Esta página descreve as diferenças em como os recursos são gerenciados entre o Linux e o Windows.
Em nós Linux, cgroups são usados como uma divisão para o controle de recursos em Pods. Os contêineres são criados dentro desse limite para o isolamento de rede, processo e sistema de arquivos. As APIs de cgroup do Linux podem ser usadas para coletar estatísticas de uso de CPU, E/S e memória.
Em contraste, o Windows usa um objeto de trabalho por contêiner com um filtro de namespace do sistema para conter todos os processos em um contêiner e fornecer isolamento lógico ao hospedar. (Os objetos de trabalho são um mecanismo de isolamento de processo do Windows e são diferentes dos que o Kubernetes chama de Job).
Não há como executar um contêiner do Windows sem a filtragem de namespace. Isso significa que os privilégios do sistema não podem ser assegurados no contexto do host e, portanto, os contêineres privilegiados não estão disponíveis no Windows. Os contêineres não podem assumir uma identidade do host porque o Gerente de Conta de Segurança (Security Account Manager, ou SAM) é separado.
Gerenciamento de memória
O Windows não possui um eliminador de processo por falta de memória como o Linux. O Windows sempre trata todas as alocações de memória do modo de usuário como virtuais e os arquivos de paginação são obrigatórios.
Os nós Windows não superdimensionam a memória para os processos. O efeito real é que o Windows não atingirá as condições de falta de memória da mesma forma que o Linux, e estará processando a página em disco em vez de estar sujeito ao encerramento por falta de memória (OOM). Se a memória for superprovisionada e toda a memória física estiver esgotada, a paginação poderá diminuir o desempenho.
Gerenciamento de CPU
O Windows pode limitar a quantidade de tempo de CPU alocado para diferentes processos, mas não pode garantir uma quantidade mínima de tempo de CPU.
No Windows, o kubelet oferece suporte a uma flag de linha de comando para definir a
prioridade do escalonador do processo kubelet:
--windows-priorityclass
. Essa flag permite que o processo kubelet obtenha
mais fatias de tempo de CPU quando comparado a outros processos em execução no host do Windows.
Mais informações sobre os valores permitidos e os seus significados estão disponíveis em
classes de prioridade do Windows.
Para garantir que os Pods em execução não deixem o kubelet sem ciclos de CPU, defina essa flag como ABOVE_NORMAL_PRIORITY_CLASS
ou acima.
Reserva de recursos
Para contabilizar a memória e a CPU usadas pelo sistema operacional, o agente de execução de contêiner
e os processos de host do Kubernetes, como o kubelet, você pode (e deve)
reservar recursos de memória e CPU com as flags --kube-reserved
e/ou --system-reserved
do kubelet.
No Windows, esses valores são usados apenas para calcular o recursos
alocáveis pelo nó.
Conforme você implanta cargas de trabalho, defina a memória de recursos e os limites de CPU nos contêineres.
Isso também subtrai de NodeAllocatable
e ajuda o escalonador de todo o cluster a determinar quais pods colocar em quais nós.
Alocar pods sem limites pode superprovisionar os nós do Windows e, em casos extremos, fazer com que os nós não sejam íntegros.
No Windows, uma boa prática é reservar pelo menos 2GiB de memória.
Para determinar quanta CPU reservar, identifique a densidade máxima do pod para cada nó e monitore o uso da CPU dos serviços do sistema em execução, depois escolha um valor que atenda às necessidades das suas cargas de trabalho.