Meilleures pratiques pour les performances et la mise à l’échelle des charges de travail volumineuses dans Azure Kubernetes Service (AKS)

Remarque

Cet article se concentre sur les meilleures pratiques d’ordre général pour les charges de travail volumineuses. Pour connaître les meilleures pratiques propres aux petites et moyennes charges de travail, consultez Performances et meilleures pratiques de mise à l’échelle pour les petites et moyennes charges de travail dans Azure Kubernetes Service (AKS).

Lorsque vous déployez et gérez des clusters dans AKS, vous pouvez utiliser les meilleures pratiques suivantes pour optimiser le niveau de performance et la mise à l’échelle.

N’oubliez pas que volumineux est un terme relatif. Kubernetes a une enveloppe de mise à l’échelle multidimensionnelle et l’enveloppe de mise à l’échelle de votre charge de travail dépend des ressources que vous utilisez. Par exemple, un cluster avec 100 nœuds et des milliers de pods ou de CRD peut être considéré comme volumineux. Un cluster de 1 000 nœuds avec 1 000 pods et plusieurs autres ressources peut être considéré comme petit selon la perspective du plan de contrôle. Le meilleur signal de mise à l’échelle d’un plan de contrôle Kubernetes est le taux de réussite et la latence des requêtes HTTP du serveur d’API, car il s’agit d’un proxy pour la quantité de charge sur le plan de contrôle.

Cet article porte sur les points suivants :

  • Mise à l’échelle des nœuds.
  • Scalabilité du plan de contrôle Kubernetes et d’AKS.
  • Meilleures pratiques du client Kubernetes, y compris interruption progressive, surveillance et pagination.
  • Contraintes de limitation des API et de la plateforme Azure.
  • Limitations des fonctionnalités.
  • Bonnes pratiques en matière de mise en réseau.

Mise à l’échelle des nœuds

Lorsque vous mettez à l’échelle vos clusters AKS vers des niveaux d'échelle plus élevés, gardez à l’esprit les meilleures pratiques de mise à l’échelle des nœuds suivantes :

  • Lors de l’exécution à grande échelle de clusters AKS, utilisez l’autoscaler de cluster ou le provisionnement automatique de nœud dans la mesure du possible pour garantir la mise à l’échelle dynamique des nœuds en fonction de la demande de ressources de calcul.
  • Si vous mettez à l'échelle plus de 1 000 nœuds sans utiliser l’autoscaler de cluster, nous vous recommandons de le faire par lots de 500 à 700 nœuds maximum à la fois. Les opérations de mise à l’échelle doivent prévoir un délai d'attente de deux à cinq minutes entre chaque augmentation afin d’éviter la limitation de l'API Azure. Si vous souhaitez en savoir plus, veuillez consulter la rubrique Gestion des API : stratégies de mise en cache et de limitation.
  • Pour les pools de nœuds système, utilisez la référence SKU Standard_D16ds_v5 ou une référence SKU de machine virtuelle de noyau/mémoire équivalente avec des disques de système d’exploitation éphémères pour fournir des ressources de calcul suffisantes pour les pods kube-system.
  • Étant donné qu’AKS a une limite de 1 000 nœuds par pool de nœuds, nous vous recommandons de créer au moins cinq pools de nœuds d’utilisateurs pour mettre à l’échelle jusqu’à 5 000 nœuds.

Scalabilité du plan de contrôle Kubernetes et d’AKS

Dans Kubernetes, tous les objets exécutés dans un cluster sont gérés par le plan de contrôle, qui est géré par AKS. Alors qu’AKS optimise le plan de contrôle Kubernetes et ses composants pour la scalabilité et le niveau de performance, il est toujours lié par les limites du projet en amont.

Kubernetes dispose d'une enveloppe de mise à l'échelle multidimensionnelle, chaque type de ressource représentant une dimension, et toutes les ressources ne sont pas égales en termes de coût. Par exemple, les secrets sont souvent surveillés par plusieurs contrôleurs et pods, et chacun d’eux effectue un appel LIST initial pour synchroniser l’état. Étant donné que les secrets sont généralement volumineux et fréquemment mis à jour, ils placent plus de charge sur le plan de contrôle que les ressources moins fréquemment surveillées.

