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 innerhalb desselben virtuellen Netzwerks oder in einem anderen virtuellen Netzwerk über virtuelles Netzwerk-Peering befinden. In diesem Artikel wird veranschaulicht, wie Sie einen internen Lastenausgleich mit AKS erstellen und verwenden.

Wichtig

Ab dem 30. September 2025 unterstützt Azure Kubernetes Service (AKS) den Basic Load Balancer nicht mehr. Um potenzielle Dienstunterbrechungen zu vermeiden, empfehlen wir die Verwendung des Standardlastenausgleichs für neue Bereitstellungen und das Aktualisieren vorhandener Bereitstellungen auf den Standardlastenausgleich. Weitere Informationen zu dieser Abkündigung finden Sie im GitHub-Issue "Retirement" und in der Azure Updates Ankündigung zur Abkündigung. Um über Ankündigungen und Updates auf dem Laufenden zu bleiben, folgen Sie den AKS-Versionshinweisen.

Bevor Sie beginnen

  • Dieser Artikel setzt voraus, dass Sie über ein vorhandenes 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 Konfigurieren von Azure CNI-Netzwerken in AKS. Wenn Sie das Load Balancer für die Verwendung einer IP-Adresse in einem anderen Subnetz konfigurieren, sollten Sie sicherstellen, dass die AKS-Clusteridentität auch Zugriff auf dieses Subnetz hat Read.

Erstellen Sie einen internen Load Balancer

  1. Erstellen Sie ein Dienstmanifest namens internal-lb.yaml mit dem Diensttyp LoadBalancer und der Anmerkung azure-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

  2. 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

  3. 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 Load Balancer angeben, muss diese IP-Adresse im vom Load Balancer verwendeten Subnetz verfügbar sein. Standardmäßig verwendet der Lastenausgleich dasselbe Subnetz wie der AKS-Cluster. Verwenden Sie keine Azure reservierte IP-Adresse, keine IP-Adresse, die bereits einer anderen Ressource zugewiesen ist, oder eine IP-Adresse aus dem Kubernetes-Dienst CIDR.

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 Load Balancer 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. Weitere Informationen zu Dienstanmerkungen finden Sie unter Azure Load Balancer unterstützte Anmerkungen.

  1. Legen Sie Dienstanmerkungen mithilfe von service.beta.kubernetes.io/azure-load-balancer-ipv4 für eine IPv4-Adresse und service.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

  2. 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.

Wichtig

Private Link Dienst hat die folgenden Einschränkungen:

  • Private Link Dienst unterstützt nur IPv4-Datenverkehr und unterstützt nur die TCP- und UDP-Transportprotokolle.
  • Wenn der Dienst externalTrafficPolicy: Local verwendet, muss sich das Subnetz des Private Link-Diensts vom Pod-Subnetz unterscheiden. Um dasselbe Subnetz zu verwenden, setzen Sie externalTrafficPolicy auf Cluster.
  • Wenn Sie das PROXY-Protokoll aktivieren und verwenden externalTrafficPolicy: Local, müssen Sie einen benutzerdefinierten Integritätstest konfigurieren, da der Standardintegritätstest fehlschlägt.

Weitere Informationen finden Sie unter Private Link Diensteinschränkungen und Azure Private Link Dienstintegrationseinschränkungen.

  1. Erstellen Sie ein Dienstmanifest namens internal-lb-pls.yaml mit dem Diensttyp LoadBalancer und den Anmerkungen azure-load-balancer-internal und azure-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

  2. 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. Außerdem wird ein Private Link Service-Objekt erstellt, das eine Verbindung mit der Frontend-IP-Konfiguration des internen Lastenausgleichs herstellt, der dem Kubernetes-Dienstobjekt zugeordnet ist.

    kubectl apply -f internal-lb-pls.yaml

  3. 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

  4. 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

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. Ersetzen Sie pls-xyz durch den Private Link-Dienstnamen, der im vorherigen Schritt zurückgegeben wurde.

Legen Sie diese --resource-group Einstellung auf die Zielressourcengruppe fest, in der Sie den privaten Endpunkt erstellen möchten. Legen Sie --subnet und --vnet-name auf das virtuelle Netzwerk und das Subnetz fest, die den privaten Endpunkt enthalten. Legen Sie --private-connection-resource-id auf die Ressourcen-ID des Private Link-Diensts fest, die in AKS_PLS_ID abgerufen wurde.

# Create variables for the Private Link Service

AKS_PLS_NAME=pls-xyz
AKS_PLS_ID=$(az network private-link-service show -g $AKS_MC_RG --name $AKS_PLS_NAME --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

Mit den folgenden Anmerkungen können Sie die PLS-Ressource anpassen:

Anmerkung Wert Beschreibung Erforderlich Voreinstellung
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 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> Zeichenfolge, die das Subnetz angibt, in dem die PLS bereitgestellt wird. Dieses Subnetz muss im selben virtuellen Netzwerk 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 zur zeit nicht unterstützt.) Die Gesamtanzahl der IPs sollte nicht größer sein als die in service.beta.kubernetes.io/azure-pls-ip-configuration-ip-address-count. 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 vollqualifizierter Domänennamen, die der 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. Der Back-End-Dienst MUSS das PROXY-Protokoll unterstützen, oder die Verbindung schlägt fehl. Optional false
service.beta.kubernetes.io/azure-pls-visibility "sub1 sub2 sub3 … subN" oder "*" Eine durch Leerzeichen getrennte Liste von 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 Leere Liste[], die nur die rollenbasierte Zugriffssteuerung angibt: Dieser Private Link Dienst ist nur für Benutzer mit den erforderlichen Azure RBAC-Berechtigungen verfügbar, einschließlich autorisierter Benutzer über Mandanten hinweg. (am restriktivsten).
service.beta.kubernetes.io/azure-pls-auto-approval "sub1 sub2 sub3 … subN" Eine durch Leerzeichen getrennte Liste von Azure Abonnement-IDs, deren PE-Verbindungsanforderungen an die PLS automatisch genehmigt werden. Die Liste der automatischen Genehmigung muss eine Teilmenge der Sichtbarkeitsliste sein. Optional []

Verwenden Sie einen internen Load Balancer mit privaten Netzwerken

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 Konfigurieren Ihrer eigenen Subnetze des virtuellen Netzwerks mit Kubenet oder mit Azure CNI.

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. Das Lastenausgleichsmodul wird in der Knotenressourcengruppe für Ihren AKS-Cluster erstellt und mit Ihrem privaten virtuellen Netzwerk und Subnetz verbunden, wie im folgenden Beispiel gezeigt:

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 Ihrem Dienst die Annotation azure-load-balancer-internal-subnet hinzu, um ein Subnetz für Ihren Load Balancer anzugeben. Das angegebene Subnetz muss sich dabei im gleichen virtuellen Netzwerk wie Ihr AKS-Cluster befinden. Nach der Bereitstellung ist die Adresse EXTERNAL-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

Legen Sie den service.beta.kubernetes.io/azure-load-balancer-internal-subnetAnnotationswert auf die Zeichenfolge des Subnetznamens fest, z. B. "apps-subnet".

Löschen des Lastenausgleichs

Das Lastenausgleichsmodul wird gelöscht, wenn Sie alle zugehörigen Kubernetes-Dienste löschen.

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.

  • Last updated on