Evitando OOM erros - Amazon EKS

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 OOM erros

O Windows não tem um assassino de out-of-memory processos 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 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.

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, tempo de execução 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 NodeAllocatablea 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 out-of-memory (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 e/ou --system-reserve para reduzir NodeAllocatable.

Seguindo a documentação dos nós do Windows EKS autogerenciados da Amazon, 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 as seguintes bandeiras 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-o-kubelet/

Requisitos de memória de contêiner do Windows

De acordo com a documentação da Microsoft, uma imagem base do Windows Server 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. NETEstrutura, serviços da Web 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 suas camadas de aplicativo, e a defina como recursos/solicitações do contêiner 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.

📝 Edite esta página em GitHub