Verwenden eines internen Lastenausgleichs mit Azure Kubernetes Service (AKS)

  • Artikel

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

Erstellen eines internen Load Balancers

  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 Lastenausgleich angeben, muss sich diese im gleichen Subnetz wie der AKS-Cluster befinden und darf keiner Ressource zugewiesen sein. Beispielsweise sollte keine IP-Adresse aus dem Bereich verwendet werden, der für das Kubernetes-Subnetz im AKS-Cluster festgelegt ist.

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.

  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

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

Voraussetzungen

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

  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.

    # 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 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

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.