Legacy-CNI (Container Networking Interfaces) in AKS

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-Knotensubnetz und Kubenet 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.

Hinweis

Kubenet ist für Windows Server-Container nicht verfügbar. Um Windows Server-Knotenpools verwenden zu können, müssen Sie Azure CNI verwenden.

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.

Kubenet

AKS-Cluster verwenden kubenet und erstellen für Sie standardmäßig ein virtuelles Azure-Netzwerk und -Subnetz. Mit kubenet erhalten Knoten eine IP-Adresse aus dem Subnetz des virtuellen Azure-Netzwerks. Pods erhalten eine IP-Adresse von einem logisch unterschiedlichen Adressraum zum Subnetz des virtuellen Azure-Netzwerks der Knoten. Die Netzwerkadressübersetzung (Network Address Translation, NAT) wird dann so konfiguriert, dass die Pods Ressourcen im virtuellen Azure-Netzwerk erreichen können. Die Quell-IP-Adresse des Datenverkehrs wird mit NAT in die primäre IP-Adresse des Knotens übersetzt. Dieser Ansatz reduziert die Anzahl der IP-Adressen, die Sie in Ihrem Netzwerkadressraum für die Verwendung durch Pods reservieren müssen, erheblich.

Sie können die maximale Anzahl von Pods, die auf einem Knoten bereitgestellt werden können, zum Zeitpunkt der Clustererstellung oder beim Erstellen neuer Knotenpools konfigurieren. Wenn Sie maxPods beim Erstellen neuer Knotenpools nicht angeben, wird der Standardwert 110 für kubenet verwendet.

Übersicht über kubenet-Netzwerke mit eigenem Subnetz

In vielen Umgebungen haben Sie virtuelle Netzwerke und Subnetze mit zugeordneten IP-Adressbereichen definiert und verwenden diese Ressourcen zur Unterstützung mehrerer Dienste und Anwendungen. Um Netzwerkkonnektivität zu gewährleisten, können AKS-Cluster kubenet (grundlegender Netzwerkbetrieb) oder Azure CNI (erweiterter Netzwerkbetrieb) verwenden.

Mit kubenet erhalten nur die Knoten eine IP-Adresse im Subnetz des virtuellen Netzwerks. Pods können nicht direkt miteinander kommunizieren. Stattdessen sorgen benutzerdefiniertes Routing (User Defined Routing, UDR) und IP-Weiterleitung für die Konnektivität zwischen Pods über Knoten hinweg. UDRs und die IP-Weiterleitungskonfiguration werden erstellt und standardmäßig vom AKS-Dienst verwaltet, Sie können jedoch Ihre eigene Routingtabelle für die benutzerdefinierte Routenverwaltung verwenden, wenn Sie dies möchten. Sie können auch Pods hinter einem Dienst bereitstellen, der eine zugewiesene IP-Adresse empfängt und einen Lastenausgleich des Datenverkehrs für die Anwendung durchführt. Das folgende Diagramm zeigt, wie die AKS-Knoten eine IP-Adresse im Subnetz des virtuellen Netzwerks empfangen, aber nicht die Pods:

Azure unterstützt maximal 400 Routen in einer UDR, also können Sie keinen AKS-Cluster mit mehr als 400 Knoten haben. Virtuelle Knoten in AKS und Azure-Netzwerkrichtlinien werden mit kubenet nicht unterstützt. Calico-Netzwerkrichtlinien werden unterstützt.

Einschränkungen und Erwägungen für kubenet

• Beim Entwurf von kubenet ist ein zusätzlicher Hop erforderlich, wodurch der Pod-Kommunikation eine geringfügige Wartezeit hinzugefügt wird.
• Routingtabellen und benutzerdefinierte Routen sind für die Verwendung von kubenet erforderlich, wodurch die Vorgänge komplexer werden.
  • Weitere Informationen finden Sie unter Anpassen des ausgehenden Clusters mit einer benutzerdefinierten Routingtabelle in AKS und Anpassen des ausgehenden Clusters mit ausgehenden Typen in AKS.
