Considérations relatives à la topologie de réseau et à la connectivité pour AKS

Remarques relatives à la conception

Azure Kubernetes Service (AKS) fournit trois modèles de mise en réseau différents pour la mise en réseau de conteneurs : Kubenet, la superposition CNI et CNI. Chacun de ces modèles a son ensemble unique de fonctionnalités et d’avantages, offrant des options de flexibilité et de scalabilité de la mise en réseau de conteneurs dans AKS.

Kubenet

Kubenet est une solution de mise en réseau de base qui conserve l’espace d’adressage IP et offre une configuration simple. Il est idéal pour les petits clusters AKS comportant moins de 400 nœuds, où la gestion et la maintenance manuelles des itinéraires définis par l’utilisateur sont acceptables. Il convient aux scénarios où les équilibreurs de charge internes ou externes sont suffisants pour atteindre des pods depuis l’extérieur du cluster.

Azure CNI

Azure CNI est un modèle de réseau conçu pour une mise en réseau avancée. Il fournit une connectivité de réseau virtuel complète des pods, permettant une connectivité pod à pod et pod à machine virtuelle. Il est idéal pour les scénarios requérant des fonctionnalités AKS avancées, telles que des nœuds virtuels. Il convient aux scénarios où un espace d’adressage IP suffisant est disponible et où des ressources externes doivent atteindre directement les pods. Les stratégies réseau AKS sont également prises en charge par Azure CNI.

Superposition Azure CNI

La superposition Azure CNI est conçue pour résoudre les pénuries d’adresses IP et simplifier la configuration du réseau. Elle convient aux scénarios où une mise à l’échelle jusqu’à 1 000 nœuds et 250 pods par nœud est suffisante, et où un tronçon supplémentaire pour la connectivité des pods est acceptable. Les exigences de sortie AKS peuvent également être satisfaites avec une superposition Azure CNI.

Pour obtenir un résumé des cas d’usage recommandés par modèle réseau, consultez Comparer les modèles réseau dans AKS.

En outre, lors de la conception de votre cluster AKS, il est important de planifier soigneusement l’adressage IP et la taille du sous-réseau de réseau virtuel pour prendre en charge la mise à l’échelle. Les nœuds virtuels peuvent être utilisés pour mettre rapidement à l’échelle des clusters, mais il existe des limitations connues.

Les clusters AKS prennent en charge les références SKU de base et standard Azure Load Balancer, et les services peuvent être exposés avec des équilibreurs de charge publics ou internes. AKS utilise CoreDNS pour fournir une résolution de noms aux pods qui s’exécutent dans le cluster, et le trafic réseau sortant (sortie) peut être envoyé via un cluster pare-feu Azure ou d’appliance virtuelle réseau.

Par défaut, tous les pods d’un cluster AKS peuvent envoyer et recevoir du trafic sans aucune limite. Cependant, les stratégies réseau Kubernetes peuvent être utilisées pour améliorer la sécurité et filtrer le trafic réseau entre les pods dans un cluster AKS. Deux modèles de stratégies réseau sont disponibles pour AKS : les stratégies réseau Azure et Calico.

Finalement, AKS définit un groupe de sécurité réseau (NSG) sur le sous-réseau dans lequel le cluster est déployé. Il est recommandé de ne pas modifier manuellement ce groupe de sécurité réseau, mais les services déployés dans AKS peuvent l’influencer.

Dans l’ensemble, la sélection du modèle réseau approprié et une planification minutieuse des ressources réseau peuvent vous aider à optimiser les performances, la sécurité et le coût de votre cluster AKS.

Clusters privés

La visibilité IP du cluster AKS peut être publique ou privée. Les clusters privés exposent l’API Kubernetes sur une adresse IP privée, mais pas sur une adresse publique. Cette adresse IP privée est représentée dans le réseau virtuel AKS par le biais d’un point de terminaison privé. L’API Kubernetes ne doit pas être accessible par le biais de son adresse IP, mais plutôt par le biais de son nom de domaine complet (FQDN). La résolution du FQDN de l’API Kubernetes en adresse IP est généralement effectuée par une zone DNS privée Azure. Cette zone DNS peut être créée par Azure dans le groupe de ressources du nœud AKS, ou vous pouvez spécifier une zone DNS existante.

