Entrée NGINX managée avec le module complémentaire de routage d’applications

L’un des moyens d’acheminer le trafic HTTP (Hypertext Transfer Protocol) et HTTPS (sécurisé) vers des applications s’exécutant sur un cluster Azure Kubernetes Service (AKS) consiste à utiliser l’objet d’entrée Kubernetes. Lorsque vous activez le module complémentaire de routage des applications avec NGINX, il crée, configure et gère un contrôleur d’entrée dans votre cluster AKS.

Cet article explique comment activer le contrôleur d’entrée NGINX managé et configurer un objet d’entrée pour router le trafic vers une application dans votre cluster AKS.

Module complémentaire de routage d’applications avec les fonctionnalités de NGINX

Le module complémentaire de routage d’applications avec NGINX offre les avantages suivants :

• Configuration facile des contrôleurs d'entrée NGINX managés basés sur le contrôleur d’entrée NGINX Kubernetes.
• Intégration à Azure DNS pour la gestion des zones publiques et privées.
• Arrêt SSL avec des certificats stockés dans Azure Key Vault

Pour les autres configurations, consultez :

• Configuration DNS et SSL.
• Configuration du module complémentaire de routage des applications.
• Configurez le contrôleur d’entrée NGINX interne pour Azure zone DNS privée.

Conditions préalables

• Un abonnement Azure. Si vous n’avez pas d’abonnement Azure, vous pouvez créer un compte gratuit.
• Azure CLI version 2.54.0 ou ultérieure installé et configuré. Exécutez az --version pour trouver la version. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI.

Limites

• Le module complémentaire de routage d’applications prend en charge jusqu’à cinq zones Azure DNS.

• Le module complémentaire de routage d’applications ne peut être activé que sur des clusters AKS avec identité managée.

• Toutes les zones Azure DNS globales intégrées au module complémentaire doivent se trouver dans le même groupe de ressources.

• Toutes les zones Azure DNS privées intégrées au module complémentaire doivent se trouver dans le même groupe de ressources.

• La modification du ConfigMap ingress-nginx dans l’espace de noms app-routing-system n’est pas prise en charge.

• Si une valeur d’annotation de snippet correspond à l’une des valeurs bloquées suivantes, l’Ingress n’est pas configuré :

  Valeur bloquée	Résultat
  load_module	L’Ingress n’est pas configuré.
  lua_package	L’Ingress n’est pas configuré.
  _by_lua	L’Ingress n’est pas configuré.
  location	L’Ingress n’est pas configuré.
  root	L’Ingress n’est pas configuré.
  proxy_pass	L’Ingress n’est pas configuré.
  serviceaccount	L’Ingress n’est pas configuré.
  {	L’Ingress n’est pas configuré.
  }	L’Ingress n’est pas configuré.
  '	L’Ingress n’est pas configuré.

• Le module complémentaire ne prend pas officiellement en charge l’injection de sidecars non gérés par Microsoft (par exemple, des agents de télémétrie personnalisés, de journalisation ou de sécurité) dans les pods proxy ingress-nginx qu’il gère. Si vous choisissez d’injecter votre propre side-car dans un pod proxy géré, Microsoft fournit uniquement une assistance dans la mesure du possible pour tout problème que vous rencontrez.

Clusters multilocataires

Le contrôleur Ingress NGINX géré est basé sur le projet ingress-nginx d’origine. Le projet ingress-nginx suppose que les utilisateurs qui peuvent créer des objets Ingress sont des administrateurs de cluster. Le projet indique de ne pas utiliser ingress-nginx dans les clusters de production multilocataires. Pour plus d’informations, consultez Kubernetes multilocataire dans la FAQ d’ingress-nginx.

Les comportements suivants s’étendent au-delà des limites des espaces de noms :

• Un contrôleur Ingress NGINX sert les objets Ingress de sa classe Ingress à partir de tous les espaces de noms. Le contrôleur fusionne les règles de ces objets Ingress dans une configuration NGINX. Pour plus d’informations, voir Fonctionnement.
• Un Ingress dans un espace de noms peut ajouter des chemins à un hôte qu’un Ingress dans un autre espace de noms utilise. Si deux objets Ingress utilisent le même hôte, l’objet Ingress le plus ancien contrôle les paramètres TLS et les annotations au niveau du serveur pour cet hôte. S’ils utilisent également le même chemin d’accès, l’objet Ingress le plus ancien obtient le trafic pour ce chemin.
• Le module complémentaire autorise les annotations d’extraits de code, à l’exception des valeurs bloquées dans Limitations. Les annotations snippet ajoutent la configuration NGINX au contrôleur partagé.
• Le contrôleur d’entrée NGINX peut lire les secrets dans tous les espaces de noms. Le module complémentaire permet d’utiliser l’option allow-cross-namespace-resources. À l’aide de cette option, certaines annotations peuvent référencer un secret ou ConfigMap dans un espace de noms différent.
• Un utilisateur qui peut créer une Ingress peut utiliser n’importe quelle classe Ingress. Un NginxIngressController distinct pour chaque locataire n’isole pas les locataires.

Pour réduire ce risque, utilisez ces pratiques :

