Netplan vs. NetworkManager: Konflikte erkennen und eine konsistente Netzkonfiguration erzwingen

Netplan vs. NetworkManager ist keine akademische Frage, sondern ein operatives Risiko: Wenn zwei Komponenten versuchen, dieselben Netzwerkressourcen zu steuern, folgen Ausfälle, inkonsistente IP‑Zuweisungen und Probleme für Dienste wie Kubernetes. Dieser Leitfaden richtet sich an Administratoren, System Engineers und Operatoren und erklärt in praktischen Schritten, wie Sie Konflikte erkennen, eine klare Renderer‑Policy erzwingen, Kubernetes‑Nodes sicher umstellen, automatisierte Validierungen aufsetzen und schnelle Rollbacks vorbereiten.

Warum Renderer‑Policy so wichtig ist

Netplan ist ein deklaratives Frontend: YAML‑Dateien unter /etc/netplan beschreiben die gewünschte Netzwerktopologie. Netplan übersetzt diese Vorgaben zur Laufzeit in Konfigurationsdateien für einen Renderer. Renderer sind die tatsächlichen Manager — typischerweise systemd-networkd (häufig kurz networkd) oder NetworkManager. NetworkManager ist ein persistenter Daemon mit eigenem State und Policy. Wenn die Organisation keine eindeutige Policy hat, entstehen Race‑Conditions, weil netplan beim Deploy die Renderer‑Konfiguration schreibt, während NetworkManager parallel Verbindungen verwaltet oder cloud‑init beim Boot neue Settings einspielt.

Diagnose: systematisch und nicht‑invasiv

Beginnen Sie mit Fakten: Was ist derzeit effektiv im Kernel konfiguriert? Danach schauen Sie, welche Manager aktiv sind und wie Netplan die Laufzeitsettings erzeugt.

Basisbefehle für Status und Sichtbarkeit

ip -br link
ip -br addr
ip route show

Diese Darstellung ist unabhängig von Netplan oder NetworkManager und zeigt den aktuellen Zustand im Kernel.

Manager‑Perspektiven

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 gibt die Sicht von NetworkManager, networkctl die von systemd‑networkd. Widersprüche hier sind ein klarer Hinweis auf konkurrierende Kontrolle.

Fehlerbilder und ihre Ursachen

Wichtige Symptome und typische Ursachen — kurz erklärt:

• IP ändert sich nach Reboot: Entweder mehrere DHCP‑Clients oder cloud‑init setzt beim ersten Boot andere Werte.
• Default‑Route verschwindet: Renderer hat unterschiedliche Routing‑Policy/metric, oder eine Verbindung wird deaktiviert.
• Kubernetes Node NotReady: CNI‑Interface wurde neu erstellt oder NetworkManager hat Bridge/Bond verändert. CNI‑Plugins erwarten statische Host‑Zusammenhänge.
• Logs mit „Device is already managed“: NetworkManager entdeckt ein Device, das netplan eigentlich networkd zuweisen wollte.

Konkrete Prüfungen, wenn etwas schiefgeht

Wenn die Ursachen nicht offensichtlich sind, gehen Sie sequenziell vor:

1. Zeiten und Reihenfolge prüfen: Vergleichen Sie journalctl vor und nach Boots oder Konfigurationsänderungen.
2. DHCP‑Traffic beobachten, um parallele Clients zu entdecken.
3. Netplan‑Generierung inspizieren, um zu sehen, was tatsächlich in den Renderer geschrieben wird.

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

Konfigurationsbeispiele: Wie Renderer kontrolliert wird

Netplan‑YAML legt den Renderer deklarativ fest. Beispiel: Erzwingen von networkd als Renderer.

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

Nachdem Sie die Datei deployt haben, nutzen Sie netplan generate und netplan apply. netplan generate zeigt, welche Dateien erzeugt würden; netplan apply wendet aktiv an. Bei kritischen Hosts ist netplan try sinnvoll — es rollt die Änderung automatisch zurück, wenn Sie nicht innerhalb eines Timers bestätigen.

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

NetworkManager: Keyfile‑Beispiel und unmanaged‑devices

NetworkManager verwendet Keyfiles für persistente Verbindungen. Wenn NetworkManager aktiv bleiben muss, aber bestimmte CNI‑Interfaces ignorieren soll, erstellen Sie eine Konfiguration in /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

