Übersicht über Azure CNI-Netzwerke in Azure Kubernetes Service (AKS)
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.
Hinweis
Dieser Artikel bietet nur eine Einführung in die herkömmliche Azure CNI. Für Azure CNI Overlay, Azure CNI-VNet für dynamische IP-Zuordnung und Azure CNI-VNet – Statische Blockzuweisung (Vorschau). Weitere Informationen finden Sie stattdessen in der jeweiligen Dokumentation.
Voraussetzungen
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/16oder192.0.2.0/24fü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 in Ihrem 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/actionMicrosoft.Network/virtualNetworks/subnets/readMicrosoft.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.
Planen der IP-Adressierung für Ihren Cluster
Für Cluster, für die Azure CNI-Netzwerke konfiguriert sind, ist eine zusätzliche Planung erforderlich. Die Größe Ihres virtuellen Netzwerks und des zugehörigen Subnetzes muss die Anzahl von Pods, die ausgeführt werden sollen, und die Anzahl von Knoten für den Cluster abdecken.
IP-Adressen für die Pods und die Knoten des Clusters werden über das angegebene Subnetz im virtuellen Netzwerk zugewiesen. Jeder Knoten wird mit einer primären IP-Adresse konfiguriert. Azure CNI konfiguriert standardmäßig 30 zusätzliche IP-Adressen vor. Diese IP-Adressen werden Pods zugewiesen, die auf dem Knoten geplant sind. Wenn Sie Ihren Cluster aufskalieren, wird jeder Knoten auf ähnliche Weise mit IP-Adressen aus dem Subnetz konfiguriert. Sie können auch die maximale Anzahl von Pods pro Knoten anzeigen.
Wichtig
Die Anzahl der erforderlichen IP-Adressen sollte Überlegungen für Upgrade- und Skalierungsvorgänge beinhalten. Wenn Sie den IP-Adressbereich so einstellen, dass er nur eine feste Anzahl von Knoten unterstützt, können Sie Ihren Cluster weder aktualisieren noch skalieren.
Wenn Sie Ihren AKS-Cluster aktualisieren, wird im Cluster ein neuer Knoten bereitgestellt. Dienste und Workloads werden auf dem neuen Knoten ausgeführt, und ein älterer Knoten wird aus dem Cluster entfernt. Dieser rollende Aktualisierungsprozess erfordert, dass mindestens ein zusätzlicher Block von IP-Adressen verfügbar ist. Die Knotenanzahl ist dann
n + 1.- Dieser Aspekt ist besonders wichtig, wenn Sie Windows Server-Knotenpools verwenden. Windows Server-Knoten in AKS wenden Windows-Updates nicht automatisch an. Stattdessen führen Sie ein Upgrade im Knotenpool aus. Dieses Upgrade stellt neue Knoten mit dem neuesten Window Server 2019-Basisknotenimage und Sicherheitspatches bereit. Weitere Informationen zum Upgrade eines Windows Server-Knotenpools finden Sie unter Durchführen eines Upgrades für einen Knotenpool in AKS.
Wenn Sie Ihren AKS-Cluster skalieren, wird im Cluster ein neuer Knoten bereitgestellt. Dienste und Workloads werden auf dem neuen Knoten ausgeführt. Bei Ihrem IP-Adressbereich muss berücksichtigt werden, wie Sie die Anzahl der Knoten und Pods, die Ihr Cluster unterstützen kann, hochskalieren können. Es sollte auch ein zusätzlicher Knoten für Aktualisierungsvorgänge integriert werden. Die Knotenanzahl ist dann
n + number-of-additional-scaled-nodes-you-anticipate + 1.
Wenn Sie erwarten, dass Ihre Knoten die maximale Anzahl von Pods ausführen und regelmäßig Pods zerstören und bereitstellen, sollten Sie auch einige zusätzliche IP-Adressen pro Knoten einplanen. Es kann einige Sekunden dauern, einen Dienst zu löschen und seine IP-Adresse freizugeben, bevor ein neuer Dienst bereitgestellt und die Adresse abgerufen werden kann. Mit zusätzlichen IP-Adressen wird diese Möglichkeit berücksichtigt.
Der IP-Adressplan eines AKS-Clusters enthält neben einem virtuellen Netzwerk mindestens ein Subnetz für Knoten und Pods sowie einen Kubernetes-Dienstadressbereich.
| Adressbereich/Azure-Ressourcen | Grenzen und Kontingente |
|---|---|
| Virtuelles Netzwerk | Das virtuelle Azure-Netzwerk kann eine Größe von /8 haben, ist aber auf 65.536 konfigurierte IP-Adressen beschränkt. Berücksichtigen Sie alle Netzwerkanforderungen, einschließlich der Kommunikation mit Diensten in anderen virtuellen Netzwerken, bevor Sie den Adressraum konfigurieren. Wenn Sie z. B. einen zu großen Adressraum konfigurieren, treten möglicherweise Probleme mit überlappenden Adressräumen in Ihrem Netzwerk auf. |
| Subnet | Muss groß genug für die Knoten, Pods und alle Kubernetes- und Azure-Ressourcen sein, die in Ihrem Cluster bereitgestellt werden können. Wenn Sie beispielsweise einen internen Azure Load Balancer bereitstellen, werden dessen Front-End-IP-Adressen aus dem Clusternetzwerk zugeordnet, nicht die öffentlichen IP-Adressen. Die Größe des Subnetzes sollte auch Aktualisierungsvorgänge oder zukünftige Skalierungsanforderungen berücksichtigen. Nutzen Sie die folgende Gleichung, um die minimale Subnetzgröße einschließlich eines zusätzlichen Knotens für Upgradevorgänge zu berechnen: Beispiel für einen Cluster mit 50 Knoten: Beispiel für einen Cluster mit 50 Knoten, der auch die Bereitstellung von 10 zusätzlichen Knoten zur Skalierung beinhaltet: Wenn Sie beim Erstellen des Clusters keine maximale Anzahl von Pods pro Knoten angeben, wird diese auf 30 festgelegt. Die mindestens erforderliche Anzahl von IP-Adressen basiert auf diesem Wert. Wenn Sie Ihre mindestens erforderliche Anzahl von IP-Adressen anhand eines anderen Maximalwerts berechnen, finden Sie Informationen zum Festlegen dieses Werts beim Bereitstellen des Clusters unter Maximale Anzahl von Pods pro Knoten. |
| Kubernetes-Dienstadressbereich | Netzwerkelemente, die sich in diesem virtuellen Netzwerk befinden oder mit diesem verbunden sind, dürfen diesen Bereich nicht verwenden. Das Dienstadress-CIDR darf höchstens eine Größe von /12 aufweisen. Sie können diesen Bereich für unterschiedliche AKS-Cluster wiederverwenden. |
| Kubernetes-DNS-Dienst – IP-Adresse | Die IP-Adresse im Kubernetes-Dienstadressbereich wird bei der Clusterdienstermittlung verwendet. 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. |
Maximale Pods pro Knoten
Die maximale Anzahl von Pods pro Knoten in einem AKS-Cluster ist 250. Standardmäßig variiert die maximale Anzahl von Pods pro Knoten zwischen kubenet- und Azure CNI-Netzwerken sowie je nach Methode für die Clusterbereitstellung.
| Bereitstellungsmethode | Kubenet-Standardeinstellung | Azure CNI-Standardeinstellung | Bei der Bereitstellung konfigurierbar |
|---|---|---|---|
| Azure CLI | 110 | 30 | Ja (bis zu 250) |
| Resource Manager-Vorlage | 110 | 30 | Ja (bis zu 250) |
| Portal | 110 | 110 (konfigurierbar auf der Registerkarte „Knotenpools“) | Ja (bis zu 250) |
Konfigurieren der maximalen Anzahl von Pods pro Knoten für neue Cluster
Sie können die maximale Anzahl von Pods pro Knoten bei der Clusterbereitstellung oder beim Hinzufügen von neuen Knotenpools konfigurieren. Sie können den Wert für die maximale Anzahl von Pods pro Knoten auf maximal 250 festlegen.
Wenn Sie die maximale Anzahl von Pods maxPods beim Erstellen neuer Knotenpools nicht angeben, wird der Standardwert 30 für Azure CNI verwendet.
Ein Mindestwert für maximale Pods pro Knoten wird erzwungen, um Platz für Systempods zu garantieren, die für die Clusterintegrität entscheidend sind. Der Mindestwert, der für maximale Pods pro Knoten festgelegt werden kann, ist nur dann 10, wenn die Konfiguration der einzelnen Knotenpools Platz für mindestens 30 Pods bietet. Wenn Sie z. B. die maximale Podanzahl pro Knoten auf mindestens 10 festlegen, muss jeder einzelne Knotenpool mindestens drei Knoten aufweisen. Diese Anforderung gilt auch für jeden neu erstellten Knotenpool, d. h., wenn für die maximale Podanzahl pro Knoten der Wert 10 definiert ist, muss jeder weitere hinzugefügte Knotenpool mindestens drei Knoten aufweisen.
| Netzwerk | Minimum | Maximum |
|---|---|---|
| Azure CNI | 10 | 250 |
| Kubenet | 10 | 250 |
Hinweis
Der Mindestwert in der obigen Tabelle wird vom AKS-Dienst strikt erzwungen. Sie können für maxPods keinen niedrigeren Wert als den angezeigten Mindestwert festlegen, da dadurch der Start des Clusters verhindert werden kann.
- Azure CLI: Geben Sie das
--max-pods-Argument an, wenn Sie einen Cluster mit dem Befehl az aks create bereitstellen. Der Höchstwert ist 250. - Resource Manager-Vorlage: Geben Sie die
maxPods-Eigenschaft im Objekt ManagedClusterAgentPoolProfile an, wenn Sie einen Cluster mit einer Resource Manager-Vorlage bereitstellen. Der Höchstwert ist 250. - Azure-Portal: Ändern Sie das Feld
Max pods per nodein den Knotenpooleinstellungen beim Erstellen eines Clusters oder Hinzufügen eines neuen Knotenpools.
Konfigurieren der maximalen Anzahl von Pods pro Knoten für vorhandene Cluster
Die Einstellung maxPods pro Knoten kann beim Erstellen eines neuen Knotenpools definiert werden. Wenn Sie die Einstellung maxPods in einem vorhandenen Cluster erhöhen müssen, fügen Sie einen neuen Knotenpool mit dem neuen gewünschten Wert für maxPods hinzu. Nachdem Sie Ihre Pods in den neuen Pool migriert haben, löschen Sie den älteren Pool. Wenn Sie einen älteren Pool in einem Cluster löschen möchten, müssen Sie sicherstellen, dass Sie die Modi der Knotenpools gemäß der Definition im Artikel Verwalten von Systemknotenpools in Azure Kubernetes Service (AKS) festlegen.
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. Wenn Sie ein neues virtuelles Netzwerk für Ihren Cluster erstellen möchten, können Sie Neu erstellen wählen und die Schritte im Abschnitt Erstellen eines virtuellen Netzwerks ausführen. Wenn Sie ein vorhandenes virtuelles Netzwerk auswählen 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. Wenn Sie ein neues Subnetz im virtuellen Netzwerk für Ihren Cluster erstellen möchten, können Sie Neu erstellen wählen und die Schritte im Abschnitt Erstellen eines Subnetzes ausführen. 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/16oder192.0.2.0/24befinden.
Auch wenn es technisch möglich ist, einen Dienstadressbereich in demselben virtuellen Netzwerk wie Ihr Cluster anzugeben, wird dies nicht empfohlen. Bei Verwendung sich überlappender IP-Adressbereiche kann es zu unvorhersehbarem Verhalten kommen. Weitere Informationen finden Sie im Abschnitt Häufig gestellte Fragen in diesem Artikel. 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.
Häufig gestellte Fragen
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-agenteliminiert, 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?
Ja, wenn Sie einen Cluster mit der Azure CLI oder einer Resource Manager-Vorlage bereitstellen. Weitere Informationen finden Sie unter Maximale Pods pro Knoten.
Sie können die maximalen Anzahl von Pods pro Knoten für einen vorhandenen Cluster nicht ändern.
Wie kann ich zusätzliche Eigenschaften für das Subnetz konfigurieren, das ich während der Erstellung des AKS-Clusters erstellt habe? Beispiel: Dienstendpunkte.
Die vollständige Liste mit Eigenschaften für das virtuelle Netzwerk und Subnetze, die Sie während der Erstellung des AKS-Clusters erstellen, kann im Azure-Portal auf der Standardseite für die Konfiguration des virtuellen Netzwerks konfiguriert werden.
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.
Nächster Schritt
Weitere Informationen zu Netzwerken in AKS finden Sie in den folgenden Artikeln: