Legacy-CNI (Container Networking Interfaces) in AKS

2025-05-05

Von Bedeutung

Am 31. März 2028 wird kubenet Networking für Azure Kubernetes Service (AKS) eingestellt.

Um Dienstunterbrechungen zu vermeiden, müssen Sievor diesem Datumein Upgrade auf das Azure Container Networking Interface (CNI)-Overlay durchführen, wenn Workloads, die auf Kubenet für AKS ausgeführt werden, nicht mehr unterstützt werden.

Obwohl in Azure Kubernetes Service (AKS) die Azure CNI-Überlagerung und das Azure CNI-Podsubnetz für die meisten Szenarios empfohlen werden, sind ältere Netzwerkmodelle wie das Azure CNI-Knotensubnetz und Kubenet weiterhin verfügbar und werden unterstützt. Diese Legacymodelle bieten unterschiedliche Ansätze für die Pod-IP-Adressverwaltung und die Netztechnologie – jeweils mit eigenen Funktionen und Überlegungen. In diesem Artikel finden Sie eine Übersicht über diese Legacynetztechnologieoptionen, Details zu den Voraussetzungen, Bereitstellungsparametern und wichtigsten Merkmalen, die Ihnen helfen, ihre Rollen zu verstehen und wie sie in Ihren AKS-Clustern effektiv verwendet werden können.

Voraussetzungen

Die folgenden Voraussetzungen sind für das Azure CNI-Knoten-Subnetz erforderlich:

Das virtuelle Netzwerk des AKS-Clusters muss ausgehende Internetkonnektivität zulassen.
AKS-Cluster können 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16 oder 192.0.2.0/24 für den Adressbereich des Kubernetes-Diensts, den Adressbereich für den Pod oder den Adressbereich für das virtuelle Clusternetzwerk nicht verwenden.
Die vom AKS-Cluster verwendete Clusteridentität muss mindestens Berechtigungen Netzwerkmitwirkender für das Subnetz im virtuellen Netzwerk haben. Wenn Sie eine benutzerdefinierte Rolle anstelle der integrierten Rolle des Netzwerkmitwirkenden definieren möchten, sind die folgenden Berechtigungen erforderlich:
- Microsoft.Network/virtualNetworks/subnets/join/action
- Microsoft.Network/virtualNetworks/subnets/read
- Microsoft.Authorization/roleAssignments/write
Das Subnetz, das dem AKS-Knotenpool zugewiesen ist, darf kein delegiertes Subnetz sein.

AKS wendet keine Netzwerksicherheitsgruppen (NSGs) auf sein Subnetz an und ändert keine der NSGs, die diesem Subnetz zugeordnet sind. Wenn Sie Ihr eigenes Subnetz bereitstellen und NSGs hinzufügen, die diesem Subnetz zugeordnet sind, müssen Sie sicherstellen, dass die Sicherheitsregeln in den NSGs Datenverkehr im CIDR-Knotenbereich zulassen. Weitere Informationen finden Sie unter Netzwerksicherheitsgruppen.

Azure CNI-Knotensubnetz

Mit Azure Container Networking Interface (CNI) erhält jeder Pod eine IP-Adresse aus dem Subnetz, mit der direkt darauf zugegriffen werden kann. Systeme im gleichen virtuellen Netzwerk wie der AKS-Cluster sehen die Pod-IP als Quelladresse für jeglichen Datenverkehr aus dem Pod. Systeme, die sich außerhalb des virtuellen Netzwerks des AKS-Clusters befinden, sehen die Knoten-IP als Quelladresse für jeglichen Datenverkehr aus dem Pod. Diese IP-Adressen müssen in Ihrem Netzwerkadressraum eindeutig sein und im Voraus geplant werden. Jeder Knoten verfügt über einen Konfigurationsparameter für die maximale Anzahl von Pods, die er unterstützt. Die entsprechende Anzahl von IP-Adressen pro Knoten wird dann im Voraus für diesen Knoten reserviert. Dieser Ansatz erfordert mehr Planung und führt oft zu einer Erschöpfung der IP-Adresse oder der Notwendigkeit, Cluster in einem größeren Subnetz neu zu erstellen, wenn die Anforderungen Ihrer Anwendung wachsen.

