Installer un contrôleur d’entrée Application Gateway (AGIC) à l’aide d’une instance Application Gateway existante
Le contrôleur d’entrée Application Gateway (AGIC) est un pod au sein de votre cluster Azure Kubernetes Service (AKS). AGIC surveille les ressources d’entrée Kubernetes, et crée et applique la configuration Application Gateway en fonction de l’état du cluster Kubernetes.
Conseil
Consultez également Qu’est-ce que Passerelle d’application pour conteneurs ?.
Plan
- Conditions préalables
- Authentification Azure Resource Manager (ARM)
- Option 1 : configurer l’ID de charge de travail Microsoft Entra et créer une identité Azure sur des machines virtuelles arms
- Option 2 : configurer un principal de service
- Installer le contrôleur d’entrée avec Helm
- Application Gateway partagée : installez AGIC dans un environnement où Application Gateway est partagée entre un cluster AKS et/ou d’autres composants Azure.
Prérequis
Ce document suppose que vous avez déjà installé l’infrastructure et les outils suivants :
- un de cluster AKS avec azure Container Networking Interface (CNI)
- Application Gateway v2 dans le même réseau virtuel que le cluster AKS
- 'ID de charge de travail Microsoft Entra configuré pour votre cluster AKS
- Cloud Shell est l’environnement d’interpréteur de commandes Azure, qui a
az
CLI,kubectl
ethelm
installés. Ces outils sont nécessaires pour les commandes utilisées pour prendre en charge la configuration de ce déploiement.
Sauvegarder la configuration de votre passerelle Application Gateway avant d’installer AGIC :
- À partir du portail Azure , accédez à votre instance Application Gateway.
- Sous la section Automation , sélectionnez exporter le modèle , puis Télécharger.
Le fichier zip que vous avez téléchargé contient des modèles JSON, bash et des scripts PowerShell que vous pouvez utiliser pour restaurer App Gateway si cela devient nécessaire
Installer Helm
Helm est un gestionnaire de package pour Kubernetes, utilisé pour installer le package application-gateway-kubernetes-ingress
.
Remarque
Si vous utilisez Cloud Shell, vous n’avez pas besoin d’installer Helm. Azure Cloud Shell est fourni avec Helm version 3. Ignorez la première étape et ajoutez simplement le référentiel Helm AGIC.
Installez Helm et exécutez la commande suivante pour ajouter le package Helm
application-gateway-kubernetes-ingress
:- Cluster AKS sur lequel Kubernetes RBAC est activé
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
Ajoutez le dépôt Helm AGIC :
helm repo add application-gateway-kubernetes-ingress https://appgwingress.blob.core.windows.net/ingress-azure-helm-package/ helm repo update
Authentification Azure Resource Manager
AGIC communique avec le serveur d’API Kubernetes et Azure Resource Manager. Une identité est nécessaire pour accéder à ces API.
Configurer l’ID de charge de travail Microsoft Entra
'ID de charge de travail Microsoft Entra est une identité que vous affectez à une charge de travail logicielle, pour authentifier et accéder à d’autres services et ressources. Cette identité permet à votre pod AKS d’utiliser cette identité et de s’authentifier auprès d’autres ressources Azure. Pour cette configuration, nous avons besoin d’autorisation pour que le pod AGIC effectue des requêtes HTTP à ARM.
Utilisez la commande Azure CLI az account set pour définir un abonnement spécifique comme abonnement actif actuel. Utilisez ensuite la commande az identity create pour créer une identité managée. L’identité doit être créée dans le groupe de ressources de nœud . Un nom est attribué au groupe de ressources de nœud par défaut, par exemple MC_myResourceGroup_myAKSCluster_eastus.
az account set --subscription "subscriptionID"
az identity create --name "userAssignedIdentityName" --resource-group "resourceGroupName" --location "location" --subscription "subscriptionID"
Pour l’attribution de rôle, exécutez la commande suivante pour identifier l'
principalId
de l’identité nouvellement créée :$resourceGroup="resource-group-name" $identityName="identity-name" az identity list -g $resourceGroup --query "[?name == '$identityName'].principalId | [0]" -o tsv
Accordez à l’identité Contributeur l’accès à votre application Gateway. Vous avez besoin de l’ID d’Application Gateway, qui ressemble à ceci :
/subscriptions/A/resourceGroups/B/providers/Microsoft.Network/applicationGateways/C
. Tout d’abord, obtenez la liste des ID Application Gateway dans votre abonnement en exécutant la commande suivante :az network application-gateway list --query '[].id'
Pour affecter l’accès Contributeur d’identité , exécutez la commande suivante :
$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
Accordez à l’identité Lecteur l’accès au groupe de ressources Application Gateway. L’ID du groupe de ressources ressemble à ceci :
/subscriptions/A/resourceGroups/B
. Vous pouvez récupérer tous les groupes de ressources avec :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
Remarque
Vérifiez que l’identité utilisée par AGIC a la Microsoft.Network/virtualNetworks/subnets/join/action autorisation déléguée au sous-réseau où Application Gateway est déployée. Si aucun rôle personnalisé n'est défini avec cette autorisation, vous pouvez utiliser le rôle de Contributeur Réseau intégré, qui contient l'autorisation Microsoft.Network/virtualNetworks/subnets/join/action.
Utiliser un principal du service
Il est également possible de fournir un accès AGIC à ARM à l’aide d’un secret Kubernetes.
Créez un principal du service Azure Active Directory et encodez-le en base64. L’encodage base64 est requis pour enregistrer le blob JSON dans Kubernetes.
az ad sp create-for-rbac --role Contributor --sdk-auth | base64 -w0
Ajoutez le blob JSON encodé en base64 au fichier
helm-config.yaml
. Pour en savoir plus surhelm-config.yaml
, consultez la section suivante.armAuth: type: servicePrincipal secretJSON: <Base64-Encoded-Credentials>
Déployer le module complémentaire du contrôleur d’entrée Azure Application Gateway
Créer un manifeste de déploiement du contrôleur d’entrée
---
# 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
Déployer le contrôleur d’entrée
$namespace="namespace"
$file="pet-supplies-ingress.yaml"
kubectl apply -f $file -n $namespace
Installer le contrôleur d’entrée en tant que chart Helm
Les premières étapes consistent à installer Tiller de Helm sur votre cluster Kubernetes. Utilisez Cloud Shell pour installer le package AGIC Helm :
Ajoutez le référentiel Helm
application-gateway-kubernetes-ingress
et mettez à jour à Helmhelm repo add application-gateway-kubernetes-ingress https://appgwingress.blob.core.windows.net/ingress-azure-helm-package/ helm repo update
Téléchargez helm-config.yaml, qui configure AGIC :
wget https://raw.githubusercontent.com/Azure/application-gateway-kubernetes-ingress/master/docs/examples/sample-helm-config.yaml -O helm-config.yaml
Ou copiez le fichier YAML suivant :
# 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>
Modifiez helm-config.yam et renseignez les valeurs pour
appgw
etarmAuth
.Remarque
Le
<identity-client-id>
est une propriété de l’ID de charge de travail Microsoft Entra que vous configurez dans la section précédente. Vous pouvez récupérer ces informations en exécutant la commande suivante :az identity show -g <resourcegroup> -n <identity-name>
, où<resourcegroup>
est le groupe de ressources hébergeant les ressources d’infrastructure liées au cluster AKS, à Application Gateway et à l’identité managée.Installez le chart Helm
application-gateway-kubernetes-ingress
avec la configurationhelm-config.yaml
de l’étape précédentehelm install -f <helm-config.yaml> application-gateway-kubernetes-ingress/ingress-azure
Vous pouvez également combiner
helm-config.yaml
et la commande Helm en une seule étape :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
Consultez le journal du pod nouvellement créé pour vérifier s’il a démarré correctement
Reportez-vous à ce guide pratique pour comprendre comment vous pouvez exposer un service AKS via HTTP ou HTTPS sur Internet, à l’aide d’une instance Azure Application Gateway.
Passerelle d’application partagée
Par défaut, AGIC suppose que la propriété complète d’Application Gateway est liée. AGIC version 0.8.0 et ultérieure peut partager une seule instance Application Gateway unique avec d’autres composants Azure. Par exemple, nous pourrions utiliser la même passerelle Application Gateway pour une application hébergée sur un groupe de machines virtuelles identiques et un cluster AKS.
Sauvegarder la configuration de votre application Gateway avant d’activer ce paramètre :
- À partir du portail Azure , accédez à votre instance de
Application Gateway
- Sous la section Automation , sélectionnez exporter le modèle , puis Télécharger.
Le fichier zip que vous avez téléchargé contient des modèles JSON, bash et des scripts PowerShell que vous pouvez utiliser pour restaurer Application Gateway
Exemple de scénario
Examinons une instance Application Gateway imaginaire, qui gère le trafic de deux sites web :
dev.contoso.com
- hébergé sur un nouveau cluster AKS, à l’aide d’Application Gateway et DGICprod.contoso.com
- hébergé sur un groupe de machines virtuelles identiques Azure
Avec les paramètres par défaut, AGIC suppose que la propriété 100 % de l’Application Gateway vers lequel il pointe. AGIC remplace toute la configuration de l’instance Application Gateway. Si vous créez manuellement un écouteur pour prod.contoso.com
(sur Application Gateway) sans le définir dans l’entrée Kubernetes, AGIC supprime la configuration prod.contoso.com
en quelques secondes.
Pour installer AGIC et traiter prod.contoso.com
à partir de notre groupe de machines virtuelles identiques, nous devons contraindre AGIC à configurer dev.contoso.com
uniquement. Cela est facilité par l’instanciation du CRD suivant :
cat <<EOF | kubectl apply -f -
apiVersion: "appgw.ingress.k8s.io/v1"
kind: AzureIngressProhibitedTarget
metadata:
name: prod-contoso-com
spec:
hostname: prod.contoso.com
EOF
La commande ci-dessus crée un objet AzureIngressProhibitedTarget
. Cela permet à AGIC (version 0.8.0 et ultérieure) de prendre conscience de l’existence de la configuration de l’instance Application Gateway pour prod.contoso.com
et de lui demander explicitement d’éviter de modifier la configuration liée à ce nom d’hôte.
Activer avec une nouvelle installation AGIC
Pour limiter AGIC (version 0.8.0 et ultérieure) à un sous-ensemble de la configuration de l’instance Application Gateway, modifiez le modèle helm-config.yaml
.
Dans la section appgw:
, ajoutez shared
clé et définissez-la sur true
.
appgw:
subscriptionId: <subscriptionId> # existing field
resourceGroup: <resourceGroupName> # existing field
name: <applicationGatewayName> # existing field
shared: true # <<<<< Add this field to enable shared Application Gateway >>>>>
Appliquez les modifications Helm :
Assurez-vous que le CRD
AzureIngressProhibitedTarget
est installé avec :kubectl apply -f https://raw.githubusercontent.com/Azure/application-gateway-kubernetes-ingress/7b55ad194e7582c47589eb9e78615042e00babf3/crds/AzureIngressProhibitedTarget-v1-CRD-v1.yaml
Mettez à jour Helm :
helm upgrade \ --recreate-pods \ -f helm-config.yaml \ ingress-azure application-gateway-kubernetes-ingress/ingress-azure
Par conséquent, votre cluster AKS a une nouvelle instance de AzureIngressProhibitedTarget
appelée prohibit-all-targets
:
kubectl get AzureIngressProhibitedTargets prohibit-all-targets -o yaml
L’objet prohibit-all-targets
, comme son nom l’indique, interdit à AGIC de modifier la configuration de tout hôte et chemin d’accès.
Helm installe avec appgw.shared=true
déploie AGIC, mais n’apporte aucune modification à Application Gateway.
Élargir les autorisations
Étant donné que Helm avec appgw.shared=true
et l' prohibit-all-targets
par défaut empêche AGIC d’appliquer une configuration, élargissez les autorisations AGIC :
Créez un fichier YAML nommé
AzureIngressProhibitedTarget
avec l’extrait de code suivant contenant votre configuration spécifique :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
Une fois que vous avez créé votre interdiction personnalisée, vous pouvez supprimer la valeur par défaut, qui est trop large :
kubectl delete AzureIngressProhibitedTarget prohibit-all-targets
Activer pour une installation AGIC existante
Supposons que nous avons déjà un cluster AKS opérationnel, Application Gateway et configuré AGIC dans notre cluster. Nous disposons d’une entrée pour prod.contoso.com
et servons correctement le trafic pour celui-ci à partir du cluster. Nous souhaitons ajouter staging.contoso.com
à notre instance Application Gateway existante, mais devons l’héberger sur une machine virtuelle. Nous allons réutiliser l’instance Application Gateway existante et configurer manuellement un écouteur et des pools principaux pour staging.contoso.com
. Toutefois, l’ajustement manuel de la configuration d’Application Gateway (à l’aide du portail , API ARM ou Terraform) serait en conflit avec les hypothèses d’AGIC de propriété complète. Peu après l’application des modifications, AGIC les remplace ou les supprime.
Nous pouvons empêcher AGIC d’apporter des modifications à un sous-ensemble de la configuration.
Créez un fichier YAML nommé
AzureIngressProhibitedTarget
avec l’extrait de code suivant :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
Affichez l’objet nouvellement créé :
kubectl get AzureIngressProhibitedTargets
Modifiez la configuration d’Application Gateway à partir du portail Azure : ajoutez des écouteurs, des règles de routage, des back-ends, etc. Le nouvel objet que nous avons créé (
manually-configured-staging-environment
) interdit à AGIC de remplacer la configuration d’Application Gateway liée àstaging.contoso.com
.