Plus vous mettez à l’échelle le cluster dans une dimension donnée, moins vous pouvez effectuer une mise à l’échelle dans d’autres dimensions. Par exemple, l’exécution de centaines de milliers de pods dans un cluster AKS a un impact sur la quantité d’attrition des pods (mutations de pods par seconde) que le plan de contrôle peut prendre en charge.

AKS prend en charge trois niveaux de plan de contrôle dans le cadre de la référence SKU de base : Gratuit, Standard et Premium. Pour plus d’informations, consultez l’article Niveaux tarifaires Gratuit, Standard et Premium pour la gestion des clusters AKS.

Important

Utilisez le niveau Standard ou Premium pour la production ou les charges de travail à grande échelle. AKS effectue automatiquement un scale-up du plan de contrôle Kubernetes pour prendre en charge les limites de mise à l’échelle suivantes :

  • Jusqu’à 5 000 nœuds par cluster AKS
  • 200 000 pods par AKS cluster (avec Azure CNI Overlay)

Dans la plupart des cas, le dépassement du seuil de limite de mise à l’échelle entraîne une dégradation du niveau de performance, mais ne provoque pas le basculement immédiat du cluster. Pour gérer la charge sur le plan de contrôle Kubernetes, envisagez de mettre à l’échelle des lots allant jusqu’à 10 à 20 % de la mise à l’échelle actuelle. Par exemple, pour un cluster de 5 000 nœuds, effectuez une mise à l’échelle par incréments de 500 à 1 000 nœuds. AKS met automatiquement à l’échelle votre plan de contrôle, mais cette mise à l’échelle automatique ne se produit pas instantanément.

Pour vous assurer que votre plan de contrôle a été mis à l’échelle, recherchez l’élément configmap large-cluster-control-plane-scaling-status.

kubectl describe configmap large-cluster-control-plane-scaling-status -n kube-system

Kubernetes : considérations relatives à l’envergure de mise à l’échelle et au plan de contrôle

Les clients Kubernetes sont des composants d’application, tels que des opérateurs ou des agents de surveillance, qui s’exécutent dans le cluster et communiquent avec le kube-apiserver pour lire ou modifier des ressources. Il est important d’optimiser le comportement de ces clients pour réduire la charge qu’ils placent sur le serveur kube-api et le plan de contrôle Kubernetes.

Le nombre de requêtes en cours de traitement par le serveur d’API à un moment donné est déterminé par les indicateurs --max-requests-inflight et --max-mutating-requests-inflight. AKS utilise les valeurs par défaut de 400 et 200 requêtes pour ces indicateurs, ce qui permet d’envoyer un total de 600 requêtes à un moment donné. À mesure que nous mettons à l’échelle le serveur d’API pour qu’il soit adapté à des tailles plus importantes, nous augmentons proportionnellement les demandes en cours.

Deux types d’objets Kubernetes, PriorityLevelConfiguration et FlowSchema (APF), déterminent comment le serveur d’API divise la capacité de requête totale entre les types de requêtes. AKS utilise la configuration par défaut.

Chaque PriorityLevelConfiguration est associé à une part des requêtes totales autorisées. Pour afficher les objets PriorityLevelConfiguration dans votre cluster et leurs partages de requêtes alloués, exécutez la commande suivante.

kubectl get --raw /metrics | grep apiserver_flowcontrol_nominal_limit_seats

FlowSchema mappe les requêtes de serveur d’API à une PriorityLevelConfiguration. Si plusieurs objets FlowSchema correspondent à une requête, le serveur d’API sélectionne celui avec la priorité correspondante la plus basse.

Le mappage de FlowSchemas à PriorityLevelConfigurations peut être consulté à l’aide de cette commande :

kubectl get flowschemas

Pour vérifier si des demandes sont supprimées en raison d’APF, exécutez la commande suivante :

kubectl get --raw /metrics | grep apiserver_flowcontrol_rejected_requests_total

Meilleures pratiques du client Kubernetes

