Netplan vs. NetworkManager : détecter les conflits et imposer une configuration réseau cohérente

Netplan vs. NetworkManager n’est pas une question académique, mais un risque opérationnel : lorsque deux composants tentent de gérer les mêmes ressources réseau, cela entraîne des pannes, des affectations d’IP incohérentes et des problèmes pour des services comme Kubernetes. Ce guide s’adresse aux administrateurs, ingénieurs systèmes et opérateurs et explique, en étapes concrètes, comment détecter les conflits, appliquer une Renderer‑Policy claire, basculer en toute sécurité des nœuds Kubernetes, mettre en place des validations automatisées et préparer des rollbacks rapides.

Pourquoi la Renderer‑Policy est si importante

Netplan est une interface déclarative : des fichiers YAML sous /etc/netplan décrivent la topologie réseau souhaitée. Netplan traduit ces spécifications à l’exécution en fichiers de configuration pour un renderer. Les renderer sont les gestionnaires effectifs — typiquement systemd-networkd (souvent abrégé networkd) ou NetworkManager. NetworkManager est un démon persistant avec son propre état et sa propre politique. Si l’organisation n’a pas de politique claire, des conditions de concurrence apparaissent, car netplan écrit la configuration du renderer lors du déploiement tandis que NetworkManager gère parallèlement des connexions ou que cloud‑init injecte de nouveaux réglages au démarrage.

Diagnostic : systématique et non invasif

Commencez par les faits : quelle configuration est effectivement appliquée dans le noyau ? Ensuite, vérifiez quels gestionnaires sont actifs et comment Netplan génère les paramètres d’exécution.

Commandes de base pour l’état et la visibilité

ip -br link
ip -br addr
ip route show

Cette vue est indépendante de Netplan ou de NetworkManager et affiche l’état actuel dans le noyau.

Perspectives des gestionnaires

systemctl is-active NetworkManager.service || true
systemctl is-active systemd-networkd.service || true
nmcli -t -f DEVICE,STATE device status
networkctl --no-legend --all

nmcli donne la vue de NetworkManager, networkctl celle de systemd‑networkd. Les contradictions ici sont un indice net d’un contrôle concurrent.

Scénarios d’erreur et leurs causes

Symptômes importants et causes typiques — expliqués brièvement :

• L’IP change après un redémarrage : soit plusieurs clients DHCP sont actifs, soit cloud‑init applique d’autres valeurs au premier démarrage.
• La route par défaut disparaît : le renderer applique une politique/metric de routage différente, ou une interface est désactivée.
• Nœud Kubernetes NotReady : l’interface CNI a été recréée ou NetworkManager a modifié un bridge/bond. Les plugins CNI attendent des associations hôte statiques.
• Journaux avec „Device is already managed“ : NetworkManager découvre un périphérique que netplan avait en fait destiné à networkd.

Vérifications concrètes en cas d’incident

Si les causes ne sont pas évidentes, procédez de manière séquentielle :

1. Vérifier les horodatages et l’ordre : comparez journalctl avant et après les démarrages ou les modifications de configuration.
2. Observer le trafic DHCP pour détecter des clients parallèles.
3. Inspecter la génération Netplan pour voir ce qui est effectivement écrit dans le renderer.

journalctl -b -u NetworkManager -u systemd-networkd --no-pager | sed -n '1,400p'
# DHCP und ARP beobachten (kurzes Sample)
tcpdump -n -i ens3 arp or port 67 or port 68 -c 200
# Netplan generieren, ohne anzuwenden
netplan generate
ls -l /run/systemd/network /run/NetworkManager 2>/dev/null

Exemples de configuration : comment contrôler le renderer

Netplan‑YAML définit le renderer de façon déclarative. Exemple : forcer networkd comme renderer.

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: true
      optional: true

Après avoir déployé le fichier, utilisez netplan generate et netplan apply. netplan generate affiche les fichiers qui seraient générés ; netplan apply applique activement. Sur des hôtes critiques, netplan try est utile — il annule automatiquement la modification si vous ne confirmez pas dans le délai imparti.

