Concepts de réseau pour les applications dans AKS (Azure Kubernetes Service)
Dans une approche du développement d’applications axée sur les microservices basés sur des conteneurs, les composants d’application travaillent ensemble pour traiter leurs tâches. Kubernetes fournit diverses ressources permettant cette coopération :
- Vous pouvez vous connecter aux applications et les exposer en interne ou en externe.
- Vous pouvez créer des applications hautement disponibles en équilibrant la charge de vos applications.
- Vous pouvez restreindre le flux du trafic vers ou entre les nœuds et les pods pour améliorer la sécurité.
- Pour vos applications plus complexes, vous pouvez configurer le trafic d’entrée pour la terminaison SSL/TLS ou le routage de plusieurs composants.
Cet article présente les concepts fondamentaux qui fournissent la mise en réseau à vos applications dans AKS :
Principes de base des réseaux Kubernetes
Kubernetes utilise une couche de réseau virtuel pour gérer l’accès dans et entre vos applications ou leurs composants :
Nœuds Kubernetes et réseau virtuel : Les nœuds Kubernetes sont connectés à un réseau virtuel. Cette configuration permet aux pods (unités de déploiement de base dans Kubernetes) d’avoir une connectivité à la fois entrante et sortante.
Composant kube-proxy : kube-proxy s’exécute sur chaque nœud et il est chargé de fournir les fonctionnalités réseau nécessaires.
Fonctionnalités propres à Kubernetes :
- Équilibreur de charge : Vous pouvez utiliser un équilibreur de charge pour distribuer uniformément le trafic réseau entre différentes ressources.
- Contrôleurs d’entrée : Ils facilitent le routage de couche 7, qui est essentiel pour diriger le trafic d’application.
- Contrôle de trafic sortant : Kubernetes vous permet de gérer et de contrôler le trafic sortant à partir de nœuds de cluster.
- Stratégies réseau: Ces stratégies activent les mesures de sécurité et le filtrage du trafic réseau dans les pods.
Dans le contexte de la plateforme Azure :
- Azure simplifie les réseaux virtuels pour les clusters AKS (Azure Kubernetes Service).
- La création d’un équilibreur de charge Kubernetes sur Azure configure simultanément la ressource d’équilibreur de charge Azure correspondante.
- Quand vous ouvrez des ports réseau sur les pods, Azure configure automatiquement les règles de groupe de sécurité réseau nécessaires.
- Azure peut également gérer des configurations DNS externes pour le routage d’application HTTP quand de nouvelles routes d’entrée sont établies.
Réseaux virtuels Azure
Dans AKS, vous pouvez déployer un cluster qui utilise un des modèles de réseau suivants :
Mise en réseau Kubenet
Les ressources réseau sont généralement créées et configurées lors du déploiement du cluster AKS.
Mise en réseau Azure Container Networking Interface (CNI)
Le cluster AKS est connecté aux ressources et configurations de réseau virtuel existantes.
Mise en réseau Kubenet (de base)
L’option de mise en réseau kubenet est la configuration par défaut de la création de cluster AKS. Avec kubenet :
- Les nœuds reçoivent une adresse IP du sous-réseau du réseau virtuel Azure.
- Les pods reçoivent une adresse IP d’un espace d’adressage logiquement différent du sous-réseau du réseau virtuel Azure des nœuds.
- La traduction d’adresses réseau (NAT) est ensuite configurée afin que les pods puissent accéder aux ressources sur le réseau virtuel Azure.
- L’adresse IP source du trafic est traduite en adresse IP principale du nœud.
Les nœuds utilisent le plug-in Kubernetes kubenet. Vous pouvez laisser la plateforme Azure créer et configurer les réseaux virtuels pour vous ou choisir de déployer votre cluster AKS dans un sous-réseau de réseau virtuel existant.
Seuls les nœuds reçoivent une adresse IP routable. Les pods utilisent la traduction d’adresses réseau pour communiquer avec d’autres ressources en dehors du cluster AKS. Cette approche réduit le nombre d’adresses IP que vous devez réserver dans votre espace réseau à l’usage des pods.
Remarque
Bien qu’un kubenet soit l’option de mise en réseau par défaut pour un cluster AKS afin de créer un réseau virtuel et un sous-réseau, il n’est pas recommandé pour les déploiements de production. Pour la plupart des déploiements de production, vous devez planifier et utiliser une mise en réseau Azure CNI en raison de ses caractéristiques de scalabilité et d’un niveau de performance supérieur.
Pour plus d’informations, consultez Configurer une mise en réseau kubenet pour un cluster AKS.
Mise en réseau Azure CNI (avancée)
Avec Azure CNI, chaque pod reçoit une adresse IP du sous-réseau et est accessible directement. Ces adresses IP doivent être planifiées et être uniques dans votre espace réseau. Chaque nœud possède un paramètre de configuration pour le nombre maximal de pods qu’il prend en charge. Le nombre équivalent d’adresses IP par nœud est alors réservé à l’avance. Cette approche peut conduire à l’épuisement des adresses IP ou à la nécessité de regénérer les clusters dans un sous-réseau plus vaste à mesure que vos demandes d’applications augmentent. Il est donc important de bien planifier. Pour éviter ces défis de planification, il est possible d’activer la fonctionnalité de mise en réseau Azure CNI pour l’allocation dynamique d’adresses IP et une prise en charge améliorée des sous-réseaux.
Remarque
En raison des limitations Kubernetes, les noms du groupe de ressources, du réseau virtuel et du sous-réseau doivent compter au plus 63 caractères.
Contrairement à kubenet, le trafic vers les points de terminaison dans le même réseau virtuel ne fait pas l’objet d’une traduction d’adresses réseau (NAT) vers l’adresse IP principale du nœud. L’adresse source pour le trafic à l’intérieur du réseau virtuel est l’adresse IP du pod. Le trafic externe au réseau virtuel continue de faire l’objet d’une traduction d’adresses réseau (NAT) vers l’adresse IP principale du nœud.
Les nœuds utilisent le plug-in Kubernetes Azure CNI.
Pour plus d’informations, consultez Configurer Azure CNI pour un cluster AKS.
Réseau de superposition Azure CNI
La Superposition Azure CNI représente une évolution d’Azure CNI, qui répond aux défis de scalabilité et de planification liés à l’affectation d’adresses IP de réseau virtuel à des pods. Azure CNI Overlay affecte des adresses IP CIDR privées aux pods. Les adresses IP privées sont distinctes du réseau virtuel et peuvent être réutilisées sur plusieurs clusters. La superposition Azure CNI peut être mise à l’échelle au-delà de la limite de 400 nœuds appliquée dans les clusters Kubenet. La superposition Azure CNI est l’option recommandée pour la plupart des clusters.
Azure CNI avec Cilium
Azure CNI avec Cilium utilise Cilium pour fournir une mise en réseau, une observabilité et une application de stratégie réseau hautes performances. Il s’intègre en mode natif à la superposition Azure CNI pour la gestion évolutive des adresses IP (IPAM).
En outre, Cilium applique les stratégies réseau par défaut, sans nécessiter de moteur de stratégie réseau distinct. Azure CNI avec Cilium peut être mis à l’échelle au-delà des limites d’Azure Network Policy Manager de 250 nœuds / 20-K pods avec des programmes eBPF et d’une structure d’objets API plus efficace.
Azure CNI avec Cilium est l’option recommandée pour les clusters qui nécessitent une application de stratégie réseau.
Utiliser votre propre CNI
Il est possible d’installer dans AKS un CNI autre que Microsoft à l’aide de la fonctionnalité Bring your own CNI .
Comparer des modèles de réseaux
Kubenet et Azure CNI fournissent une connectivité réseau pour vos clusters AKS. Chacun présente toutefois des avantages et des inconvénients. À un niveau élevé, les considérations suivantes s’appliquent :
Kubenet
- Conserve l’espace d’adressage IP.
- Utilise les équilibreurs de charge internes ou externes Kubernetes pour atteindre des pods depuis l’extérieur du cluster.
- Vous gérez et mettez à jour manuellement les itinéraires définis par l’utilisateur (UDR).
- 400 nœuds maximum par cluster.
Azure CNI
- Les pods bénéficient de la connectivité complète du réseau virtuel et sont directement accessibles via leur adresse IP privée depuis des réseaux connectés.
- Nécessite plus d’espace d’adressage IP.
| Modèle réseau | Quand l’utiliser |
|---|---|
| Kubenet | • La conservation de l’espace d’adressage IP est une priorité. • Configuration simple. • Moins de 400 nœuds par cluster. • Équilibreurs de charge internes ou externes Kubernetes sont suffisants pour atteindre des pods depuis l’extérieur du cluster. • La gestion et la maintenance manuelles des itinéraires définis par l’utilisateur sont acceptables. |
| Azure CNI | • Une connectivité de réseau virtuel complète est requise pour les pods • Des fonctionnalités AKS avancées, comme des nœuds virtuels, sont nécessaires. • Un espace d’adressage IP suffisant est disponible. • La connectivité de pod à pod et de pod à machine virtuelle est nécessaire. • Les ressources externes doivent atteindre directement les pods. • Les stratégies réseau AKS sont requises. |
| Superposition Azure CNI | • La pénurie d’adresses IP est un problème. • La mise à l’échelle jusqu’à 1,000 nœuds et 250 pods par nœud est suffisante. • Un tronçon supplémentaire pour la connectivité des pods est acceptable. • Configuration du réseau plus simple. • Les exigences de sortie AKS peuvent être satisfaites. |
Les différences de comportement suivantes existent entre kubenet et Azure CNI :
| Fonctionnalité | Kubenet | Azure CNI | Superposition Azure CNI | Azure CNI avec Cilium |
|---|---|---|---|---|
| Déployer un cluster dans un réseau virtuel nouveau ou existant | Pris en charge : UDR appliqués manuellement | Prise en charge | Prise en charge | Prise en charge |
| Connectivité pod-pod | Prise en charge | Prise en charge | Prise en charge | Prise en charge |
| Connectivité pod-machine virtuelle ; la machine virtuelle se trouve dans le même réseau virtuel | S’applique si initié par le pod | S’applique dans les deux sens | S’applique si initié par le pod | S’applique si initié par le pod |
| Connectivité pod-machine virtuelle ; la machine virtuelle se trouve dans un réseau virtuel homologué | S’applique si initié par le pod | S’applique dans les deux sens | S’applique si initié par le pod | S’applique si initié par le pod |
| Accès local à l’aide de VPN ou d’Express Route | S’applique si initié par le pod | S’applique dans les deux sens | S’applique si initié par le pod | S’applique si initié par le pod |
| Accès à des ressources sécurisées par des points de terminaison de service | Prise en charge | Prise en charge | Prise en charge | |
| Exposer des services Kubernetes à l’aide d’un service d’équilibreur de charge, App Gateway ou d’un contrôleur d’entrée | Prise en charge | Prise en charge | Prise en charge | Les limitations sont identiques lors de l’utilisation du mode Superposition |
| Prise en charge des pools de nœuds Windows | Non pris en charge | Prise en charge | Prise en charge | Disponible uniquement pour Linux et non pour Windows. |
| Azure DNS et zones privées par défaut | Prise en charge | Prise en charge | Prise en charge |
Pour plus d’informations sur Azure CNI et kubenet et pour déterminer l’option qui vous convient le mieux, consultez Configurer un réseau Azure CNI dans AKS et Utiliser la mise en réseau kubenet dans AKS.
Étendue du support entre des modèles de réseaux
Quel que soit le modèle de réseau que vous utilisez, kubenet et Azure CNI peuvent être déployés de l’une des manières suivantes :
- La plateforme Azure peut automatiquement créer et configurer les ressources de réseau virtuel lorsque vous créez un cluster AKS.
- Vous pouvez créer et configurer manuellement les ressources de réseau virtuel et joindre à ces ressources lorsque vous créez votre cluster AKS.
Bien que des fonctionnalités telles que les points de terminaison de service ou les UDR soient prises en charge avec kubenet et Azure CNI, les stratégies de support pour AKS définissent les modifications que vous pouvez apporter. Par exemple :
- Si vous créez manuellement les ressources de réseau virtuel pour un cluster AKS, une prise en charge est assurée lorsque vous configurez vos propres UDR ou points de terminaison de service.
- Si la plateforme Azure crée automatiquement les ressources de réseau virtuel pour votre cluster AKS, vous ne pouvez pas modifier manuellement ces ressources managées par AKS pour configurer vos propres UDR ou points de terminaison de service.
Contrôleurs d’entrée
Quand vous créez un service de type LoadBalancer, vous créez également une ressource d’équilibreur de charge Azure sous-jacente. L’équilibreur de charge est configuré pour distribuer le trafic vers les pods dans votre service sur un port donné.
Le LoadBalancer fonctionne uniquement au niveau de la couche 4. Au niveau de la couche 4, le service n’a pas connaissance des applications réelles et n’intervient pas dans le routage.
Les contrôleurs d’entrée fonctionnant au niveau de la couche 7, ils peuvent utiliser des règles plus intelligentes pour distribuer le trafic des applications. Les contrôleurs d’entrée acheminent généralement le trafic HTTP vers différentes applications en fonction de l’URL d’entrée.
Comparer les options d’entrée
Le tableau suivant répertorie les différences de fonctionnalités entre les différentes options de contrôleur d’entrée :
| Fonctionnalité | Module complémentaire de routage d’applications | Application Gateway pour les conteneurs | Azure Service Mesh/maillage de services Istio |
|---|---|---|---|
| Contrôleur d’entrée/passerelle | Contrôleur d’entrée NGINX | Passerelle Azure Application Gateway pour les conteneurs | Passerelle d’entrée Istio |
| API | API d’entrée | API Entrée et API Passerelle | API Gateway |
| Hébergement | Dans le cluster | Hébergé 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 |
| Arrêt SSL | Dans le cluster | Oui : Déchargement et SSL E2E | Dans le cluster |
| mTLS | S/O | Oui vers le back-end | S/O |
| Adresse IP statique | S/O | FQDN | S/O |
| Certificats SSL stockés dans Azure Key Vault | Oui | Oui | S/O |
| Intégration d’Azure DNS pour la gestion des zones DNS | Oui | Oui | S/O |
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 utiliser |
|---|---|
| NGINX managé – Module complémentaire de routage d’applications | • Contrôleurs d’entrée NGINX personnalisables, évolutifs et hébergés dans le cluster. • Capacités de base d’équilibrage de charge et de routage. • Configuration d’équilibreur de charge interne et externe. • Configuration d’adresse IP statique. • Intégration à Azure Key Vault pour la gestion des certificats. • Intégration aux zones Azure DNS pour la gestion des systèmes DNS publics et privés. • Prend en charge l’API Entrée. |
| Passerelle d’application pour conteneurs | • Passerelle d’entrée hébergée par Azure. • Stratégies de déploiement flexible gérées par le contrôleur, ou apportez votre propre Passerelle d’application 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 pondéré, et la mise à l’échelle automatique. • Intégration à Azure Key Vault pour la gestion des certificats. • Intégration aux zones Azure DNS pour la gestion des systèmes DNS publics et privés. • Prise en charge des API Entrée et Passerelle. |
| 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 de débit et la rupture de circuit. • Prise en charge de mTLS • Prise en charge l’API Passerelle. |
Créer une ressource d’entrée
Le module complémentaire de routage d’application est la méthode recommandée pour configurer un contrôleur d’entrée dans AKS. Le module complémentaire de routage d’applications est un contrôleur d’entrée complètement managé pour Azure Kubernetes Service (AKS) qui fournit les fonctionnalités suivantes :
Configuration facile des contrôleurs NGINX Ingress 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 plus d’informations sur le module complémentaire de routage d’application, consultez Entrée MANAGED NGINX avec le module complémentaire de routage d’application.
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.
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.
Contrôler le trafic sortant (sortant)
Les clusters AKS sont déployés sur un réseau virtuel et ont des dépendances sortantes sur des services en dehors de ce réseau virtuel. Ces dépendances sortantes sont presque entièrement définies avec des noms de domaine complets (FQDN). Par défaut, les clusters AKS disposent d’un accès Internet sortant illimité, ce qui permet aux nœuds et aux services que vous exécutez d’accéder aux ressources externes en fonction des besoins. Si vous le souhaitez, vous pouvez restreindre le trafic sortant.
Pour plus d’informations, consultez Contrôler le trafic de sortie pour les nœuds de cluster dans AKS.
Groupes de sécurité réseau
Un groupe de sécurité réseau filtre le trafic pour des machines virtuelles comme les nœuds AKS. Quand vous créez des services, tels qu’un LoadBalancer, la plateforme Azure configure automatiquement toutes les règles de groupe de sécurité réseau nécessaires.
Vous n’avez pas besoin de configurer manuellement des règles de groupe de sécurité réseau pour filtrer le trafic des pods dans un cluster AKS. Vous pouvez définir les ports et le transfert requis dans le cadre de vos manifestes de services Kubernetes et laisser la plateforme Azure créer ou mettre à jour les règles appropriées.
Vous pouvez également utiliser des stratégies réseau pour appliquer automatiquement des règles de filtrage de trafic aux pods.
Pour plus d’informations, consultez l’article Façon dont les groupes de sécurité réseau filtrent le trafic.
Stratégies réseau
Par défaut, tous les pods d’un cluster AKS peuvent envoyer et recevoir du trafic sans aucune limite. Pour une sécurité accrue, définissez des règles qui contrôlent le flux de trafic, par exemple :
- Les applications back-end sont exposées uniquement aux services frontaux requis.
- Les composants de base de données sont uniquement accessibles aux couches Application qui s’y connectent.
L’utilisation de stratégies réseau est une fonctionnalité Kubernetes disponible dans AKS qui vous permet de contrôler le flux de trafic entre les pods. Vous pouvez autoriser ou refuser le trafic vers le pod en fonction de paramètres tels que les étiquettes attribuées, l’espace de noms ou le port de trafic. Bien que les groupes de sécurité réseau soient mieux adaptés aux nœuds AKS, les stratégies réseau sont un moyen natif Cloud plus adapté pour contrôler le flux de trafic pour les pods. Les pods étant créés de façon dynamique dans un cluster AKS, les stratégies réseau nécessaires peuvent être appliquées automatiquement.
Pour plus d’informations, consultez Sécuriser le trafic entre les pods avec des stratégies réseau dans Azure Kubernetes Service (AKS).
Étapes suivantes
Pour bien démarrer avec les réseaux AKS, créez et configurez un cluster AKS avec vos propres plages d’adresses IP à l’aide de kubenet ou d’Azure CNI.
Pour connaître les meilleures pratiques associées, consultez Meilleures pratiques relatives à la connectivité réseau et à la sécurité dans AKS.
Pour plus d’informations sur les concepts fondamentaux de Kubernetes et d’AKS, consultez les articles suivants :