Netplan vs. NetworkManager: rilevare conflitti e imporre una configurazione di rete coerente

Netplan vs. NetworkManager non è una questione accademica, ma un rischio operativo: quando due componenti cercano di controllare le stesse risorse di rete seguono interruzioni, assegnazioni IP incoerenti e problemi per servizi come Kubernetes. Questa guida è rivolta ad amministratori, System Engineer e operatori e spiega in passaggi pratici come rilevare i conflitti, far rispettare una chiara renderer‑policy, migrare in sicurezza i nodi Kubernetes, impostare validazioni automatizzate e preparare rollback rapidi.

Perché la renderer‑policy è così importante

Netplan è un frontend dichiarativo: file YAML sotto /etc/netplan descrivono la topologia di rete desiderata. Netplan traduce queste specifiche a runtime in file di configurazione per un renderer. I renderer sono i manager effettivi — tipicamente systemd-networkd (spesso abbreviato in networkd) o NetworkManager. NetworkManager è un daemon persistente con proprio stato e propria policy. Se l’organizzazione non ha una policy univoca, si generano race condition, perché netplan durante la distribuzione scrive la configurazione del renderer mentre NetworkManager gestisce le connessioni in parallelo o cloud‑init al boot applica nuove impostazioni.

Diagnosi: sistematica e non‑invasiva

Iniziate dai fatti: cosa è effettivamente configurato nel kernel in questo momento? Poi verificate quali manager sono attivi e come Netplan genera le impostazioni di runtime.

Comandi di base per stato e visibilità

ip -br link
ip -br addr
ip route show

Questa vista è indipendente da Netplan o NetworkManager e mostra lo stato corrente nel kernel.

Prospettiva dei manager

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 fornisce la prospettiva di NetworkManager, networkctl quella di systemd‑networkd. Contraddizioni qui sono un chiaro indicatore di controllo concorrente.

Sintomi e cause

Sintomi importanti e cause tipiche — spiegati brevemente:

• L’IP cambia dopo il riavvio: o più client DHCP sono attivi oppure cloud‑init imposta valori diversi al primo avvio.
• La route predefinita scompare: il renderer applica policy/metriche di routing diverse, oppure una connessione viene disattivata.
• Kubernetes Node NotReady: l’interfaccia CNI è stata ricreata o NetworkManager ha modificato bridge/bond. I plugin CNI si aspettano relazioni statiche sull’host.
• Log con „Device is already managed“: NetworkManager rileva un device che netplan intendeva assegnare a networkd.

Controlli concreti quando qualcosa va storto

Se le cause non sono ovvie, procedete in modo sequenziale:

1. Verificare tempi e sequenza: confrontare journalctl prima e dopo riavvii o modifiche di configurazione.
2. Osservare il traffico DHCP per individuare client paralleli.
3. Ispezionare la generazione di Netplan per vedere cosa viene effettivamente scritto nel renderer.

journalctl -b -u NetworkManager -u systemd-networkd --no-pager | sed -n '1,400p'
# Osservare DHCP e ARP (campione breve)
tcpdump -n -i ens3 arp or port 67 or port 68 -c 200
# Generare netplan senza applicarlo
netplan generate
ls -l /run/systemd/network /run/NetworkManager 2>/dev/null

Konfigurationsbeispiele: Wie Renderer kontrolliert wird

Netplan‑YAML definiisce il renderer in modo dichiarativo. Esempio: forzare networkd come renderer.

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

Dopo aver distribuito il file, utilizzate netplan generate e netplan apply. netplan generate mostra quali file verrebbero generati; netplan apply applica attivamente. Su host critici è utile netplan try — annulla automaticamente la modifica se non confermate entro il timeout.

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

NetworkManager: Keyfile‑Beispiel und unmanaged‑devices

NetworkManager utilizza file Keyfile per connessioni persistenti. Se NetworkManager deve restare attivo ma ignorare alcune interfacce CNI, create una configurazione 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

