Concepts de mise en réseau pour les applications dans Azure Kubernetes Service (AKS)

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 de routage de service : selon le plan de données réseau, les nœuds utilisent soit kube-proxy Cilium pour le routage Kubernetes Service. Les clusters AKS qui utilisent Azure CNI basé sur Cilium n’utilisent pas kube-proxy.

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 la mise en réseau virtuelle 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.
  • Lorsque vous créez un service KubernetesLoadBalancer, Azure configure les règles de groupe de sécurité réseau nécessaires pour le trafic de service sur les ressources gérées par AKS.
  • Azure peut également gérer des configurations DNS externes pour le routage d’applications HTTP lorsque de nouveaux routes Ingress sont établies.

réseaux virtuels Azure

Dans AKS, vous pouvez déployer un cluster qui utilise un des modèles de réseau suivants :

  • Modèle de réseau de superposition : le réseau de superposition est le modèle de réseau le plus couramment utilisé dans Kubernetes. Les pods reçoivent une adresse IP à partir d’un CIDR privé et logiquement distinct du sous-réseau de réseau virtuel Azure où les nœuds AKS sont déployés. Ce modèle permet une scalabilité plus simple et améliorée par rapport au modèle de réseau plat.
  • Modèle de réseau plat : un modèle de réseau plat dans AKS affecte des adresses IP aux pods à partir d’un sous-réseau dans le même réseau virtuel Azure que les nœuds AKS. Pour le trafic réseau privé, l’adresse IP source qu’une destination voit dépend de l’option de gestion des adresses IP (IPAM). Azure CNI Pod Subnet préserve l’adresse IP du pod entre les réseaux virtuels connectés. Avec Azure CNI Node Subnet, les destinations situées dans le réseau virtuel du cluster voient l’adresse IP du pod, mais les destinations situées hors du réseau virtuel du cluster voient l’adresse IP du nœud. Pour le trafic sortant vers Internet, la méthode de sortie configurée détermine l’adresse IP source publique visible par les destinations sur Internet.

Pour plus d’informations sur les modèles de réseau dans AKS, consultez Réseau CNI 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, lesquels sont presque entièrement définis avec des noms de domaine complets (FQDN). AKS fournit plusieurs options de configuration de trafic sortant qui vous permettent de personnaliser la façon d’accéder à ces ressources externes.

Important

À compter de March 31, 2026, Azure Kubernetes Service (AKS) ne prend plus en charge l’accès sortant par défaut pour les machines virtuelles. Les nouveaux clusters AKS qui utilisent l’option de réseau virtuel managé par AKS placent les sous-réseaux de cluster dans des sous-réseaux privés par défaut (defaultOutboundAccess = false). Ce paramètre n’a pas d’impact sur le trafic de cluster géré par AKS, qui utilise des chemins sortants configurés explicitement. Il peut affecter des scénarios non pris en charge, tels que le déploiement d’autres ressources dans le même sous-réseau. Les clusters utilisant des réseaux virtuels BYO ne sont pas affectés par cette modification. Dans les configurations prises en charge, aucune action n’est requise. Pour plus d’informations sur cette mise hors service, consultez l’annonce de la mise hors service d'Azure Updates. Pour rester informé des annonces et des mises à jour, suivez les notes de publication AKS.

Options de configuration sortante

Pour plus d'informations sur les types de configuration de sortie d'un cluster AKS pris en charge, consultez Personnaliser la sortie de cluster avec des types de sortie dans Azure Kubernetes Service (AKS).

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 sur la façon de limiter le trafic sortant de votre cluster, 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. Lorsque vous créez des services, tels qu’un LoadBalancer, la plateforme Azure configure automatiquement les règles de groupe de sécurité réseau nécessaires pour le trafic de service sur les ressources gérées par AKS.

