Partager via


Personnaliser la sortie de cluster avec des types sortants dans Azure Kubernetes Service (AKS)

Vous pouvez personnaliser la sortie d’un cluster AKS pour l’adapter à des scénarios spécifiques. Par défaut, AKS approvisionne un équilibreur de charge de référence SKU standard à configurer et utiliser pour la sortie. 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 des tronçons supplémentaires sont nécessaires pour la sortie.

Cet article décrit les différents types de connectivité sortante disponibles dans les clusters AKS.

Notes

Vous pouvez maintenant mettre à jour le outboundType après la création du cluster.

Important

Dans les clusters non privés, le trafic du cluster de serveurs d’API est acheminé et traité via le type sortant des clusters. Pour empêcher le traitement du trafic du serveur d’API en tant que trafic public, envisagez d’utiliser uncluster privé, ou consultez la fonctionnalité Intégration au réseau virtuel du serveur d’API.

Limites

  • La définition de outboundType nécessite des clusters AKS avec un vm-set-typeVirtualMachineScaleSets et une load-balancer-skuStandard.

Types sortants dans AKS

Vous pouvez configurer un cluster AKS à l’aide des types sortants suivants : équilibreur de charge, passerelle NAT ou routage défini par l’utilisateur. Le type de sortie impacte seulement le trafic de sortie de votre cluster. Pour plus d’informations, consultez Configuration des contrôleurs d’entrée.

Notes

Vous pouvez utiliser votre propre [route table][byo-route-table] avec la mise en réseau kubenet et UDR. Vérifiez que l’identité du cluster (principal de service ou identité managée) a des autorisations de Contributeur sur la table de routage personnalisée.

Type sortant de loadBalancer

L’équilibreur de charge est utilisé pour la sortie via une adresse IP publique affectée à AKS. Un type de sortie loadBalancer prend en charge les services Kubernetes de type loadBalancer, qui attendent une sortie de l’équilibreur de charge créé par le fournisseur de ressources AKS.

Si loadBalancer est défini, AKS effectue automatiquement la configuration suivante :

  • Une adresse IP publique est provisionnée pour la sortie du cluster.
  • L’adresse IP publique est affectée à la ressource d’équilibreur de charge.
  • Les pools de back-end pour l’équilibreur de charge sont configurés pour les nœuds d’agent dans le cluster.

Le diagramme illustre les IP entrante et sortante, où l’IP entrante dirige le trafic vers un équilibreur de charge, qui dirige le trafic vers et depuis un cluster interne et un autre trafic vers l’IP sortante, qui dirige le trafic vers Internet, MCR, les services Azure requis et le plan de contrôle AKS.

Pour plus d’informations, consultez Utiliser un équilibreur de charge standard dans AKS.

Type sortant de managedNatGateway ou userAssignedNatGateway

Si managedNatGateway ou userAssignedNatGateway sont sélectionnés pour outboundType, AKS s’appuie sur la passerelle NAT réseau Azure pour la sortie du cluster.

  • Sélectionnez managedNatGateway lorsque vous utilisez des réseaux virtuels managés. AKS approvisionne une passerelle NAT et l’attachera au sous-réseau du cluster.
  • Sélectionnez userAssignedNatGateway lors de l’utilisation de la mise en réseau virtuelle bring-your-own. Pour utiliser cette option, vous devez avoir provisionné une passerelle NAT avant la création du cluster.

Pour plus d’informations, consultez Utiliser une passerelle NAT avec AKS.

Type sortant de userDefinedRouting

Notes

Le type sortant userDefinedRouting est un scénario réseau avancé et nécessite une configuration réseau appropriée.

Si userDefinedRouting est défini, AKS ne configure pas automatiquement les chemins de sortie. Vous devez configurer la sortie vous-même.

Vous devez déployer le cluster AKS dans un réseau virtuel existant, avec un sous-réseau qui a été préalablement configuré. Puisque vous n’utilisez pas une architecture standard d’équilibreur de charge (ou SLB, pour « Standard Load Balancer »), vous devez établir une sortie explicite. Cette architecture requiert l’envoi explicite du trafic sortant vers une appliance comme un pare-feu, une passerelle ou un proxy, ou pour permettre au NAT d’être effectué par une adresse IP publique attribuée à l’équilibreur de charge standard ou à l’appliance.

