Outils sysadminActualité

CoreOS, zram et oomd : trois politiques à distinguer

Sur cette page
  1. Un changement Fedora 45, pas l’état de chaque nœud
  2. La politique d’arrêt constitue une autre couche
  3. Kubernetes pose deux questions séparées

Le swap compressé et la réponse précoce à la pression mémoire traitent des problèmes différents. Les futurs réglages CoreOS ne suppriment pas les limites des conteneurs Kubernetes.

Trois questions distinctes : zram occupe encore la RAM ; autoriser kubelet à démarrer avec du swap diffère de la politique des Pods. Exemple : 4 Gio de pages compressées en 2 Gio libèrent 2 Gio avant surcoûts.
Trois questions distinctes : zram occupe encore la RAM ; autoriser kubelet à démarrer avec du swap diffère de la politique des Pods. Exemple : 4 Gio de pages compressées en 2 Gio libèrent 2 Gio avant surcoûts. Graphique : PeopleAreGeek. Source des données.
Agrandir l’image

Un changement Fedora 45, pas l’état de chaque nœud

Le changement CoreOS accepté vise Fedora 45 avec systemd-oomd et swap sur zram, pour installations nouvelles et existantes. Ce projet ne décrit pas automatiquement un nœud en marche : vérifiez version déployée, canal et réglages locaux.

Zram conserve les données compressées en RAM. Dans notre exemple simplifié, quatre Gio de pages deviennent deux Gio et libèrent environ deux Gio avant métadonnées et autres surcoûts. Cela n’ajoute pas quatre Gio physiques. Des pages peu compressibles apportent moins de répit ; compression et décompression utilisent du temps CPU.

La politique d’arrêt constitue une autre couche

Le manuel systemd-oomd décrit la surveillance cgroup-v2 et de la pression. Les politiques ManagedOOM choisissent des groupes descendants éligibles à l’arrêt ; activer le service ne cible pas automatiquement chaque unité. oomctl affiche groupes surveillés et pression.

Cette action diffère du dépassement de limite d’un conteneur et d’une éviction kubelet. Pour expliquer un redémarrage, récupérez motif côté conteneur et journaux hôte avant de nommer le responsable. Le swap compressé n’annule pas ces autres politiques.

Kubernetes pose deux questions séparées

Le guide Kubernetes distingue failSwapOn: false, autorisant le démarrage de kubelet avec du swap, de memorySwap.swapBehavior. NoSwap interdit par défaut le swap aux Pods ; les processus extérieurs peuvent encore utiliser celui de l’hôte. LimitedSwap l’autorise à certaines charges, sous limites.

La couverture sépare compression physique, démarrage kubelet et politique des charges. Avant déploiement, reproduisez la pression sur un nœud d’essai avec les mêmes runtime et configuration. Observez aussi la latence : éviter un arrêt immédiat ne suffit pas si le service devient trop lent pour remplir sa fonction.

Revue du 8 septembre : projet Fedora 45 distingué du déploiement ; mémoire compressée, action oomd et réglages kubelet séparés.