Share via

Utiliser un équilibreur de charge Standard public dans Azure Kubernetes Service (AKS)

  • Article

Azure Load Balancer est sur la couche 4 (L4) du modèle OSI (Open Systems Interconnection) qui prend en charge les scénarios entrants et sortants. Il distribue les flux entrants arrivant sur le serveur front-end de l’équilibreur de charge sur des instances du pool de back-ends.

Intégré à AKS, un équilibreur de charge public remplit deux fonctions :

  1. Fournir des connexions sortantes aux nœuds de cluster à l’intérieur du réseau virtuel AKS en traduisant l’adresse IP privée en une adresse IP publique faisant partie de son pool sortant.
  2. Fournir l’accès aux applications via des services Kubernetes de type LoadBalancer, ce qui vous permet de mettre facilement à l’échelle vos applications et de créer des services hautement disponibles.

Un équilibreur de charge interne (ou privé) est utilisé quand uniquement des adresses IP privées sont autorisées au niveau du front-end. Les équilibreurs de charge internes sont utilisés pour équilibrer la charge du trafic au sein d’un réseau virtuel. Vous pouvez également accéder au front-end d’un équilibreur de charge à partir d’un réseau local dans le cadre d’un scénario hybride.

Cet article traite de l’intégration à un équilibreur de charge public sur AKS. Pour l’intégration à un équilibreur de charge interne, consultez Utiliser un équilibreur de charge interne dans AKS.

Avant de commencer

  • Azure Load Balancer se décline en deux références SKU : De base et Standard. La référence SKU Standard est utilisée par défaut quand vous créez un cluster AKS. La référence SKU Standard vous permet d’accéder à des fonctionnalités ajoutées, telles qu’un pool principal plus grand, plusieurs pools de nœuds, zones de disponibilitéet est sécurisé par défaut. Il s’agit de la référence SKU d’équilibreur de charge recommandée pour AKS. Pour plus d’informations sur les références SKU De base et Standard, consultez Comparaison des références SKU d’Azure Load Balancer.
  • Pour obtenir une liste complète des annotations prises en charge pour les services Kubernetes avec le type LoadBalancer, consultez Annotations LoadBalancer.
  • Cet article part du principe que vous disposez d’un cluster AKS avec la référence SKU Azure Load Balancer Standard. Si vous avez besoin d’un cluster AKS, vous pouvez en créer un en utilisant Azure CLI, Azure PowerShell ou le portail Azure.
  • AKS gère le cycle de vie et les opérations des nœuds de l’agent. La modification des ressources IaaS associées aux nœuds de l’agent n’est pas prise en charge. Un exemple d’opération non prise en charge est d’apporter des modifications manuelles au groupe de ressources de l’équilibreur de charge.

Important

Si vous préférez utiliser votre propre passerelle, pare-feu ou proxy pour fournir une connexion sortante, vous pouvez ignorer la création du pool sortant de l’équilibreur de charge et de l’adresse IP frontale respective en utilisant un type de sortie UserDefinedRouting (UDR). Le type de sortie définit la méthode de sortie d’un cluster et correspond par défaut au typeLoadBalancer.

Utiliser l’équilibreur de charge standard public

Une fois que vous avez créé un cluster AKS avec le type de sortie LoadBalancer (par défaut), votre cluster est prêt à utiliser l’équilibreur de charge pour exposer les services.

Créez un manifeste de service nommé public-svc.yaml, qui crée un service public de type LoadBalancer.

apiVersion: v1
kind: Service
metadata:
  name: public-svc
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: public-app

Spécifier l’adresse IP de l’équilibreur de charge

Si vous souhaitez utiliser une adresse IP spécifique avec l’équilibreur de charge, il y a deux façons de le faire :

Important

L’ajout de la propriété LoadBalancerIP au manifeste YAML de l’équilibreur de charge est déprécié après Kubernetes en amont. Bien que l’utilisation actuelle reste la même et que les services existants soient censés fonctionner sans modification, nous recommandons vivement de définir des annotations de service à la place.

  • Définir des annotations de service : utilisez service.beta.kubernetes.io/azure-load-balancer-ipv4 pour une adresse IPv4 et service.beta.kubernetes.io/azure-load-balancer-ipv6 pour une adresse IPv6.
  • Ajouter la propriété LoadBalancerIP au manifeste YAML de l’équilibreur de charge : ajoutez la propriété Service.Spec.LoadBalancerIP au manifeste YAML de l’équilibreur de charge. Ce champ est déprécié après Kubernetes en amont et ne peut pas prendre en charge la double pile. L’utilisation actuelle reste la même et les services existants sont censés fonctionner sans modification.

Déployer le manifeste de service

Déployez le manifeste de service public avec la commande kubectl apply et spécifiez le nom de votre manifeste YAML.

kubectl apply -f public-svc.yaml

Azure Load Balancer est configuré avec une nouvelle adresse IP publique placée au premier plan du nouveau service. Étant donné qu’Azure Load Balancer peut avoir plusieurs adresses IP frontales, chaque nouveau service que vous déployez obtient une nouvelle adresse IP frontale dédiée et accessible de manière unique.

Vérifiez que votre service est créé et que l’équilibreur de charge est configuré en utilisant la commande suivante.

kubectl get service public-svc

NAMESPACE     NAME          TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)         AGE
default       public-svc    LoadBalancer   10.0.39.110    52.156.88.187   80:32068/TCP    52s

Quand vous affichez les détails du service, l’adresse IP publique créée pour ce service sur l’équilibreur de charge apparaît dans la colonne EXTERNAL-IP. Le passage de l’adresse IP de l’état <en attente> à l’état d’adresse IP publique effective peut prendre une ou deux minutes.

Si vous souhaitez en savoir plus sur votre service, utilisez la commande suivante.

kubectl describe service public-svc

