Personnaliser la sortie du cluster avec une table de routage définie par l’utilisateur dans Azure Kubernetes Service (AKS)
Article
Vous pouvez personnaliser la sortie de vos clusters Azure Kubernetes Service (AKS) en fonction de scénarios spécifiques. AKS approvisionne un équilibreur de charge SKU Standard pour la sortie par défaut. Cependant, la configuration par défaut peut ne pas répondre aux exigences de tous les scénarios si les adresses IP publiques ne sont pas autorisées ou si le scénario exige des tronçons supplémentaires pour la sortie.
Cet article explique comment personnaliser l’itinéraire de sortie d’un cluster pour prendre en charge les scénarios de réseaux personnalisés. Ces scénarios incluent ceux qui interdisent les adresses IP publiques et exigent que le cluster se trouve derrière une appliance virtuelle réseau (NVA).
Prérequis
Azure CLI version 2.0.81 ou ultérieure. Exécutez az --version pour trouver la version. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI.
API version 2020-01-01 ou ultérieure.
Conditions requises et limitations :
L’utilisation d’un type de sortie est un scénario réseau avancé et nécessite une configuration réseau appropriée. Les exigences et limitations suivantes s’appliquent à l’utilisation du type de trafic sortant :
La définition de outboundType nécessite des clusters AKS avec un vm-set-typeVirtualMachineScaleSets et un load-balancer-skuStandard.
La définition de outboundType sur une valeur UDR nécessite une route définie par l’utilisateur avec une connectivité de sortie valide pour le cluster.
La définition de outboundType sur la valeur UDR implique que l’adresse IP source en entrée routée vers l’équilibreur de charge puisse ne pas correspondre à l’adresse de destination en sortie de la sortie du cluster.
Vue d’ensemble de la personnalisation de la sortie avec une table de routage définie par l’utilisateur
AKS ne configure pas automatiquement les chemins de sortie si userDefinedRouting est défini, ce qui signifie que vous devez configurer la sortie.
Quand vous n’utilisez pas une architecture d’équilibreur de charge standard (SLB), vous devez établir une sortie explicite. Vous devez déployer votre cluster AKS dans un réseau virtuel existant, avec un sous-réseau qui a été préalablement configuré. Cette architecture requiert l’envoi explicite du trafic sortant vers une appliance comme un pare-feu, une passerelle ou un proxy, pour qu’une adresse IP publique attribuée à l’équilibreur de charge standard ou à l’appliance puisse gérer la traduction d’adresses réseau (NAT).
Création d’un équilibreur de charge avec userDefinedRouting
Les clusters AKS avec le type sortant UDR obtiennent un équilibreur de charge standard uniquement quand le premier service Kubernetes de type loadBalancer est déployé. L’équilibrage de charge est configuré avec une adresse IP publique pour les demandes entrantes et un pool principal pour les demandes sortantes. Le fournisseur de cloud Azure configure les règles de trafic entrant, mais il ne configure pas d’adresse IP publique sortante ou de règles de trafic sortant. Votre UDR est la seule source de trafic sortant.
Le type sortant UDR requiert un itinéraire pour 0.0.0.0/0 et une destination de tronçon suivant NVA dans la table de routage.
La table de routage contient déjà une valeur par défaut 0.0.0.0/0 vers Internet. Sans adresse IP publique pour Azure à utiliser pour la traduction d’adresses réseau sources (SNAT), le simple fait d’ajouter cet itinéraire ne fournit pas de connectivité Internet sortante. AKS vérifie que l’itinéraire 0.0.0.0/0 que vous créez ne pointe pas vers Internet, mais vers une passerelle, une appliance réseau virtuelle, etc. Quand vous utilisez un type sortant UDR, aucune adresse IP publique d’équilibreur de charge pour les demandes entrantes n’est créée, sauf si vous configurez un service de type loadbalancer. AKS ne crée jamais d’adresse IP publique pour les demandes sortantes si vous définissez un type sortant UDR.
Étapes suivantes
Pour plus d’informations sur les itinéraires définis par l’utilisateur et la mise en réseau Azure, consultez les articles suivants :
La source de ce contenu se trouve sur GitHub, où vous pouvez également créer et examiner les problèmes et les demandes de tirage. Pour plus d’informations, consultez notre guide du contributeur.
Commentaires sur Azure Kubernetes Service
Azure Kubernetes Service est un projet open source. Sélectionnez un lien pour fournir des commentaires :
Sécuriser la connectivité Internet sortante pour Azure VMware Solution à l’aide du Serveur de routes Azure, du Pare-feu Azure et d’une appliance virtuelle réseau tierce
Faites la démonstration de la conception, de l’implémentation et de la maintenance de l’infrastructure de mise en réseau, du trafic d’équilibrage de charge, du routage réseau Azure et bien plus encore.