Mit dem Azure CNI-Knotensubnetz empfängt jeder Pod eine IP-Adresse im IP-Subnetz und kann direkt mit anderen Pods und Diensten kommunizieren. Ihre Cluster können so groß wie der IP-Adressbereich sein, den Sie angeben. Allerdings müssen Sie den IP-Adressbereich im Voraus planen, und alle IP-Adressen werden von den AKS-Knoten basierend auf der maximalen Anzahl von Pods konsumiert, die sie unterstützen können. Erweiterte Netzwerkfeatures und -szenarios wie z. B. virtuelle Knoten oder Netzwerkrichtlinien (entweder Azure oder Calico) werden mit Azure CNI unterstützt.

Bereitstellungsparameter

Beim Erstellen eines AKS-Clusters können folgende Parameter für Azure CNI-Netzwerke konfiguriert werden:

Virtuelles Netzwerk: Das virtuelle Netzwerk, in dem Sie den Kubernetes-Cluster bereitstellen möchten. Sie können ein neues virtuelles Netzwerk erstellen oder ein bereits vorhandenes virtuelles Netzwerk auswählen. Wenn Sie ein vorhandenes virtuelles Netzwerk verwenden möchten, stellen Sie sicher, dass es sich am selben Standort und im selben Azure-Abonnement wie Ihr Kubernetes-Cluster befindet. Weitere Informationen zu Grenzwerten und Kontingenten für virtuelle Azure-Netzwerke finden Sie unter Einschränkungen für Azure-Abonnements und Dienste, Kontingente und Einschränkungen.

Subnetz: Das Subnetz im virtuellen Netzwerk, in dem Sie den Cluster bereitstellen möchten. Sie können dem virtuellen Netzwerk während des Clustererstellungsprozesses neue Subnetze hinzufügen. Bei Hybridkonnektivität sollte sich der Adressbereich nicht mit anderen virtuellen Netzwerken in Ihrer Umgebung überschneiden.

Azure-Netzwerk-Plug-In: Wenn das Azure-Netzwerk-Plug-In verwendet wird, ist der Zugriff auf den internen Lastenausgleich mit „externalTrafficPolicy=Local“ nicht über VMs mit einer IP-Adresse in clusterCIDR außerhalb des AKS-Clusters möglich.

Kubernetes-Dienstadressbereich: Dieser Parameter enthält die virtuellen IP-Adressen, die Kubernetes den internen Diensten in Ihrem Cluster zuweist. Dieser Bereich kann nicht aktualisiert werden, nachdem Sie Ihren Cluster erstellt haben. Sie können jeden privaten Adressbereich verwenden, der die folgenden Anforderungen erfüllen:

Darf nicht innerhalb des IP-Adressbereichs des virtuellen Netzwerk Ihres Clusters liegen
Darf sich nicht mit anderen virtuellen Netzwerken überlappen, die Peers des virtuellen Netzwerks des Clusters sind
Er darf sich nicht mit lokalen IP-Adressen überlappen.
Er darf sich nicht in den Bereichen 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16 oder 192.0.2.0/24 befinden.

Es ist zwar möglich, einen Dienstadressbereich innerhalb desselben virtuellen Netzwerks wie Ihr Cluster anzugeben, es wird jedoch nicht empfohlen. Überlappende IP-Bereiche können zu unvorhersehbaren Verhaltensweisen führen. Weitere Informationen finden Sie in den häufig gestellten Fragen. Weitere Informationen zu Kubernetes-Diensten finden Sie in der Kubernetes-Dokumentation unter Dienste.

Kubernetes DNS service IP address (Kubernetes-DNS-Dienst – IP-Adresse): Die IP-Adresse für den DNS-Dienst des Clusters. Diese Adresse muss innerhalb des Kubernetes-Dienstadressbereichs liegen. Verwenden Sie nicht die erste IP-Adresse Ihres Adressbereichs. Die erste Adresse Ihres Subnetzbereichs wird für die Adresse kubernetes.default.svc.cluster.local genutzt.

