Entscheidungskriterien
Die Auswahl des besten Netzwerk-Plug-Ins für Ihren Anwendungsfall hängt von Ihren Kriterien ab. Jede Option hat ihre eigenen Vor- und Nachteile, und bei der Auswahl sollten Kompromisse in Betracht gezogen werden.
Entscheidungskriterien auf hoher Ebene
IPv4-Erschöpfung
Bei der Entwicklung von kubenet wurde auf die Schonung des IP-Adressraums geachtet. Azure CNI bietet Pods mit vollständiger Netzwerkkonnektivität, erfordert jedoch einen größeren IP-Adressraum und mehr Planung. IPv4-Erschöpfung ist der Zeitpunkt, an dem die Anzahl der Adressen den Grenzwert erreicht und Knoten von einem Skalierungs- oder Upgradevorgang abhält. Während der Erschöpfung erfordert Ihre Anwendung zu viele Ressourcen und schafft es nicht, mitzuhalten.
Mit kubenet können die Knoten definierte IP-Adressen empfangen, ohne dass vorab eine große Anzahl von IP-Adressen für alle möglichen Pods reserviert werden muss, die im Cluster ausgeführt werden könnten. Mit kubenet machen Sie sich weniger Gedanken über die IPv4-Erschöpfung und behandeln einen kleinen IP-Adressbereich für große Clusterunterstützung und Anwendungsanforderungen.
Die folgenden grundlegenden Berechnungen vergleichen den Adressraum in den Netzwerkmodellen:
- kubenet: Ein einfacher /24-IP-Adressbereich kann bis zu 251 Knoten im Cluster unterstützen (jedes Subnetz eines virtuellen Azure-Netzwerks reserviert die ersten drei IP-Adressen für Verwaltungsvorgänge). Diese Knotenanzahl könnte bis zu 27.610 Pods unterstützen (mit standardmäßig maximal 110 Pods pro Knoten mit kubenet).
- Azure CNI: derselbe grundlegende /24-Subnetzadressbereich könnte nur maximal 8 Knoten im Cluster unterstützen. Diese Knotenanzahl könnte nur bis zu 240 Pods unterstützen (mit standardmäßig maximal 30 Pods pro Knoten mit Azure CNI).
Clustergröße
Kubenet verfügt über maximal 400 Knoten pro Cluster, während Azure CNI von der Konfiguration des Plug-Ins abhängig ist.
Konnektivität
In kubenet müssen Sie benutzerdefinierten Routen (UDRs) manuell verwalten und warten. Um Pods von außerhalb des Clusters zu erreichen, muss ein Lastenausgleich verwendet werden. Pods erhalten mit Azure CNI vollständige VM-Konnektivität und können direkt über die private IP-Adresse aus verbundenen Netzwerken erreicht werden.
Unterstützung für mehrere Cluster
In kubenet können mehrere Cluster nicht das gleiche Knotensubnetz verwenden. Mit Azure CNI ist diese Konfiguration möglich.
Latency
Im Vergleich zu Azure CNI benötigt kubenet einen zusätzlichen Hop, der zu einer geringfügigen Wartezeit führen kann. Wartezeitempfindliche Workloads sollten auf Clustern mithilfe von Azure CNI bereitgestellt werden.
Zusätzliche Funktionen
Azure CNI unterstützt komplexe Netzwerktopologien mit Azure CNI-Netzwerken, z. B. virtuelle Knoten oder Azure-Netzwerkrichtlinien.
Diese zusätzlichen Funktionen sind:
- Subnetz pro Knotenpool
- Dynamische Zuordnung von IPs
- Knoten- und Pod-Subnetzzuordnungen
Verhaltensunterschiede zwischen kubenet und Azure CNI
Zusätzlich zu den Kriterien auf hoher Ebene gibt es viele Verhaltensunterschiede und Abweichungen bei der Featureunterstützung:
| Funktion | Kubenet | Azure CNI | Azure CNI Overlay | Azure CNI Powered by Cilium |
|---|---|---|---|---|
| Bereitstellen von Clustern in vorhandenen oder neuen virtuellen Netzwerken | Unterstützt – benutzerdefinierte Routen werden manuell angewandt. | Unterstützt | Unterstützt | Unterstützt |
| Pod-Pod-Konnektivität | Unterstützt | Unterstützt | Unterstützt | Unterstützt |
| Pod-VM-Konnektivität; VM im gleichen virtuellen Netzwerk | Funktioniert, wenn vom Pod initiiert | Funktioniert in beide Richtungen | Funktioniert, wenn vom Pod initiiert | Funktioniert, wenn vom Pod initiiert |
| Pod-VM-Konnektivität; VM in virtuellem Peernetzwerk | Funktioniert, wenn vom Pod initiiert | Funktioniert in beide Richtungen | Funktioniert, wenn vom Pod initiiert | Funktioniert, wenn vom Pod initiiert |
| Lokaler Zugriff per VPN oder ExpressRoute | Funktioniert, wenn vom Pod initiiert | Funktioniert in beide Richtungen | Funktioniert, wenn vom Pod initiiert | Funktioniert, wenn vom Pod initiiert |
| Zugriff auf Ressourcen, die von Dienstendpunkten geschützt werden | Unterstützt | Unterstützt | Unterstützt | |
| Zugriff auf Ressourcen, die von privaten Endpunkten verfügbar gemacht werden | Unterstützt | Unterstützt | ||
| Verfügbarmachen von Kubernetes-Diensten über einen Lastenausgleichsdienst, App Gateway oder einen Eingangscontroller | Unterstützt | Unterstützt | Unterstützt | Dieselben Einschränkungen gelten bei Verwendung des Überlagerungsmodus |
| Standard: Azure DNS und private Zonen | Unterstützt | Unterstützt | Unterstützt | |
| Unterstützung für Windows Knotenpools | Nicht unterstützt | Unterstützt | Unterstützt | Nur für Linux verfügbar |
| Virtuelle Knoten | Nicht unterstützt | Unterstützt | Nicht unterstützt | |
| Mehrere Cluster, die ein Subnetz gemeinsam nutzen | Nicht unterstützt | Unterstützt | Unterstützt | |
| Unterstützte Netzwerkrichtlinien | Calico | Calico und Azure-Netzwerkrichtlinien | Calico, Azure-Netzwerkrichtlinien, Cilium | Ciliuim |