Anforderungen an die IP-Adressplanung
Gilt für: Azure Local, Version 23H2
Die VON Azure Arc aktivierte IP-Adressplanung umfasst das Entwerfen eines Netzwerks, das Anwendungen, Knotenpools, Podnetzwerke, Dienstkommunikation und externen Zugriff unterstützt. Dieser Artikel führt Sie durch einige wichtige Überlegungen zur effektiven IP-Adressplanung und zur Mindestanzahl der IP-Adressen, die für die Bereitstellung von AKS in der Produktion erforderlich sind. Lesen Sie die AKS-Netzwerkkonzepte und -anforderungen , bevor Sie diesen Artikel lesen.
Einfache IP-Adressplanung für Kubernetes-Cluster und -Anwendungen
Im folgenden szenario walk-through reservieren Sie IP-Adressen aus einem einzigen Netzwerk für Ihre Kubernetes-Cluster und -Dienste. Dieses Beispiel ist das einfachste und einfachste Szenario für die IP-Adresszuweisung.
| IP-Adressanforderung | Mindestanzahl von IP-Adressen | Wie und wo sie diese Reservierung vornehmen können |
|---|---|---|
| AKS Arc-VM-IPs | Reservieren Sie eine IP-Adresse für jeden Arbeitsknoten in Ihrem Kubernetes-Cluster. Wenn Sie beispielsweise drei Knotenpools mit 3 Knoten in jedem Knotenpool erstellen möchten, benötigen Sie 9 IP-Adressen in Ihrem IP-Pool. | Reservieren Sie IP-Adressen über IP-Pools im logischen Arc VM-Netzwerk. |
| AKS Arc K8s-Versionsupgrade-IPs | Da AKS Arc rollierende Upgrades durchführt, reservieren Sie für jeden AKS Arc-Cluster eine IP-Adresse für Kubernetes-Versionsupgradevorgänge. | Reservieren Sie IP-Adressen über IP-Pools im logischen Arc VM-Netzwerk. |
| Ip-Adresse der Steuerebene | Reservieren Sie eine IP-Adresse für jeden Kubernetes-Cluster in Ihrer Umgebung. Wenn Sie beispielsweise insgesamt 5 Cluster erstellen möchten, reservieren Sie 5 IP-Adressen, eine für jeden Kubernetes-Cluster. | Reservieren Sie IP-Adressen über IP-Pools im logischen Arc VM-Netzwerk. |
| Lastenausgleichs-IPs | Die Anzahl der reservierten IP-Adressen hängt von Ihrem Anwendungsbereitstellungsmodell ab. Als Ausgangspunkt können Sie eine IP-Adresse für jeden Kubernetes-Dienst reservieren. | Reservieren Sie IP-Adressen im selben Subnetz wie das logische Arc-VM-Netzwerk, aber außerhalb des IP-Pools. |
Beispiel für die exemplarische Vorgehensweise für die IP-Adressreservierung für Kubernetes-Cluster und -Anwendungen
Jane ist ein IT-Administrator, der gerade mit AKS beginnt, die von Azure Arc aktiviert sind. Jane möchte zwei Kubernetes-Cluster bereitstellen: Kubernetes-Cluster A und Kubernetes Cluster B im Azure Local Cluster. Jane möchte auch eine Abstimmungsanwendung über Cluster A ausführen. Diese Anwendung verfügt über drei Instanzen der Front-End-Benutzeroberfläche, die über die beiden Cluster und eine Instanz der Back-End-Datenbank ausgeführt wird. Alle AKS-Cluster und -Dienste werden in einem einzigen Netzwerk mit einem einzigen Subnetz ausgeführt.
- Kubernetes-Cluster A verfügt über 3 Steuerebenenknoten und 5 Arbeitsknoten.
- Kubernetes-Cluster B verfügt über 1 Steuerebenenknoten und 3 Arbeitsknoten.
- 3 Instanzen der Front-End-Benutzeroberfläche (Port 443).
- 1 Instanz der Back-End-Datenbank (Port 80).
Basierend auf der vorherigen Tabelle muss Jane insgesamt 19 IP-Adressen im Subnetz von Jane reservieren:
- 8 IP-Adressen für die VMs des AKS Arc-Knotens im Cluster A (eine IP pro K8s-Knoten-VM).
- 4 IP-Adressen für die VMs des AKS Arc-Knotens im Cluster B (eine IP pro K8s-Knoten-VM).
- 2 IP-Adressen für die Ausführung des AKS Arc-Upgradevorgangs (eine IP-Adresse pro AKS Arc-Cluster).
- 2 IP-Adressen für die AKS Arc-Steuerebene (eine IP-Adresse pro AKS Arc-Cluster)
- 3 IP-Adressen für den Kubernetes-Dienst (eine IP-Adresse pro Instanz der Front-End-UI, da sie alle denselben Port verwenden. Die Back-End-Datenbank kann eine der drei IP-Adressen verwenden, solange ein anderer Port verwendet wird).
Wenn Sie mit diesem Beispiel fortfahren und der folgenden Tabelle hinzufügen, erhalten Sie Folgendes:
| Parameter | Anzahl von IP-Adressen | Wie und wo sie diese Reservierung vornehmen können |
|---|---|---|
| AKS Arc VMs, K8s Versionsupgrade und Steuerungsebene IP | Reservieren von 16 IP-Adressen | Stellen Sie diese Reservierung über IP-Pools im logischen Azure-Netzwerk vor. |
| Lastenausgleichs-IPs | 3 IP-Adresse für Kubernetes-Dienste, für Janes Abstimmungsanwendung. | Diese IP-Adressen werden verwendet, wenn Sie ein Lastenausgleichsmodul auf Cluster A installieren. Sie können die MetalLB Arc-Erweiterung verwenden oder Ihren eigenen Drittanbieter zum Lastenausgleich bringen. Stellen Sie sicher, dass sich diese IP im selben Subnetz wie das logische Arc-Netzwerk befindet, aber außerhalb des im logischen Arc-VM-Netzwerk definierten IP-Pools. |
Beispiel-CLI-Befehle für DIE IP-Adressreservierung für Kubernetes-Cluster und -Anwendungen
In diesem Abschnitt wird der Satz von Befehlen beschrieben, die Jane für ihr Szenario ausführt. Erstellen Sie zunächst ein logisches Netzwerk mit einem IP-Pool mit mindestens 16 IP-Adressen. Wir haben den IP-Pool mit 20 IP-Adressen erstellt, um die Option zum Skalieren am Tag N bereitzustellen. Ausführliche Informationen zu Parameteroptionen in logischen Netzwerken finden Sie unter az stack-hci-vm network lnet create:
$ipPoolStart = "10.220.32.18"
$ipPoolEnd = "10.220.32.37"
az stack-hci-vm network lnet create --subscription $subscription --resource-group $resource_group --custom-location $customLocationID --name $lnetName --vm-switch-name $vmSwitchName --ip-allocation-method "Static" --address-prefixes $addressPrefixes --gateway $gateway --dns-servers $dnsServers --ip-pool-start $ipPoolStart --ip-pool-end $ipPoolEnd
Erstellen Sie als Nächstes einen AKS Arc-Cluster mit dem vorherigen logischen Netzwerk:
az aksarc create -n $aksclustername -g $resource_group --custom-location $customlocationID --vnet-ids $lnetName --aad-admin-group-object-ids $aadgroupID --generate-ssh-keys
Jetzt können Sie den MetalLB-Lastenausgleich mit einem IP-Pool von 3 IP-Adressen im selben Subnetz wie das logische Arc VM-Netzwerk aktivieren. Sie können später weitere IP-Pools hinzufügen, wenn Ihre Anwendung eine Erhöhung benötigt. Detaillierte Anforderungen finden Sie in der Übersicht über die MetalLB Arc-Erweiterung.
az k8s-runtime load-balancer create --load-balancer-name $lbName --resource-uri subscriptions/$subscription/resourceGroups/$resource_group/providers/Microsoft.Kubernetes/connectedClusters/metallb-demo --addresses 10.220.32.47-10.220.32.49 --advertise-mode ARP
Überlegungen zu LNETs für AKS-Cluster und Arc-VMs
Logische Netzwerke in Azure Local werden sowohl von AKS-Clustern als auch von Arc-VMs verwendet. Sie können logische Netzwerke auf eine der folgenden 2 Arten konfigurieren:
- Teilen Sie ein logisches Netzwerk zwischen AKS und Arc-VMs.
- Definieren Sie separate logische Netzwerke für AKS-Cluster und Arc-VMs.
Die Gemeinsame Nutzung eines logischen Netzwerks zwischen AKS und Arc VMs auf Azure Local bietet den Vorteil einer optimierten Kommunikation, Kosteneinsparungen und vereinfachten Netzwerkverwaltung. Dieser Ansatz führt jedoch auch potenzielle Herausforderungen wie Ressourcenkonflikt, Sicherheitsrisiken und Komplexität bei der Problembehandlung ein.
| Kriterien | Freigeben eines logischen Netzwerks | Definieren separater logischer Netzwerke |
|---|---|---|
| Konfigurationskomplexität | Einfachere Konfiguration mit einem einzigen Netzwerk, wodurch die Einrichtungskomplexität reduziert wird. | Komplexeres Setup, da Sie mehrere logische Netzwerke für VMs und AKS-Cluster konfigurieren müssen. |
| Skalierbarkeit | Mögliche Skalierbarkeitseinschränkungen, da sowohl Arc-VMs als auch AKS-Cluster Netzwerkressourcen gemeinsam nutzen. | Skalierbarer, da Netzwerkressourcen voneinander getrennt sind und unabhängig skaliert werden können. |
| Netzwerkrichtlinienverwaltung | Einfachere Verwaltung mit einer Reihe von Netzwerkrichtlinien, aber schwieriger, Workloads zu isolieren. | Einfacheres Isolieren von Workloads, da separate Richtlinien pro logischem Netzwerk angewendet werden können. |
| Sicherheitshinweise | Erhöhtes Risiko von kommunikationsübergreifenden Sicherheitsrisiken, wenn sie nicht ordnungsgemäß segmentiert werden. | Bessere Sicherheit, da jedes Netzwerk strenger segmentiert und isoliert werden kann. |
| Auswirkungen von Netzwerkfehlern | Ein Fehler im freigegebenen Netzwerk kann sich auf AKS und Arc VMs gleichzeitig auswirken. | Ein Fehler in einem Netzwerk wirkt sich nur auf die Workloads innerhalb dieses Netzwerks aus, wodurch das Gesamtrisiko reduziert wird. |
IP-Adressbereichszuordnung für pod CIDR und Dienst-CIDR
In diesem Abschnitt werden die IP-Adressbereiche beschrieben, die von Kubernetes für die Pod- und Dienstkommunikation innerhalb eines Clusters verwendet werden. Diese IP-Adressbereiche werden während des AKS-Clustererstellungsprozesses definiert und zum Zuweisen eindeutiger IP-Adressen zu Pods und Diensten innerhalb des Clusters verwendet.
Pod-Netzwerk-CIDR
Pod Network CIDR ist eine Reihe von IP-Adressen, die von Kubernetes verwendet werden, um den einzelnen Pods, die in einem Kubernetes-Cluster ausgeführt werden, eindeutige IP-Adressen zuzuweisen. Jeder Pod erhält eine eigene IP-Adresse innerhalb dieses Bereichs, sodass Pods miteinander und mit Diensten innerhalb des Clusters kommunizieren können. In AKS werden Pod-IP-Adressen über Calico CNI im VXLAN-Modus zugewiesen. Calico VXLAN hilft beim Erstellen von Overlaynetzwerken, bei denen die IP-Adressen von Pods (aus dem Pod Network CIDR) virtualisiert und über das physische Netzwerk tunnelt werden. In diesem Modus wird jedem Pod eine IP-Adresse aus dem POD-Netzwerk-CIDR zugewiesen, diese IP-Adresse ist jedoch nicht direkt im physischen Netzwerk routingfähig. Stattdessen wird es innerhalb der Netzwerkpakete gekapselt und über das zugrunde liegende physische Netzwerk gesendet, um seinen Ziel-Pod auf einem anderen Knoten zu erreichen.
AKS stellt einen Standardwert von 10.244.0.0/16 für das Pod-Netzwerk CIDR bereit. AKS unterstützt Anpassungen für das Pod-Netzwerk-CIDR. Sie können ihren eigenen Wert mithilfe des --pod-cidr Parameters beim Erstellen des AKS-Clusters festlegen. Stellen Sie sicher, dass der CIDR-IP-Bereich groß genug ist, um die maximale Anzahl von Pods pro Knoten und über den Kubernetes-Cluster hinweg aufzunehmen.
Dienstnetzwerk-CIDR
Der DIENSTnetzwerk-CIDR ist der Bereich von IP-Adressen, die für Kubernetes-Dienste wie LoadBalancers, ClusterIP und NodePort in einem Cluster reserviert sind. Kubernetes unterstützt die folgenden Diensttypen:
- ClusterIP: Der Standarddiensttyp, der den Dienst innerhalb des Clusters verfügbar macht. Auf die vom Dienstnetzwerk-CIDR zugewiesene IP kann nur innerhalb des Kubernetes-Clusters zugegriffen werden.
- NodePort: Macht den Dienst für einen bestimmten Port auf der IP-Adresse jedes Knotens verfügbar. Das ClusterIP wird weiterhin intern verwendet, aber der externe Zugriff erfolgt über die Knoten-IPs und einen bestimmten Port.
- LoadBalancer: Dieser Typ erstellt einen vom Cloudanbieter verwalteten Lastenausgleich und macht den Dienst extern verfügbar. Der Cloudanbieter verwaltet in der Regel die externe IP-Zuweisung, während der interne ClusterIP innerhalb des Dienstnetzwerk-CIDR verbleibt.
AKS stellt einen Standardwert von 10.96.0.0/12 für das Dienstnetzwerk CIDR bereit. AKS unterstützt heute keine Anpassungen für das Dienstnetzwerk CIDR.
Nächste Schritte
Erstellen logischer Netzwerke für Kubernetes-Cluster in Azure Local, Version 23H2