Les appels LIST émis par des clients non optimisés sont souvent l’un des principaux facteurs limitant l’extensibilité d’un cluster. Lorsque vous travaillez avec des listes qui peuvent avoir plus de quelque milliers de petits objets ou plus de quelques centaines d’objets volumineux, vous devez prendre en compte les instructions suivantes :

  • Prenez en compte le nombre d’objets (CR) que vous prévoyez d’exister éventuellement lors de la définition d’un nouveau type de ressource (CRD).
  • La charge sur etcd et le serveur d’API repose principalement sur la taille de la réponse. Cette aide s’applique si le client émet un petit nombre de requêtes LIST pour les objets volumineux ou un grand nombre de requêtes LIST pour les objets plus petits.

Utiliser des informateurs

  • Si votre code doit conserver une liste mise à jour d’objets en mémoire, l’utilisation d’un informateur de la bibliothèque client-go vous permet de bénéficier des avantages de la surveillance des modifications apportées aux ressources sur la base des événements, au lieu de sonder les modifications. Il s’agit de la meilleure approche pour éviter les LIST non optimisés et répétés.

Utiliser le cache du serveur d’API

  • Permet resourceVersion=0 de retourner les résultats du cache du serveur d’API. Cela peut empêcher l’extraction d’objets à partir d’etcd réduisant ainsi la charge etcd, mais elle ne prend pas en charge la pagination.

    /api/v1/namespaces/default/pods?resourceVersion=0

Utilisation efficace de l’API Kubernetes

  • Nous vous recommandons d’utiliser l’argument de surveillance dès que cela est possible. Sans argument, le comportement par défaut consiste à répertorier les objets. Reportez-vous à l’exemple ci-dessous.

    /api/v1/namespaces/default/pods?watch=true

    Procédez à la surveillance à l’aide d’un resourceVersion défini pour être la valeur connue la plus récente reçue de la liste ou de la phase de surveillance précédentes. Cette opération est gérée automatiquement dans client-go. Mais vérifiez si vous utilisez un client Kubernetes dans d’autres langues.

    /api/v1/namespaces/default/pods?watch=true&resourceVersion=<resourceversion>

  • Si les contrôleurs ou les opérateurs doivent utiliser des appels LIST, ils doivent éviter d’interroger les ressources à l’échelle du cluster sans étiquette ou sélecteurs de champs, en particulier dans les clusters volumineux. Les exemples suivants montrent les appels LIST optimisés et non optimisés.

    LISTE optimisée :

    /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running

    LISTE non optimisée :

    /api/v1/pods

  • Utilisez la pagination pour réduire la taille des réponses LIST si le client doit extraire des données à partir de etcd. L’exemple suivant utilise l’argument limite pour restreindre la réponse à 100 objets.

    /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running&limit=100

    Si vous souhaitez que la liste continue à retourner tous les objets pod dans l’exemple ci-dessus, utilisez l’argument continuer avec une limite.

    /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running&limit=100&continue=<continue_token>

    Si kubectl est utilisé, l’argument --chunk-size peut être appliqué directement pour paginer les réponses.

    kubectl get pods -n default --chunk-size=100

  • Si vos contrôleurs ou opérateurs utilisent des mises à jour de bail pour les élections de leader, veillez à ce qu’ils soient résilients aux problèmes de connectivité transitoires en paramétrant leaseDuration, renewDeadline et retryPeriod, qui sont optimaux pour vos charges de travail. Pour les contrôleurs Kubernetes qui utilisent l'élection de leader de client-go, utilisez la formule suivante :

    lease_duration > renew_deadline > retry_period