Dans le respect des pratiques éprouvées à l’échelle de l’entreprise, la résolution DNS pour les charges de travail Azure est offerte par les serveurs DNS centralisés déployés dans l’abonnement à la connectivité (soit dans un réseau virtuel hub, soit dans un réseau virtuel de services partagés connecté à un réseau Azure Virtual WAN). Ces serveurs résolvent de manière conditionnelle les noms publics, ceux propres à Azure avec Azure DNS (adresse IP 168.63.129.16) et les noms privés utilisant des serveurs DNS d’entreprise. Toutefois, ces serveurs DNS centralisés ne peuvent pas résoudre le nom de domaine complet de l’API AKS tant qu’ils ne sont pas connectés à la zone privée DNS créée pour le cluster AKS. Chaque AKS a une zone DNS privée unique, un GUID aléatoire étant ajouté au début du nom de la zone. Pour chaque nouveau cluster AKS, sa zone DNS privée correspondante doit donc être connectée au réseau virtuel où se trouvent les serveurs DNS centraux.

Tous les réseaux virtuels doivent être configurés de manière à utiliser ces serveurs DNS centraux pour la résolution de noms. Toutefois, si le réseau virtuel AKS est configuré de manière à utiliser les serveurs DNS centraux et que ces serveur DNS ne sont pas encore connectés à la zone DNS privée, les nœuds AKS ne peuvent pas résoudre le FQDN de l’API Kubernetes, et la création du cluster AKS échoue. Le réseau virtuel AKS doit être configuré pour utiliser les serveurs DNS centraux uniquement après la création du cluster.

Une fois le cluster créé, la connexion est établie entre la zone DNS privée et le réseau virtuel sur lequel les serveurs DNS centraux sont déployés. Le réseau virtuel AKS est également configuré de manière à utiliser les serveurs DNS centraux dans l’abonnement à la connectivité, et l’accès administrateur à l’API Kubernetes AKS suit ce flux :

Remarque

Les images de cet article reflètent la conception basée sur le modèle de connectivité « hub-and-spoke » traditionnel. Les zones d’atterrissage à l’échelle de l’entreprise peuvent opter pour le modèle de connectivité Virtual WAN, dans lequel les serveurs DNS centraux se trouvent dans un réseau virtuel de services partagés connecté à un hub Virtual WAN.

1. L’administrateur résout le nom de domaine complet de l’API Kubernetes. Les serveurs DNS locaux transfèrent la demande aux serveurs faisant autorité : les programmes de résolution DNS dans Azure. Ces serveurs transfèrent la demande au serveur Azure DNS (168.63.129.16), qui obtiendra l’adresse IP à partir de la zone DNS privée Azure.
2. Après la résolution de l’adresse IP, le trafic à l’API Kubernetes est acheminé du niveau local à la passerelle VPN ou ExpressRoute dans Azure, selon le modèle de connectivité.
3. Le point de terminaison privé aura introduit un itinéraire /32 dans le réseau virtuel hub. Le VPN et les passerelles ExpressRoute envoie le trafic directement vers le point de terminaison privé de l’API Kubernetes déployé dans le réseau virtuel AKS.

Trafic des utilisateurs d’applications vers le cluster

Des contrôleurs entrants (ou « contrôleurs d’entrée ») peuvent être utilisés pour exposer des applications qui s’exécutent dans les clusters AKS.

• Les contrôleurs d’entrée fournissent un routage au niveau de l’application au détriment d’une légère augmentation de la complexité.
• Les contrôleurs d’entrée peuvent incorporer la fonctionnalité Web Application Firewall (WAF).
• Les contrôleurs d’entrée peuvent s’exécuter hors cluster et en cluster :
  • Un contrôleur d’entrée hors cluster décharge le calcul (tel que le routage du trafic HTTP ou la terminaison TLS) sur un autre service en dehors d’AKS, comme le module complémentaire Azure Application Gateway Ingress Controller (AGIC).
  • Une solution en cluster consomme des ressources de cluster AKS pour le calcul (comme le routage du trafic HTTP ou la terminaison TLS). Les contrôleurs d’entrée en cluster peuvent offrir des coûts inférieurs, mais demandent une planification et une maintenance minutieuses des ressources.
• Le module complémentaire de routage d’applications HTTP de base est facile à utiliser, mais il présente quelques restrictions qui sont documentées dans le routage d’applications HTTP.

Les contrôleurs d’entrée peuvent exposer des applications et des API avec une adresse IP publique ou privée.

• La configuration doit être alignée sur la conception du filtrage de sortie pour éviter le routage asymétrique. Les UDR peuvent potentiellement provoquer un routage asymétrique, mais pas nécessairement. Application Gateway peut effectuer une SNAT sur le trafic, ce qui signifie que le trafic de retour revient au nœud Application Gateway et non à l’itinéraire UDR si l’UDR est uniquement configuré pour le trafic Internet.
• Si la terminaison TLS est nécessaire, la gestion des certificats TLS doit être envisagée.

Le trafic des applications peut provenir du réseau local ou de l’Internet public. L’illustration suivante montre un exemple de passerelle applicative Azure configurée pour inverser le proxy des connexions aux clusters en provenance à la fois du réseau local et de l’Internet public.