# Interaktives Anwenden mit Fallback
netplan try
# Oder idempotent in Automatisierung
netplan generate && netplan apply

NetworkManager: Keyfile‑Beispiel und unmanaged‑devices

NetworkManager utilise des Keyfiles pour les connexions persistantes. Si NetworkManager doit rester actif mais ignorer certaines interfaces CNI, créez une configuration dans /etc/NetworkManager/conf.d/ :

# /etc/NetworkManager/conf.d/10-unmanaged.conf
[main]
plugins=keyfile

[keyfile]
unmanaged-devices=interface-name:cni0;interface-name:flannel.1;interface-name:calico0

Cette entrée empêche NetworkManager de gérer les ponts/interfaces CNI — important pour Kubernetes.

systemd‑networkd: .network Beispiel

Si vous préférez networkd comme renderer, les fichiers .network peuvent être utilisés pour des réglages d’hôte plus fins (généralement inutile si Netplan génère tout de manière centralisée, mais utile pour des règles spécifiques).

# /etc/systemd/network/10-ens3.network
[Match]
Name=ens3

[Network]
DHCP=yes
IPv6AcceptRA=yes

[Route]
Gateway=192.0.2.1

Un fichier .network direct est lu par networkd ; Netplan génère automatiquement de tels fichiers lorsqu’il est configuré avec networkd comme renderer.

Migrationsstrategie: sicher, schrittweise, reversibel

Lors d’une migration en environnement de production, une approche conservatrice est impérative. Étapes recommandées :

1. Définir la politique : spécifiez les groupes d’hôtes (p. ex. k8s‑worker, db‑server, workstation) et leur renderer.
2. Canary‑Rollout : choisissez 1–3 nœuds non critiques comme cas de test.
3. Effectuer des sauvegardes : /etc/netplan, /etc/NetworkManager, sauvegarder les configurations cloud‑init.
4. Fenêtre de maintenance et accès hors‑bande : prévoyez KVM/IPMI/console série.
5. Validation automatisée : vérifier IP, routes, CNI, état de kubelet, santé des services.
6. Déploiement progressif et surveillance : surveiller les métriques, configurer des alertes sur des motifs définis.

Beispiel-Validationsscript (Basic)

#!/usr/bin/env bash
set -euo pipefail
IF=ens3
# IP prüfen
ip addr show "$IF" | grep -q "inet " || { echo "IP fehlt"; exit 2; }
# Default-Route prüfen
ip route show default | grep -q "dev $IF" || { echo "Default-Route fehlt"; exit 3; }
# Kubelet prüfen (nur auf K8s-Nodes)
systemctl is-active --quiet kubelet || { echo "kubelet nicht aktiv"; exit 4; }
# CNI-Interfaces prüfen
ip link show | grep -E "cni|calico|flannel" >/dev/null || echo "Keine CNI-Interfaces gefunden (ist das ok?)"
echo "Validation ok"

Ce script est volontairement simple ; étendez-le avec des vérifications Prometheus, une requête API vers kube‑apiserver ou des pods de test si vous l’intégrez dans un CI/CD.

Détails et pièges spécifiques à Kubernetes

Kubernetes rend les modifications réseau immédiatement visibles : les Pods peuvent perdre la connectivité, les CNI‑Plug‑Ins peuvent se réinitialiser et kubelet vérifie les conditions réseau de l’hôte. Remarques spécifiques :

• Drain und uncordon : Avant des modifications réseau importantes, effectuez un drain (kubectl drain) et, après validation, annulez le cordon.
• DaemonSets berücksichtigen : les daemons CNI s’exécutent sur chaque Node ; gérez les séquences de mise à jour pour éviter que le CNI ne redémarre simultanément.
• IP‑Masquerade und Forwarding : vérifiez les règles iptables/nftables, car NM peut parfois ajuster les relations de pare‑feu.

# Sicheres Node-Update Ablauf (Kurzform)
kubectl drain node01 --ignore-daemonsets --delete-local-data
# Änderungen anwenden
# Validieren: CNI Pods, kubelet, Netztests
kubectl uncordon node01

Monitoring: Metriken, Alerts und sinnvolle Thresholds

Configurez la supervision pour qu’un flap isolé ne déclenche pas systématiquement un pager. Exemples de métriques pertinentes :

• Nombre de flaps d’interface par hôte en 10 minutes (>5 → Avertissement).
• Renouvellements DHCP par MAC (>3 en 5 minutes → indicateur de clients concurrents).
• Événements Kubernetes Node NotReady après des modifications réseau (critique).
• Boucles de redémarrage de service pour NetworkManager ou systemd‑networkd (alerter au niveau hôte).

Typische Edge‑Cases und wie Sie sie lösen

Certains problèmes n’apparaissent que dans des conditions particulières — voici les plus courants :

• Provider‑Images : les images cloud contiennent parfois des profils NetworkManager préconfigurés. Vérifiez et nettoyez ces profils avant le déploiement.
• Persistent‑Interface‑Naming : des changements Udev/matériel peuvent modifier les noms. Préférez des correspondances basées sur MAC dans Netplan ou les fichiers .network si vous identifiez un risque.
• VLANs, Bridge und Bonding : NetworkManager et networkd diffèrent en syntaxe et en comportement ; testez le basculement de bonding et le LACP en environnement de test.

VLAN + Bond Beispiel (Netplan)

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3: {}
  bonds:
    bond0:
      interfaces: [ens3]
      parameters:
        mode: 802.3ad
        mii-monitor-interval: 100
  vlans:
    vlan100:
      id: 100
      link: bond0
      dhcp4: true

Rollback‑Praxis: Vorbereitung ist alles

Un rollback prend souvent plus de temps que la modification elle‑même. Préparez les éléments suivants :

• Backups : /root/netcfg-backups avec des horodatages explicites.
• Rollback‑Skripte : étapes automatisées qui RESTaurent les fichiers et redémarrent les services.
• Accès hors bande et plan de test : que mesurer pour valider le succès ?

# Backup (bevor Änderungen gemacht werden)
mkdir -p /root/netcfg-backups/$(date +%F_%H%M)
cp -a /etc/netplan /root/netcfg-backups/$(date +%F_%H%M)/
cp -a /etc/NetworkManager /root/netcfg-backups/$(date +%F_%H%M)/ || true
cp -a /etc/cloud /root/netcfg-backups/$(date +%F_%H%M)/ || true

Operational Recommendations — kurz und praktisch

• Définissez pour chaque groupe d’hôtes une politique de renderer claire et conservez‑la dans le CM/GitOps.
• Utilisez netplan try sur les hôtes critiques pour un retour automatique en cas de perte réseau.
• Protégez les interfaces CNI via unmanaged-devices avant d’autoriser NetworkManager.
• Testez toutes les modifications dans un environnement de staging, y compris les Node‑Drains pour Kubernetes.
• Implémentez des validations automatiques et des alertes qui détectent des motifs plutôt que des événements isolés.

Fazit

Netplan vs. NetworkManager est en pratique une question de discipline : une bonne exploitation établit une source unique de vérité, protège les CNI‑Devices, automatise les validations et conserve un plan de rollback testé. Des mesures techniques (Netplan‑Renderer, unmanaged‑devices, Node‑Drain) combinées à des directives organisationnelles (groupes d’hôtes, Change‑Windows, accès hors bande) minimisent les risques et maintiennent les réseaux opérables. Planifiez votre migration par phases, documentez vos décisions et mesurez automatiquement les impacts — ainsi votre réseau RESTe fiable et reproductible.

Netplan vs. NetworkManager : stratégies d’intégration, de sécurité et de dérive

En complément de la Renderer‑Policy, vous devriez adresser trois niveaux opérationnels : intégration au Configuration Management/GitOps, audit et durcissement contre les modifications d’exécution non souhaitées, ainsi que procédures de test et de validation sécurisées. Ces aspects empêchent que la dérive de configuration, des modifications D‑Bus non autorisées ou des agents fournisseur ne compromettent votre topologie réseau.

