As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Evitando erros de OOM

O Windows não tem um assassino de processos sem memória, como o Linux. O Windows sempre trata todas as alocações de memória no modo de usuário como virtuais, e os arquivos de paginação são obrigatórios. O efeito final é que o Windows não atingirá as condições de memória da mesma forma que o Linux. Os processos serão paginados para o disco em vez de estarem sujeitos ao encerramento de falta de memória (OOM). Se a memória estiver superprovisionada e toda a memória física estiver esgotada, a paginação poderá diminuir o desempenho.

Reservando memória do sistema e do kubelet

Diferente do Linux, onde --kubelet-reserve captura a reserva de recursos para daemons do sistema kubernetes, como kubelet, runtime de contêiner, etc.; e --system-reserve captura a reserva de recursos para daemons do sistema operacional, como sshd, udev e etc. No Windows, esses sinalizadores não capturam e definem limites de memória no kubelet ou nos processos em execução no nó.

No entanto, você pode combinar esses sinalizadores para conseguir reduzir NodeAllocatable a capacidade no nó com o limite de recursos de memória do manifesto do pod para controlar a alocação de memória por pod. Usando essa estratégia, você tem um melhor controle da alocação de memória, bem como um mecanismo para minimizar a falta de memória (OOM) nos nós do Windows.

Nos nós do Windows, uma prática recomendada é reservar pelo menos 2 GB de memória para o sistema operacional e o processo. Use --kubelet-reserve and/or --system-reserve para reduzir NodeAllocatable.

Seguindo a documentação dos nós Self-managed Windows do Amazon EKS, use o CloudFormation modelo para iniciar um novo grupo de nós do Windows com personalizações na configuração do kubelet. O CloudFormation tem um elemento chamado BootstrapArguments que é o mesmo queKubeletExtraArgs. Use com os seguintes sinalizadores e valores:

--kube-reserved memory=0.5Gi,ephemeral-storage=1Gi --system-reserved memory=1.5Gi,ephemeral-storage=1Gi --eviction-hard memory.available<200Mi,nodefs.available<10%"

Se eksctl for a ferramenta de implantação, verifique a documentação a seguir para personalizar a configuração do kubelet https://eksctl.io/usage/customizing-the-kubelet/

Requisitos de memória de container do Windows

De acordo com a documentação da Microsoft, uma imagem base do Windows Server para NANO requer pelo menos 30 MB, enquanto o Server Core exige 45 MB. Esses números aumentam à medida que você adiciona componentes do Windows, como o.NET Framework, serviços Web como IIS e aplicativos.

É essencial que você saiba a quantidade mínima de memória exigida pela sua imagem de contêiner do Windows, ou seja, a imagem base mais suas camadas de aplicativo, e defina-a como a do contêiner resources/requests na especificação do pod. Você também deve definir um limite para evitar que os pods consumam toda a memória do nó disponível no caso de um problema no aplicativo.

No exemplo abaixo, quando o agendador do Kubernetes tenta colocar um pod em um node, as solicitações do pod são usadas para determinar qual node tem recursos suficientes disponíveis para agendamento.

 spec:
  - name: iis
    image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
    resources:
      limits:
        cpu: 1
        memory: 800Mi
      requests:
        cpu: .1
        memory: 128Mi

Conclusão

O uso dessa abordagem minimiza os riscos de esgotamento da memória, mas não impede que isso aconteça. Usando o Amazon CloudWatch Metrics, você pode configurar alertas e remediações em caso de esgotamento da memória.