A memória fora de memória do Container-Optimized OS do GKE congela

Question

Eu tenho problema com o Container-Optimized OS no GKE. Se eu executar este comando simples link para consumir toda a RAM, em algum momento o host congelará e não responderá a nada. Comportamento esperado: o processo deve ser morto pelo killer da OOM. Eu tentei isso em imagens Ubuntu e CentOS e eles funcionam perfeitamente: o processo é morto sem congelamento.

Existem três saídas kmsg possíveis no console Serial:

1. Em alguns casos, o log não contém nada relacionado ao congelamento
2. Às vezes, há uma série de mortes de OOM de outros processos seguidas de congelamento sem qualquer mensagem relacionada
3. E o mais interessante: OOM mata seguido por kernel panic ( link )

Os congelamentos são acompanhados por quase 100% da carga da CPU.

Então, esse é um comportamento esperado ou algo está errado?

    

Answer 1

Depois de algumas experiências, descobri que não é relacionado ao GKE ou ao GCP. E nem sequer está relacionado à imagem COS.

Na verdade, é como o kernel Linux lida com o OOM. O OOM killer começa tarde demais e está atuando em um ambiente altamente limitado à memória. Ele decide qual processo será eliminado usando os processos ' oom_score .

Ao executar o Kubernetes em um host, há muitos processos com alto valor oom_score_adjust (eles são pods sem limites de memória em sua especificação ). Se seu pod de comedor de RAM tiver limites definidos, seu oom_score resultante provavelmente será menor do que muitos outros processos.

Neste caso, o killer da OOM irá primeiro matar aqueles muitos processos com o maior oom_score antes que ele tenha chance de matar o processo realmente ganancioso. Eu não sei porque, mas nessas situações o Linux congela totalmente.

Como solução alternativa, encontrei esta ferramenta . Instalá-lo como DaemonSet resolve o problema. Mata processos gananciosos sem piedade.

    

Answer 2

O comportamento é esperado e não está sendo causado pela imagem COS em si. Em vez disso, está relacionado em como o Kubernetes lida com o Nó OOM . Nesse caso, o script está sendo executado no nó e não em um POD. Recipientes estão sendo mortos, mas não o processo principal, privando a memória.

Existem algumas propostas e implementações para ajudar a reservar recursos para o nó Daemons .

A partir dos nós que contêm a versão 1.7.6, o Google Container Engine reservará uma parte dos recursos de computação de cada nó para a sobrecarga do sistema usando o Kubernetes Recurso Allocatable do nó . Isso aumentará a confiabilidade dos componentes do sistema e não será um aumento na sobrecarga do sistema. Essa alteração reserva explicitamente os recursos de computação que os componentes do sistema já podem consumir.