antrea-io/antrea: Kubernetes-Vernetzung auf Open vSwitch
Antrea ist ein Open-Source-Kubernetes-Netzwerk- und Sicherheitsprojekt, das auf Open vSwitch basiert und Pod-Netzwerke, Richtliniendurchsetzung, Observability-Integration und Gateway-Kontrollen für Produktionscluster bereitstellt.
Auf einen Blick
- Was ist das?
- Das Projekt antrea-io/antrea verbindet Pod-Vernetzung, Richtliniendurchsetzung und Beobachtbarkeit in einem CNI, dessen Datenpfad vollständig auf Open vSwitch beruht.
- Für wen ist es gedacht?
- Antrea passt zu Betreibern, die einen Datenpfad auf Open-vSwitch-Basis einsetzen wollen und von einem erweiterten Richtlinienmodell, Windows-Knoten und Multi-Cluster-Verbund profitieren. Es passt weniger zu Umgebungen, in denen das Open-vSwitch-Kernelmodul auf jedem Knoten nicht verfügbar ist, etwa bei gehärteten oder unveränderlichen Betriebssystemimages, und zu sehr kleinen Clustern, die den Betrieb eines zusätzlichen Controllers nicht tragen.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Go, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Was antrea-io/antrea mit Open vSwitch als Datenpfad tut
Antrea aus dem Repository antrea-io/antrea wird als Kubernetes-Vernetzungslösung beschrieben, die ausdrücklich Kubernetes-nativ sein will. Sie arbeitet auf Schicht 3 und 4 und erbringt Vernetzungs- und Sicherheitsdienste für einen Cluster, wobei Open vSwitch als Datenpfad genutzt wird. Als Hauptsprache ist Go eingetragen, die Lizenz ist Apache-2.0, die Projektseite liegt unter antrea.io.
Die Wahl des Datenpfads prägt das gesamte Projekt. Laut README setzt Antrea Open vSwitch für sämtliche Netzwerkfunktionen ein, einschließlich der Lastverteilung für Kubernetes-Services, und nutzt dessen Hardware-Offloading-Fähigkeiten für anspruchsvolle Arbeitslasten. Für Kubernetes-Network-Policies ergebe sich daraus eine sehr effiziente Umsetzung.
Zum Erhebungszeitpunkt verzeichnet das Repository 1.808 Sterne, 492 Forks und 199 offene Issues, Standard-Branch ist main. Als letzte Veröffentlichungen sind v2.7.0, v2.6.3 und v2.5.3 eingetragen, alle mit Datum vom 15. August 2026. Eine Liste von Anwendern führt das Projekt in der Datei ADOPTERS.md, die Planung in ROADMAP.md.
Voraussetzungen: Kubernetes 1.23, NodeIPAMController und das OVS-Kernelmodul
Die Einstiegshürden sind im README benannt und lassen sich vor einer Installation prüfen. Getestet wurde Antrea mit Clustern ab Kubernetes-Version 1.23. Auf jedem Knoten muss das Open-vSwitch-Kernelmodul vorhanden sein, was bei stark angepassten oder schreibgeschützten Images der erste Prüfpunkt ist.
Für die Adressvergabe gibt es zwei Wege. Entweder ist NodeIPAMController im Cluster aktiviert, oder die NodeIPAM-Funktion des Antrea-Controllers wird aktiviert und konfiguriert. Wer einen Cluster mit kubeadm aufbaut, muss laut README die Option --pod-network-cidr mit einem CIDR-Bereich angeben.
Zur Installation selbst ist das README knapp. Es nennt als Merkmal die Ausbringung über eine einzige YAML-Manifestdatei und verweist für die konkreten Schritte auf docs/getting-started.md. Einen direkt kopierbaren Befehl enthält die README nicht, diese Angabe fehlt dort. Für die Architektur verweist das Projekt auf docs/design/architecture.md, die Liste der Neuerungen je Version liegt in CHANGELOG/README.md.
Richtlinienmodell mit Tiering, Regelprioritäten und Node Policies
Über die Standard-Network-Policies von Kubernetes hinaus beschreibt das README ein erweitertes Modell. Es baut auf Kubernetes-Network-Policies auf und ergänzt Ebenenbildung für Richtlinien, Prioritäten für einzelne Regeln, clusterweite Richtlinien sowie Richtlinien für Knoten.
Der praktische Nutzen dieser Ergänzungen liegt in der Reihenfolge. Wo mehrere Richtlinien gleichzeitig greifen, erlaubt die Ebenenbildung eine feste Rangfolge, und Regelprioritäten lösen Konflikte innerhalb einer Ebene. Clusterweite Richtlinien adressieren Fälle, die nicht an einen einzelnen Namespace gebunden sind, während Node Policies den Verkehr von und zu Knoten selbst regeln. Die vollständige Übersicht liegt in docs/antrea-network-policy.md.
Für Verschlüsselung nennt das README IPsec- oder WireGuard-Tunnel für den Pod-Verkehr zwischen Knoten. Die Auswahl zwischen beiden wird im README nicht begründet, entsprechende Angaben zu Leistung oder Empfehlungen fehlen. Auch hier gilt, dass die README keine Vergleichswerte liefert, eine Entscheidung also anhand eigener Messungen im Zielnetz getroffen werden muss.
Multi-Cluster-Verbund, Windows-Knoten und Nephe für virtuelle Maschinen
Über den Einzelcluster hinaus bietet Antrea laut README einen Verbund mehrerer Cluster mit einheitlichem Datenpfad, einschließlich clusterübergreifender Services, sowie eine einheitliche Sicherheitshaltung. Der Einstieg wird in docs/multicluster/user-guide.md beschrieben.
Ein zweiter Punkt betrifft gemischte Knotenlandschaften. Dank der Portabilität von Open vSwitch kann Antrea dieselbe Datenpfadimplementierung auf Linux- und auf Windows-Knoten verwenden. Für Umgebungen mit Windows-Containern ist das ein starkes Argument, weil kein zweiter Netzwerkstack gepflegt werden muss.
Drittens reichen die Antrea-eigenen Richtlinien über Kubernetes hinaus. Sie können auf Nicht-Kubernetes-Knoten durchgesetzt werden, also auf virtuellen Maschinen und auf Bare-Metal-Servern. Das Projekt Nephe unter antrea-io/nephe setzt darauf auf und implementiert Sicherheitsrichtlinien für virtuelle Maschinen über mehrere Clouds hinweg. Zum Betriebsmodus von Windows-Knoten oder zur Leistung des Multi-Cluster-Verbunds macht das README keine Messwerte, Details verbleiben in den verlinkten Anleitungen.
Fehlersuche mit Paketverfolgung und Beobachtbarkeit über Theia
Für den Betrieb stellt das README eine eigene Werkzeuggruppe heraus. Es gibt Kommandozeilen- und Oberflächenwerkzeuge, die Sicht und Diagnose liefern, konkret Paketverfolgung, Richtlinienanalyse und Flussinspektion. Ergänzend werden Prometheus-Metriken bereitgestellt, und Netzwerkflussinformationen lassen sich an Sammler und Analysatoren exportieren.
Diese drei Sichten greifen ineinander. Die Flussinspektion zeigt, welche Verbindungen tatsächlich laufen, die Richtlinienanalyse ordnet sie den geltenden Regeln zu, und die Paketverfolgung klärt den Einzelfall, wenn eine Verbindung unerwartet blockiert wird. Gerade beim Einführen eines neuen Richtlinienmodells mit Ebenen und Prioritäten ist diese Kombination der Teil, der die meiste Zeit spart.
Für die Auswertung über längere Zeiträume verweist das README auf Theia im Repository antrea-io/theia für feinteilige Sicht auf die Kommunikation zwischen Arbeitslasten. Theia stellt Antrea-Flüsse in Grafana-Dashboards dar und schlägt Network Policies zur Absicherung vor. Ob die vorgeschlagenen Regeln zur eigenen Umgebung passen, bleibt eine Prüfaufgabe, allgemeine Aussagen zur Trefferqualität enthält das README nicht.
Abgrenzung zu einem CNI ohne Open vSwitch, etwa Cilium
Der wichtigste Unterschied zu Alternativen liegt in der Abhängigkeit, die das README selbst nennt: Auf jedem Kubernetes-Knoten muss das Open-vSwitch-Kernelmodul vorhanden sein. Wer einen Datenpfad auf anderer technischer Grundlage sucht, etwa Cilium, entfällt diese Voraussetzung, und damit auch die Möglichkeit, Hardware-Offloading über Open vSwitch zu nutzen, das Antrea ausdrücklich als Merkmal führt.
Innerhalb von Antrea selbst gibt es eine zweite Entscheidung, die ähnlich weit reicht. Das README nennt als Merkmal, in privaten Clouds, öffentlichen Clouds und auf Bare Metal laufen zu können und den Verkehrsmodus passend zur Infrastruktur zu wählen, also mit oder ohne Overlay. Ohne Overlay entfällt die Kapselung, dafür müssen die unterliegenden Netze die Pod-Adressen routen. Das ist kein Ersatz für einen Produktvergleich, aber die Wahl mit dem größten Einfluss auf Durchsatz und Fehlersuche.
Wer die Entscheidung praktisch vorbereiten will, kann bei Antrea mit einem Prüfpunkt beginnen, der sich aus dem README ableiten lässt: Ist das Kernelmodul geladen und ist NodeIPAMController aktiv, kommt die Installation über das einzelne YAML-Manifest aus docs/getting-started.md in Frage. Scheitert einer der beiden Punkte, etwa weil die Knotenimages kein modifizierbares Kernelmodul erlauben, ist ein Datenpfad ohne Open vSwitch die belastbarere Richtung.
Redaktionelles Fazit
Antrea passt zu Betreibern, die einen Datenpfad auf Open-vSwitch-Basis einsetzen wollen und von einem erweiterten Richtlinienmodell, Windows-Knoten und Multi-Cluster-Verbund profitieren. Es passt weniger zu Umgebungen, in denen das Open-vSwitch-Kernelmodul auf jedem Knoten nicht verfügbar ist, etwa bei gehärteten oder unveränderlichen Betriebssystemimages, und zu sehr kleinen Clustern, die den Betrieb eines zusätzlichen Controllers nicht tragen. Vor der Installation sollte geprüft werden, ob NodeIPAMController aktiv ist oder alternativ die NodeIPAM-Funktion des Antrea-Controllers konfiguriert wird, und ob die beteiligten Images das Kernelmodul mitbringen. Wer ohne OVS-Abhängigkeit auskommen muss, sucht besser bei einem Datenpfad auf anderer Grundlage.
Community-Notizen