Dieser Eintrag verhindert, dass NetworkManager CNI‑Bridges/Interfaces verwaltet — wichtig für Kubernetes.

systemd‑networkd: .network Beispiel

Wenn Sie networkd als Renderer bevorzugen, können .network‑Dateien für feinkörnigere Host‑Einstellungen genutzt werden (gewöhnlich nicht nötig, wenn Netplan alles zentral generiert, aber hilfreich für spezielle Regeln).

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

[Network]
DHCP=yes
IPv6AcceptRA=yes

[Route]
Gateway=192.0.2.1

Eine direkte .network‑Datei wird von networkd gelesen; Netplan erzeugt solche Dateien automatisch, wenn es als Renderer networkd gesetzt ist.

Migrationsstrategie: sicher, schrittweise, reversibel

Bei der Umstellung in produktiven Umgebungen ist ein konservatives Vorgehen Pflicht. Empfohlene Schritte:

1. Policy definieren: Legen Sie Hostgruppen (z. B. k8s‑worker, db‑server, workstation) und deren Renderer fest.
2. Canary‑Rollout: Wählen Sie 1–3 nichtkritische Nodes als Testfall.
3. Backups erstellen: /etc/netplan, /etc/NetworkManager, cloud‑init Konfigurationen sichern.
4. Change‑Window und Out‑of‑Band‑Zugang: Sorgen Sie für KVM/IPMI/Serienkonsole.
5. Automatisierte Validierung: IP, Routen, CNI, kubelet‑Status, Servicegesundheit prüfen.
6. Schrittweises Ausrollen und Monitoring: Metriken beobachten, Alerts auf definierte Muster.

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"

Dieses Script ist bewusst einfach; erweitern Sie es um Prometheus‑Checks, eine API‑Abfrage an kube‑apiserver oder Test‑Pods, wenn Sie es in CI/CD integrieren.

Kubernetes‑spezifische Details und Fallstricke

Kubernetes macht Netzwerkänderungen direkt sichtbar: Pods verlieren Connectivity, CNI‑Plug‑Ins können neu initialisieren und kubelet prüft Hostnetzwerkbedingungen. Spezielle Hinweise:

• Drain und uncordon: Vor größeren Netzwerkänderungen immer drainen (kubectl drain) und nach Validierung uncordonieren.
• DaemonSets berücksichtigen: CNI‑Daemons laufen auf jedem Node; verwalten Sie Update‑Sequenzen so, dass CNI nicht gleichzeitig neu startet.
• IP‑Masquerade und Forwarding: Prüfen Sie iptables/nftables Regeln, da NM gelegentlich Firewall‑Beziehungen anpassen kann.

# 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

Konfigurieren Sie Monitoring so, dass nicht jeder Flap ein Pager auslöst. Beispiele für relevante Metriken:

• Interface flaps pro Host in 10 Minuten (>5 → Warnung).
• DHCP‑Renewals pro MAC (>3 in 5 Minuten → Indikator für konkurrierende Clients).
• Kubernetes Node NotReady Events nach Netzwerkänderungen (kritisch).
• Service Restart Loops für NetworkManager oder systemd‑networkd (auf Host‑Level alarmieren).

Typische Edge‑Cases und wie Sie sie lösen

Einige Probleme treten nur unter bestimmten Bedingungen auf — hier die gängigsten:

• Provider‑Images: Cloud‑Images haben manchmal vorkonfigurierte NetworkManager‑Profile. Prüfen und reinigen Sie diese vor dem Rollout.
• Persistent‑Interface‑Naming: Udev/Hardware‑Änderungen können Namen wechseln. Verwenden Sie lieber MAC‑basierte Matches in Netplan oder .network, wenn Sie Gefahr sehen.
• VLANs, Bridge und Bonding: NetworkManager und networkd unterscheiden sich in Syntax und Verhalten; testen Sie Bonding‑Failover und LACP in Testumgebung.

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

Ein Rollback dauert oft länger als die Änderung. Legen Sie folgende Artefakte bereit:

• Backups: /root/netcfg-backups mit eindeutigen Timestamps.
• Rollback‑Skripte: Automatisierte Schritte, die Dateien wiederherstellen und Dienste neu starten.
• Out‑of‑Band‑Zugang und Testplan: Was wird gemessen, um Erfolg zu bestätigen?

# 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