• Direkte Pod-Adressierung wird aufgrund des kubenet-Designs für kubenet nicht unterstützt.
• Im Gegensatz zu Azure CNI-Clustern können mehrere kubenet-Clustern Subnetze nicht gemeinsam verwenden.
• 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 zwischen den CIDR-Knoten und -Pods zulassen. Weitere Details finden Sie unter Netzwerksicherheitsgruppen.
• Zu den in kubenet nicht unterstützten Funktionen gehören:
  • Azure-Netzwerkrichtlinien
  • Windows-Knotenpools
  • Add-On für virtuelle Knoten

Hinweis

Einige der System-Pods, z. B. Konnektivität innerhalb des Clusters, verwenden die IP-Adresse des Hostknotens statt einer IP aus dem Überlagerungsadressraum. Die System-Pods verwenden nur die Knoten-IP und keine IP-Adresse aus dem virtuellen Netzwerk.

IP-Adressenverfügbarkeit und -auslastung

Ein häufiges Problem bei Azure CNI ist, dass der zugewiesene IP-Adressbereich zu klein ist, um dann mehr Knoten hinzuzufügen, wenn Sie einen Cluster skalieren oder upgraden. Möglicherweise ist das Netzwerkteam auch nicht in der Lage, einen ausreichend großen IP-Adressbereich zu vergeben, um die erwarteten Anforderungen Ihrer Anwendung zu erfüllen. Als Kompromiss können Sie einen AKS-Cluster erstellen, der kubenet verwendet und eine Verbindung mit einem vorhandenen Subnetz eines virtuellen Netzwerks herstellt. Mit diesem Ansatz können die Knoten definierte IP-Adressen empfangen, ohne dass vorab eine große Anzahl von IP-Adressen für potentielle Pods reserviert werden muss, die im Cluster ausgeführt werden könnten.

Mit kubenet können Sie einen viel kleineren IP-Adressbereich verwenden und große Cluster- und Anwendungsanforderungen unterstützen. Sie können beispielsweise mit einem /27-IP-Adressbereich in Ihrem Subnetz einen Cluster mit 20-25 Knoten mit genügend Platz zum Skalieren oder Upgraden ausführen. Diese Clustergröße unterstützt bis zu 2200-2750 Pods (mit standardmäßig maximal 110 Pods pro Knoten). Die maximale Anzahl von Pods pro Knoten, die Sie mit Kubenet in AKS konfigurieren können, ist 250.

Die folgenden grundlegenden Berechnungen zeigen den Unterschied zwischen Netzwerkmodellen im Vergleich:

• kubenet: Ein einfacher /24-IP-Adressbereich kann bis zu 251 Knoten im Cluster unterstützen. Jedes Subnetz des virtuellen Azure-Netzwerks reserviert die ersten drei IP-Adressen für Verwaltungsvorgänge. Diese Knotenanzahl kann bis zu 27 610 Pods mit standardmäßig maximal 110 Pods pro Knoten unterstützen.
• 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 das Peering virtueller Netzwerke von Azure oder ExpressRoute-Verbindungen mit Azure CNI und kubenet 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?

  Standardmäßig verwenden AKS-Cluster kubenet und erstellen ein virtuelles Netzwerk und ein Subnetz für Sie. Mit kubenet erhalten Knoten eine IP-Adresse aus einem Subnetz des virtuellen Netzwerks. Die Netzwerkadressübersetzung (NAT) wird dann auf den Knoten konfiguriert, und die Pods erhalten eine IP-Adresse, die hinter der Knoten-IP „versteckt“ ist. Dieser Ansatz reduziert die Anzahl der IP-Adressen, die Sie in Ihrem Netzwerkadressraum für die Verwendung von Pods reservieren müssen.

  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.