Détecter et corriger proactivement la dérive de configuration

Ne vous fiez pas au fait que les fichiers dans /etc correspondent automatiquement à votre dépôt Git. Un job court et automatisable détecte les écarts et peut, si nécessaire, RESTaurer une configuration approuvée ou déclencher une alerte.

#!/usr/bin/env bash
set -euo pipefail
REPO=/srv/git/netcfg.git
TMP=/tmp/netcheck
rm -rf "$TMP" && git clone "file://$REPO" "$TMP"
if ! diff -r "$TMP/etc/netplan" /etc/netplan >/dev/null; then
  echo "Drift detected: /etc/netplan differs from Git" >&2
  # optional: RESTore or trigger automation
  exit 2
fi
echo "Netplan OK"

Ces jobs s’exécutent en tant que cron, systemd‑timer ou dans la pipeline CI/CD. Décidez si une correction automatique (git checkout) ou seulement de l’alerte doit être appliquée — les deux approches ont des avantages et des inconvénients en matière de contrôle des changements.

Aspects de sécurité : D‑Bus, PolicyKit et verrouillage des services

NetworkManager expose des fonctions de contrôle via D‑Bus ; cela facilite les modifications pilotées par API, mais ouvre des vecteurs d’attaque. Limitez les modifications réseau via des règles PolicyKit, des droits de fichiers stricts et, lorsque pertinent, le masquage des services.

# NetworkManager temporär sperren (wird beim Maskieren nicht gestartet)
sudo systemctl mask NetworkManager
# Zurücksetzen
sudo systemctl unmask NetworkManager && sudo systemctl start NetworkManager

Pour les environnements auditables, consignez toutes les modifications de /etc/netplan et les appels D‑Bus (auditd ou journald avec filtrage des champs). Vous disposez ainsi d’une chaîne de modifications traçable pour la conformité et l’analyse post‑mortem.

Tests en bac à sable avec des network‑namespaces

Avant d’appliquer des règles en production, simulez le comportement de manière isolée avec des veth‑pairs et netns. Ainsi vous pouvez vérifier DHCP, VLANs ou politiques de routage sans perturber les interfaces de l’hôte.

# Einfacher Test: veth-Paar und DHCP-Client in Namespace
ip netns add tn
ip link add veth0 type veth peer name veth1
ip link set veth1 netns tn
ip addr add 192.0.2.1/24 dev veth0; ip link set veth0 up
ip netns exec tn ip link set lo up; ip netns exec tn ip link set veth1 up
# Im Namespace kann man jetzt dhclient, ip route etc. testen
ip netns exec tn dhclient -v veth1 & sleep 5; ip netns exec tn ip addr show

Automatisation : tâches idempotentes et Preflight‑Checks

Utilisez dans Ansible ou dans votre CM des modules/tâches idempotents et ajoutez des contrôles Preflight qui valident l’état du noyau (ip addr, ip route, ponts CNI). N’appliquez les modifications que si tous les Preflights réussissent ; sinon, interrompez et déclenchez une alerte.

# Beispiel (Ansible, vereinfachte Form)
- name: Deploy Netplan from repo
  hosts: k8s_workers
  tasks:
    - name: Ensure /etc/netplan matches repo
      copy:
        src: files/50-netcfg.yaml
        dest: /etc/netplan/50-netcfg.yaml
        owner: root
        mode: '0644'
      notify: Apply netplan

Regroupez l’intégration, la sécurité et l’automatisation des tests : ce n’est qu’ainsi que vous obtiendrez des configurations réseau reproductibles, éviterez des modifications inattendues par des tiers (Provider‑Agents, processus utilisateur) et conserverez le contrôle entre Netplan et NetworkManager en exploitation quotidienne.

Les renderers Netplan et le conflit avec NetworkManager sont également importants pour ce sujet. Ce texte situe ces aspects de manière claire et indique ce qui est essentiel dans la pratique quotidienne.