L’exemple de sortie suivant est une version condensée de la sortie après l’exécution de kubectl describe service. Entrée de l’équilibreur de charge affiche l’adresse IP externe exposée par votre service. Adresse IP affiche les adresses internes.

Name:                        public-svc
Namespace:                   default
Labels:                      <none>
Annotations:                 <none>
Selector:                    app=public-app
...
IP:                          10.0.39.110
...
LoadBalancer Ingress:        52.156.88.187
...
TargetPort:                  80/TCP
NodePort:                    32068/TCP
...
Session Affinity:            None
External Traffic Policy:     Cluster
...

Configurer l’équilibreur de charge standard public

Vous pouvez personnaliser différents paramètres pour votre équilibreur de charge public standard quand vous créez le cluster ou en le mettant à jour. Ces options de personnalisation vous permettent de créer un équilibreur de charge qui répond aux besoins de votre charge de travail. Avec l’équilibreur de charge standard, vous pouvez :

  • Définir ou mettre à l’échelle le nombre d’adresses IP sortantes gérées.
  • Fournir vos propres adresses IP sortantes ou préfixes d’adresses IP sortantes.
  • Personnaliser le nombre de ports de sortie alloués à chaque nœud du cluster.
  • Configurer le paramètre de délai d’expiration pour les connexions inactives.

Important

Une seule option d’adresse IP sortante (adresse IP gérée, apport d’une adresse IP propre ou préfixe IP) peut être utilisée à un moment donné.

Modifier le type de pool entrant

Les nœuds AKS peuvent être référencés dans les pools principaux de l’équilibreur de charge par leur configuration IP (appartenance basée sur Microsoft Azure Virtual Machine Scale Sets) ou par leurs adresses IP uniquement. L’utilisation de l’appartenance au pool principal basé sur l’adresse IP offre une plus grande efficacité lors de la mise à jour des services et de l’approvisionnement des équilibreurs de charge, en particulier en cas de nombre élevé de nœuds. L’approvisionnement de nouveaux clusters avec des pools principaux basés sur une adresse IP et la conversion de clusters existants sont désormais pris en charge. Lorsqu’il est combiné à NAT Gateway ou à des types de routage de sortie définis par l’utilisateur, l’approvisionnement de nouveaux nœuds et services est plus performant.

Deux types d’appartenance au pool sont disponibles :

  • nodeIPConfiguration : type d’appartenance au pool basé sur la configuration IP héritée Virtual Machine Scale Sets
  • nodeIP - Type d’appartenance basée sur une adresse IP

Spécifications

  • Le cluster AKS doit être de version 1.23 ou ultérieure.
  • Le cluster AKS doit utiliser des équilibreurs de charge standard et des groupes de machines virtuelles identiques.

Créer un cluster AKS avec l’appartenance au pool entrant basé sur une adresse IP

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-backend-pool-type=nodeIP

Mettre à jour un cluster AKS existant pour utiliser l’appartenance au pool entrant basé sur une adresse IP

Avertissement

Cette opération entraîne une interruption temporaire du trafic de service entrant dans le cluster. Le temps d’impact augmente avec des clusters plus grands qui ont de nombreux nœuds.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-backend-pool-type=nodeIP

Mettre à l’échelle le nombre d’adresses IP sortantes gérées

Azure Load Balancer fournit la connectivité sortante et entrante à partir d’un réseau virtuel. Les règles de trafic sortant simplifient la configuration de la traduction d’adresses réseau pour l’équilibreur de charge standard public.

Les règles de trafic sortant suivent la syntaxe des règles d’équilibrage de charge et des règles de NAT de trafic entrant :

Adresses IP frontales + paramètres + pool backend

Une règle de trafic sortant configure la NAT de trafic sortant pour que toutes les machines virtuelles identifiées par le pool backend soient traduites sur le frontend. Les paramètres permettent de contrôler davantage l’algorithme de la NAT de trafic sortant.

Même si vous pouvez utiliser une règle de trafic sortant avec une seule adresse IP publique, les règles de trafic sortant sont idéales pour la mise à l’échelle de la NAT de trafic sortant, car elles allègent la charge liée à la configuration. Vous pouvez utiliser plusieurs adresses IP pour vos scénarios à grande échelle et des règles de trafic sortant afin de limiter les risques d’épuisement de ports SNAT. Chaque adresse IP fournie par un front-end met à disposition 64 000 ports éphémères que l’équilibreur de charge peut utiliser en tant que ports SNAT.

Quand vous utilisez un équilibreur de charge de référence (SKU) Standard avec des adresses IP sortantes publiques gérées (qui sont créées par défaut), vous pouvez mettre à l’échelle le nombre de ces adresses avec le paramètre --load-balancer-managed-outbound-ip-count.

Utilisez la commande suivante pour mettre à jour un cluster existant. Vous pouvez également définir ce paramètre afin d’avoir plusieurs adresses IP sortantes publiques gérées.

Important

Nous vous déconseillons d’utiliser le portail Azure pour apporter des modifications aux règles de trafic sortant. Quand vous apportez ces modifications, vous devez passer par le cluster AKS et non pas les effectuer directement sur la ressource Load Balancer.

Les modifications de règle de trafic sortant effectuées directement sur la ressource Load Balancer sont supprimées chaque fois que le cluster fait l’objet d’un rapprochement, par exemple quand il est arrêté, démarré, mis à niveau ou mis à l’échelle.

Utilisez Azure CLI, comme indiqué dans les exemples. Les modifications apportées aux règles de trafic sortant avec des commandes CLI az aks sont permanentes pendant les temps d’arrêt du cluster.

Pour plus d’informations, consultez Règles de trafic sortant dans Azure Load Balancer.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-managed-outbound-ip-count 2

L’exemple ci-dessus définit le nombre d’adresses IP sortantes publiques gérées sur 2 pour le cluster myAKSCluster dans myResourceGroup.