Pour plus d’informations, consultez Configurer la sortie du cluster via le routage défini par l’utilisateur.

Mise à jour outboundType après la création du cluster

La modification du type sortant après la création du cluster déploie ou supprime des ressources si nécessaire pour placer le cluster dans la nouvelle configuration de sortie.

Les tableaux suivants indiquent les chemins de migration pris en charge entre les types sortants pour les réseaux virtuels managés et BYO.

Chemins de migration pris en charge pour le VNet managé

Chaque ligne indique si le type sortant peut être migré vers les types répertoriés en haut. « Pris en charge » signifie qu’une migration est possible, alors que « Non pris en charge » ou « N/A » signifie qu’une migration n’est pas possible.

De/À loadBalancer managedNATGateway userAssignedNATGateway userDefinedRouting
loadBalancer S/O Prise en charge Non pris en charge Non pris en charge
managedNATGateway Prise en charge S/O Non pris en charge Non pris en charge
userAssignedNATGateway Non pris en charge Non pris en charge N/A Non pris en charge

Chemins de migration pris en charge pour le VNet BYO

De/À loadBalancer managedNATGateway userAssignedNATGateway userDefinedRouting
loadBalancer S/O Non pris en charge Prise en charge Prise en charge
managedNATGateway Non pris en charge N/A Non pris en charge Non pris en charge
userAssignedNATGateway Prise en charge Non pris en charge N/A Prise en charge
userDefinedRouting Prise en charge Non pris en charge Prise en charge S/O

La migration est prise en charge uniquement entre loadBalancer, managedNATGateway (si vous utilisez un réseau virtuel managé), userAssignedNATGateway et userDefinedRouting (si vous utilisez un réseau virtuel personnalisé).

Avertissement

La migration du type sortant vers des types gérés par l’utilisateur (userAssignedNATGateway et userDefinedRouting) change les adresses IP publiques sortantes du cluster. Si Plages IP autorisées est activé, vérifiez que la nouvelle plage IP sortante est ajoutée à la plage IP autorisée.

Avertissement

La modification du type sortant sur un cluster perturbe la connectivité réseau et entraîne une modification de l’adresse IP de sortie du cluster. Si des règles de pare-feu ont été configurées pour restreindre le trafic à partir du cluster, vous devez les mettre à jour pour correspondre à la nouvelle adresse IP de sortie.

Mettre à jour un cluster pour utiliser un nouveau type sortant

Remarque

Vous devez utiliser une version >= 2.56 d’Azure CLI pour migrer le type sortant. Installez az upgrade pour mettre à jour vers la version la plus récente d’Azure CLI.

  • Mettez à jour la configuration sortante de votre cluster à l’aide de la commande az aks update.

Mettre à jour le cluster de loadbalancer vers managedNATGateway

az aks update --resource-group <resourceGroup> --name <clusterName> --outbound-type managedNATGateway --nat-gateway-managed-outbound-ip-count <number of managed outbound ip>

Mettre à jour le cluster de managedNATGateway vers loadbalancer

az aks update --resource-group <resourceGroup> --name <clusterName> \
--outbound-type loadBalancer \
<--load-balancer-managed-outbound-ip-count <number of managed outbound ip>| --load-balancer-outbound-ips <outbound ip ids> | --load-balancer-outbound-ip-prefixes <outbound ip prefix ids> >

Avertissement

Ne réutilisez pas une adresse IP déjà utilisée dans des configurations sortantes antérieures.

Mettre à jour le cluster de managedNATGateway vers userDefinedRouting

az aks update --resource-group <resourceGroup> --name <clusterName> --outbound-type userDefinedRouting

Mettre à jour le cluster de loadbalancer vers userAssignedNATGateway dans le scénario VNet BYO

az aks update --resource-group <resourceGroup> --name <clusterName> --outbound-type userAssignedNATGateway

Étapes suivantes