Azure CNI: Derselbe grundlegende /24-Subnetzadressbereich kann nur maximal 8 Knoten im Cluster unterstützen. Diese Knotenanzahl kann nur bis zu 240 Pods mit standardmäßig maximal 30 Pods pro Knoten unterstützen.

Hinweis

Bei diesen Maximalwerten werden keine Upgrade- oder Skalierungsvorgänge berücksichtigt. In der Praxis können Sie nicht die maximale Anzahl von Knoten ausführen, die der Subnetz-IP-Adressbereich unterstützt. Sie müssen einige IP-Adressen für Skalierungs- oder Upgradevorgänge verfügbar halten.

Peering virtueller Netzwerke und ExpressRoute-Verbindungen

Sie können Azure Virtual Network Peering - oder ExpressRoute-Verbindungen mit Azure CNI verwenden, um lokale Konnektivität bereitzustellen. Planen Sie Ihre IP-Adresse sorgfältig, um Überschneidungen und falsches Datenverkehrsrouting zu verhindern. In vielen lokalen Netzwerken wird z.B. ein 10.0.0.0/8-Adressbereich verwendet, der über die ExpressRoute-Verbindung angekündigt wird. Es wird empfohlen, Ihre AKS-Cluster in Subnetzen virtueller Azure-Netzwerke außerhalb dieses Adressbereichs zu erstellen, z. B. 172.16.0.0/16.

Weitere Informationen finden Sie unter Vergleichen von Netzwerkmodellen und deren Supportbereiche.

Häufig gestellte Fragen zum Azure CNI-Podsubnetz

Kann ich VMs in meinem Clustersubnetz bereitstellen?

Ja, für das Azure CNI-Knotensubnetz können die virtuellen Computer im selben Subnetz wie der AKS-Cluster bereitgestellt werden.
Welche Quell-IP-Adressen sind für externe Systeme bei Datenverkehr sichtbar, der aus einem Azure CNI-fähigen Pod stammt?

Systeme im gleichen virtuellen Netzwerk wie der AKS-Cluster sehen die Pod-IP als Quelladresse für jeglichen Datenverkehr aus dem Pod. Systeme, die sich außerhalb des virtuellen Netzwerks des AKS-Clusters befinden, sehen die Knoten-IP als Quelladresse für jeglichen Datenverkehr aus dem Pod. Aber für die dynamische IP-Zuordnung für Azure CNI ist die Pod-IP immer die Quelladresse für jeden Datenverkehr vom Pod, unabhängig davon, ob sich die Verbindung innerhalb desselben virtuellen Netzwerks befindet oder über virtuelle Netzwerke verteilt ist. Der Grund dafür ist, dass die Azure CNI für die dynamische IP-Zuordnung die Microsoft Azure Container Networking-Infrastruktur implementiert, die eine durchgängige Erfahrung bietet. Daher wird die Verwendung von ip-masq-agent eliminiert, die noch von der herkömmlichen Azure CNI verwendet wird.
Kann ich Netzwerkrichtlinien pro Pod konfigurieren?

Ja, die Kubernetes-Netzwerkrichtlinie ist in AKS verfügbar. Informationen zu den ersten Schritten finden Sie unter Sicherer Datenverkehr zwischen Pods durch Netzwerkrichtlinien in Azure Kubernetes Service.
Ist die maximale Anzahl von Pods, die auf einem Knoten bereitgestellt werden können, konfigurierbar?

Mit Azure Container Networking Interface (CNI) erhält jeder Pod eine IP-Adresse aus dem Subnetz, mit der direkt darauf zugegriffen werden kann. Systeme im gleichen virtuellen Netzwerk wie der AKS-Cluster sehen die Pod-IP als Quelladresse für jeglichen Datenverkehr aus dem Pod. Systeme, die sich außerhalb des virtuellen Netzwerks des AKS-Clusters befinden, sehen die Knoten-IP als Quelladresse für jeglichen Datenverkehr aus dem Pod. Diese IP-Adressen müssen in Ihrem Netzwerkadressraum eindeutig sein und im Voraus geplant werden. Jeder Knoten verfügt über einen Konfigurationsparameter für die maximale Anzahl von Pods, die er unterstützt. Die entsprechende Anzahl von IP-Adressen pro Knoten wird dann im Voraus für diesen Knoten reserviert. Dieser Ansatz erfordert mehr Planung und führt oft zu einer Erschöpfung der IP-Adresse oder der Notwendigkeit, Cluster in einem größeren Subnetz neu zu erstellen, wenn die Anforderungen Ihrer Anwendung wachsen.
Kann ich VMs in meinem Clustersubnetz bereitstellen?

