Depuis Kubernetes 1.8, il semble que je doive désactiver le swap sur mes nœuds (ou définir --fail-swap-on a 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 ? Des raisons de sécurité ? Pourquoi cette raison n'est-elle pas documentée ?
L'idée de Kubernetes est de regrouper les instances de manière à ce qu'elles soient aussi proches que possible d'une utilisation à 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 devrait jamais utiliser de swap. Vous ne voulez pas utiliser l'échange car cela ralentira les choses.
C'est principalement pour la performance.
TL;DR ne pas utiliser correctement le swap est juste un hack paresseux qui démontre une mauvaise compréhension des sous-systèmes de mémoire et un manque de compétences fondamentales en administration de systèmes. Concevoir des services d'infrastructure sans comprendre ces systèmes est voué à l'échec.
J'ai donc un commentaire à faire à ce sujet, cela ressemble plus à de la paresse qu'à une fonctionnalité 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 toucher au swap. Il y a une multitude d'outils construits autour de cela et vous pouvez garantir qu'un processus n'utilisera pas le swap assez facilement, donc le point de performance est incorrect. C'est tout simplement un codage paresseux de ne pas mettre cette instrumentation, et globalement la suppression complète de l'échange sera au détriment des performances du système. La clé ici est de l'utiliser correctement. Je suis d'accord sur le fait que l'échange de pods contre des disques aura un impact sur les performances, mais il y a un certain nombre de choses que l'on peut faire pour améliorer les performances. devrait être transféré sur le disque.
De plus, le noyau linux est conçu pour utiliser le swap, et le désactiver complètement va avoir des conséquences négatives. Une meilleure façon de gérer cela serait d'épingler les pods en mémoire principale et de ne pas les autoriser à échanger sur le disque, de réduire la pression du cache vfs afin qu'il n'échange pas sauf si c'est absolument nécessaire, et même dans ce cas, vous pourriez faire en sorte que les processus épinglés échouent MALLOC dans le cas où la mémoire principale est épuisée.
En fonction des processus dans les conteneurs, une défaillance matérielle du conteneur ou sa destruction par un tueur OOM peut avoir des conséquences assez désastreuses. 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 d'exploitation de systèmes, je n'ai pas vu une seule fois tout le monde suivre la conception prévue à la lettre 100% du temps.
De plus, cela ne tient pas compte des technologies futures telles que la mémoire non volatile et les nouveaux systèmes de mémoire comme Intel xpoint qui peuvent être utilisés pour étendre la mémoire principale de manière significative en utilisant des systèmes hybrides disque/mémoire. Avec ce type de systèmes, on peut 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.
D'après ce que j'ai compris, la raison en est que le kubelet n'est pas conçu pour gérer les situations de swap et que l'équipe Kubernetes n'a pas l'intention de le mettre en œuvre, l'objectif étant que les pods tiennent dans la mémoire de l'hôte.
Le support pour le swap n'est pas trivial. Les pods garantis ne devraient jamais avoir besoin de swap. Les pods stables devraient voir leurs demandes satisfaites sans nécessiter de swap. Les pods BestEffort n'ont aucune garantie. Le kubelet manque actuellement l'intelligence pour fournir la bonne quantité de comportement prévisible ici à travers les pods.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
