Partager via

Problèmes courants lors de l’exécution ou de la mise à l’échelle de clusters AKS volumineux

  • Article

Cet article répond aux questions fréquemment posées sur les problèmes courants qui peuvent se produire lorsque vous exécutez ou mettez à l’échelle de grands clusters dans Microsoft Azure Kubernetes Service (AKS). Un cluster volumineux est n’importe quel cluster qui s’exécute à plus d’une échelle de 500 nœuds.

J’obtiens une erreur « dépassement de quota » lors de la création, du scale-up ou de la mise à niveau

Pour résoudre ce problème, créez une demande de support dans l’abonnement dans lequel vous essayez de créer, mettre à l’échelle ou mettre à niveau, puis demandez un quota pour le type de ressource correspondant. Pour plus d’informations, consultez les quotas de calcul régionaux.

J’obtiens une erreur « insufficientSubnetSize » quand je déploie un cluster AKS qui utilise la mise en réseau avancée

Cette erreur indique qu’un sous-réseau en cours d’utilisation pour un cluster n’a plus d’adresses IP disponibles dans son CIDR pour une attribution de ressource réussie. Ce problème peut se produire lors des mises à niveau, des montées en puissance parallèles ou de la création d’un pool de nœuds. Ce problème se produit car le nombre d’adresses IP gratuites dans le sous-réseau est inférieur au résultat de la formule suivante :

nombre de nœuds demandés * valeur du pool --max-pod de nœuds

Prerequisites

  • Pour effectuer une mise à l’échelle au-delà de 400 nœuds, vous devez utiliser le plug-in de mise en réseau Azure CNI.

  • Pour planifier votre réseau virtuel et vos sous-réseaux pour prendre en charge le nombre de nœuds et de pods que vous déployez, consultez la planification des adresses IP de votre cluster. Pour réduire la surcharge liée à la planification du sous-réseau ou à la recréation du cluster que vous feriez en raison de l’épuisement des adresses IP, consultez l’allocation d’adresses IP dynamiques.

Solution

Étant donné que vous ne pouvez pas mettre à jour la plage CIDR d’un sous-réseau existant, vous devez avoir l’autorisation de créer un sous-réseau pour résoudre ce problème. Effectuez les étapes suivantes :

  1. Regénérer un nouveau sous-réseau qui a une plus grande plage CIDR suffisante pour les objectifs d’opération.

  2. Créez un sous-réseau qui a une nouvelle plage qui ne se chevauche pas.

  3. Créez un nouveau pool de nœuds sur le nouveau sous-réseau.

  4. Drainez les pods à partir de l’ancien pool de nœuds qui réside dans l’ancien sous-réseau qui sera remplacé.

  5. Supprimez l’ancien sous-réseau et l’ancien pool de nœuds.

J’ai des échecs de connectivité de sortie sporadiques en raison de l’épuisement des ports SNAT

Pour les clusters qui s’exécutent à une échelle relativement importante (plus de 500 nœuds), nous vous recommandons d’utiliser la passerelle NAT (Managed Network Address Translation) AKS pour une plus grande scalabilité. La passerelle NAT Azure autorise jusqu’à 64 512 flux de trafic UDP et TCP sortants par adresse IP et un maximum de 16 adresses IP.

Si vous n’utilisez pas managed NAT, consultez Résoudre les problèmes d’épuisement des adresses réseau sources (SNAT) et les délais d’expiration de connexion pour comprendre et résoudre les problèmes d’épuisement des ports SNAT.

Je ne peux pas monter en puissance jusqu’à 5 000 nœuds à l’aide du Portail Azure

Utilisez Azure CLI pour effectuer un scale-up jusqu’à un maximum de 5 000 nœuds en procédant comme suit :

  1. Créez un nombre minimal de pools de nœuds dans le cluster (car la limite maximale du nœud du pool de nœuds est de 1 000) en exécutant la commande suivante :

    az aks nodepool add --resource-group MyResourceGroup --name nodepool1 --cluster-name MyManagedCluster

  2. Effectuez un scale-up des pools de nœuds un par un. Dans l’idéal, définissez cinq minutes de temps de veille entre des scale-ups consécutifs de 1 000. Exécutez la commande suivante :

    az aks nodepool scale --resource-group MyResourceGroup --name nodepool1 --cluster-name MyManagedCluster