Le trafic en provenance du réseau local suit le flux indiqué par les flèches avec un numéro bleu dans le diagramme précédent.

1. Le client résout le nom de domaine complet attribué à l’application en utilisant les serveurs DNS déployés dans l’abonnement à la connectivité ou les serveurs DNS locaux.
2. Une fois le FQDN de l’application résolu en adresse IP (l’adresse IP privée de la passerelle applicative), le trafic est acheminé par le biais d’une passerelle VPN ou ExpressRoute.
3. Le routage dans le sous-réseau de passerelle est configuré pour envoyer la demande au pare-feu d’applications web.
4. Le pare-feu d’applications web envoie les demandes valides à la charge de travail en cours d’exécution dans le cluster AKS.

Azure Application Gateway dans cet exemple peut être déployée sur le même abonnement que le cluster AKS. En effet, sa configuration étant étroitement liée aux charges de travail déployées dans AKS, elle est gérée par la même équipe de développement d’application. L’accès en provenance d’Internet suit le flux indiqué par les flèches avec un numéro vert dans le diagramme précédent.

1. Les clients de l’Internet public résolvent le nom DNS de l’application avec Azure Traffic Manager. Vous pouvez également utiliser d’autres technologies d’équilibrage de charge global comme Azure Front Door.
2. Le FQDN public de l’application est résolu par Traffic Manager en adresse IP publique, celle de la passerelle applicative à laquelle les clients peuvent accéder sur l’Internet public.
3. La passerelle applicative accède à la charge de travail déployée dans AKS.

Remarque

Ces flux sont uniquement valides pour des applications web. Les applications non-web n’entrent pas dans le cadre de cet article et peuvent être exposées par le biais du Pare-feu Azure dans le réseau virtuel hub ou le hub virtuel sécurisé si vous utilisez le modèle de connectivité Virtual WAN.

Vous pouvez également configurer les flux de trafic pour les applications web de manière à traverser à la fois le Pare-feu Azure dans l’abonnement à la connectivité et le WAF dans le réseau virtuel AKS. Cette approche présente l’avantage d’offrir une protection supplémentaire. Par exemple, le filtrage basé sur les renseignements de Pare-feu Azure peut annuler le trafic en provenance d’adresses IP malveillantes connues sur Internet. Toutefois, elle présente aussi certains inconvénients, Comme la perte de l’adresse IP du client d’origine et les efforts supplémentaires de coordination entre le pare-feu et les équipes de développement d’application lors de l’exposition d’applications. Cela est dû au fait que des règles de traduction d’adresses réseau (DNAT) de destination sont nécessaires dans le Pare-feu Azure.

Trafic en provenance des pods AKS vers les services back-end

Les pods qui s’exécutent dans le cluster AKS peuvent avoir besoin d’accéder à des services back-end (stockage Azure, bases de données Azure SQL, bases de données NoSQL Azure Cosmos DB, etc.). Vous pouvez utiliser des points de terminaison de service de réseau virtuel et Private Link pour sécuriser la connexion à ces services managés Azure.

Si vous utilisez des points de terminaison privés Azure pour le trafic back-end, la résolution DNS pour les services Azure peut être effectuée à l’aide des zones DNS privées Azure. Dans la mesure où les programmes de résolution DNS pour l’ensemble de l’environnement se trouvent dans le réseau virtuel hub (ou le réseau virtuel de services partagés si vous utilisez le modèle de connectivité Virtual WAN), ces zones privées doivent être créées dans l’abonnement à la connectivité. Pour créer l’enregistrement A nécessaire pour résoudre le FQDN du service privé, vous pouvez associer la zone DNS privée (dans l’abonnement à la connectivité) au point de terminaison privé (dans l’abonnement à l’application). Cette opération nécessite certains privilèges dans ces abonnements.

Vous pouvez créer manuellement les enregistrements A, mais l’association de la zone DNS privée au point de terminaison privé produit une configuration moins sujette aux erreurs.

La connectivité back-end entre les pods AKS et les services Azure PaaS exposés via des points de terminaison privés suit cette séquence :

1. Les pods AKS résolvent le nom de domaine complet de la plateforme Azure en tant que service (PaaS) à l’aide des serveurs DNS centraux dans l’abonnement à la connectivité, ceux-ci étant définis en tant que serveurs DNS personnalisés dans le réseau virtuel AKS.
2. L’adresse IP résolue est l’adresse IP privée des points de terminaison privés qui sont accessibles directement à partir des pods AKS.

