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.

Plan

Prérequis

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

Sauvegarder la configuration de votre passerelle Application Gateway avant d’installer AGIC :

  1. À partir du portail Azure , accédez à votre instance Application Gateway.
  2. 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.

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

  1. 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"
    
  2. 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
    
  3. 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
    
  4. 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.

  1. 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
    
  2. Ajoutez le blob JSON encodé en base64 au fichier helm-config.yaml. Pour en savoir plus sur helm-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 :

  1. Ajoutez le référentiel Helm application-gateway-kubernetes-ingress et mettez à jour à Helm

    helm repo add application-gateway-kubernetes-ingress https://appgwingress.blob.core.windows.net/ingress-azure-helm-package/
    helm repo update
    
  2. 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>
    
  3. Modifiez helm-config.yam et renseignez les valeurs pour appgw et armAuth.

    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.

  4. Installez le chart Helm application-gateway-kubernetes-ingress avec la configuration helm-config.yaml de l’étape précédente

    helm 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
    
  5. 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 :

  1. À partir du portail Azure , accédez à votre instance de Application Gateway
  2. 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 :

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 :

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

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

  1. 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
    
  2. Affichez l’objet nouvellement créé :

    kubectl get AzureIngressProhibitedTargets
    
  3. 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.