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?
Réponses:
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.
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.
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.
Il existe un ticket pour l'activer à nouveau, vous obtiendrez plus de perspicacité là-bas