CNI-Plugin – Wie Kubernetes das Pod-Netzwerk realisiert

Ein CNI-Plugin (Container Network Interface) ist die Kubernetes-Komponente, die für mich das Netzwerk meiner Pods bereitstellt. Ohne ein CNI-Plugin könnten Pods weder IP-Adressen erhalten noch miteinander oder mit Services kommunizieren.

Kubernetes selbst bringt kein eigenes Netzwerk mit. Stattdessen definiert es mit CNI eine Standardschnittstelle, über die verschiedene Netzwerk-Lösungen eingebunden werden können.

Wo wird ein CNI-Plugin betrieben?

Ein CNI-Plugin wird auf allen Worker Nodes meines Kubernetes-Clusters betrieben. Technisch läuft es meist als:

  • DaemonSet-Pod auf jeder Node
  • lokale Binärdateien unter /opt/cni/bin
  • Netzwerk-Konfigurationen unter /etc/cni/net.d

kubelet ruft das CNI-Plugin immer dann auf, wenn für mich ein Pod gestartet oder beendet wird. Die Control Plane greift dabei nicht direkt ins Netzwerk ein.

Was macht ein CNI-Plugin konkret?

Für mich übernimmt ein CNI-Plugin folgende Kernaufgaben:

  • Vergabe einer eindeutigen Pod-IP
  • Einbindung des Pods ins Cluster-Netzwerk
  • Routing zwischen Pods auf verschiedenen Nodes
  • Optional: Network Policies und Security-Regeln

Wichtig für mein Kubernetes-Verständnis: Jeder Pod erhält eine eigene IP-Adresse und kann andere Pods direkt erreichen – ohne NAT.

Wie funktioniert ein CNI-Plugin technisch?

Der Ablauf ist für mich klar definiert:

  1. Ich erstelle einen Pod über die Kubernetes API
  2. kubelet startet den Pod auf einer Worker Node
  3. kubelet ruft das CNI-Plugin auf
  4. Das Plugin erstellt Netzwerk-Interfaces
  5. Der Pod erhält eine IP-Adresse
  6. Routing-Regeln werden gesetzt

Beim Löschen eines Pods wird derselbe Prozess rückwärts ausgeführt, damit IPs und Netzwerkressourcen wieder freigegeben werden.

Bekannte CNI-Plugins

Kubernetes unterstützt viele unterschiedliche CNI-Implementierungen. Häufig genutzte sind:

  • Calico – Netzwerk + Network Policies
  • Cilium – eBPF-basiertes High-Performance-Netzwerk
  • Flannel – einfaches Overlay-Netzwerk
  • Weave Net – Mesh-basiertes Pod-Netzwerk

Welches Plugin ich nutze, entscheidet über Performance, Sicherheit und Funktionsumfang meines Clusters.

Was ein CNI-Plugin nicht macht

  • Es startet keine Container (das macht die Container Runtime)
  • Es plant keine Pods auf Nodes (das macht der Scheduler)
  • Es ersetzt keinen Ingress oder LoadBalancer

Fazit

Ein CNI-Plugin ist für mich die zentrale Netzwerk-Komponente auf jeder Kubernetes-Worker-Node. Es sorgt dafür, dass Pods IP-Adressen erhalten, miteinander kommunizieren können und mein Cluster als ein zusammenhängendes Netzwerk funktioniert. Ohne CNI gäbe es kein funktionierendes Kubernetes-Netzwerk.

Nach oben scrollen