• Accordez l’autorisation de créer ou de mettre à jour des objets Ingress uniquement aux utilisateurs auxquels vous faites autant confiance qu’aux administrateurs du cluster.
• Si les tenants ne se font pas confiance les uns aux autres, utilisez un cluster distinct pour chaque tenant. Pour plus d’informations, consultez grappes physiquement isolées.

Activer le module complémentaire de routage des applications à l’aide de Azure CLI

Activer sur un nouveau cluster

Pour activer le routage d’applications sur un nouveau cluster, utilisez la commande az aks create en spécifiant l’indicateur --enable-app-routing.

az aks create \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --location <location> \
    --enable-app-routing \
    --generate-ssh-keys

Activer sur un cluster existant

Pour activer le routage d’applications sur un cluster existant, utilisez la commande az aks approuting enable.

az aks approuting enable --resource-group <resource-group-name> --name <cluster-name>

Se connecter à votre cluster AKS

Pour vous connecter au cluster Kubernetes à partir de votre ordinateur local, vous utilisez kubectl, le client de ligne de commande Kubernetes. Vous pouvez l’installer localement avec la commande az aks install-cli. Si vous utilisez Azure Cloud Shell, kubectl est déjà installé.

Configurez kubectl afin de vous connecter à votre cluster Kubernetes avec la commande az aks get-credentials.

az aks get-credentials --resource-group <resource-group-name> --name <cluster-name>

Déployer une application

Les objets d’entrée Kubernetes définissent des règles de routage pour un contrôleur d’entrée. Utilisez la classe d’entrée managée du module complémentaire de routage d’application et les annotations prises en charge pour configurer la façon dont son contrôleur gère le trafic.

1. Créez un espace de noms de l’application appelé aks-store pour exécuter les exemples de pods à l’aide de la commande kubectl create namespace.

   kubectl create namespace aks-store
   

2. Déployez l’application de magasin AKS à l’aide du fichier manifeste YAML suivant :

   kubectl apply -f https://raw.githubusercontent.com/Azure-Samples/aks-store-demo/main/sample-manifests/docs/app-routing/aks-store-deployments-and-services.yaml -n aks-store
   

Ce manifeste crée les déploiements rabbitmq, order-service, product-service et store-front, ainsi que les services correspondants. Le service expose le store-front port 80, vers lequel l’entrée est acheminée dans la section suivante.

Créer l’objet d'entrée

Lorsque vous activez le module complémentaire de routage d’application, il crée une classe d’entrée nommée webapprouting.kubernetes.azure.com. Spécifiez cette classe dans un objet d’entrée pour utiliser le contrôleur d’entrée NGINX managé du module complémentaire.

1. Copiez le manifeste YAML suivant dans un nouveau fichier nommé ingress.yaml et enregistrez le fichier sur votre ordinateur local.

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: store-front
     namespace: aks-store
   spec:
     ingressClassName: webapprouting.kubernetes.azure.com
     rules:
     - http:
         paths:
         - backend:
             service:
               name: store-front
               port:
                 number: 80
           path: /
           pathType: Prefix
   

2. Créez la ressource d’entrée avec la commande kubectl apply.

   kubectl apply -f ingress.yaml -n aks-store
   

   La sortie de l’exemple suivant montre la ressource créée :

   ingress.networking.k8s.io/store-front created
   

Vérifier la ressource Ingress gérée

Vous pouvez vérifier que l’entrée managée a été créée avec la commande kubectl get ingress.

kubectl get ingress -n aks-store

L’exemple de sortie suivant montre l’entrée managée créée :

NAME          CLASS                                HOSTS   ADDRESS       PORTS   AGE
store-front   webapprouting.kubernetes.azure.com   *       51.8.10.109   80      110s

Vous pouvez vérifier que la boutique AKS fonctionne en dirigeant votre navigateur vers l’adresse IP publique du contrôleur Ingress. La commande suivante récupère l’adresse IP externe attribuée par l’équilibreur de charge au Service nginx du contrôleur d’entrée NGINX géré dans l’espace de noms app-routing-system :

kubectl get service -n app-routing-system nginx -o jsonpath="{.status.loadBalancer.ingress[0].ip}"

Supprimer le module complémentaire de routage d’applications

Pour supprimer l’espace de noms associé, utilisez la commande kubectl delete namespace.

kubectl delete namespace aks-store

Pour supprimer le module complémentaire de routage d’applications de votre cluster, utilisez la commande az aks approuting disable.

az aks approuting disable --name <cluster-name> --resource-group <resource-group-name>

Contenu connexe

• Activez l’implémentation de l’API passerelle de routage d’application pour gérer le trafic d’entrée avec l’API de passerelle Kubernetes.
• Configurer des configurations d’entrée personnalisées montre comment créer une configuration d’entrée avancée. Configurez un domaine personnalisé à l’aide de Azure DNS pour gérer les zones DNS et configurer une entrée sécurisée.
• Pour intégrer un équilibreur de charge interne Azure et configurer une zone DNS Azure privée afin de permettre la résolution DNS des points de terminaison privés pour résoudre des domaines spécifiques, consultez Configurer un contrôleur d’entrée NGINX interne pour la zone DNS privée Azure.
• Découvrez comment surveiller les métriques du contrôleur d’entrée-nginx incluses dans le module complémentaire de routage d’application avec Prometheus dans Grafana (préversion) dans le cadre de l’analyse des performances et de l’utilisation de votre application.