Ma mise à niveau est en cours d’exécution, mais elle est lente

Dans sa configuration par défaut, AKS se déclenche pendant une mise à niveau en effectuant les actions suivantes :

  • Création d’un nœud.
  • Mise à l’échelle du pool de nœuds au-delà du nombre de nœuds souhaité par un nœud.

Pour les paramètres max surge, une valeur par défaut d’un nœud signifie qu’AKS crée un nouveau nœud avant qu’il vide les applications existantes et remplace un nœud versionné antérieure. Ce nœud supplémentaire permet à AKS de réduire les interruptions de charge de travail.

Lorsque vous mettez à niveau des clusters qui ont de nombreux nœuds, la mise à niveau de l’ensemble du cluster peut prendre plusieurs heures si vous utilisez la valeur max-surgepar défaut . Vous pouvez personnaliser la max-surge propriété par pool de nœuds pour permettre un compromis entre la vitesse de mise à niveau et l’interruption de mise à niveau. En augmentant la valeur maximale d’augmentation, vous activez le processus de mise à niveau plus tôt. Toutefois, une valeur importante pour une augmentation maximale peut également entraîner des interruptions pendant le processus de mise à niveau.

Exécutez la commande suivante pour augmenter ou personnaliser l’augmentation maximale pour un pool de nœuds existant :

az aks nodepool update --resource-group MyResourceGroup --name mynodepool --cluster-name MyManagedCluster --max-surge 5

Il est également important de prendre en compte la façon dont vos paramètres de déploiement peuvent retarder l’achèvement de l’opération de mise à niveau ou de mise à l’échelle :

Conseil

Pour obtenir plus d’informations sur ce comportement, vous pouvez afficher des détails d’erreur sur la page Journal d’activité dans le Portail Azure ou consulter les journaux des ressources sur votre cluster.

Ma mise à niveau atteint la limite de quota (5 000 clusters)

Pour résoudre ce problème, consultez Augmenter les quotas de processeurs virtuels régionaux.

Ma création de service interne à plus de 750 nœuds est lente ou défaillante en raison d’une erreur de délai d’attente

Les mises à jour du pool principal Standard Load Balancer (SLB) sont un goulot d’étranglement des performances connu. Nous travaillons sur une nouvelle fonctionnalité qui permettra une création plus rapide de services et de SLB à grande échelle. Pour nous envoyer vos commentaires sur ce problème, consultez la prise en charge d’Azure Kubernetes pour l’équilibreur de charge avec le pool principal basé sur IP.

Solution

Nous vous recommandons d’effectuer un scale-down du cluster à moins de 750 nœuds, puis de créer un équilibreur de charge interne pour le cluster. Pour créer un équilibreur de charge interne, créez un type de service et azure-load-balancer-internal une LoadBalancer annotation, conformément à l’exemple de procédure suivant.

Étape 1 : Créer un équilibreur de charge interne

Pour créer un équilibreur de charge interne, créez un manifeste de service nommé internal-lb.yaml et qui contient le LoadBalancer type de service et l’annotation azure-load-balancer-internal , comme illustré dans l’exemple suivant :

apiVersion: v1
kind: Service
metadata:
  name: internal-app
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: internal-app

Étape 2 : Déployer l’équilibreur de charge interne

Déployez l’équilibreur de charge interne à l’aide de la kubectl apply commande et spécifiez le nom de votre manifeste YAML, comme illustré dans l’exemple suivant :

kubectl apply -f internal-lb.yaml

Une fois votre cluster créé, vous pouvez également provisionner un équilibreur de charge interne (conformément à cette procédure) et maintenir un service d’équilibrage de charge interne en cours d’exécution. Cela vous permet d’ajouter d’autres services à l’équilibreur de charge à grande échelle.

La création du service SLB à grande échelle prend des heures pour s’exécuter

Les mises à jour du pool principal SLB sont un goulot d’étranglement des performances connu. Nous travaillons sur une nouvelle fonctionnalité qui vous permettra d’exécuter des services à charge équilibrée à grande échelle avec des performances considérablement plus rapides pour les opérations de création, de mise à jour et de suppression. Pour nous envoyer vos commentaires, consultez la prise en charge d’Azure Kubernetes pour l’équilibreur de charge avec le pool principal basé sur IP.

Exclusion de responsabilité de tiers

Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.