Pourquoi désactiver swap sur kubernetes

35

Depuis Kubernetes 1.8, il me semble que je dois désactiver le swap sur mes noeuds (ou --fail-swap-onsur false).

Je ne trouve pas la raison technique pour laquelle Kubernetes insiste pour que le swap soit désactivé. Est-ce pour des raisons de performance? Raisons de sécurité? Pourquoi la raison de ceci n'est-elle pas documentée?

kubernetes swap Jeroen Jacobs
la source

Réponses:

28

L'idée des kubernetes est de regrouper étroitement les instances pour qu'elles soient aussi proches que possible de 100%. Tous les déploiements doivent être épinglés avec des limites de CPU / mémoire. Ainsi, si le planificateur envoie un pod à une machine, il ne doit jamais utiliser de swap. Vous ne voulez pas échanger car cela ralentira les choses.

C'est principalement pour la performance.

Mike
la source
2
L’idée est que si un noeud n’a que 3gig à utiliser .. et que votre nouveau pod veut 4 .. sa va aller sur un autre noeud.
Mike
Cela n'a pas beaucoup de sens pour moi. Vous pourriez sûrement compresser un peu plus vos nœuds en laissant le système d'exploitation mettre en swap certaines pages de mémoire rarement utilisées sans nuire sensiblement aux performances.
Frederik Baetens le
13

Si j'ai bien compris, la raison en est que le kubelet n'est pas conçu pour gérer les situations d'échange et que l'équipe Kubernetes n'envisage pas de le mettre en œuvre, l'objectif étant que les pods tiennent dans la mémoire de l'hôte.

de ce numéro

La prise en charge de swap n’est pas triviale. Les gousses garanties ne devraient jamais nécessiter d'échange. Les demandes des modules pouvant être éclatés doivent être satisfaites sans qu'il soit nécessaire de les échanger. Les pods BestEffort n'ont aucune garantie. À l’heure actuelle, la kubelet n’a pas l’intelligence voulue pour offrir la bonne quantité de comportement prévisible ici, sur toutes les gousses.

Rory McCune
la source
10

TL; DR n’utilise pas correctement le swap n’est qu’un hack paresseux qui démontre une mauvaise compréhension des sous-systèmes de la mémoire et un manque de compétences fondamentales en matière d’administration de systèmes. Concevoir des services d'infrastructure sans comprendre ces systèmes est voué à l'échec.

Donc, j'ai quelques commentaires à ce sujet, cela me semble plus une paresse qu'un trait ou une exigence. Il est absolument possible de gérer correctement le swap, d'analyser la mémoire et de déterminer comment utiliser correctement le sous-système de mémoire sans effectuer de swap. De nombreux outils sont construits autour de cela et vous pouvez garantir qu'un processus n'utilisera pas l'échange très facilement, de sorte que le point de performance est incorrect. C’est tout simplement du codage paresseux pour ne pas utiliser cette instrumentation, et dans l’ensemble, la suppression complète du swap se fera au détriment des performances du système. La clé ici l'utilise correctement. Je conviens que l'échange de modules sur des disques aura une incidence sur les performances. Toutefois, un certain nombre d'éléments doivent être échangés sur un disque.

De plus, le noyau Linux est conçu pour utiliser le swap, et le désactiver complètement aura des conséquences négatives. Une meilleure solution consiste à épingler les pods dans la mémoire principale sans les autoriser à permuter sur le disque, à réduire la pression de la mémoire cache vfs afin qu’elle ne permute pas sauf si cela est absolument nécessaire. échouez MALLOC si la mémoire principale est épuisée.

En fonction des processus dans les conteneurs ayant une défaillance matérielle du conteneur ou son assassinat par le tueur OOM, des résultats assez désastreux pourraient en résulter. Je comprends cependant que les processus exécutés dans ces conteneurs devraient idéalement être apatrides et éphémères, mais en 20 ans de systèmes en fonctionnement, je n’ai jamais vu tout le monde suivre la conception à la lettre à la lettre 100% du temps.

En outre, cela ne prend pas en compte les technologies futures telles que la mémoire non volatile, ni les systèmes de mémoire plus récents, tels que intel xpoint, qui peuvent être utilisés pour étendre considérablement la mémoire principale à l'aide de systèmes de disque / mémoire hybrides. Avec ce type de systèmes, ils peuvent les utiliser directement comme mémoire principale supplémentaire ou utiliser des fichiers d'échange pour étendre la mémoire principale avec un impact négligeable sur les performances.

Michael Rutledge
la source
2
Je doute fort que les responsables du projet kubernetes soient paresseux. Aucun des arguments proposés ne semble se situer dans le contexte d'un écosystème conteneurisé fonctionnant en kubernetes.
spuder