Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Wählen Sie eine Pod-Netzwerkkonfiguration basierend darauf aus, ob Pods direkten IP-Zugriff über verbundene Netzwerke und Ihre IP-Adressskalaanforderungen benötigen.
Benötigen Sie direkten Pod-IP-Zugriff?
Das Pod-Netzwerk steuert, wie Pods IP-Adressen erhalten, und definiert, wie Pods miteinander, mit Clusterknoten und mit Zielen außerhalb des Clusters kommunizieren. Kubernetes implementiert Pod-Netzwerke über ein CNI-Plug-In (Container Network Interface ), das Pod-IP-Adressen und Netzwerkkonnektivität verwaltet.
Beim Einrichten von Pod-Netzwerken müssen Sie die IP-Adressverwaltung (IPAM) und Routing und Transport (Data Plane) planen.
Wenn Ihre Workloads pods benötigen, um von privaten IP-Adressen aus mit dem Azure Kubernetes Service (AKS) Cluster-VNet verbundenen Netzwerken erreichbar zu sein, verwenden Sie ein Flat Networking-Modell. Verwenden Sie andernfalls Azure CNI Overlay.
IP-Adressverwaltungsoptionen (IPAM)
Beim Einrichten von IPAM können Sie zwischen einem Overlay-Netzwerkmodell mit Azure CNI Overlay und einem flachen Netzwerkmodell mit Azure CNI Pod Subnet oder Azure CNI Node Subnet wählen:
In der folgenden Tabelle werden die ipAM-Optionen verglichen, die für AKS-Pod-Netzwerke verfügbar sind, einschließlich ihrer wichtigsten Features und Skalierungsgrenzwerte.
| IPAM-Optionen | Diagramm der Netzwerkkomponenten | Merkmale und Funktionen |
|---|---|---|
| Overlay-Netzwerkmodell (mit Azure CNI-Overlay) |
|
• Pod-IPs stammen aus einem Überlagerungsbereich, der nicht Teil des VNet-Raums ist. • Hochskalierbares Netzwerk mit bis zu 5.000 Knoten und 200.000 Pods pro Cluster. Die Knoten-Grenzwerte, die Pod-Grenzwerte pro Knoten und die aggregierten Pod-Grenzwerte sind unabhängig. • Der Overlay-Adressraum für Pods kann über unabhängige Cluster hinweg wiederverwendet werden. Die Pod-CIDR darf sich nicht mit direkt verbundenen Netzwerken überschneiden, einschließlich gekoppelter VNets, über ExpressRoute oder ein VPN verbundener Netzwerke und anderer Routen, die privaten Adressraum offenlegen. • Unterstützung von Dual-Stack (IPv4/IPv6). • Auf Pods kann nicht direkt von außerhalb des Clusters zugegriffen werden. |
| Flaches Netzwerkmodell (mit Azure CNI Pod-Subnetz oder Knotensubnetz) |
|
• Knoten- und Pod-IPs stammen aus dem VNet-Raum. • Pods können über ihre privaten IP-Adressen aus verbundenen Netzwerken aufgerufen werden. Azure CNI Pod Subnet behält die Pod-Quell-IP über verbundene VNets hinweg bei, während für Ziele außerhalb des Cluster-VNets die Quell-IP des Knotens mit Azure CNI Node Subnet verwendet wird. • Azure CNI Pod Subnet-Optionen umfassen dynamische IP-Zuordnung für Effizienz oder statische Blockzuordnung für skalierung. |
Überlegungen zu Flat Networking Model-Optionen
Beachten Sie bei der Entscheidung zwischen Azure CNI Pod Subnet mit dynamischer IP-Zuordnung, Azure CNI Pod Subnetz mit statischer Blockzuweisung und Azure CNI-Knoten-Subnetz die folgenden Überlegungen:
| Option „Flat Networking Model“ | Überlegungen |
|---|---|
| Azure CNI Pod Subnet mit dynamischer IP-Zuordnung | • Erfordert separate Knoten- und Pod-Subnetze, die Sie unabhängig voneinander dimensionieren und skalieren können. • Weist den Knoten Pod-IP-Adressen aus dem Pod-Subnetz in Gruppen zu je 16 zu. • Vorbehaltlich der von VNet konfigurierten grenzwerte für private IP-Adressen. |
| Azure CNI-Pod-Subnetz mit statischer Blockzuweisung | • Erfordert eine sorgfältige Planung, da Sie einen bestimmten Bereich von IPs für Ihre Pods zuordnen und sicherstellen müssen, dass sie nicht mit anderen Subnetzen überlappen. • Kann bis zu 1.000.000 IPs abrufen. • IPs werden möglicherweise nicht so effizient verwendet, was zu Einer Verschwendung führen könnte. |
| Azure-CNI-Knoten-Subnetz | • Legacyoption, die ein von AKS verwaltetes VNet oder ein vom Kunden verwaltetes VNet und Subnetz verwenden kann. • Knoten und Pods teilen das Knotensubnetz, daher müssen Sie die Kapazität im Voraus für Knoten, Pods, Skalierung und Upgrades planen. • Vorbehaltlich der von VNet konfigurierten grenzwerte für private IP-Adressen. |
Routing- und Transportoptionen (Datenebene)
Beim Einrichten Ihrer Datenebene können Sie zwischen Azure CNI Powered by Cilium, Azure iptables Data Plane und BYO CNI wählen:
In der folgenden Tabelle werden die Für AKS-Pod-Netzwerke verfügbaren Datenebenenoptionen und ihre wichtigsten Funktionen verglichen.
| Datenebenenoptionen | Merkmale und Funktionen |
|---|---|
| Azure CNI unterstützt von Cilium | • Verbesserte Skalierung und Leistung für Linux-Knotenpools. Windows-Knotenpools werden nicht unterstützt. • Integrierte Erzwingung von Cilium-Netzwerkrichtlinien. • FQDN-Filterung erfordert Advanced Container Networking Services und Kubernetes 1.29 oder höher. |
| Azure iptables | • Verwenden Sie Calico für Windows Durchsetzung von Netzwerkrichtlinien. Azure Netzwerkrichtlinien-Manager (NPM)-Support endet am 30. September 2026 für Windows und den 30. September 2028 für Linux. Neue Abonnements können Azure NPM nicht mehr aktivieren. • Verwenden Sie für Linux-Cluster Azure CNI Powered by Cilium anstelle von Azure NPM. • Unterstützt Kubernetes NetworkPolicy. |
| BYO CNI | • Kein verwaltetes CNI-Plug-In installiert - Sie können jede Option verwenden, die AKS unterstützt. • CNI-bezogene Probleme werden von Microsoft nicht unterstützt. |
Empfehlungen für AKS-Podnetzwerke
Unsere allgemeine Empfehlung ist die Verwendung von Azure CNI Overlay. Wenn Sie direkten Pod-IP-Zugriff von verbundenen Netzwerken benötigen und über Effizienz- oder Skalierungsanforderungen verfügen, sollten Sie Azure CNI-Pod-Subnetz mit dynamischer IP-Zuordnung oder Azure CNI-Pod-Subnetz mit statischer Blockzuordnung verwenden. Azure CNI-Knoten-Subnetz ist eine Legacyoption. Verwenden Sie sie im Allgemeinen nur, wenn Sie ein von AKS verwaltetes VNet für Ihren Cluster benötigen.