Au moment de la création du cluster, vous pouvez également définir le nombre initial d’adresses IP publiques sortantes gérées en ajoutant le paramètre --load-balancer-managed-outbound-ip-count et en lui attribuant la valeur de votre choix. Le nombre d’adresses IP sortantes publiques gérées par défaut est 1.

Fournir vos propres adresses IP sortantes ou préfixes

Lorsque vous utilisez un équilibreur de charge SKU Standard, le cluster AKS crée automatiquement une adresse IP publique dans le groupe de ressources de l’infrastructure gérée par AKS et l’affecte au pool sortant de l’équilibreur de charge.

Une adresse IP publique créée par AKS est une ressource managée par AKS. En d’autres termes, AKS gère le cycle de vie de cette adresse IP publique et ne nécessite aucune action de l’utilisateur directement sur la ressource IP publique. Vous pouvez également affecter votre propre adresse IP publique ou préfixe d’adresse IP publique au moment de la création du cluster. Vos adresses IP personnalisées peuvent également être mises à jour sur les propriétés de l’équilibreur de charge d’un cluster existant.

Exigences liées à l’utilisation de votre propre adresse IP publique ou préfixe :

  • Les utilisateurs doivent créer, puis posséder des adresses IP publiques personnalisées. Les adresses IP publiques gérées créées par AKS ne peuvent pas être réutilisées comme « adresses IP personnalisées » car cela peut entraîner des conflits de gestion.
  • Vous devez vous assurer que l’identité de cluster AKS (principal de service ou identité managée) dispose des autorisations nécessaires pour accéder à l’adresse IP sortante, conformément à la liste des autorisations IP publiques requises.
  • Vérifiez que vous respectez les conditions préalables et contraintes requises pour configurer des adresses IP sortantes ou des préfixes d’adresses IP sortantes.

Mettre à jour le cluster avec votre propre adresse IP publique sortante

Utilisez la commande az network public-ip show pour répertorier les ID de vos adresses IP publiques.

az network public-ip show --resource-group myResourceGroup --name myPublicIP --query id -o tsv

La commande ci-dessus affiche l’ID de l’adresse IP publique myPublicIP dans le groupe de ressources myResourceGroup.

Utilisez la commande az aks update avec le paramètre load-balancer-outbound-ips pour mettre à jour votre cluster avec vos adresses IP publiques.

L’exemple suivant utilise le paramètre load-balancer-outbound-ips avec les ID obtenus par la commande précédente.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ips <publicIpId1>,<publicIpId2>

Mettre à jour le cluster avec votre propre préfixe d’adresse IP publique sortante

Vous pouvez également utiliser des préfixes IP publics pour la sortie avec votre équilibreur de charge de référence (SKU) Standard. L’exemple suivant utilise la commande az network public-ip prefix show pour répertorier les ID de vos préfixes IP publics.

az network public-ip prefix show --resource-group myResourceGroup --name myPublicIPPrefix --query id -o tsv

La commande ci-dessus affiche l’ID du préfixe IP public myPublicIPPrefix dans le groupe de ressources myResourceGroup.

L’exemple suivant utilise le paramètre load-balancer-outbound-ip-prefixes avec les ID obtenus par la commande précédente.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ip-prefixes <publicIpPrefixId1>,<publicIpPrefixId2>

Créer le cluster avec vos propres adresses IP publiques ou préfixes

Quand vous créez votre cluster, vous pouvez apporter vos propres adresses IP ou préfixes d’adresses IP pour la sortie afin de prendre en charge des scénarios tels que l’ajout de points de terminaison de sortie à une liste verte. Pour définir vos propres adresses IP et préfixes IP publics au moment de la création du cluster, ajoutez les mêmes paramètres que dans la commande précédente.

Utilisez la commande az aks create avec le paramètre load-balancer-outbound-ips pour créer un cluster avec vos propres adresses IP publiques.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ips <publicIpId1>,<publicIpId2>

Utilisez la commande az aks create avec le paramètre load-balancer-outbound-ip-prefixes pour créer un cluster avec vos propres préfixes IP publics.

az aks create \
    --resource-group myResourceGroup \
    --load-balancer-outbound-ip-prefixes <publicIpPrefixId1>,<publicIpPrefixId2>

Configurer les ports de sortie alloués

Important

Si votre cluster comprend des applications pouvant établir un grand nombre de connexions vers un petit ensemble de destinations, comme plusieurs instances d’une application front-end se connectant à une base de données, vous risquez de vous retrouver dans une situation d’épuisement de ports SNAT. L’insuffisance de ports SNAT se produit lorsqu’une application n’a plus assez de ports de sortie pour établir une connexion à une autre application ou à un autre hôte. Si vous êtes dans une situation susceptible de faire l’objet d’une insuffisance de ports SNAT, nous recommandons fortement d’augmenter le nombre de ports de sortie et d’IP front-end sortantes sur l’équilibreur de charge.

Pour plus d’informations sur SNAT, consultez Utiliser SNAT pour les connexions sortantes.

Par défaut, AKS définit AllocatedOutboundPorts sur son équilibreur de charge avec la valeur 0, ce qui permet l’affectation automatique des ports de sortie en fonction de la taille du pool de back-ends lors de la création d’un cluster. Par exemple, si un cluster a 50 nœuds ou moins, 1 024 ports sont alloués à chaque nœud. À mesure que le nombre de nœuds dans le cluster augmente, le nombre de ports disponibles par nœud diminue.

Important

Il existe une limite stricte de 1024 ports, que les adresses IP front-end soient ajoutées ou non, lorsque la taille du nœud est inférieure ou égale à 50 (1-50).

Pour afficher la valeur d’AllocatedOutboundPorts affectée à l’équilibreur de charge du cluster AKS, utilisez az network lb outbound-rule list.

NODE_RG=$(az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv)
az network lb outbound-rule list --resource-group $NODE_RG --lb-name kubernetes -o table