• Definieren Sie für jede Hostgruppe eine klare Renderer‑Policy und halten Sie sie in CM/GitOps fest.
• Nutzen Sie netplan try bei kritischen Hosts, um automatisch zurückzurollen, falls Netzverlust eintritt.
• Schützen Sie CNI‑Interfaces per unmanaged-devices, bevor Sie NetworkManager erlauben.
• Testen Sie alle Änderungen in einer Staging‑Umgebung inklusive Node‑Drains für Kubernetes.
• Implementieren Sie automatische Validations und Alerts, die auf Muster und nicht auf Einzelereignisse reagieren.

Fazit

Netplan vs. NetworkManager ist in der Praxis eine Frage der Disziplin: Ein guter Betrieb führt zu einer Single Source of Truth, schützt CNI‑Devices, automatisiert Validations und behält einen getesteten Rollback‑Plan. Technische Maßnahmen (Netplan‑Renderer, unmanaged‑devices, Node‑Drain) zusammen mit organisatorischen Vorgaben (Hostgruppen, Change‑Windows, Out‑of‑Band‑Zugriff) minimieren Risiko und halten Netzwerke wartbar. Planen Sie Ihre Migration phasenweise, dokumentieren Sie Entscheidungen und messen Sie die Auswirkungen automatisiert — so bleibt Ihr Netzwerk zuverlässig und reproduzierbar.

Netplan vs. NetworkManager: Integrations-, Sicherheits- und Drift‑Strategien

Zusätzlich zur Renderer‑Policy sollten Sie drei operative Ebenen adressieren: Integration in Konfigurationsmanagement/GitOps, Audit und Härtung gegen ungewollte Laufzeitänderungen sowie sichere Test‑ und Validierungsverfahren. Diese Aspekte verhindern, dass Konfigurationsdrift, unautorisierte D‑Bus‑Änderungen oder Provider‑Agenten Ihre Netzwerk‑Topologie unterlaufen.

Konfigurations‑Drift proaktiv erkennen und beheben

Vertrauen Sie nicht darauf, dass Dateien in /etc automatisch mit Ihrem Git‑Repo übereinstimmen. Ein kurzer, automatisierbarer Prüfjob erkennt Abweichungen und kann bei Bedarf eine genehmigte Konfiguration wiederherstellen oder eine Alarmierung auslösen.

#!/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"

Solche Jobs laufen als Cron, systemd‑timer oder in der CI/CD‑Pipeline. Entscheiden Sie, ob automatische Korrektur (git checkout) oder nur Alerting erfolgen soll — beides hat Vor‑ und Nachteile im Hinblick auf Change‑Control.

Sicherheitsaspekte: D‑Bus, PolicyKit und Service‑Lockdown

NetworkManager exponiert Steuerfunktionen über D‑Bus; das erleichtert API‑gesteuerte Änderungen, eröffnet aber Angriffsflächen. Beschränken Sie Netzwerkänderungen durch PolicyKit‑Regeln, enge Dateirechte und, wo sinnvoll, Service‑Maskierung.

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

Für audit‑fähige Umgebungen protokollieren Sie alle Änderungen an /etc/netplan und die D‑Bus‑Aufrufe (auditd oder journald mit Feldfiltern). So haben Sie eine nachvollziehbare Änderungs‑Kette für Compliance und Post‑Mortem.

Sandbox‑Tests mit Netzwerk‑Namespaces

Bevor Sie Regeln produktiv anwenden, simulieren Sie Verhalten isoliert mit veth‑Pairs und netns. So können Sie DHCP, VLANs oder Routing‑Policy prüfen, ohne Host‑Interfaces zu stören.

# 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

Automatisierung: idempotente Tasks und Preflight‑Checks

Nutzen Sie in Ansible oder Ihrem CM idempotente Module/Tasks und ergänzen Sie Preflight‑Checks, die Kernel‑State validieren (ip addr, ip route, CNI‑Bridges). Führen Sie Änderungen nur, wenn alle Preflights erfolgreich sind; andernfalls abbrechen und Alarm auslösen.

# 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

Fassen Sie Integration, Sicherheit und Testautomatisierung zusammen: Nur so erreichen Sie reproduzierbare Netzwerkkonfigurationen, vermeiden unerwartete Änderungen durch Dritte (Provider‑Agents, Nutzerprozesse) und behalten die Kontrolle über Netplan vs. NetworkManager im Tagesbetrieb.

Für dieses Thema sind auch Netplan Renderer und Networkmanager Konflikt wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.