Daemonsets

  • Il existe une différence significative entre un seul contrôleur répertoriant des objets et un DaemonSet s’exécutant sur chaque nœud faisant la même chose. Si plusieurs instances de votre application cliente répertorient régulièrement un grand nombre d’objets, la solution ne s’adapte pas bien aux clusters volumineux.

  • Sur les clusters avec des milliers de nœuds, la création d’un DaemonSet, la mise à jour d’un DaemonSet ou l’augmentation du nombre de nœuds peut entraîner une charge élevée placée sur le plan de contrôle. Si les pods DaemonSet émettent des demandes coûteuses de serveur d’API au démarrage des pods, ils peuvent entraîner une utilisation élevée des ressources sur le plan de contrôle à partir d’un grand nombre de requêtes simultanées.

  • Utilisez une stratégie RollingUpdate pour déployer progressivement de nouveaux pods DaemonSet. Lorsque le modèle DaemonSet est mis à jour, le contrôleur remplace les anciens pods par de nouveaux pods de manière contrôlée. Lorsque la stratégie de mise à jour continue n’est pas configurée explicitement, Kubernetes crée par défaut un RollingUpdate avec maxUnavailable à 1, maxSurge à 0 et minReadySeconds à 0s. Reportez-vous à l’exemple suivant.

      minReadySeconds: 30
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 1

  • La stratégie RollingUpdate s’applique uniquement aux pods DaemonSet existants. Elle ne limite pas l’impact de l’ajout de nouveaux nœuds, ce qui crée des pods DaemonSet supplémentaires ou déploie entièrement de nouveaux DaemonSets.

  • Pour empêcher les DaemonSets d’émettre des requêtes LIST simultanées au serveur d’API pendant le démarrage après le scale-out du nœud ou de nouveaux déploiements DaemonSet, implémentez la gigue de démarrage dans le point d’entrée du conteneur et configurez les stratégies d’interruption exponentielle et de nouvelle tentative appropriées pour les réponses 5xx ou 429 afin d’empêcher les nouvelles tentatives répétées de requêtes LIST volumineuses.

      spec:
    template:
      spec:
        containers:
        - name: my-daemonset-container
          image: <image>
          command: ["/bin/sh", "-c", "sleep $(( (RANDOM % 60) + 1 )); exec /path/to/your/app --args"]

Remarque

Vous pouvez analyser le trafic du serveur d’API et le comportement du client via les journaux d’audit Kube. Si vous souhaitez en savoir plus, veuillez consultez la rubrique Résoudre les problèmes du plan de contrôle Kubernetes.

Optimisations "etcd"

  • Conservez la taille globale etcd petite et n’utilisez pas etcd comme base de données à usage général. AKS fournit 8 Go de stockage etcd par défaut, mais les bases de données etcd plus volumineuses augmentent le temps de défragmentation, ce qui peut entraîner des problèmes de performances de lecture et d’écriture. Les bases de données etcd plus volumineuses peuvent également augmenter la probabilité de problèmes de fiabilité du serveur d’API et etcd si un client non optimisé extrait un grand nombre d’objets à partir de etcd fréquemment. Si la taille de votre base de données etcd dépasse 2 Go, envisagez d’utiliser les techniques de réduction de taille d’objet répertoriées ci-dessous.
  • Pour réduire les tailles de spécification des pods, déplacez les variables d’environnement des spécifications de pod vers ConfigMaps.
  • Fractionnez les secrets volumineux ou ConfigMaps en éléments plus petits et plus gérables.
  • Stockez les secrets dans Azure Key Vault au lieu des secrets Kubernetes lorsque cela est possible pour réduire le nombre de secrets stockés dans etcd.
  • Nettoyer les objets inutilisés
    • Supprimez les tâches obsolètes et les pods terminés. Utilisez ttlSecondsAfterFinished sur les travaux afin que les objets terminés soient supprimés automatiquement.
    • Assurez-vous que les contrôleurs définissent ownerReferences. Cela permet au garbage collection Kubernetes de supprimer automatiquement les objets dépendants lorsque la ressource parente est supprimée.
    • Limitez l’historique CronJob en définissant successfulJobsHistoryLimit et failedJobsHistoryLimit pour ne conserver qu’un petit nombre d’enregistrements de travaux terminés.
    • Réduire l’historique de déploiement. Les anciens ReplicaSets sont également stockés en tant qu’objets API. La valeur par défaut est 10.
  • Réduisez l’historique de révision Helm avec l’argument --history-max . Dans les clusters volumineux, conservez-le au-dessous de 5.

Surveiller les métriques et journaux du plan de contrôle AKS

La surveillance des métriques de plan de contrôle dans les grands clusters AKS est essentielle pour garantir la stabilité et les performances des charges de travail Kubernetes. Ces métriques fournissent une visibilité sur l’intégrité et le comportement des composants critiques tels que le serveur d’API, etcd, le gestionnaire de contrôleurs et le planificateur. Dans les environnements à grande échelle, où les conflits de ressources et les grands volumes d’appels d’API sont courants, la surveillance des métriques du plan de contrôle permet d’identifier les goulots d’étranglement, de détecter les anomalies et d’optimiser l’utilisation des ressources. En analysant ces métriques, les opérateurs peuvent résoudre de manière proactive des problèmes tels que la latence du serveur d’API, les objets etcd élevés ou la consommation excessive de ressources du plan de contrôle, en garantissant une opération de cluster efficace et en réduisant les temps d’arrêt.