L’exemple de sortie suivant montre que l’affectation automatique des ports de sortie en fonction de la taille du pool de back-ends est activée pour le cluster.

AllocatedOutboundPorts    EnableTcpReset    IdleTimeoutInMinutes    Name             Protocol    ProvisioningState    ResourceGroup
------------------------  ----------------  ----------------------  ---------------  ----------  -------------------  -------------
0                         True              30                      aksOutboundRule  All         Succeeded            MC_myResourceGroup_myAKSCluster_eastus

Pour configurer une valeur spécifique pour AllocatedOutboundPorts et les adresses IP sortantes lors de la création ou de la mise à jour d’un cluster, utilisez load-balancer-outbound-ports et load-balancer-managed-outbound-ip-count, load-balancer-outbound-ips ou load-balancer-outbound-ip-prefixes. Avant de définir une valeur spécifique ou d’incrémenter une valeur existante pour les ports de sortie ou les adresses IP sortantes, vous devez calculer le nombre approprié de ports de sortie et d’adresses IP sortantes. Utilisez l’équation suivante pour arrondir ce calcul à l’entier le plus proche : 64,000 ports per IP / <outbound ports per node> * <number of outbound IPs> = <maximum number of nodes in the cluster>.

Quand vous calculez le nombre de ports de sortie et d’adresses IP sortantes et définissez les valeurs correspondantes, gardez à l’esprit les informations suivantes :

  • Le nombre de ports de sortie par nœud est fixé en fonction de la valeur que vous définissez.
  • La valeur des ports de sortie doit être un multiple de 8.
  • L’ajout d’adresses IP n’ajoute pas de ports à un nœud, mais fournit de la capacité pour un plus grand nombre de nœuds dans le cluster.
  • Vous devez prendre en compte les nœuds qui pourraient être ajoutés dans le cadre de mises à niveau, notamment le nombre de nœuds spécifié par les valeurs maxSurge.

Les exemples suivants montrent l’impact des valeurs que vous définissez sur le nombre de ports de sortie et d’adresses IP sortantes :

  • Si les valeurs par défaut sont utilisées et que le cluster a 48 nœuds, chaque nœud dispose de 1024 ports.
  • Si les valeurs par défaut sont utilisées et que le cluster passe de 48 à 52 nœuds, le nombre de ports disponibles pour chaque nœud passe de 1024 à 512.
  • Si le nombre de ports de sortie est défini sur 1 000 et le nombre d’IP sortantes sur 2, le cluster peut prendre en charge un maximum de 128 nœuds : 64,000 ports per IP / 1,000 ports per node * 2 IPs = 128 nodes.
  • Si le nombre de ports de sortie est défini sur 1 000 et le nombre d’IP sortantes sur 7, le cluster peut prendre en charge un maximum de 448 nœuds : 64,000 ports per IP / 1,000 ports per node * 7 IPs = 448 nodes.
  • Si le nombre de ports de sortie est défini sur 4 000 et le nombre d’IP sortantes sur 2, le cluster peut prendre en charge un maximum de 32 nœuds : 64,000 ports per IP / 4,000 ports per node * 2 IPs = 32 nodes.
  • Si le nombre de ports de sortie est défini sur 4 000 et le nombre d’IP sortantes sur 7, le cluster peut prendre en charge un maximum de 112 nœuds : 64,000 ports per IP / 4,000 ports per node * 7 IPs = 112 nodes.

Important

Après avoir calculé le nombre de ports de sortie et d’IP sortantes, vérifiez que vous disposez d’une capacité supplémentaire de ports de sortie pour faire face à la surutilisation des nœuds pendant les mises à niveau. Il est essentiel d’allouer suffisamment de ports d’appoint compte tenu des nœuds supplémentaires nécessaires à la mise à niveau et à d’autres opérations. Par défaut, AKS a un nœud tampon pour les opérations de mise à niveau. Si vous utilisez des valeurs maxSurge, multipliez le nombre de ports de sortie par nœud par votre valeur maxSurge pour déterminer le nombre de ports nécessaires. Par exemple, si vous calculez qu’il vous faut 4 000 ports par nœud avec 7 adresses IP sur un cluster avec au maximum 100 nœuds et 2 nœuds d’appoint :

  • 2 nœuds d’appoint * 4 000 ports par nœud = 8 000 ports nécessaires pour faire face à la surutilisation des nœuds pendant les mises à niveau.
  • 100 nœuds * 4 000 ports par nœud = 400 000 ports nécessaires pour votre cluster.
  • 7 IP * 64 000 ports par IP = 448 000 ports disponibles pour votre cluster.

L’exemple ci-dessus montre que le cluster a une capacité excédentaire de 48 000 ports, ce qui est suffisant pour gérer les 8 000 ports nécessaires pour faire face à la surutilisation des nœuds pendant les mises à niveau.

Une fois les valeurs calculées et vérifiées, vous pouvez les appliquer en utilisant load-balancer-outbound-ports et load-balancer-managed-outbound-ip-count, load-balancer-outbound-ips ou load-balancer-outbound-ip-prefixes lors de la création ou de la mise à jour d’un cluster.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-managed-outbound-ip-count 7 \
    --load-balancer-outbound-ports 4000

Configuration du délai d’expiration de l’équilibreur de charge

En cas d’épuisement des ressources de port SNAT, les flux sortants échouent tant que les flux existants ne libèrent pas des ports SNAT. L’équilibreur de charge récupère les ports SNAT quand le flux se ferme, et l’équilibreur de charge configuré par AKS utilise un délai d’expiration de 30 minutes pour récupérer les ports SNAT des flux inactifs.

Vous pouvez également utiliser un transport (par exemple, TCP keepalives ouapplication-layer keepalives) pour actualiser un flux inactif et réinitialiser ce délai d’expiration, si nécessaire. Vous pouvez configurer ce délai d’inactivité en suivant l’exemple ci-dessous.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-idle-timeout 4

