Installer AGIC à l’aide d’un déploiement Application Gateway existant

Article
10/21/2024

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. Il crée et applique une configuration Azure Application Gateway en fonction de l’état du cluster Kubernetes.

Conseil

Envisagez une Passerelle d’application pour conteneurs pour votre solution d’entrée Kubernetes. Pour plus d’informations, consultez Démarrage rapide : déployer le contrôleur ALB de la Passerelle d’application pour conteneurs.

Prérequis

Cet article suppose que vous avez déjà installé les outils et l’infrastructure suivants :

Un 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.
Azure Cloud Shell en tant qu’environnement d’interpréteur de commandes Azure, qui a az (Azure CLI), kubectl et helm installés. Ces outils sont nécessaires pour les commandes qui prennent en charge la configuration de ce déploiement.

Ajoutez le référentiel Helm.

Helm est un gestionnaire de package pour Kubernetes. Nous l’utilisons pour installer le package application-gateway-kubernetes-ingress.

Si vous utilisez Cloud Shell, vous n’avez pas besoin d’installer Helm. Cloud Shell est fourni avec Helm version 3. Exécutez les commandes suivantes pour ajouter le référentiel Helm AGIC pour un cluster AKS activé avec le contrôle d’accès en fonction du rôle Kubernetes (RBAC) :

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

Sauvegarder le déploiement d’Application Gateway

Avant d’installer AGIC, sauvegardez la configuration de votre déploiement Application Gateway :

Dans le Portail Azure, accédez à votre déploiement Application Gateway.
Sous la section Automation, sélectionnez Exporter le modèle, puis Télécharger.

Le fichier .zip téléchargé contient des modèles JSON, des scripts Bash et des scripts PowerShell que vous pouvez utiliser pour restaurer Application Gateway, si une restauration est nécessaire.

Configurer une identité pour l’authentification Resource Manager

AGIC communique avec le serveur d’API Kubernetes et Azure Resource Manager. Une identité est nécessaire pour accéder à ces API. Vous pouvez utiliser l’ID de charge de travail Microsoft Entra ou un principal de service.

Configurer l’ID de charge de travail Microsoft Entra

L’ID de charge de travail Microsoft Entra est une identité que vous attribuez à une charge de travail logicielle. Cette identité permet à votre pod AKS de s’authentifier auprès d’autres ressources Azure.

Pour cette configuration, vous avez besoin d’autorisation pour que le pod AGIC effectue des requêtes HTTP à Azure Resource Manager.

Utilisez la commande Azure CLI az account set pour définir un abonnement spécifique comme abonnement actif actuel :
```
az account set --subscription "subscriptionID"
```
Utilisez ensuite la commande az identity create pour créer une identité managée. Vous devez créer l’identité dans le groupe de ressources de nœud. Le groupe de ressources de nœud se voit attribué un nom par défaut, tel que MC_myResourceGroup_myAKSCluster_eastus.
```
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 la valeur 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 au Contributeur d’identité l’accès à votre déploiement Application Gateway. Vous avez besoin de l’ID du déploiement Application Gateway, qui ressemble à /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 à /subscriptions/A/resourceGroups/B. Vous pouvez récupérer tous les groupes de ressources en exécutant 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 l’autorisation Microsoft.Network/virtualNetworks/subnets/join/action déléguée au sous-réseau où Application Gateway est déployée. Si vous n’avez pas défini de rôle personnalisé disposant de cette autorisation, vous pouvez utiliser le rôle Contributeur réseau intégré.

Configurer un principal de service

Il est également possible de fournir un accès AGIC à Azure Resource Manager à l’aide d’un secret Kubernetes :

Créez un principal du service Active Directory et encodez-le en Base64. L’encodage Base64 est nécessaire 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. Le fichier helm-config.yaml configure AGIC.
```
armAuth:
    type: servicePrincipal
    secretJSON: <Base64-Encoded-Credentials>