Azure Monitor met à disposition des métriques ainsi que des journaux d’activité détaillés relatifs à l’état du plan de contrôle via les configurations Azure Managed Prometheus et Diagnostic.

Métriques clés de la plateforme du plan de contrôle

AKS expose les métriques de plateforme suivantes dans Azure Monitor pour surveiller la santé du serveur d’API et d’etcd. Ces métriques sont disponibles sans activer Managed Prometheus et peuvent être consultées directement dans le portail Azure sous Metrics pour votre cluster AKS.

Métriques du serveur d’API :

Unité de mesure Description
apiserver_cpu_usage_percentage Pourcentage maximal d’UC (basé sur la limite actuelle) utilisé par le pod du serveur API sur l’ensemble des instances.
apiserver_memory_usage_percentage Pourcentage maximal de mémoire (basé sur la limite actuelle) utilisé par le pod du serveur d’API entre les instances.
apiserver_current_inflight_requests (préversion) Nombre maximal de requêtes actives en cours sur le serveur d’API, par type de requête.

Métriques Etcd :

Unité de mesure Description
etcd_cpu_usage_percentage Pourcentage maximal d’UC (basé sur la limite actuelle) utilisé par le pod etcd du serveur API sur l’ensemble des instances.
etcd_memory_usage_percentage Pourcentage maximal de mémoire (basé sur la limite actuelle) utilisé par le pod etcd entre les instances.
etcd_database_usage_percentage Utilisation maximale de la base de données etcd entre les instances. Surveillez cela de près pour éviter de dépasser la limite de stockage etcd.

Surveillez constamment apiserver_cpu_usage_percentage et apiserver_memory_usage_percentage pour détecter la pression des ressources sur le serveur d’API. Si etcd_database_usage_percentage est constamment supérieur à 50 %, consultez la section Optimisations Etcd pour réduire la taille de la base de données. Pour obtenir la liste complète des métriques disponibles, consultez la référence des données de surveillance AKS.

Limites des fonctionnalités

À mesure que vous mettez à l’échelle vos clusters AKS vers des points d’échelle plus importants, gardez à l’esprit les limitations des fonctionnalités suivantes :

  • AKS prend en charge le scale-up jusqu’à 5 000 nœuds par défaut pour tous les clusters de niveau Standard/LTS. AKS met à l’échelle le plan de contrôle de votre cluster au moment de l’exécution en fonction de la taille du cluster et de l’utilisation des ressources du serveur d’API. Si l’augmentation de capacité jusqu’à la limite autorisée n’est pas possible, activez les métriques du plan de contrôle (en préversion) en utilisant le service managé Azure Monitor pour Prometheus afin d’assurer la supervision du plan de contrôle. Pour résoudre les problèmes de performances de mise à l’échelle ou de fiabilité, consultez les ressources suivantes :

    Remarque

    Pendant l’opération de mise à l’échelle du plan de contrôle, vous pouvez rencontrer une latence élevée ou des délais d’expiration du serveur d’API pendant un maximum de 15 minutes. Si vous continuez à avoir des problèmes de mise à l’échelle vers la limite prise en charge, ouvrez un ticket support.

  • Azure Network Policy Manager (Azure npm) prend uniquement en charge jusqu’à 250 nœuds.

  • Certaines métriques de nœud AKS, notamment l'utilisation du disque de nœud, l'utilisation du processeur et de la mémoire du nœud, et l'entrée/sortie du réseau, ne seront pas accessibles dans les métriques de la plateforme Azure Monitor après avoir mis à l'échelle le plan de contrôle.

  • Vous ne pouvez pas utiliser la fonctionnalité Arrêter et démarrer avec les clusters qui ont plus de 100 nœuds. Si vous souhaitez en savoir plus, veuillez consulter la rubrique Arrêter et démarrer un cluster AKS.

API Azure et contrôle de débit de la plateforme