Si vous anticipez de nombreuses connexions à durée de vie limitée, aucune connexion à longue durée et quelques périodes d’inactivité prolongées, par exemple en utilisant kubectl proxy ou kubectl port-forward, vous pouvez utiliser une valeur de délai d’expiration faible, par exemple 4 minutes. Lorsque vous utilisez des conservations de connexion active TCP, il suffit de les activer sur un côté de la connexion. Par exemple, il suffit de les activer sur le côté serveur uniquement pour réinitialiser la minuterie d’inactivité. Il n’est pas nécessaire que les deux côtés démarrent des keepalives TCP. Des concepts similaires existent pour la couche d’application, notamment les configurations client-serveur de base de données. Examinez côté serveur les options de persistance de connexion spécifiques aux applications.

Important

AKS active la réinitialisation TCP inactif par défaut. Nous recommandons de conserver cette configuration et de l’appliquer pour bénéficier d’un comportement d’application plus prévisible dans vos scénarios.

TCP RST est envoyé uniquement au cours d’une connexion TCP dont l’état est ESTABLISHED. Pour en savoir plus, cliquez ici.

Lorsque vous définissez IdleTimeoutInMinutes sur une valeur différente de la valeur par défaut égale à 30 minutes, réfléchissez à la durée pendant laquelle vos charges de travail ont besoin d’une connexion sortante. Tenez également compte de la valeur du délai d’expiration par défaut d’un équilibreur de charge de la référence SKU Standard utilisé en dehors d’AKS qui s’élève à 4 minutes. Une valeur IdleTimeoutInMinutes qui reflète plus précisément votre charge de travail AKS spécifique peut contribuer à réduire l’épuisement SNAT provoqué par la liaison des connexions qui ne sont plus utilisées.

Avertissement

La modification des valeurs de AllocatedOutboundPorts et de IdleTimeoutInMinutes peut changer considérablement le comportement de la règle de trafic sortant pour votre équilibreur de charge et ne doit pas être effectuée à la légère. Consultez la section Dépannage SNAT et examinez les règles de sortie de l’équilibreur de charge et les connexions sortantes dans Azure avant de mettre à jour ces valeurs pour bien comprendre l’impact de vos modifications.

Limiter le trafic entrant à des plages d’adresses IP spécifiques

Le manifeste suivant utilise loadBalancerSourceRanges afin de spécifier une nouvelle plage d’adresses IP pour le trafic externe entrant.

apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-vote-front
  loadBalancerSourceRanges:
  - MY_EXTERNAL_IP_RANGE

Cet exemple met à jour la règle pour autoriser le trafic externe entrant uniquement à partir de la plage MY_EXTERNAL_IP_RANGE. Si vous remplacez MY_EXTERNAL_IP_RANGE par l’adresse IP du sous-réseau interne, le trafic est limité à des adresses IP internes du cluster. Si le trafic est limité à des adresses IP internes du cluster, les clients en dehors de votre cluster Kubernetes ne peuvent pas accéder à l’équilibreur de charge.

Remarque

  • Le trafic entrant et externe passe de l’équilibreur de charge au réseau virtuel pour votre cluster AKS. Le réseau virtuel dispose d’un groupe de sécurité réseau (NSG) qui autorise tout le trafic entrant provenant de l’équilibreur de charge. Ce groupe de sécurité réseau utilise une balise de service de type LoadBalancer pour autoriser le trafic provenant de l’équilibreur de charge.
  • Le CIDR de pod doit être ajouté à loadBalancerSourceRanges s’il existe des pods devant accéder à l’adresse IP LoadBalancer du service pour les clusters avec la version v1.25 ou ultérieure.

Conserver l’adresse IP du client sur les connexions entrantes

Par défaut, les services de type LoadBalancerdans Kubernetes et dans AKS ne conservent pas l’adresse IP du client sur la connexion au pod. L’adresse IP source du paquet livré au pod devient l’adresse IP privée du nœud. Pour conserver l’adresse IP du client, vous devez définir service.spec.externalTrafficPolicy sur local dans la définition du service. Le manifeste suivant montre un exemple.

apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  ports:
  - port: 80
  selector:
    app: azure-vote-front

Personnalisations via des annotations Kubernetes

Les annotations suivantes sont prises en charge pour les services Kubernetes de type LoadBalancer et s’appliquent uniquement aux flux INBOUND.

Annotation Valeur Description
service.beta.kubernetes.io/azure-load-balancer-internal true ou false Spécifiez si l’équilibreur de charge doit être interne. Si la valeur n’est pas définie, la valeur par défaut est public.
service.beta.kubernetes.io/azure-load-balancer-internal-subnet Nom du sous-réseau Spécifiez le sous-réseau auquel l’équilibreur de charge interne doit être lié. Si la valeur n’est pas définie, la valeur par défaut correspond au sous-réseau configuré dans le fichier de configuration cloud.
service.beta.kubernetes.io/azure-dns-label-name Nom de l’étiquette DNS sur les adresses IP publiques Spécifiez le nom d’étiquette DNS pour le service public. Si cette valeur est définie sur une chaîne vide, l’entrée DNS de l’adresse IP publique n’est pas utilisée.
service.beta.kubernetes.io/azure-shared-securityrule true ou false Spécifiez l’exposition du service via une règle de sécurité Azure potentiellement partagée pour augmenter l’exposition du service, en utilisant les règles de sécurité augmentée Azure dans les groupes de sécurité réseau.
service.beta.kubernetes.io/azure-load-balancer-resource-group Nom du groupe de ressources Spécifiez le groupe de ressources des adresses IP publiques de l’équilibreur de charge ne figurant pas dans le même groupe de ressources que l’infrastructure de cluster (groupe de ressources de nœud).
service.beta.kubernetes.io/azure-allowed-service-tags Liste des balises de service autorisées Spécifiez une liste d’étiquettes de service autorisées et séparées par des virgules.
service.beta.kubernetes.io/azure-load-balancer-tcp-idle-timeout Le délai d'expiration TCP en minutes Spécifiez la valeur en minutes des délais d’expiration de la connexion TCP sur l’équilibreur de charge. La valeur par défaut et minimale est 4. La valeur maximale est 30. La valeur doit être un entier.
service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset true ou false Spécifiez si l’équilibreur de charge doit désactiver la réinitialisation TCP lors du délai d’inactivité.
service.beta.kubernetes.io/azure-load-balancer-ipv4 Adresse IPv4 Spécifiez l’adresse IPv4 à affecter à l’équilibreur de charge.
service.beta.kubernetes.io/azure-load-balancer-ipv6 Adresse IPv6 Spécifiez l’adresse IPv6 à affecter à l’équilibreur de charge.