Questa voce impedisce a NetworkManager di gestire bridge/interfacce CNI — importante per Kubernetes.

systemd‑networkd: .network Beispiel

Se preferite networkd come renderer, i file .network possono essere usati per impostazioni host più granulari (di solito non necessario se Netplan genera tutto centralmente, ma utile per regole specifiche).

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

[Network]
DHCP=yes
IPv6AcceptRA=yes

[Route]
Gateway=192.0.2.1

Un file .network diretto viene letto da networkd; Netplan genera automaticamente tali file quando è impostato come renderer networkd.

Strategia di migrazione: sicura, graduale, reversibile

Nella transizione in ambienti di produzione è obbligatorio un approccio conservativo. Passi raccomandati:

1. Definire le policy: stabilire gruppi di host (p.es. k8s‑worker, db‑server, workstation) e i loro renderer.
2. Canary‑rollout: scegliere 1–3 nodi non critici come caso di prova.
3. Creare backup: salvare /etc/netplan, /etc/NetworkManager, configurazioni cloud‑init.
4. Finestra di manutenzione e accesso out‑of‑band: prevedere KVM/IPMI/console seriale.
5. Validazione automatizzata: verificare IP, rotte, CNI, stato di kubelet, salute dei servizi.
6. Distribuzione graduale e monitoring: monitorare metriche, allarmi per pattern definiti.

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"

Questo script è intenzionalmente semplice; estendetelo con controlli Prometheus, una chiamata API a kube‑apiserver o pod di test se lo integrate in CI/CD.

Dettagli specifici per Kubernetes e insidie

Kubernetes rende le modifiche di rete immediatamente visibili: i Pod perdono connettività, i CNI‑Plug‑Ins possono reinizializzarsi e kubelet verifica le condizioni della rete host. Indicazioni specifiche:

• Drain und uncordon: Prima di modifiche di rete importanti eseguire sempre il drain (kubectl drain) e dopo la validazione eseguire l’uncordon.
• DaemonSets berücksichtigen: i demoni CNI girano su ogni Node; gestite le sequenze di aggiornamento in modo che il CNI non si riavvii contemporaneamente.
• IP‑Masquerade und Forwarding: verificate le regole iptables/nftables, poiché NM occasionalmente può modificare le impostazioni del firewall.

# Procedura sicura di aggiornamento del Node (versione breve)
kubectl drain node01 --ignore-daemonsets --delete-local-data
# Applicare le modifiche
# Validazione: Pod CNI, kubelet, test di rete
kubectl uncordon node01

Monitoring: Metriken, Alerts und sinnvolle Thresholds

Configurate il monitoring in modo che non ogni flap generi un pager. Esempi di metriche rilevanti:

• Flap delle interfacce per host in 10 minuti (>5 → avviso).
• Rinnovi DHCP per MAC (>3 in 5 minuti → indicatore di client concorrenti).
• Eventi Kubernetes Node NotReady dopo modifiche di rete (critico).
• Loop di riavvio dei servizi per NetworkManager o systemd‑networkd (allarmare a livello host).

Typische Edge‑Cases und wie Sie sie lösen

Alcuni problemi si manifestano solo in condizioni particolari — qui i più comuni:

• Provider‑Images: le immagini cloud a volte hanno profili NetworkManager preconfigurati. Verificate e ripulite questi profili prima del rollout.
• Persistent‑Interface‑Naming: modifiche a udev/hardware possono cambiare i nomi. Preferite match basati su MAC in Netplan o .network se prevedete rischio.
• VLANs, Bridge und Bonding: NetworkManager e networkd differiscono per sintassi e comportamento; testate il failover di bonding e LACP in ambiente di 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 spesso richiede più tempo della modifica. Preparate i seguenti artefatti:

• Backups: /root/netcfg-backups con timestamp univoci.
• Rollback‑Skripte: script di rollback automatizzati che ripristinano file e riavviano i servizi.
• Out‑of‑Band‑Zugang und Testplan: accesso out-of-band e piano di test: cosa viene misurato per confermare il successo?

