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.
Important
AKS-Preview-Funktionen stehen auf Selbstbedienungs- und Opt-in-Basis zur Verfügung. Vorschauversionen werden „im Istzustand“ und „wie verfügbar“ bereitgestellt und sind von den Service Level Agreements und der eingeschränkten Garantie ausgeschlossen. AKS-Vorschauversionen werden teilweise vom Kundensupport auf Grundlage der bestmöglichen Leistung abgedeckt. Daher sind diese Funktionen nicht für die Verwendung in der Produktion vorgesehen. Weitere Informationen finden Sie in den folgenden Supportartikeln:
Flex-Knoten verbinden vom Kunden verwaltete Linux-Hostcomputer mit einem Azure Kubernetes Service (AKS) Cluster. Bevor Sie einen Host anfügen, planen Sie, wie er den AKS-API-Server erreicht und wie Knoten, Pods und Kubernetes-Dienste über den gesamten Cluster kommunizieren.
Verstehen Sie das Netzwerkmodell der Flex-Knoten
Flex-Knoten verwenden während der öffentlichen Vorschau ein Bring-Your-Own-Netzwerkmodell. Sie stellen verbindungen zwischen der vom Kunden verwalteten Hostumgebung und dem AKS-Cluster bereit und verwalten sie.
AKS-verwaltete Netzwerk-Plug-Ins, einschließlich Azure Container Networking Interface (CNI) und Azure CNI Powered by Cilium, werden während der öffentlichen Vorschau nicht auf Flexknoten ausgeführt. Sie können einen Flex-Knoten an einen vorhandenen Cluster anfügen, der eines dieser Plug-Ins verwendet, aber die Pod-Netzwerk-, Netzwerkidentitäts- und Netzwerkrichtlinienfunktionen des Plug-Ins erweitern sich nicht auf den Flex-Knoten.
Die end-to-End-Konfiguration, die in "Netzwerk konfigurieren" dokumentiert ist und einen Flex-Knotenpool in AKS erstellt, erstellt einen AKS-Cluster ohne integriertes Netzwerk-Plug-In und stellt ungebundenes Net-Netzwerk sowohl auf den AKS-Knoten in Azure als auch auf Flexknoten bereit. Andere kompatible vom Kunden verwaltete Container network Interface (CNI)-Konfigurationen können unterschiedliche Anforderungen und Supportgrenzen aufweisen.
Grundlegendes zum Netzwerk von Pods mit mehreren Speicherorten
Ein Standard-CNI setzt in der Regel voraus, dass Clusterknoten bereits über eine direkte Netzwerkreichbarkeit verfügen. Flex-Knoten können in einem anderen Azure virtuellen Netzwerk, einer Region, einem Rechenzentrum, einem Edgestandort oder einer Umgebung von Drittanbietern ausgeführt werden. Das Pod-Netzwerk für Flex-Knoten fügt die Adresszuweisung und das Routing hinzu, die erforderlich sind, um diese Standorte zu verbinden.
Flex-Knoten erfordern daher eine Netzwerkkonfiguration, die:
- Weist Pod-Adressbereiche Knoten zu, ohne doppelte Pod-IP-Adressen zu erstellen.
- Konfiguriert lokale Podnetzwerke für jeden teilnehmenden Knoten.
- Leitet den Pod-Datenverkehr zwischen AKS-verwalteten Knoten und Flexknoten weiter.
- Verwendet einen vorhandenen Layer-3-Pfad direkt, wenn beide Standorte die jeweiligen Knotenadressen des anderen erreichen können.
- Unterstützt einen verschlüsselten Gatewaypfad für Topologien, die über ein öffentliches Netzwerk kommunizieren.
Diese Netzwerkebene verfügt über zwei Arten von Komponenten. Ein Controller verwaltet die Knotenplatzierung, die Podadresszuweisung und den standortübergreifenden Routingstatus. Ein Knoten-Agent wird auf allen teilnehmenden AKS-Standardknoten und Flexknoten ausgeführt, um lokale Podnetzwerke und Routen zu konfigurieren.
Wenn ein neuer Flexknoten dem Cluster beitritt, ordnet der Netzwerkcontroller seine interne IP-Adresse dem Knoten-CIDR eines Netzwerkstandorts zu. Der Knoten erhält dann Pod-Adressen aus dem Pod-CIDR dieses Standorts.
Treffen von zwei unabhängigen Netzwerkentscheidungen
Planen Sie die AKS-API-Belichtung und die Flex-Knotenkonnektivität separat.
Note
Die Wahl eines öffentlichen oder privaten API-Endpunkts hat keinen Einfluss darauf, wie der Workload-Datenverkehr zwischen Knoten und Pods geleitet wird.
- AKS-API-Exposition: Der erste Pfad verbindet den Netzwerkadministrator und den vom Kunden verwalteten Flexhost mit dem AKS-API-Server. Ein öffentlicher AKS-Cluster macht einen gesicherten öffentlichen API-Endpunkt verfügbar. Ein privater AKS-Cluster erfordert privaten Netzwerkzugriff und privates DNS.
- Konnektivität von Flex-Knoten: Dieser Pfad verbindet AKS-Standardknoten, Flex-Knoten, Pods und Kubernetes-Dienste. Außerdem wird der Rückrufpfad vom API-Server zum Flexknoten für Vorgänge wie Protokolle, Befehlsausführung und Portweiterleitung bereitgestellt.
Planen von nicht überlappenden Adressbereichen
Planen Sie separate Adressbereiche für jeden Teil der Bereitstellung:
| Adressbereich | Purpose |
|---|---|
| AKS-Knoten-Subnetz und Standortknoten-CIDR | Adressen, die AKS-Standardknoten als Mitglieder der AKS-Website identifizieren. |
| AKS pod CIDR | Adresspool, aus dem Pod-Bereiche pro Knoten für AKS-Standardknoten zugewiesen werden. |
| Flex-Host-Subnetz- und Standortknoten CIDR | Adressen, die vom Kunden verwaltete Hosts als Mitglieder der Flex-Website identifizieren. |
| Flex pod CIDR | Adresspool, aus dem Pod-Bereiche pro Knoten den Flex-Knoten zugewiesen werden. |
| Kubernetes-Dienst CIDR | Virtuelle Adressen, die von Kubernetes-Diensten verwendet werden. |
Die AKS-Knoten-, AKS-Pod-, Flex-Knoten-, Flex-Pod- und Kubernetes-Dienstbereiche sollten sich weder untereinander noch mit einem Netzwerk überschneiden, das über Peering, VPN oder ExpressRoute erreichbar ist. Jedes Subnetz muss innerhalb seines entsprechenden Standortknotens CIDR enthalten sein. Die DNS-Dienst-IP muss sich innerhalb des Kubernetes-Diensts CIDR befinden.
Azure kann einige Adresskonflikte erkennen, aber es kann nicht jedes externe oder geroutete Netzwerk überprüfen. Koordinieren Sie den endgültigen Adressplan mit Ihrem Netzwerkadministrator.
Netzwerkaufgaben von Flex-Knoten
AKS stellt die Kubernetes-Steuerungsebene, den Flexknotenpool und die Maschinenressourcen bereit. Sie sind für das externe Hostnetzwerk und das ausgewählte vom Kunden verwaltete multi-location CNI verantwortlich.
Zu den Verantwortlichkeiten des Kunden gehören:
- Routing zwischen den AKS- und Flex-Hostnetzwerken.
- Virtuelles Netzwerkpeering, VPN, ExpressRoute oder Gatewaykonfiguration bei Bedarf.
- Regeln für Firewall- und Netzwerksicherheitsgruppen.
- Konfiguration für DNS, Proxy und ausgehenden Zugriff.
- Installation, Upgrades, Status und Kompatibilität des Netzwerkcontrollers und des Node-Agents auf allen teilnehmenden Knoten.
- Überprüfung der Knoten-, Pod-, Dienst-, DNS-, ausgehenden und Rückrufkonnektivität.