La charge sur une application cloud peut varier au fil du temps, selon des facteurs tels que le nombre d’utilisateurs actifs ou les types d’activités effectués par les utilisateurs. Si les exigences de traitement du système dépassent la capacité des ressources disponibles, le système peut être surchargé et subir un niveau de performance médiocre et des défaillances.

Pour gérer différentes tailles de charge dans une application cloud, vous pouvez autoriser l’application à utiliser des ressources jusqu’à une limite spécifiée, puis les limiter lorsque la limite est atteinte. Sur Azure, le throttling se produit à deux niveaux. Azure Resource Manager (ARM) impose des restrictions sur le volume de requêtes à l’échelle de l’abonnement et du locataire. Si la requête se trouve sous les limites de limitation pour l’abonnement et le tenant, ARM achemine la requête vers le fournisseur de ressources. Le fournisseur de ressources applique alors des limites de limitation adaptées à ses opérations. Si vous souhaitez en savoir plus, veuillez consulter la rubrique Requêtes de limitations ARM.

Gérer la limitation dans AKS

Les limites d'API Azure sont généralement définies au niveau d'une combinaison abonnement-région. Par exemple, tous les clients au sein d’un abonnement dans une région donnée partagent des limites d’API pour une API Azure donnée, comme Virtual Machine Scale Sets API PUT. Chaque cluster AKS a plusieurs clients appartenant à AKS, tels que le fournisseur de cloud ou l’autoscaler de cluster, ou les clients appartenant au client, tels que Datadog ou Prometheus auto-hébergé, qui appellent des API Azure. Lors de l’exécution de plusieurs clusters AKS dans un abonnement dans une région donnée, tous les clients appartenant à AKS et appartenant au client au sein des clusters partagent un ensemble commun de limites d’API. Par conséquent, le nombre de clusters que vous pouvez déployer dans une région d’abonnement varie en fonction du nombre de clients déployés, de leurs modèles d’appel et de l’échelle globale et de l’élasticité des clusters.

Gardez à l’esprit les considérations ci-dessus. Les clients sont généralement en mesure de déployer entre 20 et 40 clusters de petite à moyenne échelle par région d’abonnement. Vous pouvez agrandir votre échelle d’abonnement à l’aide des meilleures pratiques suivantes :

Mettez toujours à niveau vos clusters Kubernetes vers la dernière version. Les versions plus récentes contiennent de nombreuses améliorations qui résolvent les problèmes de niveau de performance et de limitation. Si vous utilisez une version mise à niveau de Kubernetes et que vous voyez toujours la limitation en raison de la charge réelle ou du nombre de clients dans l’abonnement, vous pouvez essayer les options suivantes :

  • Analyser les erreurs à l’aide d’AKS Diagnostiquer et résoudre des problèmes : vous pouvez utiliser AKS Diagnostiquer et résoudre les problèmes pour analyser les erreurs, identifier la cause racine et obtenir des recommandations de résolution.
  • Split vos clusters en différents abonnements ou régions : si vous avez un grand nombre de clusters et de pools de nœuds qui utilisent Virtual Machine Scale Sets, vous pouvez les fractionner en différents abonnements ou régions au sein du même abonnement. La plupart des limites d’API Azure sont partagées au niveau de l’abonnement-région. Vous pouvez donc déplacer ou mettre à l’échelle vos clusters vers différents abonnements ou régions pour contourner la limitation de débit de l’API Azure. Cette option est particulièrement utile si vous attendez que vos clusters aient une activité élevée. Il n’existe aucune directive générique pour ces limites. Si vous souhaitez obtenir une aide spécifiques, vous pouvez créer un ticket de support.

Réseau