# Backup (prima di effettuare le modifiche)
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

• Definite per ogni gruppo di host una chiara renderer‑policy e mantenetela in CM/GitOps.
• Usate netplan try sui host critici per effettuare un rollback automatico in caso di perdita di rete.
• Proteggete le interfacce CNI per mezzo di unmanaged-devices prima di abilitare NetworkManager.
• Testate tutte le modifiche in un ambiente di staging, inclusi i Node‑Drains per Kubernetes.
• Implementate validazioni e alert automatici che reagiscono a pattern e non a singoli eventi.

Fazit

Netplan vs. NetworkManager è nella pratica una questione di disciplina: un buon esercizio operativo conduce a una fonte unica di verità, protegge i dispositivi CNI, automatizza le validazioni e mantiene un piano di rollback testato. Misure tecniche (Netplan‑Renderer, unmanaged‑devices, Node‑Drain) insieme a direttive organizzative (gruppi di host, Change‑Windows, accesso fuori banda) minimizzano i rischi e mantengono le reti manutenibili. Pianificate la migrazione per fasi, documentate le decisioni e misurate gli effetti in modo automatizzato — così la vostra rete RESTerà affidabile e riproducibile.

Netplan vs. NetworkManager: strategie di integrazione, sicurezza e drift

Oltre alla policy del renderer dovRESTe affrontare tre livelli operativi: integrazione con il configuration management/GitOps, audit e indurimento contro modifiche non intenzionali in runtime e procedure di test e validazione sicure. Questi aspetti impediscono che la deriva di configurazione, modifiche non autorizzate via D‑Bus o agenti del provider compromettano la topologia di rete.

Rilevare e correggere proattivamente la deriva di configurazione

Non date per scontato che i file in /etc corrispondano automaticamente al vostro repo Git. Un breve lavoro di verifica automatizzabile individua le discrepanze e, se necessario, può ripristinare una configurazione approvata o generare un allarme.

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

Questi job vengono eseguiti come Cron, systemd‑timer o nella pipeline CI/CD. Decidete se attivare la correzione automatica (git checkout) o solo la segnalazione — entrambe le opzioni hanno pro e contro in termini di controllo delle modifiche.

Aspetti di sicurezza: D‑Bus, PolicyKit e lockdown dei servizi

NetworkManager espone funzioni di controllo tramite D‑Bus; ciò facilita le modifiche attraverso API ma apre anche superfici di attacco. Limitate le modifiche di rete tramite regole PolicyKit, permessi di file RESTrittivi e, quando opportuno, il mascheramento (masking) dei servizi.

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

Per ambienti con requisiti di audit registrate tutte le modifiche a /etc/netplan e le chiamate D‑Bus (auditd o journald con filtri di campo). In questo modo avrete una catena di modifiche verificabile per compliance e analisi post‑mortem.

Test in sandbox con namespace di rete

Prima di applicare regole in produzione, simulate il comportamento in isolamento con veth‑Pairs e netns. In questo modo potete verificare DHCP, VLAN o policy di routing senza disturbare le interfacce host.

# 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

Automazione: task idempotenti e controlli di preflight

Utilizzi in Ansible o nel suo CM moduli/task idempotenti e integri controlli preflight che convalidino lo stato del kernel (ip addr, ip route, CNI‑Bridges). Applichi le modifiche solo se tutti i preflight risultano positivi; altrimenti interrompa e generi un allarme.

# 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

Raggruppi integrazione, sicurezza e automazione dei test: solo così otterrà configurazioni di rete riproducibili, eviterà modifiche inattese da terzi (agent dei provider, processi utente) e manterrà il controllo tra Netplan e NetworkManager nell’operatività quotidiana.

Per questo ambito sono rilevanti anche i renderer di Netplan e i conflitti con NetworkManager. Il contributo inquadra questi aspetti in modo chiaro e indica cosa conta nella pratica quotidiana.