Personnaliser la sonde d’intégrité de l’équilibreur de charge

Annotation Valeur Description
service.beta.kubernetes.io/azure-load-balancer-health-probe-interval Intervalle de la sonde d’intégrité
service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe Nombre minimal de réponses non saines de la sonde d’intégrité
service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path Chemin d’accès de la requête de la sonde d’intégrité
service.beta.kubernetes.io/port_{port}_no_lb_rule true/false {port} est le numéro de port de service. Lorsque la valeur est true, aucune règle lb ou règle de sonde d’intégrité pour ce port n’est générée. Le service de contrôle d’intégrité ne doit pas être exposé à l’Internet public (par exemple, service de contrôle d’intégrité istio/envoy)
service.beta.kubernetes.io/port_{port}_no_probe_rule true/false {port} est le numéro de port de service. Lorsque la valeur est true, aucune règle de sonde d’intégrité pour ce port n’est générée.
service.beta.kubernetes.io/port_{port}_health-probe_protocol Protocole de la sonde d’intégrité {port} est le numéro de port de service. Protocole explicite de sonde d’intégrité pour le port de service {port}, remplaçant port.appProtocol s’il est défini.
service.beta.kubernetes.io/port_{port}_health-probe_port numéro du port ou nom du port dans le manifeste de service {port} est le numéro de port de service. Protocole explicite de sonde d’intégrité pour le port de service {port}, remplaçant la valeur par défaut.
service.beta.kubernetes.io/port_{port}_health-probe_interval Intervalle de la sonde d’intégrité {port} est le numéro de port de service.
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe Nombre minimal de réponses non saines de la sonde d’intégrité {port} est le numéro de port de service.
service.beta.kubernetes.io/port_{port}_health-probe_request-path Chemin d’accès de la requête de la sonde d’intégrité {port} est le numéro de port de service.

Comme indiqué ici, Tcp, Http et Https sont trois protocoles pris en charge par le service d’équilibreur de charge.

Actuellement, le protocole par défaut de la sonde d’intégrité varie selon les services, avec différents protocoles de transport, protocoles d’application, annotations et stratégies de trafic externe.

  1. pour les services locaux, HTTP et /healthz seront utilisés. La sonde d’intégrité interrogera NodeHealthPort plutôt que le service principal effectif
  2. pour les services TCP de cluster, TCP sera utilisé.
  3. pour les services UDP de cluster, aucune sonde d’intégrité.

Remarque

Pour les services locaux avec l’intégration PLS et le protocole de proxy PLS activés, la sonde d’intégrité HTTP+/healthz par défaut ne fonctionne pas. Ainsi, la sonde d’intégrité peut être personnalisée de la même façon que les services de cluster pour prendre en charge ce scénario.

Depuis la version 1.20, l’annotation de service service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path est introduite pour déterminer le comportement de la sonde d’intégrité.

  • Pour les clusters <=1.23, spec.ports.appProtocol ne sera utilisé comme protocole de sonde que lorsque service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path est également défini.
  • Pour les clusters >1.24, spec.ports.appProtocol sera utilisé comme protocole de sonde et / sera utilisé comme chemin d’accès de la requête de la sonde par défaut (service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path pourra être utilisé pour passer à un autre chemin de requête).

Notez que le chemin d’accès de la requête sera ignoré en cas d’utilisation du protocole TCP ou si spec.ports.appProtocol est vide. Plus précisément :

loadbalancer sku externalTrafficPolicy spec.ports.Protocol spec.ports.AppProtocol service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path Protocole de sonde LB Chemin d’accès de la requête de la sonde LB
standard locaux tous tous tous http /healthz
standard cluster udp tous tous null null
standard cluster tcp (ignoré) tcp null
standard cluster tcp tcp (ignoré) tcp null
standard cluster tcp http/https TCP(<=1.23) ou http/https(>=1.24) null(<=1.23) ou /(>=1.24)
standard cluster tcp http/https /custom-path http/https /custom-path
standard cluster tcp protocole non pris en charge /custom-path tcp null
bases locaux tous tous tous http /healthz
bases cluster tcp (ignoré) tcp null
bases cluster tcp tcp (ignoré) tcp null
bases cluster tcp http TCP(<=1.23) ou http/https(>=1.24) null(<=1.23) ou /(>=1.24)
bases cluster tcp http /custom-path http /custom-path
bases cluster tcp protocole non pris en charge /custom-path tcp null

Depuis la version 1.21, deux annotations de service, service.beta.kubernetes.io/azure-load-balancer-health-probe-interval et load-balancer-health-probe-num-of-probe, sont introduites, et personnalisent la configuration de la sonde d’intégrité. Si service.beta.kubernetes.io/azure-load-balancer-health-probe-interval n’est pas défini, la valeur par défaut 5 est appliquée. Si load-balancer-health-probe-num-of-probe n’est pas défini, la valeur par défaut 2 est appliquée. Et la sonde totale doit être inférieure à 120 secondes.

Sonde d’intégrité de l’équilibreur de charge personnalisée pour le port

