Verwenden eines internen Lastenausgleichs mit Azure Kubernetes Service (AKS)
Sie können zum Einschränken des Zugriffs auf Ihre Anwendungen in Azure Kubernetes Service (AKS) einen internen Lastenausgleich erstellen und verwenden. Ein interner Lastenausgleich besitzt keine öffentliche IP-Adresse und macht einen Kubernetes-Dienst nur für Anwendungen zugänglich, die die private IP-Adresse erreichen können. Diese Anwendungen können sich im gleichen VNet oder in einem anderen VNet mit VNet-Peering befinden. In diesem Artikel wird veranschaulicht, wie Sie einen internen Lastenausgleich mit AKS erstellen und verwenden.
Hinweis
Azure Load Balancer ist in zwei SKUs verfügbar: Basic und Standard. Beim Erstellen eines AKS-Clusters wird standardmäßig die SKU vom Typ Standard verwendet. Wenn Sie den Diensttyp LoadBalancer erstellen, erhalten Sie denselben Lastenausgleichstyp wie bei der Bereitstellung des Clusters. Weitere Informationen finden Sie unter Vergleich der Azure Load Balancer-SKUs.
Voraussetzungen
- Es wird vorausgesetzt, dass Sie über ein AKS-Cluster verfügen. Wenn Sie einen AKS-Cluster benötigen, können Sie einen mithilfe der Azure CLI, von Azure PowerShell oder des Azure-Portals erstellen.
- Sie benötigen mindestens Version 2.0.59 der Azure CLI. Führen Sie
az --version
aus, um die Version zu ermitteln. Informationen zum Durchführen einer Installation oder eines Upgrades finden Sie bei Bedarf unter Installieren der Azure CLI. - Wenn Sie ein bestehendes Subnetz oder eine vorhandene Ressourcengruppe verwenden möchten, benötigt die AKS-Clusteridentität die Berechtigung zum Verwalten von Netzwerkressourcen. Weitere Informationen finden Sie unter Verwenden von kubenet-Netzwerken mit Ihren eigenen IP-Adressbereichen in Azure Kubernetes Service (AKS) oder Konfigurieren von Azure CNI-Netzwerken in Azure Kubernetes Service (AKS). Wenn Sie Ihren Lastenausgleich so konfigurieren, dass eine IP-Adresse in einem anderen Subnetz verwendet wird, stellen Sie sicher, dass die AKS-Clusteridentität auch Lesezugriff auf dieses Subnetz hat.
- Weitere Informationen zu Berechtigungen finden Sie unter Delegieren des Zugriffs auf andere Azure-Ressourcen.
Erstellen eines internen Load Balancers
Erstellen Sie ein Dienstmanifest namens
internal-lb.yaml
mit dem DiensttypLoadBalancer
und der Anmerkungazure-load-balancer-internal
.apiVersion: v1 kind: Service metadata: name: internal-app annotations: service.beta.kubernetes.io/azure-load-balancer-internal: "true" spec: type: LoadBalancer ports: - port: 80 selector: app: internal-app
Stellen Sie den internen Lastenausgleich mit dem Befehl
kubectl apply
bereit. Mit diesem Befehl wird ein Azure-Lastenausgleich in der Knotenressourcengruppe erstellt, die mit demselben virtuellen Netzwerk wie der AKS-Cluster verbunden ist.kubectl apply -f internal-lb.yaml
Zeigen Sie die Dienstdetails mithilfe des Befehls
kubectl get service
an.kubectl get service internal-app
Die IP-Adresse des internen Lastenausgleichs wird in der Spalte
EXTERNAL-IP
angezeigt, wie in der folgenden Beispielausgabe gezeigt. In diesem Kontext bezieht sich External auf die externe Schnittstelle des Lastenausgleichs. Es bedeutet nicht, dass er eine öffentliche, externe IP-Adresse erhält. Diese IP-Adresse wird dynamisch aus dem Subnetz zugewiesen, in dem sich auch der AKS-Cluster befindet.NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE internal-app LoadBalancer 10.0.248.59 10.240.0.7 80:30555/TCP 2m
Angeben einer IP-Adresse
Wenn Sie eine IP-Adresse für den Lastenausgleich angeben, muss sich diese im gleichen virtuellen Netzwerk wie der AKS-Cluster befinden und darf keiner anderen Ressource im virtuellen Netzwerk zugewiesen sein. Beispielsweise sollte keine IP-Adresse aus dem Bereich verwendet werden, der für das Kubernetes-Subnetz im AKS-Cluster festgelegt ist. Die Verwendung einer IP-Adresse, die bereits einer anderen Ressource im selben virtuellen Netzwerk zugewiesen ist, kann zu Problemen mit dem Load Balancer führen.
Sie können den Azure CLI-Befehl az network vnet subnet list
oder das PowerShell-Cmdlet Get-AzVirtualNetworkSubnetConfig
verwenden, um die Subnetze in Ihrem virtuellen Netzwerk abzurufen.
Weitere Informationen zu Subnetzen finden Sie unter Hinzufügen eines Knotenpools mit einem eindeutigen Subnetz.
Wenn Sie eine bestimmte IP-Adresse mit dem Lastenausgleich verwenden möchten, haben Sie zwei Möglichkeiten: Dienstanmerkungen festlegen oder die LoadBalancerIP-Eigenschaft zum YAML-Lastenausgleichsmanifest hinzufügen.
Wichtig
Das Hinzufügen der LoadBalancerIP-Eigenschaft zum YAML-Manifest des Lastenausgleichs ist nach der Upstreamversion von Kubernetes veraltet. Auch wenn der aktuelle Verbrauch unverändert bleibt und von vorhandenen Diensten erwartet wird, dass sie ohne Änderungen funktionieren, wird dringend empfohlen, stattdessen Dienstanmerkungen festzulegen.
Legen Sie Dienstanmerkungen mithilfe von
service.beta.kubernetes.io/azure-load-balancer-ipv4
für eine IPv4-Adresse undservice.beta.kubernetes.io/azure-load-balancer-ipv6
für eine IPv6-Adresse fest.apiVersion: v1 kind: Service metadata: name: internal-app annotations: service.beta.kubernetes.io/azure-load-balancer-ipv4: 10.240.0.25 service.beta.kubernetes.io/azure-load-balancer-internal: "true" spec: type: LoadBalancer ports: - port: 80 selector: app: internal-app
Zeigen Sie die Dienstdetails mithilfe des Befehls
kubectl get service
an.kubectl get service internal-app
Die IP-Adresse in der Spalte
EXTERNAL-IP
sollte ihre angegebene IP-Adresse widerspiegeln, wie in der folgenden Beispielausgabe gezeigt:NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE internal-app LoadBalancer 10.0.184.168 10.240.0.25 80:30225/TCP 4m
Weitere Informationen zum Konfigurieren Ihres Lastenausgleichs in einem anderen Subnetz finden Sie unter Angeben eines anderen Subnetzes.
Verbinden des Azure Private Link-Diensts mit dem internen Lastenausgleich
Voraussetzungen
- Sie benötigen Kubernetes 1.22.x oder höher.
- Sie benötigen eine vorhandene Ressourcengruppe mit einem VNet und einem Subnetz. In dieser Ressourcengruppe erstellen Sie den privaten Endpunkt. Wenn Sie nicht über diese Ressourcen verfügen, lesen Sie die Informationen unter Erstellen eines virtuellen Netzwerks und des Subnetzes.
Erstellen einer Private Link-Dienstverbindung
Erstellen Sie ein Dienstmanifest namens
internal-lb-pls.yaml
mit dem DiensttypLoadBalancer
und den Anmerkungenazure-load-balancer-internal
undazure-pls-create
. Weitere Optionen finden Sie im Entwurfsdokument zur Azure Private Link-Dienstintegration.apiVersion: v1 kind: Service metadata: name: internal-app annotations: service.beta.kubernetes.io/azure-load-balancer-internal: "true" service.beta.kubernetes.io/azure-pls-create: "true" spec: type: LoadBalancer ports: - port: 80 selector: app: internal-app
Stellen Sie den internen Lastenausgleich mit dem Befehl
kubectl apply
bereit. Mit diesem Befehl wird ein Azure-Lastenausgleich in der Knotenressourcengruppe erstellt, die mit demselben virtuellen Netzwerk wie der AKS-Cluster verbunden ist. Dadurch wird außerdem ein Private Link-Dienstobjekt erzeugt, das eine Verbindung mit der Front-End-IP-Konfiguration des dem Kubernetes-Dienst zugeordneten Lastenausgleichs herstellt.kubectl apply -f internal-lb-pls.yaml
Zeigen Sie die Dienstdetails mithilfe des Befehls
kubectl get service
an.kubectl get service internal-app
Die IP-Adresse des internen Lastenausgleichs wird in der Spalte
EXTERNAL-IP
angezeigt, wie in der folgenden Beispielausgabe gezeigt. In diesem Kontext bezieht sich External auf die externe Schnittstelle des Lastenausgleichs. Es bedeutet nicht, dass er eine öffentliche, externe IP-Adresse erhält.NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE internal-app LoadBalancer 10.125.17.53 10.125.0.66 80:30430/TCP 64m
Zeigen Sie die Details des Private Link-Dienstobjekts mithilfe des Befehls
az network private-link-service list
an.# Create a variable for the node resource group AKS_MC_RG=$(az aks show -g myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv) # View the details of the Private Link Service object az network private-link-service list -g $AKS_MC_RG --query "[].{Name:name,Alias:alias}" -o table
Ihre Ausgabe sollte in etwa dem folgendem Beispiel entsprechen:
Name Alias -------- ------------------------------------------------------------------------- pls-xyz pls-xyz.abc123-defg-4hij-56kl-789mnop.eastus2.azure.privatelinkservice
Erstellen eines privaten Endpunkts für den Private Link-Dienst
Mit einem privaten Endpunkt können Sie eine private Verbindung mit Ihrem Kubernetes-Dienstobjekt über den von Ihnen erstellten Private Link-Dienst herstellen.
Erstellen Sie den privaten Endpunkt mithilfe des Befehls
az network private-endpoint create
.# Create a variable for the private link service AKS_PLS_ID=$(az network private-link-service list -g $AKS_MC_RG --query "[].id" -o tsv) # Create the private endpoint $ az network private-endpoint create \ -g myOtherResourceGroup \ --name myAKSServicePE \ --vnet-name myOtherVNET \ --subnet pe-subnet \ --private-connection-resource-id $AKS_PLS_ID \ --connection-name connectToMyK8sService
PLS-Anpassungen über Anmerkungen
Im Folgenden finden Sie Anmerkungen, die zum Anpassen der PLS-Ressource verwendet werden können.
Anmerkung | Wert | Beschreibung | Erforderlich | Standard |
---|---|---|---|---|
service.beta.kubernetes.io/azure-pls-create |
"true" |
Ein boolescher Wert, der angibt, ob ein PLS erstellt werden muss | Erforderlich | |
service.beta.kubernetes.io/azure-pls-name |
<PLS name> |
Eine Zeichenfolge, die den Namen der zu erstellenden PLS-Ressource angibt | Optional | "pls-<LB frontend config name>" |
service.beta.kubernetes.io/azure-pls-resource-group |
Resource Group name |
Eine Zeichenfolge, die den Namen der Ressourcengruppe angibt, in der die PLS-Ressource erstellt wird | Optional | MC_ resource |
service.beta.kubernetes.io/azure-pls-ip-configuration-subnet |
<Subnet name> |
Eine Zeichenfolge, die das Subnetz angibt, in dem der PLS bereitgestellt wird. Dieses Subnetz muss im selben VNet wie der Back-End-Pool vorhanden sein. PLS-NAT-IPs werden in diesem Subnetz zugeordnet. | Optional | Wenn der Wert service.beta.kubernetes.io/azure-load-balancer-internal-subnet lautet, wird dieses ILB-Subnetz verwendet. Andernfalls wird das Standardsubnetz aus der Konfigurationsdatei verwendet. |
service.beta.kubernetes.io/azure-pls-ip-configuration-ip-address-count |
[1-8] |
Die Gesamtzahl der privaten NAT-IPs, die zugewiesen werden sollen | Optional | 1 |
service.beta.kubernetes.io/azure-pls-ip-configuration-ip-address |
"10.0.0.7 ... 10.0.0.10" |
Eine durch Leerzeichen getrennte Liste statischer IPv4-Adressen, die zugewiesen werden sollen. (IPv6 wird derzeit nicht unterstützt.) Die Gesamtzahl der IPs sollte die in service.beta.kubernetes.io/azure-pls-ip-configuration-ip-address-count angegebene Anzahl nicht überschreiten. Wenn weniger IPs angegeben sind, werden die restlichen dynamisch zugeordnet. Die erste IP in der Liste wird als Primary festgelegt. |
Optional | Alle IPs werden dynamisch zugeordnet. |
service.beta.kubernetes.io/azure-pls-fqdns |
"fqdn1 fqdn2" |
Eine durch Leerzeichen getrennte Liste von FQDNS, die dem PLS zugeordnet sind | Optional | [] |
service.beta.kubernetes.io/azure-pls-proxy-protocol |
"true" oder "false" |
Ein boolescher Wert, der angibt, ob das TCP-Proxyprotokoll auf dem PLS aktiviert werden soll, um Verbindungsinformationen zu übergeben, einschließlich der Link-ID und der Quell-IP-Adresse. Beachten Sie, dass der Back-End-Dienst das Proxyprotokoll unterstützen muss, da Verbindungen ansonsten fehlschlagen. | Optional | false |
service.beta.kubernetes.io/azure-pls-visibility |
"sub1 sub2 sub3 … subN" oder "*" |
Eine durch Leerzeichen getrennte Liste der Azure-Abonnement-IDs, für die der Private Link-Dienst sichtbar ist. Verwenden Sie "*" , um den PLS für alle Abonnements sichtbar zu machen (am wenigsten restriktiv). |
Optional | Eine leere Liste in [] , die nur die rollenbasierte Zugriffssteuerung angibt: Dieser Private Link-Dienst ist nur für Benutzer*innen mit RBAC-Berechtigungen in Ihrem Verzeichnis verfügbar (am restriktivsten). |
service.beta.kubernetes.io/azure-pls-auto-approval |
"sub1 sub2 sub3 … subN" |
Eine durch Leerzeichen getrennte Liste der Azure-Abonnement-IDs. Dadurch können PE-Verbindungsanforderungen aus den Abonnements, die für den PLS aufgeführt sind, automatisch genehmigt werden. Das funktioniert nur, wenn die Sichtbarkeit auf „*“ festgelegt ist. | Optional | [] |
Verwenden privater Netzwerke
Beim Erstellen des AKS-Clusters können Sie erweiterte Netzwerkeinstellungen angeben. Mit diesen Einstellungen können Sie den Cluster in einem vorhandenen virtuellen Azure-Netzwerk und in Subnetzen bereitstellen. Sie können beispielsweise den AKS-Cluster in einem privaten Netzwerk bereitstellen, das mit Ihrer lokalen Umgebung verbunden ist, und nur intern zugängliche Dienste ausführen.
Weitere Informationen finden Sie unter Verwenden von kubenet-Netzwerken mit Ihren eigenen IP-Adressbereichen in Azure Kubernetes Service (AKS) oder Konfigurieren von Azure CNI-Netzwerken in Azure Kubernetes Service (AKS).
Wenn Sie einen internen Lastenausgleich in einem AKS-Cluster bereitstellen möchten, der ein privates Netzwerk verwendet, müssen keine Änderungen an den vorherigen Schritten vorgenommen werden. Der Lastenausgleich wird in derselben Ressourcengruppe wie der AKS-Cluster erstellt. Dabei wird er jedoch wie im folgenden Beispiel gezeigt mit Ihrem privaten virtuellen Netzwerk und dem Subnetz verbunden:
$ kubectl get service internal-app
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
internal-app LoadBalancer 10.1.15.188 10.0.0.35 80:31669/TCP 1m
Hinweis
Die vom AKS-Cluster verwendete Clusteridentität muss mindestens die Rolle Netzwerkmitwirkender in Ihrer virtuellen Netzwerk-Ressource haben. Sie können die Clusteridentität mithilfe des az aks show
-Befehls anzeigen, z. B. az aks show --resource-group <resource-group-name> --name <cluster-name> --query "identity"
. Sie können die Rolle „Netzwerkmitwirkender“ mithilfe des az role assignment create
-Befehls zuweisen, z. B. az role assignment create --assignee <identity-resource-id> --scope <virtual-network-resource-id> --role "Network Contributor"
.
Wenn Sie stattdessen eine benutzerdefinierte Rolle definieren möchten, benötigen Sie die folgenden Berechtigungen:
Microsoft.Network/virtualNetworks/subnets/join/action
Microsoft.Network/virtualNetworks/subnets/read
Weitere Informationen finden Sie unter Hinzufügen, Ändern oder Löschen eines Subnetzes virtueller Netzwerke.
Angeben eines anderen Subnetzes
Fügen Sie dem Dienst die Anmerkung
azure-load-balancer-internal-subnet
hinzu, um ein Subnetz für den Lastenausgleich anzugeben. Das angegebene Subnetz muss sich dabei im gleichen virtuellen Netzwerk wie Ihr AKS-Cluster befinden. Nach der Bereitstellung ist die AdresseEXTERNAL-IP
des Lastenausgleichs Teil des angegebenen Subnetzes.apiVersion: v1 kind: Service metadata: name: internal-app annotations: service.beta.kubernetes.io/azure-load-balancer-internal: "true" service.beta.kubernetes.io/azure-load-balancer-internal-subnet: "apps-subnet" spec: type: LoadBalancer ports: - port: 80 selector: app: internal-app
Löschen des Lastenausgleichs
Der Lastenausgleich wird gelöscht, wenn alle zugehörigen Dienste gelöscht werden.
Wie jede andere Kubernetes-Ressource können Sie einen Dienst direkt löschen (z. B. kubectl delete service internal-app
). Dadurch wird auch der zugrunde liegende Azure-Lastenausgleich gelöscht.
Nächste Schritte
Weitere Informationen zu Kubernetes-Diensten finden Sie in der Dokumentation zu Kubernetes-Diensten.
Azure Kubernetes Service