Fedora CoreOS activera systemd-oomd.service et le swap sur zram par défaut, à partir de Fedora Linux 45. Le comité d'ingénierie et de pilotage de Fedora a approuvé le changement à l'unanimité sous le ticket 3661, et Phoronix l'a rapporté le 10 août 2026. Le point qui mérite votre attention n'est pas la fonctionnalité elle-même, puisque toutes les autres variantes de Fedora la livrent depuis des années. C'est sa portée. La proposition indique clairement qu'elle touche tous les nœuds, y compris ceux déjà en service, et met en garde sur les applications qui n'acceptent pas le swap par défaut. Si vous faites tourner Kubernetes sur CoreOS, cette phrase est toute l'histoire.
The short answer
Fedora CoreOS activera systemd-oomd.service et le swap sur zram par défaut à partir de Fedora Linux 45, ce qui l'aligne sur les autres variantes de Fedora. FESCo a approuvé le changement sous le ticket 3661. Il a été retenu pendant des années parce que le kubelet refusait de tourner sur un nœud avec du swap, et il est débloqué maintenant que Kubernetes gère le swap sur les nœuds derrière une configuration explicite. La proposition précise que le changement touche les nœuds déjà en service, pas seulement les nouvelles installations.
La plupart des changements de valeur par défaut dans une distribution méritent une ligne dans les notes de version et rien de plus. Celui-ci mérite vingt minutes de votre après-midi, et la raison tient à une seule phrase de la proposition plutôt qu'à la fonctionnalité qu'elle décrit.
Fedora CoreOS active systemd-oomd.service et le swap sur zram par défaut avec Fedora Linux 45. Les deux sont livrés sur Workstation et les autres variantes depuis des années, donc la fonctionnalité en soi n'est pas une nouvelle. Ce que la proposition ajoute, c'est la portée : le changement touche tous les nœuds, y compris ceux déjà en service, et vous dit explicitement de vous occuper des applications qui n'accepteront pas le swap comme comportement par défaut. Kubernetes est nommé.
Le comité d'ingénierie et de pilotage de Fedora a approuvé le changement à l'unanimité sous le ticket 3661. Phoronix l'a rapporté le 10 août 2026. Le changement est porté par Nemric et jbtrystram, et la page du wiki a été mise à jour le 28 juillet 2026.
Pourquoi CoreOS était la variante qui ne pouvait pas l'avoir
Le kubelet refusait de démarrer sur un nœud avec du swap actif. Ce n'était pas de la prudence, c'était une position de correction.
La comptabilité mémoire de Kubernetes traite la limite mémoire d'un pod comme un plafond physique dur, et l'ordonnanceur place le travail sur les nœuds à partir de ce modèle. Le swap casse le modèle d'une manière précise : un conteneur qui dépasse son jeu de travail peut déborder sur le swap et continuer à tourner très lentement, au lieu d'être tué à la limite. La limite cesse d'être une limite et devient une falaise de performance que l'ordonnanceur ne voit pas. Sur un nœud qui n'exécute qu'une charge, c'est seulement désagréable. Sur un nœud partagé, cela veut dire qu'un voisin bruyant dégrade tout le monde pendant que chaque tableau de bord annonce une grappe en bonne santé.
Kubernetes a depuis gagné la prise en charge du swap sur les nœuds derrière une configuration explicite du kubelet, ce qui a rendu cette proposition possible. Les porteurs du changement rapportent le faire tourner avec failSwapOn à false et un comportement de swap contraint. C'est le détail important pour quiconque s'apprête à hériter de ce défaut : cela fonctionne, mais cela fonctionne parce que quelqu'un l'a configuré, pas parce que c'est sûr par accident.
Ce que systemd-oomd change dans la façon dont un nœud échoue
Le tueur OOM du noyau est un dernier recours et se comporte comme tel. Il intervient quand une allocation a déjà échoué, ce qui, sur une machine à court de mémoire, arrive après plusieurs minutes d'écroulement pendant lesquelles le nœud est indisponible en pratique tout en étant techniquement vivant. Il choisit ensuite un processus par heuristique et le tue. Quiconque a vu une base de données sélectionnée parce qu'elle avait le plus gros jeu résident sait comment cela se passe.
systemd-oomd intervient plus tôt et sur un autre signal. Il lit les informations de blocage sous pression, les compteurs PSI du noyau qui indiquent combien de temps les tâches passent bloquées en attente de mémoire, et quand un cgroup franchit un seuil de pression configuré pendant une durée configurée, il tue ce cgroup entier. Tuer le cgroup plutôt qu'un processus compte, parce qu'une charge est en général faite de plusieurs processus et qu'en retirer un vous laisse une moitié cassée.
Le comportement obtenu, c'est un nœud qui se déleste rapidement d'une charge au lieu d'un nœud qui rame dix minutes avant de supprimer quelque chose d'arbitraire. C'est meilleur sur presque tous les axes. C'est aussi un changement dans le moment où vos alertes se déclenchent et dans ce qu'elles disent, et c'est la partie qui surprend.
Lire honnêtement l'arbitrage zram
Un périphérique zram est un périphérique bloc adossé à de la mémoire compressée. Y swapper coûte du processeur pour la compression et rend de la capacité, sans disque impliqué, sans amplification d'écriture sur le SSD, et avec une latence à comparer à celle de la RAM plutôt qu'à celle du stockage.
La limite est structurelle et mérite d'être dite simplement : le swap vit dans la mémoire qui vous manquait. La compression sur des charges réelles se situe couramment autour de deux ou trois pour un, donc l'effet est qu'une machine retient nettement plus de données résidentes avant que la pression monte. C'est de la marge, pas la capacité que donne un fichier de swap sur disque. Sur un nœud dont le mode de défaillance est un bref pic d'allocation, la marge est exactement le bon remède. Sur un nœud simplement sous-dimensionné pour ce qu'il exécute, elle repousse le problème de quelques minutes.
La configuration zram livrée par Fedora vit dans les chemins habituels des générateurs systemd, et la distribution a porté la taille par défaut du périphérique à celle de la RAM, plafonnée à 8 Gio, lors d'un changement antérieur. Vérifiez la valeur sur votre propre image plutôt que de la supposer, les variantes ayant historiquement différé.
Ce que nous vérifierions avant l'arrivée de F45
Commencez par la configuration du kubelet, parce que c'est là qu'une protection implicite s'apprête à disparaître. Si votre configuration ne fixe pas explicitement failSwapOn et un comportement de swap, vous vous appuyez sur l'ancien refus de démarrage du kubelet comme filet de sécurité. Ce n'est pas une décision de configuration, c'est un accident qui vous protégeait, et il cesse de vous protéger quand le nœud revient d'une mise à niveau avec du swap actif et un kubelet prêt à le tolérer.
Regardez ensuite les charges dont les limites mémoire ont été réglées en supposant que les dépasser signifie une mort immédiate. Les traitements par lots et tout ce qui fuit et se corrigeait tout seul par le tueur OOM sont les candidats. Sous swap, ils se dégradent au lieu de mourir, ce qui est en général pire parce que c'est plus difficile à remarquer.
Enfin, vérifiez si vous tracez la pression mémoire PSI. systemd-oomd va décider à partir d'un signal que la plupart des équipes ne collectent pas, et la première fois qu'il agira, vous voudrez l'historique. Lire /proc/pressure/memory suffit pour commencer, et l'amener jusqu'à votre outil de métriques habituel représente une heure de travail rentabilisée la première fois qu'un nœud largue un pod à trois heures du matin.
Si vous voulez éprouver ce comportement délibérément plutôt que de le découvrir, nous avons examiné récemment une interface debugfs pour diriger la pression mémoire sur un système Linux, meilleure voie que la production. Et pour savoir où va le versant grappe, notre note sur Kubernetes 1.37 et containerd 2 couvre la version que tout cela va rencontrer.
Sources et pour aller plus loin
- Changes/CoreOS default to enable systemd-oomd and swap on Zram, wiki du projet Fedora
- Fedora CoreOS To Enable systemd-oomd & zRAM Swap By Default, Phoronix, 10 août 2026
- systemd-oomd for Fedora CoreOS, ticket 840 de fedora-coreos-tracker
- Revisit enabling swap on zram by default, ticket 859 de fedora-coreos-tracker
- systemd/zram-generator sur GitHub
Questions fréquentes
Que fait systemd-oomd que le tueur OOM du noyau ne fait pas ?
Il agit plus tôt et il agit sur des cgroups plutôt que sur des processus. Le tueur OOM du noyau intervient quand une allocation a déjà échoué, ce qui est tardif : la machine a alors généralement passé plusieurs minutes à s'écrouler et se trouve indisponible en pratique alors que rien n'est techniquement mort. systemd-oomd surveille les informations de blocage sous pression, les métriques PSI du noyau qui indiquent combien de temps les tâches passent à attendre de la mémoire, et quand un cgroup franchit un seuil de pression configuré, il tue le cgroup entier. La différence concrète sur un serveur, c'est entre un nœud qui se dégrade dix minutes avant de tuer un processus au hasard, et un nœud qui se déleste rapidement d'une charge et continue de répondre.
Pourquoi Fedora CoreOS a-t-il retenu ce changement alors que les autres variantes le livrent depuis des années ?
Kubernetes. Le kubelet refusait historiquement de démarrer sur un nœud avec du swap actif, ce que le réglage failSwapOn sert à contrôler, parce que la comptabilité mémoire de l'ordonnanceur suppose que la limite mémoire d'un pod est un plafond physique dur. Le swap casse cette hypothèse : un conteneur au-delà de son jeu de travail peut déborder sur le swap et continuer de tourner lentement au lieu d'être tué, ce qui rend les limites molles d'une manière que l'ordonnanceur ne modélise pas. Kubernetes a depuis gagné la prise en charge du swap sur les nœuds derrière une configuration explicite du kubelet, ce qui a débloqué la proposition. Les porteurs du changement indiquent le faire tourner avec failSwapOn à false et un comportement de swap limité.
Le swap sur zram aide-t-il vraiment, ou est-ce du swap avec des étapes en plus ?
C'est un arbitrage différent et il vaut la peine d'être compris comme tel. Un périphérique zram est un périphérique bloc adossé à de la mémoire compressée : y swapper coûte des cycles processeur pour la compression et rend de la capacité, sans disque impliqué et sans amplification d'écriture sur votre SSD. La compression sur des charges réelles tourne souvent autour de deux ou trois pour un, ce qui signifie qu'une machine peut retenir sensiblement plus de données résidentes avant que la pression monte. Ce qu'il ne peut pas faire, c'est survivre à la disparition de la mémoire, puisque le swap vit dans la mémoire qui vous manquait. Il achète de la marge et de la latence, pas de la capacité au sens d'un fichier de swap sur disque.
Comment refuser ce comportement sur un nœud où il serait inadapté ?
Par Butane et Ignition comme tout le reste sur CoreOS, et il vaut mieux écrire la configuration avant la mise à niveau qu'après. Le périphérique zram est créé par un générateur systemd qui lit sa configuration dans les chemins systemd habituels, donc un fichier de surcharge qui remplace le réglage de taille livré supprime le périphérique, et systemd-oomd est une unité ordinaire que l'on peut masquer. Placez les deux dans la configuration machine qui provisionne le nœud, pour que l'état soit déclaré et non appliqué à la main. Vérifiez la documentation Fedora CoreOS pour les noms de fichiers exacts dans la version que vous utilisez, parce que les chemins de configuration des générateurs sont le genre de détail qui bouge.
Que faut-il vérifier sur mes nœuds avant que Fedora 45 les atteigne ?
Trois choses. Si votre configuration kubelet fixe explicitement failSwapOn et un comportement de swap, parce que s'appuyer sur l'ancien refus de démarrer n'est pas une configuration, c'est un accident qui vous protégeait. Si une charge du nœud a des limites mémoire réglées en supposant que les dépasser signifie une mort immédiate, puisque le swap transforme cela en dégradation lente. Et si vous surveillez la pression mémoire PSI, parce que systemd-oomd va commencer à décider à partir d'un signal que la plupart des équipes ne tracent pas aujourd'hui.