Pourquoi désactiver le swap sur Kubernetes
Depuis Kubernetes 1.8, il semble que je doive désactiver le swap sur mes nœuds (ou définir --fail-swap-on à 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 performances? Raisons de sécurité? Pourquoi la raison de ceci n'est-elle pas documentée?
L'idée de kubernetes est de regrouper étroitement les instances pour qu'elles soient utilisées le plus près possible à 100%. Tous les déploiements doivent être épinglés avec des limites CPU/mémoire. Donc, si le planificateur envoie un pod à une machine, il ne devrait jamais utiliser swap du tout. Vous ne voulez pas échanger car cela ralentira les choses.
C'est principalement pour la performance.
TL; DR n'utilisant pas 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 et ne pas comprendre ces systèmes est voué à l'échec.
Donc, j'ai quelques commentaires à 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 existe une litanie 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 simplement un codage paresseux de ne pas mettre 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 est de l'utiliser correctement. Je conviens que l'échange de pods sur des disques aura un impact sur les performances, mais il y a un certain nombre de choses qui devraient être échangées sur le disque.
De plus, le noyau linux est conçu pour utiliser l'échange, et le désactiver complètement aura des conséquences négatives. Une meilleure façon de gérer cela serait d'épingler les pods dans la mémoire principale et de ne pas leur permettre de basculer sur le disque, de réduire la pression du cache vfs afin qu'il ne permute pas sauf si cela est absolument nécessaire, et même dans ce cas, vous pourriez provoquer des processus épinglés échouer MALLOC en cas d'épuisement de la mémoire principale.
Selon les processus dans les conteneurs, une défaillance grave du conteneur ou sa destruction par un tueur OOM pourrait entraîner des résultats assez désastreux. 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 fonctionnement des systèmes, je n'ai pas vu une fois tout le monde suivre la conception prévue à la lettre à 100% du temps.
De plus, cela ne prend pas en compte les 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 considérablement la mémoire principale à l'aide de systèmes hybrides disque/mémoire. 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.
Si je comprends bien, la raison en est que le kubelet n'est pas conçu pour gérer les situations de swap et que l'équipe Kubernetes ne prévoit pas de l'implémenter car l'objectif est que les pods doivent tenir dans la mémoire de l'hôte.
de ce problème
La prise en charge du swap n'est pas anodine. Les pods garantis ne devraient jamais nécessiter de swap. Les pods éclatables doivent voir leurs demandes satisfaites sans nécessiter de swap. Les pods BestEffort n'ont aucune garantie. Le kubelet manque actuellement d'intelligence pour fournir la bonne quantité de comportement prévisible ici à travers les pods.
et si vous installez simplement kubernetes localement sur votre ordinateur de bureau afin de pouvoir jouer avec? Je suppose que dans ce scénario, vous ignorez les règles de contrôle en amont et continuez de toute façon, en ignorant l'avertissement?