AKS n’applique pas de groupes de sécurité réseau à son sous-réseau ou modifie les groupes de sécurité réseau que vous associez à un sous-réseau fourni par le client. Si vous associez un groupe de sécurité réseau à un sous-réseau personnalisé, vous devez vous assurer que ses règles autorisent le trafic de nœud et de pod requis. Pour plus d’informations, consultez les prérequis de mise en réseau AKS CNI.

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.

Configuration requise pour le réseau virtuel personnalisé

Lorsque vous utilisez un réseau virtuel personnalisé avec des clusters AKS, si vous ajoutez des règles de groupe de sécurité réseau pour restreindre le trafic entre les sous-réseaux, vérifiez que les règles autorisent le trafic requis par la configuration de votre cluster.

L’intégration au réseau virtuel du serveur d’API est préconfigurée dans AKS Automatic. Dans AKS Standard, la fonctionnalité est facultative et vous devez l’activer explicitement. Lorsque votre cluster utilise l’intégration au réseau virtuel du serveur d’API, autorisez le trafic suivant :

Destination Origine Protocole Port Utilisation
CIDR du sous-réseau APIServer Sous-réseau de cluster TCP 443 et 4443 Obligatoire pour activer la communication entre Nodes et le serveur d’API.
CIDR du sous-réseau APIServer Azure Load Balancer (équilibreur de charge Azure) TCP 9 988 Obligatoire pour activer la communication entre Azure Load Balancer et le serveur d’API. Vous pouvez également activer toutes les communications entre l’Azure Load Balancer et le CIDR du sous-réseau du serveur d’API.

Pour plus d’informations, consultez API Server VNet Integration.

Pour la communication entre nœuds et pods, autorisez le trafic suivant lorsque les règles de groupe de sécurité réseau limitent les plages CIDR correspondantes :

Destination Origine Protocole Port Utilisation
CIDR de nœud CIDR de nœud Tous les protocoles Tous les ports Obligatoire pour activer la communication entre les nœuds.
Pod CIDR CIDR de nœud Tous les protocoles Tous les ports Obligatoire pour le routage du trafic de service.
Pod CIDR Pod CIDR Tous les protocoles Tous les ports Requis pour le trafic Pod vers Pod et Pod to Service, y compris DNS.

Les plages CIDR de nœud et de pod applicables dépendent du modèle réseau de votre cluster. Pour plus d’informations, consultez les prérequis de mise en réseau AKS CNI.

Résolution DNS

La résolution DNS est essentielle pour la découverte et la communication des services dans AKS. Par défaut, AKS utilise CoreDNS pour fournir une résolution de noms interne pour les pods et les services.

Pour améliorer les performances et la fiabilité du DNS, AKS offre localDNS, qui déploie un proxy DNS sur chaque nœud. LocalDNS résout les requêtes localement, ce qui réduit la latence et élimine la conntrack pression des tables du trafic DNS. Vous pouvez configurer LocalDNS pour fournir des réponses mises en cache en cas de panne du DNS en amont, mais la mise en cache des réponses expirées fonctionne dans la mesure du possible. LocalDNS est particulièrement utile dans les grands clusters ou environnements avec des volumes de requêtes DNS élevés.

LocalDNS est préconfiguré dans AKS Automatic. Dans AKS Standard, LocalDNS est facultatif et configuré par pool de nœuds. Avant de l’activer dans AKS Standard, vérifiez la version Kubernetes, le système d’exploitation de nœud et les prérequis de la référence SKU de machine virtuelle. L’activation de LocalDNS sur un pool de nœuds existant réimage ses nœuds. Pour connaître les prérequis et la planification du déploiement, consultez Configurer LocalDNS.

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 Trafic sécurisé entre les pods à l’aide de stratégies réseau dans Azure Kubernetes Service (AKS).

Étapes suivantes

Pour commencer à utiliser la mise en réseau AKS, créez et configurez un cluster AKS avec vos propres plages d’adresses IP à l’aide de Azure CNI Overlay ou 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 :

  • Last updated on