Desde o Kubernetes 1.8, parece que preciso desabilitar a troca em meus nós (ou definir --fail-swap-oncomo false).
Não consigo encontrar o motivo técnico pelo qual o Kubernetes insiste que a troca seja desabilitada. Isso é por razões de desempenho? Razões de segurança? Por que a razão para isso não está documentada?
A ideia do kubernetes é compactar as instâncias o mais próximo possível de 100% de utilização. Todas as implantações devem ser fixadas com limites de CPU/memória. Portanto, se o agendador enviar um pod para uma máquina, ele nunca deve usar swap. Você não quer trocar, pois isso atrasará as coisas.
É principalmente para o desempenho.
TL; DR não usando swap corretamente é apenas um hack preguiçoso que demonstra uma má compreensão dos subsistemas de memória e uma falta de habilidades fundamentais de administração de sistemas. Projetar serviços de infraestrutura e não entender esses sistemas está fadado ao fracasso.
Então, eu tenho alguns comentários sobre isso, isso parece mais preguiça para mim do que um recurso ou requisito. É absolutamente possível manipular adequadamente a troca, analisar a memória e determinar como utilizar adequadamente o subsistema de memória sem pressionar a troca. Há uma série de ferramentas construídas em torno disso e você pode garantir que um processo não utilizará a troca com bastante facilidade, portanto, o ponto de desempenho está incorreto. É simplesmente uma codificação preguiçosa não colocar essa instrumentação e, em geral, a remoção completa da troca prejudicará o desempenho do sistema. A chave aqui é usá-lo corretamente. Concordo que a troca de pods para discos afetará o desempenho, no entanto, há várias coisas que devem ser trocadas para o disco.
Além disso, o kernel do Linux foi projetado para utilizar swap, e desativá-lo completamente terá consequências negativas. Uma maneira melhor de lidar com isso seria fixar os pods na memória principal e não permitir que eles troquem para o disco, reduzir a pressão do cache vfs para que ele não troque a menos que seja absolutamente necessário e, mesmo assim, você pode fazer com que os processos fixados falha no MALLOC caso a memória principal esteja esgotada.
Dependendo dos processos nos contêineres, ter uma falha grave do contêiner ou matá-lo pelo OOM killer pode resultar em alguns resultados bastante desastrosos. Eu entendo, no entanto, que os processos executados nesses contêineres devem ser, idealmente, sem estado e efêmeros, mas em 20 anos de sistemas em execução, não vi todos seguirem o design pretendido ao pé da letra 100% do tempo.
Além disso, isso não leva em consideração tecnologias futuras, como memória não volátil e sistemas de memória mais recentes, como intel xpoint, que podem ser usados para estender significativamente a memória principal usando sistemas híbridos de disco/memória. Com esse tipo de sistema, eles podem usá-los diretamente como memória principal suplementar ou utilizar arquivos de troca para estender a memória principal com impacto insignificante no desempenho.
A razão para isso, pelo que entendi, é que o kubelet não foi projetado para lidar com situações de troca e a equipe do Kubernetes não planeja implementar isso, pois o objetivo é que os pods caibam na memória do host.
desta edição do GitHub # 53533
Há um ticket para habilitá-lo novamente, você terá mais informações lá
https://github.com/kubernetes/kubernetes/issues/53533