Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Avertissement
Le réseau SIG Kubernetes et le Comité de réponse à la sécurité ont annoncé la mise hors service du projet NGINX d’entrée, avec la maintenance se terminant en mars 2026. Aucune action immédiate n’est requise aujourd’hui pour les clusters AKS à l’aide du module complémentaire de routage des applications avec NGINX. Microsoft fournira une prise en charge officielle des correctifs de sécurité critiques pour les ressources NGINX Ingress de l'add-on de routage d'applications jusqu’en novembre 2026.
AKS s’aligne sur Kubernetes en amont en passant à l’API de passerelle comme standard à long terme pour la gestion du trafic d’entrée et L7. Nous vous recommandons de commencer à planifier votre chemin de migration en fonction de votre configuration actuelle :
- Utilisateurs du module complémentaire de routage des applications : les charges de travail de production restent entièrement prises en charge jusqu’en novembre 2026. Migrez vers la mise en œuvre de l’API de routage d’application Gateway pour une expérience de gestion du trafic d’entrée basée sur l’API Gateway.
-
Les utilisateurs OSS NGINX ont plusieurs options :
- Migrez vers le module complémentaire de routage des applications avec NGINX pour bénéficier d’une prise en charge officielle jusqu’en novembre 2026 tout en planifiant votre migration d’API de passerelle à long terme.
- Migrez vers la mise en œuvre de l’API de routage d’application Gateway pour une expérience de gestion du trafic d’entrée basée sur l’API Gateway.
- Migrez vers Application Gateway pour conteneurs, qui prend en charge l’API d’entrée et l’API de passerelle.
- Utilisateurs du maillage de service : si vous envisagez d’adopter un maillage de service, tenez compte du module complémentaire de maillage de service basé sur Istio. Utilisez Istio Ingress dès aujourd’hui et anticipez une migration vers la prise en charge de l’API Istio Gateway lorsqu’elle sera disponible en version finale.
L’entrée dans AKS est une ressource Kubernetes qui gère l’accès au trafic de type HTTP externe aux services au sein d’un cluster. Une entrée AKS peut fournir des services tels que l’équilibrage de charge, la terminaison SSL et l’hébergement virtuel basé sur des noms. Pour plus d’informations sur l’entrée Kubernetes, consultez la documentation sur l’entrée Kubernetes.
Pour la plupart des charges de travail de production, commencez par AKS Automatic. AKS Automatic est la valeur par défaut recommandée pour la production dans AKS et fournit des valeurs par défaut gérées pour la mise en réseau, la mise à l’échelle, la sécurité, la surveillance et les mises à niveau. Pour l’entrée, cela signifie que vous pouvez commencer par le chemin d’entrée managé et passer uniquement à des options plus spécialisées lorsque vous avez besoin d’un contrôle plus approfondi sur la topologie, le comportement de routage ou l’intégration du maillage de service.
Utilisez AKS Standard lorsque vous avez besoin d’un contrôle plus explicite sur la sélection du contrôleur d’entrée, la topologie de déploiement ou l’intégration réseau avancée.
Modes de cluster AKS et entrée
AKS prend en charge deux modes de cluster :
- AKS Automatic : point de départ recommandé pour la plupart des charges de travail de production. Cela réduit la surcharge opérationnelle et vous offre des valeurs par défaut gérées pour les composants réseau d’entrée et associés.
- AKS Standard : mieux quand vous avez besoin d’un contrôle explicite sur l’hébergement du contrôleur d’entrée, l’exposition au service et les modèles de gestion du trafic avancés.
Les instructions d’entrée de cet article s’appliquent aux deux modes. La principale différence est celle qui possède davantage les valeurs par défaut de la plateforme et la quantité de personnalisation dont vous avez besoin pour gérer directement.
Contrôleurs d’entrée
Lors de la gestion du trafic d’application, les contrôleurs d’entrée fournissent des fonctionnalités avancées en opérant au niveau de la couche 7. Ils peuvent acheminer le trafic HTTP vers différentes applications en fonction de l’URL entrante, ce qui permet d’obtenir des règles de distribution de trafic plus intelligentes et flexibles. Par exemple, un contrôleur d’entrée peut diriger le trafic vers différents microservices en fonction du chemin de l’URL, ce qui améliore l’efficacité et l’organisation de vos services.
D’un autre côté, un service de type LoadBalancer, lorsqu’il est créé, configure une ressource d’équilibreur de charge Azure sous-jacente. Cet équilibreur de charge fonctionne au niveau de la couche 4, en distribuant le trafic vers les pods de votre service sur un port spécifié. Toutefois, les services de la couche 4 ne connaissent pas les applications réelles et ne peuvent pas implémenter ces types de règles de routage complexes.
Comprendre la distinction entre ces deux approches vous permet de sélectionner l’outil approprié pour vos besoins de gestion du trafic.
Si vous utilisez AKS Automatic, commencez par le chemin d’entrée managé d’abord et utilisez des options plus spécialisées uniquement lorsque votre charge de travail les nécessite. Dans AKS Standard, vous avez plus de flexibilité pour choisir le contrôleur d’entrée et la topologie qui correspondent le mieux à votre architecture.
Comparer les options d’entrée
Comparaison des fonctionnalités
Le tableau suivant répertorie les différences de fonctionnalités entre les différentes options du contrôleur d’entrée. Pour la plupart des charges de travail AKS de production, le chemin d’accès par défaut recommandé est l’approche d’entrée managée dans AKS Automatic, sauf si vous avez spécifiquement besoin d’un routage personnalisé, d’une intégration de maillage de service ou d’une entrée hébergée par Azure.
| Fonctionnalité | Module complémentaire de routage des applications | Passerelle d'applications pour conteneurs | Azure Service Mesh/Istio-based service mesh |
|---|---|---|---|
| Contrôleur d’entrée/Gateway | Contrôleur d’entrée NGINX | Azure Application Gateway pour les conteneurs | Passerelle d’entrée Istio |
| API | API d’entrée | API d’entrée et API de passerelle | API d’entrée Istio |
| Hébergement | Dans le cluster | Hébergement par Azure | Dans le cluster |
| Mise à l’échelle | Mise à l’échelle automatique | Mise à l’échelle automatique | Mise à l’échelle automatique |
| Équilibrage de charge | Interne/Externe | Externe | Interne/Externe |
| Terminaison SSL | Dans le cluster | Oui : Déchargement et SSL E2E | Dans le cluster |
| mTLS | N/A | Oui : frontend et backend | Oui |
| Adresse IP statique | Oui | FQDN (sans adresse IP statique) | N/A |
| Certificats SSL stockés dans Azure Key Vault | Oui | Oui | N/A |
| Intégration d’Azure DNS pour la gestion des zones DNS | Oui | Oui | N/A |
Quand utiliser chaque contrôleur d’entrée
Le tableau suivant répertorie les différents scénarios dans lesquels vous êtes susceptible d’utiliser chaque contrôleur d’entrée :
| Option d’entrée | Quand l’utiliser |
|---|---|
| NGINX managé - Module complémentaire routage des applications | • Contrôleurs d’entrée NGINX personnalisables, évolutifs et hébergés dans le cluster. • Fonctionnalités d’équilibrage de charge et de routage de base. • Configuration de l’équilibreur de charge interne et externe. • Configuration de l’adresse IP statique. • Intégration à Azure Key Vault pour la gestion des certificats. • Intégration à Azure DNS Zones pour la gestion DNS publique et privée. • Prend en charge l’API Ingress. |
| Passerelle d’applications pour conteneurs | • Passerelle d’entrée hébergée par Azure. • Stratégies de déploiement flexibles gérées par le contrôleur ou apportez votre propre application Gateway pour conteneurs. • Fonctionnalités avancées de gestion du trafic, telles que les nouvelles tentatives automatiques, la résilience des zones de disponibilité, l’authentification mutuelle (mTLS) auprès de la cible back-end, le fractionnement du trafic/tourniquet (round robin) pondéré et la mise à l’échelle automatique. • Intégration à Azure Key Vault pour la gestion des certificats. • Intégration à Azure DNS Zones pour la gestion DNS publique et privée. • Prend en charge les API Ingress et Gateway. |
| Passerelle d’entrée Istio | • Basé sur Envoy, lors de l’utilisation avec Istio pour un maillage de services. • Fonctionnalités avancées de gestion du trafic, telles que la limitation du débit et la rupture de circuit. • Prise en charge de mTLS. |
Remarque
Le module complémentaire Istio ne prend actuellement pas en charge l’API de passerelle pour le trafic d’entrée Istio.
Créer une ressource d’entrée
Le module complémentaire De routage des applications est la méthode recommandée pour configurer un contrôleur d’entrée dans AKS, et il s’agit du chemin d’entrée managé à utiliser dans AKS Automatic pour la plupart des charges de travail. Le module complémentaire de routage des applications est un contrôleur d’entrée entièrement managé pour AKS qui fournit les fonctionnalités suivantes :
- Configuration simple 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 la plupart des charges de travail de production, il s’agit du bon point de départ par défaut. Si vous avez besoin d’une topologie d’ingress personnalisée, d’un ingress hébergé sur Azure ou d’un comportement de service mesh, vous pouvez passer à l’une des autres options d’ingress.
Pour plus d’informations sur le module complémentaire Application Routing, consultez Ingress NGINX géré avec le module complémentaire Application Routing.
Préservation de l’adresse IP source du client
Configurez votre contrôleur d’entrée pour qu’il conserve l’adresse IP source de client dans les requêtes adressées aux conteneurs de votre cluster AKS. Lorsque votre contrôleur d’entrée achemine la requête d’un client vers un conteneur de votre cluster AKS, l’adresse IP source originale de cette requête n’est pas disponible pour le conteneur cible. Lorsque vous activez la conservation de l’adresse IP source de client, l’adresse IP source du client est disponible dans l’en-tête de requête sous X-Forwarded-For.
Si vous utilisez la conservation de l’adresse IP source du client sur votre contrôleur d’entrée, vous ne pouvez pas utiliser le protocole TLS direct. La conservation de l’adresse IP source de client et le protocole TLS direct peuvent être utilisés avec d’autres services, tels que le type LoadBalancer.
Cela reste un choix de conception important dans AKS Automatic et AKS Standard, car la gestion ip source affecte l’observabilité, l’auditabilité et le comportement de l’application, quel que soit le mode de cluster.
Pour en savoir plus sur la préservation de l’adresse IP source cliente, consultez Fonctionnement de la préservation de l’adresse IP source cliente pour les services LoadBalancer dans AKS.