Par défaut, le trafic entre les pods AKS et les points de terminaison privés ne passe pas par le pare-feu Azure dans le réseau virtuel hub (ou le hub virtuel sécurisé si vous utilisez Virtual WAN), même si le cluster AKS est configuré pour le filtrage de sortie avec le pare-feu Azure. En effet, le point de terminaison privé crée un itinéraire /32 dans les sous-réseaux du réseau virtuel de l’application dans lesquels AKS est déployé.

Recommandations de conception

• Si votre stratégie de sécurité exige que l’API Kubernetes ait une adresse IP privée (à la place d’une adresse IP publique), déployez un cluster AKS privé.
  • Utilisez des zones DNS privées personnalisées lors de la création d’un cluster privé ; sinon, le processus de création utilise une zone DNS privée système.
• Utilisez Azure Container Networking Interface (CNI) comme modèle réseau, sauf si votre plage d’adresses IP pouvant être affectées au cluster AKS est limitée.
  • Suivez la documentation sur la planification des adresses IP avec CNI.
  • Pour utiliser des nœuds virtuels et des pools de nœuds Windows Server afin de vérifier d’éventuelles limitations, consultez la FAQ sur la prise en charge d’AKS par Windows.
• Utilisez Azure DDoS Protection afin de protéger le réseau virtuel utilisé pour le cluster AKS, sauf si vous utilisez Pare-feu Azure ou un pare-feu d’applications web dans un abonnement centralisé.
• Utilisez la configuration DNS liée à la configuration réseau globale avec Azure Virtual WAN ou une architecture hub-and-spoke, des zones Azure DNS et votre propre infrastructure DNS.
• Utilisez Private Link pour sécuriser les connexions réseau et une connectivité IP privée aux autres services Azure managés utilisés qui prennent en charge Private Link, comme Stockage Azure, Azure Container Registry, Azure SQL Database et Azure Key Vault.
• Utilisez un contrôleur d’entrée pour fournir un routage et une sécurité HTTP avancés et pour offrir un point de terminaison unique pour les applications.
• Toutes les applications Web configurées pour utiliser une entrée doivent s’appuyer sur le chiffrement TLS et interdire l’accès via le protocole HTTP non chiffré. Cette stratégie est déjà appliqué si l’abonnement inclut les stratégies recommandées dans Stratégies incluses dans les implémentations de référence des zones d’atterrissage à l’échelle de l’entreprise.
• Si vous le souhaitez, pour conserver les ressources de calcul et de stockage de votre cluster AKS, utilisez un contrôleur d’entrée hors cluster.
  • Utilisez le module complémentaire Azure Application Gateway Ingress Controller (AGIC), qui est un service Azure managé en interne.
  • Avec AGIC, déployez une passerelle applicative Azure dédiée pour chaque cluster AKS (ne partagez pas la même passerelle applicative entre plusieurs clusters AKS).
  • En l’absence de contraintes liées aux ressources ou aux opérations, ou si AGIC ne fournit pas les fonctionnalités nécessaires, utilisez une solution de contrôleur d’entrée en cluster telle que NGINX, Traefik ou toute autre solution prise en charge par Kubernetes.
• Pour les applications web internes, critiques pour la sécurité et accessibles sur Internet, utilisez un pare-feu d’applications web avec le contrôleur d’entrée.
  • Azure Application Gateway et Azure Front Door intègrent tous deux Azure Web Application Firewall pour protéger les applications web.
• Si votre stratégie de sécurité exige l’inspection de tout le trafic Internet sortant généré dans le cluster AKS, sécurisez le trafic de sortie à l’aide de Pare-feu Azure ou d’une appliance virtuelle réseau (NVA) tierce déployée dans le réseau virtuel hub managé. Pour plus d’informations, consultez Limiter le trafic de sortie. L’UDR de type sortant de l’AKS nécessite l’association d’une table de routage au sous-réseau du nœud AKS, de sorte qu’il ne peut pas être utilisé aujourd'hui avec l’injection d’itinéraires dynamiques prise en charge par Azure Virtual WAN ou le serveur de routes Azure.
• Pour les clusters non privés, utilisez des plages d’adresses IP autorisées.
• Utilisez le niveau standard d’Azure Load Balancer plutôt que le niveau de base.
• Lors de la conception d’un cluster Kubernetes dans Azure, l’une des considérations clés consiste à sélectionner le modèle réseau approprié à vos besoins spécifiques. Azure Kubernetes Service (AKS) propose trois modèles de mise en réseau différents : Kubenet, Azure CNI et la superposition Azure CNI. Pour prendre une décision éclairée, il est essentiel de comprendre les fonctionnalités et les caractéristiques de chaque modèle.

Pour une comparaison des fonctionnalités entre les trois modèles réseau dans AKS ; Kubenet, Azure CNI et Azure CNI Overlay, consultez Comparer les modèles réseau dans AKS.