À mesure que vous mettez à l’échelle vos clusters AKS vers des points d’échelle plus importants, gardez à l’esprit les meilleures pratiques de mise en réseau suivantes :

  • Utilisez NAT managé pour la sortie de cluster avec au moins deux adresses IP publiques sur la passerelle NAT. Si vous souhaitez en savoir plus, veuillez consulter la rubrique Créer une passerelle NAT managée pour votre cluster AKS.

  • Si vous utilisez Azure Standard Load Balancer, utilisez au moins 2 adresses IP publiques sortantes. Prenez également en compte les limites de règle de back-end du service LoadBalancer lors de la planification des clusters volumineux. Azure Standard Load Balancers prend en charge jusqu’à 10 000 configurations IP principales par adresse IP frontale. Chaque type : le service LoadBalancer crée une règle d’équilibrage de charge par port exposé et associe tous les nœuds de cluster au pool principal de l’équilibreur de charge. Par exemple, ouvrir 5 ports pour un seul service franchira cette limite à 2 000 nœuds.

    1 service * 5 ports * 2000 nodes = 10000 backend IP configurations

  • Utilisez la superposition Azure CNI pour effectuer une mise à l'échelle jusqu’à 200 000 pods et 5 000 nœuds par cluster. Pour plus d’informations, consultez Configurer le réseau virtuel Azure CNI dans AKS.

  • Si votre application a besoin d’une communication directe pod-à-pod entre clusters, utilisez Azure CNI avec une allocation d’adresses IP dynamiques et mettez à l’échelle jusqu’à 50 000 pods d’application par cluster avec une adresse IP routable par pod. Pour plus d’informations, consultez Configurer le réseau CNI d'Azure pour l’allocation dynamique d’adresses IP dans AKS.

  • Lorsque vous utilisez des services Kubernetes internes derrière un équilibreur de charge interne, nous recommandons de créer un équilibreur de charge interne ou un service inférieur à une échelle de 750 nœuds pour optimiser le niveau de performance de mise à l’échelle et l’élasticité de l’équilibreur de charge.

  • Azure Network Policy Manager (NPM) prend uniquement en charge jusqu’à 250 nœuds. Si vous souhaitez appliquer des stratégies réseau pour les clusters plus volumineux, envisagez d’utiliser Azure CNI alimenté par Cilium, qui combine le plan de contrôle robuste de Azure CNI avec le plan de données Cilium pour fournir une mise en réseau et une sécurité hautes performances.

  • Activez LocalDNS sur vos pools de nœuds pour réduire la latence de résolution DNS et décharger les pods CoreDNS centralisés. Dans les grands clusters avec des volumes de requêtes DNS élevés, la résolution DNS centralisée peut devenir un goulot d’étranglement. LocalDNS met en place un proxy DNS sous forme de service systemd sur chaque nœud, traite les requêtes en local, réduit la charge sur les tables conntrack et bascule les connexions vers TCP afin d’éviter les conditions de concurrence conntrack. LocalDNS prend également en charge le traitement des réponses mises en cache obsolètes lorsque le DNS en amont n’est pas disponible, ce qui améliore la résilience de la charge de travail pendant les défaillances temporaires. Pour plus d’informations, consultez résolution DNS dans AKS.

Considérations relatives à la mise à niveau du cluster et meilleures pratiques

  • Lorsqu’un cluster atteint la limite de 5 000 nœuds, les mises à niveau du cluster sont bloquées. Cette limite empêche une mise à niveau, car il n’existe aucune capacité de nœud disponible pour effectuer des mises à jour progressives dans la limite maximale d’augmentation. Si un cluster a atteint cette limite, nous vous recommandons d’effectuer un scale-down du cluster pour atteindre moins de 3 000 nœuds avant d’essayer une mise à niveau du cluster. Vous disposerez ainsi d’une capacité supplémentaire pour l’attrition des nœuds et réduirez la charge sur le plan de contrôle.
  • Lors de la mise à niveau de clusters avec plus de 500 nœuds, il est recommandé d’utiliser une configuration d'augmentation maximale de 10 à 20 % de la capacité du pool de nœuds. AKS configure les mises à niveau avec une valeur par défaut de 10 % pour la surtension maximale. Vous pouvez personnaliser les paramètres max surge par pool de nœuds pour obtenir un compromis entre la vitesse de mise à niveau et l’interruption de la charge de travail. Lorsque vous augmentez les paramètres de surtension maximale, le processus de mise à niveau se termine plus rapidement, mais vous risquez de subir des interruptions pendant le processus de mise à niveau. Pour plus d’informations, consultez Personnaliser la mise à niveau de l’augmentation des nœuds.
  • Pour plus d’informations sur la mise à jour de cluster, consultez Mettre à niveau un cluster AKS.
  • Last updated on