Erstellen eines Azure Kubernetes Service-Clusters mit API-Server-VNet-Integration (Vorschau)
Ein Azure Kubernetes Service-Cluster (AKS) mit konfigurierter API-Server-VNet-Integration projiziert den API-Serverendpunkt direkt in ein delegiertes Subnetz in dem VNet, in dem AKS bereitgestellt wurde. Die API-Server-VNet-Integration ermöglicht die Netzwerkkommunikation zwischen dem API-Server und den Clusterknoten, ohne dass eine private Verbindung oder ein Tunnel erforderlich ist. Der API-Server steht hinter der VIP eines internen Lastenausgleichsmoduls im delegierten Subnetz zur Verfügung, für deren Verwendung die Knoten konfiguriert werden. Durch Verwendung der API-Server-VNet-Integration können Sie sicherstellen, dass der Netzwerkdatenverkehr zwischen Ihrem API-Server und den Knotenpools ausschließlich im privaten Netzwerk verbleibt.
API-Serverkonnektivität
Die Steuerungsebene oder der API-Server befindet sich in einem von AKS verwalteten Azure-Abonnement. Ihr Cluster oder Knotenpool befindet sich in Ihrem Azure-Abonnement. Der Server und die virtuellen Computer, die die Clusterknoten bilden, können miteinander über die API-Server-VIP und die Pod-IPs kommunizieren, die in das delegierte Subnetz projiziert werden.
Die API-Server-VNet-Integration wird für öffentliche oder private Cluster unterstützt. Sie können den öffentlichen Zugriff nach der Clusterbereitstellung hinzufügen oder entfernen. Im Gegensatz zu Clustern ohne VNet-Integration kommunizieren die Agent-Knoten immer direkt ohne DNS mit der privaten IP-Adresse der ILB-IP (Internal Load Balancer) des API-Servers. Der gesamte Datenverkehr von Knoten zum API-Server bleibt im privaten Netzwerk. Es ist kein Tunnel für die Konnektivität zwischen API-Server und Knoten erforderlich. Clients, die außerhalb des Clusters liegen, die mit dem API-Server kommunizieren müssen, können dies normalerweise tun, wenn der öffentliche Netzwerkzugriff aktiviert ist. Wenn der öffentliche Netzwerkzugriff deaktiviert ist, sollten Sie dieselbe private DNS-Einrichtungsmethode wie für standardmäßige private Cluster verwenden.
Regionale Verfügbarkeit
Die VNet-Integration für API-Sever ist in allen globalen Azure-Regionen verfügbar.
Voraussetzungen
- Azure CLI mit aks-preview-Erweiterung 0.5.97 oder höher.
- Wenn Sie ARM oder die REST-API verwenden, muss die AKS-API-Version 2022-04-02-preview oder höher sein.
Installieren der Azure CLI-Erweiterung „aks-preview“
Wichtig
AKS-Previewfunktionen stehen gemäß dem Self-Service- und Aktivierungsprinzip zur Verfügung. Vorschauversionen werden „wie besehen“ und „wie verfügbar“ bereitgestellt und sind von Service Level Agreements und der Herstellergarantie 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:
Installieren Sie die Erweiterung „aks-preview“ mithilfe des Befehls
az extension add
.az extension add --name aks-preview
Führen Sie mit dem Befehl
az extension update
ein Update auf die neueste veröffentlichte Version der Erweiterung durch.az extension update --name aks-preview
Registrieren des Featureflags „EnableAPIServerVnetIntegrationPreview“
Registrieren Sie das Featureflag
EnableAPIServerVnetIntegrationPreview
mithilfe des Befehlsaz feature register
.az feature register --namespace "Microsoft.ContainerService" --name "EnableAPIServerVnetIntegrationPreview"
Es dauert einige Minuten, bis der Status Registered (Registriert) angezeigt wird.
Überprüfen Sie den Registrierungsstatus mit dem Befehl
az feature show
:az feature show --namespace "Microsoft.ContainerService" --name "EnableAPIServerVnetIntegrationPreview"
Wenn der Zustand Registered (Registriert) lautet, aktualisieren Sie die Registrierung des Ressourcenanbieters Microsoft.ContainerService mithilfe des Befehls
az provider register
.az provider register --namespace Microsoft.ContainerService
Erstellen eines AKS-Clusters mit API-Server-VNet-Integration mit verwaltetem VNet
AKS-Cluster mit API-Server-VNet-Integration können entweder im Modus „Verwaltetes VNet“ oder im Modus „Bring-Your-Own-VNet“ konfiguriert werden. Sie können die Cluster entweder als öffentliche Cluster (mit über eine öffentliche IP-Adresse verfügbarem API-Serverzugriff) oder als private Cluster (wobei der API-Server nur über private VNet-Konnektivität zugänglich ist) erstellen. Zudem können Sie zwischen einem öffentlichen und einem privaten Zustand umschalten, ohne Ihren Cluster erneut bereitzustellen.
Erstellen einer Ressourcengruppe
Erstellen Sie mit dem Befehl
az group create
eine Ressourcengruppe.az group create --location westus2 --name <resource-group>
Bereitstellen eines öffentlichen Clusters
Stellen Sie einen öffentlichen AKS-Cluster mit API-Server-VNet-Integration für verwaltetes VNet mit dem Befehl
az aks create
und dem Flag--enable-api-server-vnet-integration
bereit.az aks create --name <cluster-name> \ --resource-group <resource-group> \ --location <location> \ --network-plugin azure \ --enable-apiserver-vnet-integration \ --generate-ssh-keys
Bereitstellen eines privaten Clusters
Stellen Sie einen privaten AKS-Cluster mit API-Server-VNet-Integration für verwaltetes VNet mit dem Befehl
az aks create
sowie den Flags--enable-api-server-vnet-integration
und--enable-private-cluster
bereit.az aks create --name <cluster-name> \ --resource-group <resource-group> \ --location <location> \ --network-plugin azure \ --enable-private-cluster \ --enable-apiserver-vnet-integration \ --generate-ssh-keys
Erstellen eines privaten AKS-Clusters mit API-Server-VNet-Integration im Modus „Bring-Your-Own-VNet“
Wenn Sie den Modus „Bring-Your-Own-VNet“ verwenden, müssen Sie ein API-Serversubnetz erstellen und an Microsoft.ContainerService/managedClusters
delegieren, das dem AKS-Dienst Berechtigungen zum Einfügen der API-Serverpods und des internen Lastenausgleichsmoduls in dieses Subnetz erteilt. Sie können das Subnetz nicht für andere Workloads, jedoch für mehrere AKS-Cluster im selben virtuellen Netzwerk verwenden. Die kleinste unterstützte API-Serversubnetzgröße ist /28.
Die Clusteridentität benötigt Berechtigungen sowohl für das API-Serversubnetz als auch für das Knotensubnetz. Fehlende Berechtigungen im API-Serversubnetz können einen Bereitstellungsfehler verursachen.
Warnung
Ein AKS-Cluster reserviert mindestens 9 IP-Adressen im Subnetzadressraum. Eine unzureichende Anzahl von IP-Adressen kann die Skalierung von API-Servern verhindern, sodass ggf. nicht genügend API-Server vorhanden sind.
Erstellen einer Ressourcengruppe
- Erstellen Sie mit dem Befehl
az group create
eine Ressourcengruppe.
az group create --location <location> --name <resource-group>
Erstellen eines virtuellen Netzwerks
Erstellen Sie ein virtuelles Netzwerk mit dem Befehl
az network vnet create
.az network vnet create --name <vnet-name> \ --resource-group <resource-group> \ --location <location> \ --address-prefixes 172.19.0.0/16
Erstellen Sie mit dem Befehl
az network vnet subnet create
ein API-Serversubnetz.az network vnet subnet create --resource-group <resource-group> \ --vnet-name <vnet-name> \ --name <apiserver-subnet-name> \ --delegations Microsoft.ContainerService/managedClusters \ --address-prefixes 172.19.0.0/28
Erstellen Sie mit dem Befehl
az network vnet subnet create
ein Clustersubnetz.az network vnet subnet create --resource-group <resource-group> \ --vnet-name <vnet-name> \ --name <cluster-subnet-name> \ --address-prefixes 172.19.1.0/24
Erstellen einer verwalteten Identität und Erteilen von Berechtigungen im virtuellen Netzwerk
Erstellen Sie mithilfe des
az identity create
-Befehls eine verwaltete Identität.az identity create --resource-group <resource-group> --name <managed-identity-name> --location <location>
Weisen Sie dem API-Serversubnetz mit dem Befehl
az role assignment create
die Rolle „Netzwerkmitwirkender“ zu.az role assignment create --scope <apiserver-subnet-resource-id> \ --role "Network Contributor" \ --assignee <managed-identity-client-id>
Weisen Sie dem Clustersubnetz mit dem Befehl
az role assignment create
die Rolle „Netzwerkmitwirkender“ zu.az role assignment create --scope <cluster-subnet-resource-id> \ --role "Network Contributor" \ --assignee <managed-identity-client-id>
Bereitstellen eines öffentlichen Clusters
Stellen Sie einen öffentlichen AKS-Cluster mit API-Server-VNet-Integration mit dem Befehl
az aks create
und dem Flag--enable-api-server-vnet-integration
bereit.az aks create --name <cluster-name> \ --resource-group <resource-group> \ --location <location> \ --network-plugin azure \ --enable-apiserver-vnet-integration \ --vnet-subnet-id <cluster-subnet-resource-id> \ --apiserver-subnet-id <apiserver-subnet-resource-id> \ --assign-identity <managed-identity-resource-id> \ --generate-ssh-keys
Bereitstellen eines privaten Clusters
Stellen Sie einen privaten AKS-Cluster mit API-Server-VNet-Integration mit dem Befehl
az aks create
sowie den Flag--enable-api-server-vnet-integration
und--enable-private-cluster
bereit.az aks create --name <cluster-name> \ --resource-group <resource-group> \ --location <location> \ --network-plugin azure \ --enable-private-cluster \ --enable-apiserver-vnet-integration \ --vnet-subnet-id <cluster-subnet-resource-id> \ --apiserver-subnet-id <apiserver-subnet-resource-id> \ --assign-identity <managed-identity-resource-id> \ --generate-ssh-keys
Konvertieren eines vorhandenen AKS-Clusters in API-Server-VNet-Integration
Sie können vorhandene öffentliche/private AKS-Cluster in Cluster mit API-Server-VNet-Integration konvertieren, indem Sie ein API-Serversubnetz bereitstellen, das die oben aufgeführten Anforderungen erfüllt. Zu diesen Anforderungen gehören: Es muss sich im selben VNet wie die Clusterknoten befinden, über Berechtigungen für die AKS-Clusteridentität verfügen, nicht von anderen Ressourcen wie einem privaten Endpunkt verwendet werden und eine Größe von mindestens /28 haben. Die Konvertierung des Clusters ist eine unidirektionale Migration. Bei Clustern, für die die API-Server-VNet-Integration aktiviert wurde, kann diese nicht mehr deaktiviert werden.
Dieses Upgrade führt ein Upgrade der Knotenimageversion in allen Knotenpools aus und startet alle Workloads neu, während ein paralleles Imageupgrade durchgeführt wird.
Warnung
Das Konvertieren eines Clusters in einen mit API-Server-VNet-Integration führt zu einer Änderung der IP-Adresse des API-Servers, obwohl der Hostname unverändert bleibt. Wenn die IP-Adresse des API-Servers in Firewalls oder Netzwerksicherheitsgruppenregeln konfiguriert wurde, müssen diese Regeln möglicherweise aktualisiert werden.
Aktualisieren Sie Ihren Cluster mit dem Befehl
az aks update
und dem Flag--enable-apiserver-vnet-integration
zu einem Cluster mit API-Server-VNET-Integration.az aks update --name <cluster-name> \ --resource-group <resource-group> \ --enable-apiserver-vnet-integration \ --apiserver-subnet-id <apiserver-subnet-resource-id>
Aktivieren oder Deaktivieren des privaten Clustermodus auf einem vorhandenen Cluster mit API-Server-VNet-Integration
Für mit API-Server-VNet-Integration konfigurierte AKS-Cluster kann der öffentliche Netzwerkzugriff/private Clustermodus aktiviert oder deaktiviert werden, ohne den Cluster erneut bereitzustellen. Der Hostname des API-Servers ändert sich nicht, öffentliche DNS-Einträge werden aber bei Bedarf geändert oder entfernt.
Hinweis
--disable-private-cluster
befindet sich derzeit in der Vorschau. Weitere Informationen finden Sie unter Referenz und Supportebenen.
Aktivieren des privaten Clustermodus
Aktivieren Sie den privaten Clustermodus mit dem Befehl
az aks update
mit dem Flag--enable-private-cluster
.az aks update --name <cluster-name> \ --resource-group <resource-group> \ --enable-private-cluster
Deaktivieren des privaten Clustermodus
Deaktivieren Sie den privaten Clustermodus mit dem Befehl
az aks update
und dem Flag--disable-private-cluster
.az aks update --name <cluster-name> \ --resource-group <resource-group> \ --disable-private-cluster
Herstellen einer Verbindung mit dem Cluster mithilfe von „kubectl“
Konfigurieren Sie
kubectl
, um mithilfe des Befehls „az aks get-credentials
“ eine Verbindung mit Ihrem Cluster herzustellen.az aks get-credentials --resource-group <resource-group> --name <cluster-name>
NSG-Sicherheitsregeln
Der gesamte Datenverkehr innerhalb des VNet ist standardmäßig zulässig. Wenn Sie jedoch NSG-Regeln zum Einschränken des Datenverkehrs zwischen verschiedenen Subnetzen hinzugefügt haben, stellen Sie sicher, dass die NSG-Sicherheitsregeln die folgenden Kommunikationsarten zulassen:
Destination | Quelle | Protocol | Port | Zweck |
---|---|---|---|---|
APIServer-Subnetz-CIDR | Clustersubnetz | TCP | 443 und 4443 | Erforderlich, um die Kommunikation zwischen Knoten und dem API-Server zu aktivieren. |
APIServer-Subnetz-CIDR | Azure Load Balancer | TCP | 9988 | Erforderlich, um die Kommunikation zwischen Azure Load Balancer und dem API-Server zu aktivieren. Sie können auch alle Kommunikation zwischen Azure Load Balancer und dem API-Server-Subnetz-CIDR aktivieren. |
Nächste Schritte
Entsprechende bewährte Methoden finden Sie unter Best Practices für Netzwerkkonnektivität und Sicherheit in AKS.
Azure Kubernetes Service