Installieren eines Application Gateway-Eingangscontrollers (Application Gateway Ingress Controller, AGIC) mithilfe eines vorhandenen Application Gateways
Der Application Gateway-Eingangscontroller (Application Gateway Ingress Controller, AGIC) ist ein Pod innerhalb Ihres Azure Kubernetes Service (AKS) Clusters. AGIC überwacht die Kubernetes-Eingangsressourcen und erstellt und wendet Application Gateway-Konfiguration basierend auf dem Status des Kubernetes-Clusters an.
Tipp
Weitere Informationen unter Was ist Anwendungsgateway für Container.
Gliederung
- Voraussetzungen
- Azure Resource Manager-Authentifizierung (ARM)
- Option 1: Einrichten der Microsoft Entra Workload-ID und Erstellen einer Azure Identity auf ARMs
- Option 2: Einrichten eines Dienstprinzipals
- Installieren des Eingangscontrollers mit Helm
- Geteiltes Application Gateway: Installieren Sie AGIC in einer Umgebung, in der Application Gateway von einem AKS-Cluster und/oder anderen Azure-Komponenten gemeinsam genutzt wird.
Voraussetzungen
In diesem Dokument wird davon ausgegangen, dass Sie bereits die folgenden Tools und die folgende Infrastruktur installiert haben:
- Ein AKS-Cluster mit Azure Container Networking Interface (CNI)
- Application Gateway v2 im gleichen virtuellen Netzwerk wie das AKS-Cluster
- Microsoft Entra Workload ID, welche für Ihren AKS-Cluster konfiguriert ist
- Cloud Shell ist die Azure Shell-Umgebung, in der die
az
CLI,kubectl
undhelm
installiert werden. Diese Tools sind für Befehle erforderlich, die zum Konfigurieren dieser Bereitstellung verwendet werden.
Sichern Sie die Konfiguration Ihres Application Gateways vor der Installation von AGIC:
- Navigieren Sie von Ihrem Azure-Portal zu Ihrer Application Gateway-Instanz.
- Wählen Sie im Abschnitt Automatisierung die Option Vorlage exportieren und dann Herunterladen aus.
Die heruntergeladene ZIP-Datei enthält JSON-Vorlagen, Bash- und PowerShell-Skripte, die Sie zum Wiederherstellen des App Gateways verwenden können, wenn dies erforderlich werden sollte
Installieren von Helm
Helm ist ein Paket-Manager für Kubernetes, der zum Installieren des application-gateway-kubernetes-ingress
Pakets verwendet wird.
Hinweis
Wenn Sie Cloud Shell verwenden, müssen Sie Helm nicht installieren. Azure Cloud Shell ist in Helm Version 3 enthalten. Überspringen Sie den ersten Schritt und fügen Sie einfach das AGIC Helm-Repository hinzu.
Installieren Sie Helm, und führen Sie Folgendes aus, um das Helm-Paket
application-gateway-kubernetes-ingress
hinzuzufügen:- Für Kubernetes RBAC aktivierter AKS-Cluster
kubectl create serviceaccount --namespace kube-system tiller-sa kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller-sa helm init --tiller-namespace kube-system --service-account tiller-sa
Fügen Sie das AGIC-Helm-Repository hinzu:
helm repo add application-gateway-kubernetes-ingress https://appgwingress.blob.core.windows.net/ingress-azure-helm-package/ helm repo update
Azure Resource Manager-Authentifizierung
AGIC kommuniziert mit dem Kubernetes-API-Server und Azure Resource Manager. Für den Zugriff auf diese APIs ist eine Identität erforderlich.
Einrichten einer Microsoft Entra Workload-ID
Microsoft Entra Workload ID ist eine Identität, die Sie einer Software-Workload für die Authentifizierung und den Zugriff auf andere Dienste und Ressourcen zuweisen. Diese Identität ermöglicht es Ihrem AKS-Pod, diese Identität zu verwenden und sich mit anderen Azure-Ressourcen zu authentifizieren. Für diese Autorisierung benötigen wir hier die Berechtigung für den AGIC-Pod, um HTTP-Anforderungen an ARM zu senden.
Verwenden Sie den Azure CLI-Befehl az account set zum Festlegen eines bestimmten Abonnements als aktuelles aktives Abonnement. Verwenden Sie dann den Befehl az identity create, um eine verwaltete Identität zu erstellen. Die Identität muss in der Knoten-Ressourcengruppe erstellt werden. Der Knotenressourcengruppe wird standardmäßig ein Name zugewiesen, z. B. MC_myResourceGroup_myAKSCluster_eastus.
az account set --subscription "subscriptionID"
az identity create --name "userAssignedIdentityName" --resource-group "resourceGroupName" --location "location" --subscription "subscriptionID"
Führen Sie für die Rollenzuweisung den folgenden Befehl aus, um den
principalId
die neu erstellte Identität zu identifizieren:$resourceGroup="resource-group-name" $identityName="identity-name" az identity list -g $resourceGroup --query "[?name == '$identityName'].principalId | [0]" -o tsv
Gewähren Sie der Identität Mitwirkender Zugriff auf Ihr Application Gateway. Sie benötigen die ID des Application Gateways, welche wie folgt aussieht:
/subscriptions/A/resourceGroups/B/providers/Microsoft.Network/applicationGateways/C
. Rufen Sie zunächst die Liste der Application Gateway-IDs in Ihrem Abonnement mit dem folgenden Befehl ab:az network application-gateway list --query '[].id'
Führen Sie den folgenden Befehl aus, um der Identität Mitwirkender Zugriff zuzuweisen:
$resourceGroup="resource-group-name" $identityName="identity-Name" # Get the Application Gateway ID $AppGatewayID=$(az network application-gateway list --query '[].id' -o tsv) $role="contributor" # Get the principal ID for the User assigned identity $principalId=$(az identity list -g $resourceGroup --query "[?name == '$identityName'].principalId | [0]" -o tsv) az role assignment create --assignee $principalId --role $role --scope $AppGatewayID
Gewähren Sie der Identität Leser Zugriff auf die Application Gateway-Ressourcengruppe. Die Ressourcengruppen-ID sieht wie folgt aus:
/subscriptions/A/resourceGroups/B
. Sie können alle Ressourcengruppen wie folgt abrufen:az group list --query '[].id'
$resourceGroup="resource-group-name" $identityName="identity-Name" # Get the Application Gateway resource group $AppGatewayResourceGroup=$(az network application-gateway list --query '[].resourceGroup' -o tsv) # Get the Application Gateway resource group ID $AppGatewayResourceGroupID=$(az group show --name $AppGatewayResourceGroup --query id -o tsv) $role="Reader" # Get the principal ID for the User assigned identity $principalId=$(az identity list -g $resourceGroup --query "[?name == '$identityName'].principalId | [0]" -o tsv) # Assign the Reader role to the User assigned identity at the resource group scope az role assignment create --role $role --assignee $principalId --scope $AppGatewayResourceGroupID
Hinweis
Stellen Sie sicher, dass die von AGIC verwendete Identität über die Berechtigung Microsoft.Network/virtualNetworks/subnets/join/action verfügt, die an das Subnetz, in dem Application Gateway bereitgestellt ist, delegiert ist. Wenn keine benutzerdefinierte Rolle mit dieser Berechtigung definiert ist, können Sie die integrierte Rolle Netzwerkmitwirkender verwenden, die die Berechtigung Microsoft.Network/virtualNetworks/subnets/join/action enthält.
Verwenden eines Dienstprinzipals
Es ist auch möglich, AGIC-Zugriff auf ARM mit einem Kubernetes-Geheimnis bereitzustellen.
Erstellen Sie einen Active Directory-Dienstprinzipal, und codieren Sie ihn als base64. Die base64-Codierung ist erforderlich, damit das JSON-Blob in Kubernetes gespeichert wird.
az ad sp create-for-rbac --role Contributor --sdk-auth | base64 -w0
Fügen Sie der Datei
helm-config.yaml
das base64-codierte JSON-Blob hinzu. Weitere Informationen zuhelm-config.yaml
finden Sie im nächsten Abschnitt.armAuth: type: servicePrincipal secretJSON: <Base64-Encoded-Credentials>
Bereitstellen des Azure Application Gateway-Eingangsdatencontroller-Add-Ons
Erstellen eines Eingangscontroller-Bereitstellungsmanifests
---
# file: pet-supplies-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: pet-supplies-ingress
annotations:
kubernetes.io/ingress.class: azure/application-gateway
spec:
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: store-front
port:
number: 80
- path: /order-service
pathType: Prefix
backend:
service:
name: order-service
port:
number: 3000
- path: /product-service
pathType: Prefix
backend:
service:
name: product-service
port:
number: 3002
Bereitstellen eines Eingangscontrollers
$namespace="namespace"
$file="pet-supplies-ingress.yaml"
kubectl apply -f $file -n $namespace
Installieren des Eingangscontrollers als Helm-Diagramm
In den ersten Schritten installieren wir Tiller von Helm auf Ihrem Kubernetes-Cluster. Verwenden Sie Cloud Shell, um das AGIC Helm-Paket zu installieren:
Hinzufügen des
application-gateway-kubernetes-ingress
-Repositorys von Helm und Ausführen eines Helm-Updateshelm repo add application-gateway-kubernetes-ingress https://appgwingress.blob.core.windows.net/ingress-azure-helm-package/ helm repo update
Laden Sie die Datei „helm-config.yaml“ herunter, welche AGIC konfiguriert:
wget https://raw.githubusercontent.com/Azure/application-gateway-kubernetes-ingress/master/docs/examples/sample-helm-config.yaml -O helm-config.yaml
Oder kopieren Sie die folgende YAML-Datei:
# This file contains the essential configs for the ingress controller helm chart # Verbosity level of the App Gateway Ingress Controller verbosityLevel: 3 ################################################################################ # Specify which application gateway the ingress controller must manage # appgw: subscriptionId: <subscriptionId> resourceGroup: <resourceGroupName> name: <applicationGatewayName> # Setting appgw.shared to "true" creates an AzureIngressProhibitedTarget CRD. # This prohibits AGIC from applying config for any host/path. # Use "kubectl get AzureIngressProhibitedTargets" to view and change this. shared: false ################################################################################ # Specify which kubernetes namespace the ingress controller must watch # Default value is "default" # Leaving this variable out or setting it to blank or empty string would # result in Ingress Controller observing all accessible namespaces. # # kubernetes: # watchNamespace: <namespace> ################################################################################ # Specify the authentication with Azure Resource Manager # # Two authentication methods are available: # - Option 1: Azure-AD-workload-identity armAuth: type: workloadIdentity identityClientID: <identityClientId> ## Alternatively you can use Service Principal credentials # armAuth: # type: servicePrincipal # secretJSON: <<Generate this value with: "az ad sp create-for-rbac --role Contributor --sdk-auth | base64 -w0" >> ################################################################################ # Specify if the cluster is Kubernetes RBAC enabled or not rbac: enabled: false # true/false # Specify aks cluster related information. THIS IS BEING DEPRECATED. aksClusterConfiguration: apiServerAddress: <aks-api-server-address>
Bearbeiten Sie „helm-config.yaml“, und geben Sie die Werte für
appgw
undarmAuth
an.Hinweis
<identity-client-id>
ist eine Eigenschaft der Microsoft Entra Workload-ID, die Sie im vorherigen Abschnitt einrichten. Sie können diese Informationen abrufen, indem Sie den folgenden Befehl ausführen:az identity show -g <resourcegroup> -n <identity-name>
, wobei<resourcegroup>
die Ressourcengruppe ist, welche die Infrastruktur zum AKS Cluster, Application Gateway und die verwaltete Identität gehostet werden.Installieren des Helm-Diagramms
application-gateway-kubernetes-ingress
mit derhelm-config.yaml
-Konfiguration aus dem vorherigen Schritthelm install -f <helm-config.yaml> application-gateway-kubernetes-ingress/ingress-azure
Alternativ dazu können Sie die Datei
helm-config.yaml
und den Helm-Befehl in einem einzigen Schritt kombinieren:helm install ./helm/ingress-azure \ --name ingress-azure \ --namespace default \ --debug \ --set appgw.name=applicationgatewayABCD \ --set appgw.resourceGroup=your-resource-group \ --set appgw.subscriptionId=subscription-uuid \ --set appgw.shared=false \ --set armAuth.type=servicePrincipal \ --set armAuth.secretJSON=$(az ad sp create-for-rbac --role Contributor --sdk-auth | base64 -w0) \ --set rbac.enabled=true \ --set verbosityLevel=3 \ --set kubernetes.watchNamespace=default \ --set aksClusterConfiguration.apiServerAddress=aks-abcdefg.hcp.westus2.azmk8s.io
Überprüfen des Protokolls des neu erstellten Pods, um sicherzustellen, dass er ordnungsgemäß gestartet wurde
Lesen Sie diese Anleitung mit Vorgehensweisen, um zu verstehen, wie Sie einen AKS-Dienst über HTTP oder HTTPS über ein Azure Application Gateway im Internet bereitstellen können.
Geteiltes Application Gateway
Standardmäßig übernimmt AGIC den vollständigen Besitz des Application Gateways, mit dem er verbunden ist. AGIC Version 0.8.0 und höher kann ein einzelnes Application Gateway mit anderen Azure-Komponenten gemeinsam nutzen. Beispielsweise können wir das gleiche Application Gateway für eine App verwenden, die in einer VM-Skalierungsgruppe und in einem AKS-Cluster gehostet wird.
Sichern Sie die Konfiguration Ihres Application Gateways, bevor Sie diese Einstellung aktivieren:
- Navigieren Sie im Azure-Portal zu Ihrer
Application Gateway
-Instanz - Wählen Sie im Abschnitt Automatisierung die Option Vorlage exportieren und dann Herunterladen aus.
Die heruntergeladene ZIP-Datei enthält JSON-Vorlagen, Bash- und PowerShell-Skripte, die Sie zum Wiederherstellen des App Gateways verwenden können
Beispielszenario
Sehen wir uns eine imaginäre Application Gateway-Instanz an, die den Datenverkehr für zwei Websites verwaltet:
dev.contoso.com
– gehostet in einem neuen AKS-Cluster mithilfe von Application Gateway und AGICprod.contoso.com
: Gehostet in einer Azure-VM-Skalierungsgruppe
Mit den Standardeinstellungen übernimmt AGIC zu 100 % den Besitz des Application Gateways, auf das er verweist. AGIC überschreibt die gesamte Konfiguration des App Gateways. Sollten Sie manuell einen Listener für prod.contoso.com
(auf dem Application Gateway) erstellen, ohne ihn in Kubernetes Ingress zu definieren, löscht AGIC die prod.contoso.com
-Konfiguration innerhalb von Sekunden.
Um AGIC zu installieren und auch prod.contoso.com
über die Computer der VM-Skalierungsgruppe zu verarbeiten, müssen wir AGIC darauf beschränken, nur dev.contoso.com
zu konfigurieren. Dies wird durch Instanziierung der folgenden CRD ermöglicht:
cat <<EOF | kubectl apply -f -
apiVersion: "appgw.ingress.k8s.io/v1"
kind: AzureIngressProhibitedTarget
metadata:
name: prod-contoso-com
spec:
hostname: prod.contoso.com
EOF
Mit dem oben genannten Befehl wird ein AzureIngressProhibitedTarget
-Objekt erstellt. Dadurch wird AGIC (Version 0.8.0 und höher) über das Vorhandensein der Application Gateway-Konfiguration für prod.contoso.com
informiert und ausdrücklich angewiesen, keine Änderungen an der Konfiguration für diesen Hostnamen vorzunehmen.
Aktivierung mit der neuen AGIC-Installation
Um AGIC (Version 0.8.0 und höher) auf eine Teilmenge der Application Gateway-Konfiguration zu beschränken, ändern Sie die helm-config.yaml
-Vorlage.
Fügen Sie im Abschnitt appgw:
den Schlüssel shared
hinzu, und legen Sie ihn auf true
fest.
appgw:
subscriptionId: <subscriptionId> # existing field
resourceGroup: <resourceGroupName> # existing field
name: <applicationGatewayName> # existing field
shared: true # <<<<< Add this field to enable shared Application Gateway >>>>>
Anwenden der Helm-Änderungen:
Stellen Sie sicher, dass die
AzureIngressProhibitedTarget
-CRD wie folgt installiert ist:kubectl apply -f https://raw.githubusercontent.com/Azure/application-gateway-kubernetes-ingress/7b55ad194e7582c47589eb9e78615042e00babf3/crds/AzureIngressProhibitedTarget-v1-CRD-v1.yaml
Aktualisieren Sie Helm:
helm upgrade \ --recreate-pods \ -f helm-config.yaml \ ingress-azure application-gateway-kubernetes-ingress/ingress-azure
Ihr AKS-Cluster weist als Ergebnis eine neue Instanz von AzureIngressProhibitedTarget
namens prohibit-all-targets
auf:
kubectl get AzureIngressProhibitedTargets prohibit-all-targets -o yaml
Das Objekt prohibit-all-targets
verhindert (wie der Name schon sagt), dass AGIC die Konfiguration für beliebige Hosts und Pfade ändert.
Die Helm-Installation mit appgw.shared=true
stellt AGIC bereit, aber nimmt keine Änderungen an Application Gateway vor.
Ausweiten der Berechtigungen
Dies ist möglich, da Helm mit appgw.shared=true
und das standardmäßige prohibit-all-targets
-Objekt verhindern, dass AGIC eine Konfiguration anwendet, breiten Sie die AGIC-Berechtigungen aus:
Erstellen Sie eine neue YAML-Datei namens
AzureIngressProhibitedTarget
mit dem folgendem Codeschnipsel, welche Ihre spezifische Einrichtung enthält:cat <<EOF | kubectl apply -f - apiVersion: "appgw.ingress.k8s.io/v1" kind: AzureIngressProhibitedTarget metadata: name: your-custom-prohibitions spec: hostname: your.own-hostname.com EOF
Erst nachdem Sie Ihr eigenes benutzerdefiniertes Verbot erstellt haben, können Sie das standardmäßige Verbot löschen, das zu umfangreich ist:
kubectl delete AzureIngressProhibitedTarget prohibit-all-targets
Aktivierung für eine vorhandene AGIC-Installation
Nehmen wir an, dass wir bereits einen funktionierenden AKS-Cluster, ein Application Gateway und einen konfigurierten AGIC in unserem Cluster verwenden. Wir verfügen über eingehenden Datenverkehr für prod.contoso.com
und bedienen ihn erfolgreich von dem Cluster aus. Wir möchten unserem vorhandenen Application Gateway staging.contoso.com
hinzufügen, müssen dies jedoch auf einer VM hosten. Wir verwenden die vorhandene Application Gateway-Instanz erneut und konfigurieren manuell einen Listener und Back-End-Pools für staging.contoso.com
. Eine manuelle Anpassung der Application Gateway-Konfiguration (mit dem Portal, ARM-APIs oder Terraform) würde jedoch im Widerspruch zur Annahme des AGIC über den vollständigen Besitz stehen. Kurz nachdem wir Änderungen vorgenommen haben, überschreibt oder löscht AGIC diese.
Wir können AGIC verbieten, Änderungen an einer Teilmenge der Konfiguration vorzunehmen.
Erstellen Sie eine neue YAML-Datei namens
AzureIngressProhibitedTarget
mit dem folgendem Codeschnipsel:cat <<EOF | kubectl apply -f - apiVersion: "appgw.ingress.k8s.io/v1" kind: AzureIngressProhibitedTarget metadata: name: manually-configured-staging-environment spec: hostname: staging.contoso.com EOF
Anzeigen des neu erstellten Objekts:
kubectl get AzureIngressProhibitedTargets
Ändern der Application Gateway-Konfiguration vom Azure-Portal: Hinzufügen von Listenern, Routingregeln, Back-Ends usw. Das neue Objekt, das wir erstellt haben (
manually-configured-staging-environment
), verhindert, dass AGIC Application Gateway-Konfiguration fürstaging.contoso.com
überschreibt.