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 eliminador de processos sem 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. O efeito final é que o Windows não alcançará as condições de falta de memória da mesma forma que o Linux. Os processos serão enviados para o disco em vez de ficarem 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.
## Sistema de reserva e memória kubelet
Diferente do Linux, onde `--kubelet-reserve` **captura** a reserva de recursos para daemons do sistema kubernetes, como kubelet, runtime do 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](https://docs.aws.amazon.com/eks/latest/userguide/launch-windows-workers.html), 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 que`KubeletExtraArgs`. 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 contêiner do Windows
De acordo com a [documentação da Microsoft](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/system-requirements), uma imagem base do Windows Server para NANO requer pelo menos 30 MB, enquanto o Server Core requer 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 imagem do contêiner do Windows, ou seja, a imagem base mais as camadas do aplicativo, e a defina 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 de nós disponível no caso de um problema no aplicativo.
No exemplo abaixo, quando o programador do Kubernetes tenta colocar um pod em um nó, as solicitações do pod são usadas para determinar qual nó 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.