Partager via

Questions fréquentes (FAQ) sur les problèmes courants liés à l’exécution ou à 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 grand cluster est un cluster qui s’exécute à plus de 500 nœuds.

J’obtiens une erreur « Quota dépassé » 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, et demandez un quota pour le type de ressource correspondant. Pour plus d’informations, consultez 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 affectation 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 libres dans le sous-réseau est inférieur au résultat de la formule suivante :

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

Configuration requise

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. Procédez comme suit :

  1. Régénérez un nouveau sous-réseau qui a une plus grande plage CIDR suffisante pour les objectifs de l’opération.

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

  3. Create 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.

Je rencontre 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 grande (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 nat managé, consultez Résoudre les problèmes d’épuisement de la traduction d’adresses réseau source (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 de la Portail Azure

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

  1. Create un nombre minimal de pools de nœuds dans le cluster (car la limite maximale de nœuds 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 surtensions 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 souhaité de nœuds d’un nœud.

Pour les paramètres de surtension maximale, une valeur par défaut d’un nœud signifie qu’AKS crée un nœud avant de vider les applications existantes et de remplacer un nœud avec version antérieure. Ce nœud supplémentaire permet à AKS de réduire l’interruption de la charge de travail.

Lorsque vous mettez à niveau des clusters qui ont un grand nombre de nœuds, la mise à niveau de l’ensemble du cluster peut prendre plusieurs heures si vous utilisez la valeur par défaut de max-surge. 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 la mise à niveau. En augmentant la valeur de surtension maximale, vous permettez au processus de mise à niveau de se terminer plus tôt. Toutefois, une valeur élevée pour l’augmentation maximale peut également entraîner des interruptions pendant le processus de mise à niveau.

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

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

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 échoue en raison d’une erreur de délai d’attente

Standard Load Balancer mises à jour du pool principal (SLB) constituent un goulot d’étranglement connu des performances. Nous travaillons sur une nouvelle fonctionnalité qui permettra de créer plus rapidement des services et un SLB à grande échelle. Pour nous envoyer vos commentaires sur ce problème, consultez Prise en charge d’Azure Kubernetes pour l’équilibreur de charge avec un 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 : Create un équilibreur de charge interne

Pour créer un équilibreur de charge interne, créez un manifeste de service nommé internal-lb.yaml qui contient le type de LoadBalancer 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 à charge équilibrée interne en cours d’exécution. Cela vous permet d’ajouter d’autres services à l’équilibreur de charge à grande échelle.

L’exécution de la création du service SLB à grande échelle prend des heures

Les mises à jour du pool principal SLB sont un goulot d’étranglement connu des performances. 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 Prise en charge d’Azure Kubernetes pour l’équilibreur de charge avec un 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.