Différents ports dans un service peuvent nécessiter différentes configurations de sonde d’intégrité. Cela peut être dû à la conception du service (par exemple, un point de terminaison d’intégrité unique contrôlant plusieurs ports) ou à des fonctionnalités Kubernetes comme MixedProtocolLBService.

Les annotations suivantes peuvent être utilisées pour personnaliser la configuration de la sonde par port du service.

annotation spécifique au port annotation globale de la sonde Utilisation
service.beta.kubernetes.io/port_{port}_no_lb_rule N/A (pas d’équivalent globalement) si la valeur est true, aucune règle d’équilibreur de charge ni aucune règle de sonde ne seront générées
service.beta.kubernetes.io/port_{port}_no_probe_rule N/A (pas d’équivalent globalement) si la valeur est true, aucune règle de sonde ne sera générée
service.beta.kubernetes.io/port_{port}_health-probe_protocol N/A (pas d’équivalent globalement) Définissez le protocole de sonde d’intégrité pour ce port de service (par exemple, Http, Https, Tcp)
service.beta.kubernetes.io/port_{port}_health-probe_port N/A (pas d’équivalent globalement) Définit le port de sonde d’intégrité pour ce port de service (par exemple, 15021)
service.beta.kubernetes.io/port_{port}_health-probe_request-path service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path Pour Http ou Https, définit le chemin d’accès de la requête de la sonde d’intégrité. La valeur par défaut est /
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe Nombre d’échecs consécutifs de la sonde avant que le port ne soit considéré comme non sain
service.beta.kubernetes.io/port_{port}_health-probe_interval service.beta.kubernetes.io/azure-load-balancer-health-probe-interval Laps de temps entre les différentes tentatives de la sonde

Pour le manifeste suivant, la règle de sonde pour le serveur httpsserver de port est différente de celle du serveur http, car des annotations pour le port httpsserver sont spécifiées.

apiVersion: v1
kind: Service
metadata:
  name: appservice
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe: "5"
    service.beta.kubernetes.io/port_443_health-probe_num-of-probe: "4"
spec:
  type: LoadBalancer
  selector:
    app: server
  ports:
    - name: httpserver
      protocol: TCP
      port: 80
      targetPort: 30102
    - name: httpsserver
      protocol: TCP
      appProtocol: HTTPS
      port: 443
      targetPort: 30104

Dans ce manifeste, les ports https utilisent un autre port de nœud, une vérification de préparation HTTP au port 10256 sur /healthz(point de terminaison healthz de kube-proxy).

apiVersion: v1
kind: Service
metadata:
  name: istio
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    service.beta.kubernetes.io/port_443_health-probe_protocol: "http"
    service.beta.kubernetes.io/port_443_health-probe_port: "10256"
    service.beta.kubernetes.io/port_443_health-probe_request-path: "/healthz"
spec:
  ports:
    - name: https
      protocol: TCP
      port: 443
      targetPort: 8443
      nodePort: 30104
      appProtocol: https
  selector:
    app: istio-ingressgateway
    gateway: istio-ingressgateway
    istio: ingressgateway
  type: LoadBalancer
  sessionAffinity: None
  externalTrafficPolicy: Local
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  allocateLoadBalancerNodePorts: true
  internalTrafficPolicy: Cluster

Dans ce manifeste, les ports https utilisent un autre point de terminaison de sonde d’intégrité, une vérification de préparation HTTP au port 30000 sur /healthz/ready.

apiVersion: v1
kind: Service
metadata:
  name: istio
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    service.beta.kubernetes.io/port_443_health-probe_protocol: "http"
    service.beta.kubernetes.io/port_443_health-probe_port: "30000"
    service.beta.kubernetes.io/port_443_health-probe_request-path: "/healthz/ready"
spec:
  ports:
    - name: https
      protocol: TCP
      port: 443
      targetPort: 8443
      appProtocol: https
  selector:
    app: istio-ingressgateway
    gateway: istio-ingressgateway
    istio: ingressgateway
  type: LoadBalancer
  sessionAffinity: None
  externalTrafficPolicy: Local
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  allocateLoadBalancerNodePorts: true
  internalTrafficPolicy: Cluster

Résolution des problèmes SNAT

Si vous savez que vous lancez de nombreuses connexions TCP ou UDP sortantes vers les mêmes adresse IP et port de destination et constatez que des connexions sortantes échouent, ou si l’équipe de support vous signale que les ports SNAT (ports éphémères préaffectés) utilisés par la PAT arrivent à épuisement, plusieurs options d’atténuation générales s’offrent à vous. Passez en revue ces options et choisissez celle qui convient le mieux à votre scénario. Plusieurs options peuvent être adaptées à votre scénario. Pour plus d’informations, consultez le Guide de résolution des problèmes de connexions sortantes.

La cause racine de l’épuisement des ressources SNAT est souvent un anti-modèle du mode d’établissement et de gestion de la connectivité sortante, ou des minuteurs configurables dont la valeur par défaut a été changée. Lisez attentivement cette section.

Étapes

  1. Vérifiez si vos connexions restent inactives pendant une longue période et s’appuient sur le délai d’expiration par défaut pour libérer ce port. Dans ce cas, le délai d’expiration par défaut de 30 minutes devra éventuellement être réduit pour votre scénario.
  2. Examinez comment votre application crée une connectivité sortante (par exemple, la révision du code ou la capture de paquets).
  3. Déterminez si cette activité est un comportement attendu ou si l’application ne fonctionne pas correctement. Utilisez des métriques et des journaux d’activité dans Azure Monitor pour justifier vos découvertes. Par exemple, utilisez la catégorie « Échec » pour la métrique connexions SNAT.
  4. Évaluez si les modèles appropriés sont suivis.
  5. Évaluez si l’épuisement des ports SNAT doit être atténué avec davantage d’adresses IP sortantes + davantage de ports sortants alloués.

Modèles de conception