```

Déployer le module complémentaire AGIC

Créer un manifeste de déploiement pour le contrôleur d’entrée

---
# file: pet-supplies-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: pet-supplies-ingress
spec:
  ingressClassName: azure-application-gateway
  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

Utilisez Cloud Shell pour installer le package AGIC Helm :

Effectuez une mise à jour de Helm :
```
helm repo update
```

Télécharger helm-config.yaml :

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.yaml et renseignez les valeurs de appgw et de armAuth.

Remarque

<identity-client-id> est une propriété de la valeur d’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>. Dans cette commande, <resourcegroup> est le groupe de ressources qui héberge les ressources d’infrastructure liées au cluster AKS, à Application Gateway et à l’identité managée.

Installez le chart Helm avec la configuration helm-config.yaml de l’étape précédente :

helm install agic-controller oci://mcr.microsoft.com/azure-application-gateway/charts/ingress-azure --version 1.7.5 -f helm-config.yaml

Vous pouvez également combiner helm-config.yaml et la commande Helm en une seule étape :

helm install oci://mcr.microsoft.com/azure-application-gateway/charts/ingress-azure \
     --name agic-controller \
     --version 1.7.5 \
     --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 qu’il a démarré correctement.

Pour comprendre comment exposer un service AKS à Internet via HTTP ou HTTPS à l’aide d’un déploiement Azure Application Gateway, consultez ce guide pratique.

Configurer un déploiement Application Gateway partagé

Par défaut, AGIC est totalement propriétaire du déploiement Application Gateway auquel il est lié. AGIC version 0.8.0 et ultérieure peut partager un seul déploiement Application Gateway avec d’autres composants Azure. Par exemple, vous pouvez utiliser le même déploiement Application Gateway pour une application hébergée sur un groupe de machines virtuelles identiques Azure et un cluster AKS.

Exemple de scénario

Examinons un déploiement 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 AGIC.
prod.contoso.com : hébergé sur un groupe de machines virtuelles identiques.

Avec les paramètres par défaut, AGIC est à 100 % propriétaire du déploiement Application Gateway auquel il est lié. AGIC remplace toute la configuration d’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 servir également prod.contoso.com à partir des machines qui utilisent le groupe de machines virtuelles identiques, vous devez limiter AGIC à la configuration dev.contoso.com uniquement. Vous facilitez cette contrainte en instanciant la définition de ressource personnalisée (CRD) suivante :

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 précédente crée un objet AzureIngressProhibitedTarget. Cet objet rend AGIC (version 0.8.0 et ultérieure) conscient de l’existence de la configuration d’Application Gateway pour prod.contoso.com. Cet objet indique également explicitement à AGIC d’éviter de modifier toute configuration liée à ce nom d’hôte.

Activer un déploiement Application Gateway partagé à l’aide d’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 une clé shared 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 la CRD AzureIngressProhibitedTarget est installée :

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 \
    agic-controller
    oci://mcr.microsoft.com/azure-application-gateway/charts/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 empêche AGIC de modifier la configuration pour tout hôte et chemin d’accès. Helm installé avec appgw.shared=true déploie AGIC, mais cela n’apporte aucune modification à Application Gateway.

Élargir les autorisations

Étant donné que Helm avec appgw.shared=true et prohibit-all-targets par défaut empêche AGIC d’appliquer une configuration, vous devez élargir 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

Maintenant que vous avez créé votre interdiction personnalisée, vous pouvez supprimer celle par défaut, qui est trop large :
```
kubectl delete AzureIngressProhibitedTarget prohibit-all-targets
```

Activer un déploiement Application Gateway partagé pour une installation AGIC existante

Supposons que vous disposez déjà d’un cluster AKS opérationnel et d’un déploiement Application Gateway, et que vous avez configuré AGIC dans votre cluster. Vous disposez d’une entrée pour prod.contoso.com et servons correctement le trafic pour celui-ci à partir du cluster.

Vous souhaitez ajouter staging.contoso.com à votre déploiement Application Gateway existant, mais vous devez l’héberger sur une machine virtuelle. Vous allez réutiliser le déploiement Application Gateway existant et configurer manuellement un écouteur et des pools de back-ends pour staging.contoso.com. Toutefois, l’ajustement manuel de la configuration d’Application Gateway (à l’aide du Portail Azure, des API Resource Manager ou de Terraform) serait en conflit avec les hypothèses d’AGIC relatives à la propriété complète. Peu après l’application des modifications, AGIC les remplace ou les supprime.

Vous pouvez empêcher AGIC d’apporter des modifications à un sous-ensemble de la configuration :

Créez un fichier YAML nommé AzureIngressProhibitedTarget à l’aide de 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. Par exemple, ajoutez des écouteurs, des règles d’acheminement et des back-ends. Le nouvel objet que vous avez créé (manually-configured-staging-environment) interdit à AGIC de remplacer la configuration d’Application Gateway liée à staging.contoso.com.

Passerelle d’application pour conteneurs

Partage via

Installer AGIC à l’aide d’un déploiement Application Gateway existant

Prérequis

Ajoutez le référentiel Helm.

Sauvegarder le déploiement d’Application Gateway

Configurer une identité pour l’authentification Resource Manager

Configurer l’ID de charge de travail Microsoft Entra

Configurer un principal de service

Déployer le module complémentaire AGIC

Créer un manifeste de déploiement pour le contrôleur d’entrée

Déployer le contrôleur d’entrée

Installer le contrôleur d’entrée en tant que chart Helm

Configurer un déploiement Application Gateway partagé

Exemple de scénario

Activer un déploiement Application Gateway partagé à l’aide d’une nouvelle installation AGIC

Élargir les autorisations

Activer un déploiement Application Gateway partagé pour une installation AGIC existante

Commentaires

Ressources supplémentaires

Partage via

Installer AGIC à l’aide d’un déploiement Application Gateway existant

Prérequis

Ajoutez le référentiel Helm.

Sauvegarder le déploiement d’Application Gateway

Configurer une identité pour l’authentification Resource Manager

Configurer l’ID de charge de travail Microsoft Entra

Configurer un principal de service

Déployer le module complémentaire AGIC

Créer un manifeste de déploiement pour le contrôleur d’entrée

Déployer le contrôleur d’entrée

Installer le contrôleur d’entrée en tant que chart Helm

Configurer un déploiement Application Gateway partagé

Exemple de scénario

Activer un déploiement Application Gateway partagé à l’aide d’une nouvelle installation AGIC

Élargir les autorisations

Activer un déploiement Application Gateway partagé pour une installation AGIC existante

Contenu connexe

Commentaires

Ressources supplémentaires