Partager via


Activer la prise en charge de plusieurs espaces de noms dans un cluster AKS en utilisant AGIC

Les espaces de noms Kubernetes permettent de partitionner un cluster Kubernetes et de l’allouer à des sous-groupes d’une équipe plus grande. Ces sous-groupes peuvent ensuite déployer et gérer l’infrastructure avec des contrôles plus précis des ressources, de la sécurité et de la configuration. Kubernetes permet de définir indépendamment une ou plusieurs ressources d’entrée au sein de chaque espace de noms.

À partir de la version 0.7, le Contrôleur d’entrée Azure Application Gateway Kubernetes (AGIC, Application Gateway Ingress Controller) peut observer plusieurs espaces de noms et en ingérer les événements. Si un administrateur AKS (Azure Kubernetes Service) décide d’utiliser Azure Application Gateway comme entrée, tous les espaces de noms utilisent le même déploiement d’Application Gateway. Une seule installation d’AGIC surveille les espaces de noms accessibles et configure le déploiement Application Gateway associé.

La version 0.7 d’AGIC continue d’observer exclusivement l’espace de noms default, sauf si vous le remplacez explicitement par un ou plusieurs espaces de noms différents dans la configuration Helm.

Conseil

Envisagez une Passerelle d’application pour conteneurs pour votre solution d’entrée Kubernetes.

Activer la prise en charge de plusieurs espaces de noms

  1. Modifiez le fichier helm-config.yaml de l’une des manières suivantes :

    • Supprimez entièrement la clé watchNamespace du fichier helm-config.yaml. AGIC observe tous les espaces de noms.
    • Définissez watchNamespace sur une chaîne vide. AGIC observe tous les espaces de noms.
    • Ajoutez plusieurs espaces de noms, séparés par une virgule (par exemple, watchNamespace: default,secondNamespace). AGIC observe exclusivement ces espaces de noms.
  2. Appliquez les modifications du modèle Helm en exécutant helm install -f helm-config.yaml application-gateway-kubernetes-ingress/ingress-azure.

Une fois que vous avez déployé AGIC avec la capacité d’observer plusieurs espaces de noms, celui-ci effectue les actions suivantes :

  • Répertorie les ressources d’entrée de tous les espaces de noms accessibles
  • Filtre les ressources d’entrée annotées avec kubernetes.io/ingress.class: azure/application-gateway
  • Compose une configuration Application Gateway combinée
  • Applique la configuration au déploiement Application Gateway associé via Azure Resource Manager

Gérer les configurations conflictuelles

Des ressources d’entrée à plusieurs espaces de noms peuvent demander à AGIC de créer des configurations conflictuelles pour un seul déploiement Application Gateway. Autrement dit, deux entrées pourraient revendiquer le même domaine.

En haut de la hiérarchie, AGIC pourrait créer des écouteurs (adresse IP, port et hôte) et des règles d’acheminement (écouteur de liaison, pool de back-ends et paramètres HTTP). Plusieurs espaces de noms et entrées pourraient les partager.

À l’inverse, AGIC pourrait créer des chemins d’accès, des pools de back-ends, des paramètres HTTP et des certificats TLS pour un seul espace de noms et supprimer les doublons.

Par exemple, envisagez les ressources d’entrée en double suivantes qui sont définies dans les espaces de noms staging et production pour www.contoso.com :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: websocket-ingress
  namespace: staging
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
spec:
  rules:
    - host: www.contoso.com
      http:
        paths:
          - backend:
              serviceName: web-service
              servicePort: 80
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: websocket-ingress
  namespace: production
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
spec:
  rules:
    - host: www.contoso.com
      http:
        paths:
          - backend:
              serviceName: web-service
              servicePort: 80

Bien que les deux ressources d’entrée exigent que le trafic pour www.contoso.com soit acheminé vers les espaces de noms Kubernetes respectifs, un seul serveur principal peut fournir le trafic. AGIC crée une configuration sur la base de la « première entrée, première sortie » pour l’une des ressources. Si deux ressources d’entrée sont créées en même temps, la priorité va à la première selon l’ordre alphabétique. En fonction de cette propriété, AGIC crée les paramètres pour l’entrée production. Application Gateway est configuré avec les ressources suivantes :

  • Écouteur : fl-www.contoso.com-80
  • Règle d’acheminement : rr-www.contoso.com-80
  • Pool de back-ends : pool-production-contoso-web-service-80-bp-80
  • Paramètres HTTP : bp-production-contoso-web-service-80-80-websocket-ingress
  • Sonde d’intégrité : pb-production-contoso-web-service-80-websocket-ingress

Remarque

À l’exception de l’écouteur et de la règle d’acheminement, les ressources Application Gateway créées incluent le nom de l’espace de noms (production) pour lequel AGIC les a créées.

Si les deux ressources d’entrée sont introduites dans le cluster AKS à des moments différents, il est probable qu’AGIC se retrouve dans un scénario où il reconfigure Application Gateway et réachemine le trafic de namespace-B vers namespace-A.

Par exemple, si vous ajoutez staging en premier, AGIC configure Application Gateway pour acheminer le trafic vers le pool de back-ends intermédiaire. À un stade ultérieur, l’introduction de production entrée entraîne la réprogrammation d’Application Gateway par AGIC, qui commence à router le trafic vers le pool principal production .

Limiter l’accès aux espaces de noms

Par défaut, AGIC configure Application Gateway en fonction des entrées annotées dans n’importe quel espace de noms. Si vous souhaitez limiter ce comportement, vous disposez des options suivantes :

  • Limitez les espaces de noms en définissant explicitement ceux qu’AGIC doit observer via la clé YAML watchNamespace dans helm-config.yaml.
  • Utilisez les objets Role et RoleBinding pour limiter AGIC à des espaces de noms spécifiques.

Exemple de fichier de configuration Helm

    # 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 manages
    #
    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 watches
    # 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: AAD-Pod-Identity (https://github.com/Azure/aad-pod-identity)
    armAuth:
        type: aadPodIdentity
        identityResourceID: <identityResourceId>
        identityClientID:  <identityClientId>
    
    ## Alternatively you can use Service Principal credentials
    # armAuth:
    #    type: servicePrincipal
    #    secretJSON: <<Generate this value with: "az ad sp create-for-rbac --subscription <subscription-uuid> --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>