Ja. Für Azure CNI für die dynamische IP-Zuordnung können die VMs jedoch nicht im Subnetz des Pods bereitgestellt werden.
Welche Quell-IP-Adressen sind für externe Systeme bei Datenverkehr sichtbar, der aus einem Azure CNI-fähigen Pod stammt?

Systeme im gleichen virtuellen Netzwerk wie der AKS-Cluster sehen die Pod-IP als Quelladresse für jeglichen Datenverkehr aus dem Pod. Systeme, die sich außerhalb des virtuellen Netzwerks des AKS-Clusters befinden, sehen die Knoten-IP als Quelladresse für jeglichen Datenverkehr aus dem Pod.

Aber für Azure CNI für dynamische IP-Zuordnung ist die Pod-IP immer die Quelladresse für jeden Datenverkehr vom Pod, unabhängig davon, ob sich die Verbindung innerhalb desselben virtuellen Netzwerks befindet oder über virtuelle Netzwerke verteilt ist. Der Grund dafür ist, dass die Azure CNI für die dynamische IP-Zuordnung die Microsoft Azure Container Networking-Infrastruktur implementiert, die eine durchgängige Erfahrung bietet. Daher wird die Verwendung von ip-masq-agent eliminiert, die noch von der herkömmlichen Azure CNI verwendet wird.
Kann ich im virtuellen Netzwerk meines Clusters ein anderes Subnetz für den Kubernetes-Dienstadressbereich verwenden?

Es wird zwar nicht empfohlen, diese Konfiguration ist jedoch möglich. Der Dienstadressbereich ist ein Satz von virtuellen IP-Adressen (VIPs), die Kubernetes internen Diensten in Ihrem Cluster zuweist. Das Azure-Netzwerk hat keinen Einblick in den Dienst-IP-Adressbereich des Kubernetes-Clusters. Der fehlende Einblick in den Dienstadressbereich des Clusters kann zu Problemen führen. Es ist möglich, später ein neues Subnetz im virtuellen Netzwerk des Clusters zu erstellen, das mit dem Dienstadressbereich überlappt. Im Falle einer solchen Überlappung weist Kubernetes einem Dienst ggf. eine IP zu, die bereits von einer anderen Ressource im Subnetz verwendet wird. Dies führt zu unvorhersehbarem Verhalten oder Fehlern. Wenn Sie einen Adressbereich außerhalb des virtuellen Netzwerk des Clusters verwenden, können Sie dieses Überlappungsrisiko umgehen. Ja, wenn Sie einen Cluster mit der Azure CLI oder einer Resource Manager-Vorlage bereitstellen. Weitere Informationen finden Sie unter Maximale Pods pro Knoten.
Kann ich im virtuellen Netzwerk meines Clusters ein anderes Subnetz für den Kubernetes-Dienstadressbereich verwenden?

Es wird zwar nicht empfohlen, diese Konfiguration ist jedoch möglich. Der Dienstadressbereich ist ein Satz von virtuellen IP-Adressen (VIPs), die Kubernetes internen Diensten in Ihrem Cluster zuweist. Das Azure-Netzwerk hat keinen Einblick in den Dienst-IP-Adressbereich des Kubernetes-Clusters. Der fehlende Einblick in den Dienstadressbereich des Clusters kann zu Problemen führen. Es ist möglich, später ein neues Subnetz im virtuellen Netzwerk des Clusters zu erstellen, das mit dem Dienstadressbereich überlappt. Im Falle einer solchen Überlappung weist Kubernetes einem Dienst ggf. eine IP zu, die bereits von einer anderen Ressource im Subnetz verwendet wird. Dies führt zu unvorhersehbarem Verhalten oder Fehlern. Wenn Sie einen Adressbereich außerhalb des virtuellen Netzwerk des Clusters verwenden, können Sie dieses Überlappungsrisiko umgehen.