Installieren eines Application Gateway-Eingangscontrollers (Application Gateway Ingress Controller, AGIC) mithilfe eines vorhandenen Application Gateways

Artikel
02/07/2024

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 und helm 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 zu helm-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-Updates

helm 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 und armAuth 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 der helm-config.yaml-Konfiguration aus dem vorherigen Schritt

helm 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 AGIC
prod.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ür staging.contoso.comüberschreibt.