Tirez parti de la réutilisation des connexions et du regroupement de connexions chaque fois que c’est possible. Ces modèles vous aident à éviter les problèmes d’épuisement des ressources et entraînent un comportement prévisible. Des primitives pour ces modèles sont disponibles dans beaucoup de frameworks et de bibliothèques de développement.

  • Les demandes atomiques (une demande par connexion) ne sont généralement pas un bon choix de conception. Ces anti-modèles limitent la mise à l’échelle, réduisent le niveau de performance et diminuent la fiabilité. À la place, réutilisez les connexions HTTP/S pour réduire le nombre de connexions et les ports SNAT associés. L’échelle de l’application et le niveau de performance augmentent en raison de la réduction des établissement de liaisons, de la surcharge et du coût des opérations de chiffrement pendant l’utilisation de TLS.
  • Si vous utilisez un cluster ou un DNS personnalisé, ou des serveurs en amont personnalisés sur coreDNS, gardez à l’esprit que DNS peut introduire un grand nombre de flux individuels quand le client ne met pas en cache le résultat des programmes de résolution DNS. Veillez à personnaliser d’abord coreDNS au lieu d’utiliser des serveurs DNS personnalisés, puis à définir une valeur de mise en cache adaptée.
  • Les flux UDP (par exemple, les recherches DNS) allouent des ports SNAT pendant le délai d’inactivité. Plus le délai d’inactivité est long, plus la sollicitation des ports SNAT est forte. Utilisez un délai d’inactivité court (par exemple, 4 minutes).
  • Utilisez des pools de connexions pour déterminer votre volume de connexions.
  • N’abandonnez jamais un flux TCP en mode silencieux et ne vous fiez pas aux minuteries TCP pour nettoyer un flux. Si vous ne laissez pas le protocole TCP fermer explicitement la connexion, l’état reste alloué aux systèmes intermédiaires et aux points de terminaison. Les ports SNAT sont alors indisponibles pour les autres connexions. Ce modèle peut déclencher des échecs d’application et l’épuisement des ports SNAT.
  • Ne changez pas les valeurs de minuteur lié à la fermeture TCP au niveau du système d’exploitation sans en connaître précisément l’impact. Pendant la récupération de la pile TCP, le niveau de performance de votre application risque d’être affecté quand les points de terminaison d’une connexion ont des attentes incompatibles. Quand vous voulez changer les minuteurs, c’est généralement qu’il y a un problème de conception sous-jacent. Tenez compte des recommandations suivantes.

Passage d’un équilibreur de charge avec une référence SKU De base à une référence SKU Standard

Si vous avez un cluster existant avec l’équilibreur de charge à référence SKU De base, il existe des différences de comportement importantes à noter quand vous effectuez une migration vers l’équilibreur de charge à référence SKU Standard.

Par exemple, le fait d’effectuer des déploiements bleus/verts pour migrer des clusters est une pratique courante étant donné que le type de load-balancer-sku d’un cluster et ne peut être défini qu’au moment de la création du cluster. Toutefois, les équilibreurs de charge à référence SKU De base utilisent des adresses IP à référence SKU De base qui ne sont pas compatibles avec les équilibreurs de charge à référence SKU Standard. Les équilibreurs de charge à référence SKU Standard nécessitent des adresses IP à référence SKU Standard. Lors de la migration de clusters pour mettre à niveau les références SKU de l’équilibreur de charge, une nouvelle adresse IP avec une référence SKU d’adresse IP compatible est nécessaire.

Pour plus d’informations sur la migration de clusters, consultez notre documentation sur les considérations relatives à la migration.

Limites

Les limitations suivantes s’appliquent lorsque vous créez et gérez des clusters AKS prenant un charge un équilibreur de charge avec la référence SKU Standard :

  • Au moins une adresse IP publique ou un préfixe IP sont requis pour autoriser le trafic sortant du cluster AKS. L’adresse IP publique et le préfixe IP sont nécessaires pour maintenir la connectivité entre le plan de contrôle et les nœuds d’agent ainsi que pour assurer la compatibilité avec les versions précédentes d’AKS. Pour spécifier des adresses IP publiques ou des préfixes IP avec un équilibreur de charge de référence (SKU) Standard, vous disposez des options suivantes :
    • Fournir vos propres adresses IP publiques.
    • Fournir vos propres préfixes IP publics.
    • Spécifier un nombre de 1 à 100 pour autoriser le cluster AKS à créer ce nombre d’adresses IP publiques à référence SKU Standard dans le même groupe de ressources que le cluster AKS. Le nom de ce groupe de ressources commence généralement par MC_. AKS attribue l’adresse IP publique pour l’équilibreur de charge de référence SKU Standard. Par défaut, une adresse IP publique est automatiquement créée dans le même groupe de ressources que le cluster AKS si aucune adresse IP publique, aucun préfixe IP public ou aucun nombre d’adresses IP ne sont spécifiés. Vous devez également autoriser des adresses publiques et éviter de créer des stratégies Azure interdisant la création d’adresses IP.
  • Une adresse IP publique créée par AKS ne peut pas être réutilisée comme votre propre adresse IP publique. Les utilisateurs doivent créer, puis gérer toutes les adresses IP personnalisées.
  • Vous ne pouvez définir la référence (SKU) d’équilibreur de charge que lorsque vous créez un cluster AKS. Vous ne pouvez pas modifier la référence SKU de l’équilibreur de charge après la création d’un cluster AKS.
  • Vous pouvez utiliser un seul type de référence SKU d’équilibreur de charge (De base ou Standard) dans un même cluster.
  • Les Load Balancers à référence SKU Standard prennent uniquement en charge les adresses IP à référence SKU Standard.

Étapes suivantes

Pour en savoir plus sur les services Kubernetes, consultez la documentation des services Kubernetes.

Pour en découvrir plus sur l’utilisation de l’équilibreur de charge interne pour le trafic entrant, consultez la documentation sur l’équilibreur de charge interne AKS.