Partager via

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

  • Article

Remarque

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

Lorsque vous déployez et gérez des clusters dans AKS, vous pouvez utiliser les meilleures pratiques suivantes afin d’optimiser les performances et la mise à l’échelle.

Cet article porte sur les points suivants :

  • Compromis et recommandations pour la mise à l’échelle automatique de vos charges de travail.
  • Gestion de la mise à l’échelle et de l’efficacité des nœuds en fonction des besoins de la charge de travail.
  • Considérations relatives à la mise en réseau pour le trafic d’entrée et de sortie.
  • Surveillance et résolution des problèmes liés aux performances du plan de contrôle et du nœud.
  • Planification de la capacité, scénarios d’augmentation et mises à niveau de cluster.
  • Considérations relatives au stockage et à la mise en réseau pour les performances du plan de données.

Mise à l’échelle automatique de l’application vs mise à l’échelle automatique de l’infrastructure

Mise à l’échelle automatique de l’application

La mise à l’échelle automatique de l’application est utile en cas d’optimisation des coûts ou de limitations de l’infrastructure. Bien configuré, un outil de mise à l’échelle automatique gère la haute disponibilité pour votre application tout en minimisant les coûts. Vous payez uniquement les ressources requises pour maintenir la disponibilité, peu importe la demande.

Par exemple, si un nœud dispose d’espace, mais que le nombre d’adresses IP dans le sous-réseau est insuffisant, il peut ignorer la création d’un nouveau nœud et préférer exécuter immédiatement l’application sur un nouveau pod.

Mise à l’échelle automatique et horizontale des pods

L’implémentation de la mise à l’échelle automatique et horizontale des pods est utile pour les applications dont la demande en ressources est stable et prévisible. Le HPA (Horizontal Pod Autoscaler) assure la mise à l’échelle dynamique du nombre de réplicas de pod, ce qui répartit efficacement la charge entre plusieurs pods et nœuds. Ce mécanisme de mise à l’échelle est généralement le plus avantageux pour les applications qui peuvent se décomposer en composants plus petits et indépendants pouvant s’exécuter en parallèle.

Le HPA fournit des métriques d’utilisation des ressources par défaut. Vous pouvez également intégrer des métriques personnalisées ou tirer parti d’outils tels que le Kubernetes Event-Driven Autoscaler (KEDA) (préversion). Ces extensions permettent au HPA de prendre des décisions de mise à l’échelle en fonction de plusieurs perspectives et critères, ce qui offre une vue plus complète des performances de l’application. Cela est particulièrement utile pour les applications dont les exigences de mise à l’échelle sont complexes et variables.

Remarque

Si la haute disponibilité de l’application est une priorité absolue, nous recommandons de laisser une mémoire tampon légèrement plus élevée que le nombre minimal de pods de votre HPA, et ce afin de gérer le temps de mise à l’échelle.

Mise à l’échelle automatique et verticale des pods

L’implémentation de la mise à l’échelle automatique et verticale des pods est utile pour les applications dont la demande en ressources est fluctuante et imprévisible. Le VPA (Vertical Pod Autoscaler) vous permet d’affiner les demandes de ressources (y compris pour le processeur et la mémoire) pour les pods individuels, ce qui offre un contrôle précis sur l’allocation des ressources. Cette granularité réduit le gaspillage des ressources et améliore l’efficacité d’utilisation globale du cluster. Le VPA rationalise également la gestion des applications en automatisant l’allocation des ressources, en libérant des ressources au profit des tâches critiques.

Avertissement

Vous ne devez pas utiliser conjointement le VPA et le HPA sur les mêmes métriques de processeur ou de mémoire. Cette combinaison peut entraîner des conflits, car les deux outils de mise à l’échelle automatique tentent de répondre aux modifications de la demande avec les mêmes métriques. Toutefois, vous pouvez utiliser conjointement le VPA pour le processeur ou la mémoire et le HPA pour des métriques personnalisées, afin d’empêcher tout chevauchement et de garantir que chaque outil de mise à l’échelle automatique se concentre sur des aspects distincts de la mise à l’échelle de la charge de travail.

Remarque

Le VPA fonctionne d’après les données historiques. Nous recommandons d’attendre au moins 24 heures après le déploiement du VPA pour appliquer des modifications, et ce afin qu’il ait le temps de collecter des données de recommandation.

Mise à l’échelle automatique de l’infrastructure

Mise à l’échelle automatique du cluster

L’implémentation de la mise à l’échelle automatique du cluster est utile si la capacité des nœuds n’est pas suffisante, car elle permet le scale-up et l’approvisionnement de nouveaux nœuds.

Lorsque vous envisagez une mise à l’échelle automatique du cluster, choisir de supprimer un nœud implique de trouver un compromis entre optimiser l’utilisation des ressources et assurer la disponibilité des ressources. Supprimer les nœuds sous-utilisés permet d’améliorer l’utilisation du cluster, mais cela peut entraîner la mise en service de nouvelles charges de travail en attendant que les ressources soient approvisionnées en amont de leur déploiement. Il est important de trouver un équilibre entre ces deux facteurs qui dépendent de vos exigences de cluster et de charge de travail, et de configurer les paramètres de profil de l’outil de mise à l’échelle automatique du cluster en conséquence.

Les paramètres de profil de l’outil de mise à l’échelle automatique du cluster s’appliquent de façon universelle à tous les pools de nœuds visés par une mise à l’échelle automatique dans votre cluster. Autrement dit, toutes les actions de mise à l’échelle qui surviennent dans un pool de nœuds visé par une mise à l’échelle automatique peuvent avoir un impact sur le comportement de la mise à l’échelle automatique dans un autre pool de nœuds. Il est important d’appliquer des paramètres de profil cohérents et synchronisés à tous les pools de nœuds concernés, et ce pour vous assurer que l’outil de mise à l’échelle automatique se comporte comme prévu.

Sur-approvisionnement

Le surapprovisionnement est une stratégie qui permet d’atténuer le risque de pression des applications en s’assurant de disposer de ressources excédentaires facilement disponibles. Cette approche est particulièrement utile pour les applications dont les charges sont très variables, ainsi que pour les modèles de mise à l’échelle de cluster qui font régulièrement l’objet de scale-up et de scale-down.

Pour déterminer l’ampleur optimale du surapprovisionnement, vous pouvez utiliser la formule suivante :

1-buffer/1+traffic

Par exemple, imaginons que vous souhaitez empêcher toute utilisation du processeur à 100 % dans le cluster. Vous pouvez opter pour une mémoire tampon de 30 % afin de maintenir une marge de sécurité. Si vous prévoyez un taux de croissance moyen du trafic de 40 %, vous pouvez envisager un surapprovisionnement de 50 %, comme calculé par la formule :

1-30%/1+40%=50%

Une méthode de surapprovisionnement efficace implique d’utiliser des pods en pause. Les pods en pause sont des déploiements de faible priorité qui peuvent être facilement remplacés par des déploiements de priorité élevée. Les pods de basse priorité que vous créez servent uniquement à réserver de l’espace de mémoire tampon. Lorsqu’un pod de priorité élevée a besoin d’espace, les pods en pause sont supprimés et replanifiés sur un autre nœud (ou sur un nouveau nœud) afin de prendre en charge le pod de priorité élevée.

Le YAML suivant représente un exemple de manifeste d’un pod en pause :

apiVersion: scheduling.k8s.io/v1 
kind: PriorityClass 
metadata: 
  name: overprovisioning 
value: -1 
globalDefault: false 
description: "Priority class used by overprovisioning." 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: overprovisioning 
  namespace: kube-system 
spec: 
  replicas: 1 
  selector: 
    matchLabels: 
      run: overprovisioning 
  template: 
    metadata: 
      labels: 
        run: overprovisioning 
    spec: 
      priorityClassName: overprovisioning 
      containers: 
      - name: reserve-resources 
        image: your-custome-pause-image 
        resources: 
          requests: 
            cpu: 1 
            memory: 4Gi

Mise à l’échelle et efficacité des nœuds

Guide des meilleures pratiques :

Surveillez attentivement l’utilisation des ressources et les stratégies de planification, afin de garantir une utilisation efficace des nœuds.

La mise à l’échelle des nœuds permet d’ajuster de façon dynamique le nombre de nœuds du cluster en fonction des demandes des charges de travail. Vous devez bien comprendre que l’ajout de nœuds à un cluster ne constitue pas toujours la meilleure solution pour améliorer les performances. Pour garantir des performances optimales, vous devez surveiller attentivement l’utilisation des ressources et les stratégies de planification, afin de garantir une utilisation efficace des nœuds.

Images de nœud

Guide des meilleures pratiques :

Utilisez la dernière version d’une image de nœud pour vous assurer que vous disposez des derniers correctifs de sécurité et de bogues.

L’utilisation de la dernière version d’une image de nœud offre la meilleure expérience en termes de performances. AKS fournit des améliorations de performances dans les versions d’image hebdomadaires. Les dernières images daemonset sont mises en cache sur la dernière image de VHD, ce qui permet de bénéficier d’une latence inférieure pour l’approvisionnement et le démarrage des nœuds. Ne pas installer toutes les mises à jour peut affecter les performances. Il est donc important d’éviter tout écart important entre les versions.

Linux Azure

L’hôte de conteneur Azure Linux sur AKS utilise une image AKS native qui fournit un emplacement unique pour le développement Linux. Chaque package est généré à partir de la source puis validé, ce qui garantit que vos services s’exécutent sur des composants éprouvés.

L’hôte de conteneur Azure Linux est léger et ne contient que l’ensemble de packages nécessaires pour exécuter les charges de travail de conteneur. Il fournit une surface d’attaque réduite et élimine les mises à jour correctives et la maintenance de packages inutiles. Au niveau de la couche de base, il comporte un noyau renforcé Microsoft optimisé pour Azure. Cette image est idéale pour les charges de travail sensibles aux performances, et pour les ingénieurs ou les opérateurs de plateforme qui gèrent des flottes de clusters AKS.

Ubuntu 2204

L’image Ubuntu 2204 est l’image de nœud par défaut pour AKS. Il s’agit d’un système d’exploitation léger et efficace, qui est optimisé pour l’exécution de charges de travail conteneurisées. Autrement dit, il permet de réduire l’utilisation des ressources et d’améliorer les performances globales. L’image inclut les derniers⸱correctifs et les dernières mises à jour de sécurité, afin de garantir la protection des charges de travail contre les vulnérabilités.

L’image Ubuntu 2204 est entièrement prise en charge par Microsoft, Canonical et la communauté Ubuntu. Elle permet d’améliorer les performances et la sécurité des charges de travail conteneurisées.

Machines virtuelles

Guide des meilleures pratiques :

Lorsque vous sélectionnez une machine virtuelle, assurez-vous que la taille et les performances du disque du système d’exploitation et celles de la référence SKU de la machine virtuelle sont analogues. Un écart de taille ou de performances peut provoquer des problèmes de performances et une contention des ressources.

Les performances des applications sont étroitement liées aux références SKU de la machine virtuelle que vous utilisez pour vos charges de travail. Les machines virtuelles plus volumineuses et plus puissantes offrent généralement de meilleures performances. Pour les charges de travail stratégiques/produit, nous recommandons d’utiliser des machines virtuelles équipées au minimum d’un processeur 8 cœurs. Les machines virtuelles dotées de matériels nouvelle génération (v4 et v5, par exemple) permettent également d’améliorer les performances. N’oubliez pas que la latence de création et de mise à l’échelle peut varier en fonction de la référence SKU des machines virtuelles que vous utilisez.

Utiliser des pools de nœuds système dédiés

Pour mettre à l’échelle les performances et la fiabilité, nous recommandons d’utiliser un pool de nœuds système dédié. Avec cette configuration, le pool de nœuds système dédié réserve de l’espace aux ressources système critiques (telles que les démons système du système d’exploitation). La charge de travail d’application peut ensuite s’exécuter dans un pool de nœuds utilisateur, afin d’augmenter la disponibilité des ressources allouables pour l’application. Cette configuration permet également d’atténuer le risque de concurrence des ressources entre le système et l’application.

Opérations de création

Passez en revue les extensions et les modules complémentaires que vous avez activés lors de la création de l’approvisionnement. Les extensions et les modules complémentaires peuvent augmenter la latence et la durée globale des opérations de création. Si vous n’avez pas besoin d’extension ni de module complémentaire, nous recommandons de les supprimer, afin d’améliorer la latence de création.

Vous pouvez également utiliser les zones de disponibilité, afin de fournir un niveau de disponibilité plus élevé et de vous protéger contre les défaillances matérielles et les événements de maintenance planifiée. Les clusters AKS distribuent les ressources dans des sections logiques de l’infrastructure Azure sous-jacente. Les zones de disponibilité séparent physiquement les nœuds d’autres nœuds, et ce afin de garantir que les défaillances uniques n’affectent pas la disponibilité de l’application. Les zones de disponibilité Azure sont uniquement disponibles dans certaines régions. Pour plus d’informations, consultez Zones de disponibilité dans Azure.

Serveur d’API Kubernetes

Opérations LIST et WATCH

Kubernetes utilise les opérations LIST et WATCH pour interagir avec le serveur d’API Kubernetes et surveiller les informations relatives aux ressources de cluster. Ces opérations sont essentielles à la façon dont Kubernetes procède à la gestion des ressources.

L’opération LIST récupère une liste des ressources qui répondent à certains critères (comme tous les pods d’un espace de noms donné ou tous les services du cluster). Cette opération est utile si vous souhaitez obtenir une vue d’ensemble des ressources de cluster ou si vous devez agir sur plusieurs ressources simultanément.

L’opération LIST permet de récupérer de grandes quantités de données, en particulier dans les clusters volumineux comportant de multiples ressources. Pour rappel, l’exécution d’appels LIST fréquents ou non liés impose une charge importante au serveur d’API et peut clore les temps de réponse.

L’opération WATCH permet de surveiller les ressources en temps réel. Lorsque vous configurez une opération WATCH sur une ressource, le serveur d’API envoie des mises à jour chaque fois qu’une modification est apportée à cette ressource. Cela est important pour les contrôleurs (comme le contrôleur ReplicaSet) qui s’appuient sur l’opération WATCH pour maintenir l’état souhaité des ressources.

Pour rappel, surveiller un trop grand nombre de ressources mutables ou exécuter un trop grand nombre de requêtes WATCH simultanées peut surcharger le serveur d’API et provoquer une consommation excessive des ressources.

Pour éviter de tels problèmes et garantir la stabilité du plan de contrôle Kubernetes, vous pouvez utiliser les stratégies suivantes :

Quotas de ressources

Implémentez des quotas de ressources pour limiter le nombre de ressources que peut répertorier/surveiller un utilisateur ou un espace de noms donné, afin d’empêcher les appels excessifs.

Priorité et équité des API

Kubernetes a lancé le concept de priorité et d’équité des API (APF) afin de hiérarchiser et de gérer les requêtes d’API. Vous pouvez utiliser APF dans Kubernetes afin de protéger le serveur d’API du cluster et de réduire le nombre de réponses HTTP 429 Too Many Requests vues par les applications clientes.

Ressource personnalisée Fonctionnalités clés
PriorityLevelConfigurations • Définit différents niveaux de priorité pour les requêtes d’API.
• Spécifie un nom unique et attribue une valeur entière représentant le niveau de priorité. Les niveaux de priorité plus élevée sont associés à des valeurs entières inférieures, ce qui indique qu’ils sont plus critiques.
• Peut utiliser des multiples pour classer les requêtes en différents niveaux de priorité, en fonction de leur importance.
• Permet de déterminer si les requêtes d’un niveau de priorité donné doivent être soumises à des limites de débit.
FlowSchemas • Définit la façon dont les requêtes d’API doivent être routées vers différents niveaux de priorité, en fonction des attributs de la requête.
• Définit des règles qui correspondent aux requêtes en fonction de critères tels que les groupes d’API, les versions et les ressources.
• Lorsqu’une requête correspond à une règle donnée, elle est dirigée vers le niveau de priorité spécifié dans la ressource PriorityLevelConfiguration associée.
• Permet de définir l’ordre d’évaluation lorsque plusieurs FlowSchemas correspondent à une requête, afin de garantir que certaines règles sont prioritaires.

La configuration d’une API avec PriorityLevelConfigurations et FlowSchemas permet de privilégier les requêtes d’API critiques comparé à celles moins importantes. Cela garantit que les opérations essentielles ne manquent pas ou ne subissent pas de retards en raison de requêtes de priorité inférieure.

Optimiser l’étiquetage et les sélecteurs

Lorsque vous utilisez les opérations LIST, optimisez les sélecteurs d’étiquette pour limiter l’étendue des ressources que vous souhaitez interroger, et ce afin de réduire la quantité de données retournées et la charge sur le serveur d’API.

Avec les opérations CREATE et UPDATE de Kubernetes, reportez-vous aux actions qui gèrent et modifient les ressources de cluster.

Opérations CREATE et UPDATE

L’opération CREATE crée de nouvelles ressources dans le cluster Kubernetes (comme des pods, des services, des déploiements, des configmaps et des secrets). Pendant une opération CREATE, un client (comme kubectl ou un contrôleur) envoie une requête au serveur d’API Kubernetes pour créer la ressource. Le serveur d’API valide la requête, garantit la conformité à toutes les stratégies de contrôleur d’admission, puis crée la ressource dans l’état souhaité du cluster.

L’opération UPDATE modifie les ressources existantes dans le cluster Kubernetes, y compris les modifications apportées aux spécifications des ressources (comme le nombre de réplicas, les images conteneur, les variables d’environnement ou les étiquettes). Pendant une opération UPDATE, un client envoie une requête au serveur d’API pour mettre à jour une ressource existante. Le serveur d’API valide la requête, applique les modifications apportées à la définition de ressource et met à jour la ressource de cluster.

Les opérations CREATE et UPDATE peuvent affecter les performances du serveur d’API Kubernetes dans les conditions suivantes :

  • Haute concurrence : lorsque plusieurs utilisateurs ou applications effectuent des requêtes CREATE ou UPDATE simultanées, cela peut entraîner une augmentation des requêtes d’API arrivant au serveur en même temps. Cela peut contraindre la capacité de traitement du serveur d’API et provoquer des problèmes de performances.
  • Définitions de ressource complexes : les définitions de ressources trop complexes ou impliquant plusieurs objets imbriqués peuvent augmenter le temps nécessaire au serveur d’API pour valider et traiter les requêtes CREATE et UPDATE, ce qui peut entraîner une dégradation des performances.
  • Contrôle d’admission et validation des ressources : Kubernetes applique différentes stratégies de contrôle d’admission et des vérifications de validation sur les requêtes CREATE et UPDATE entrantes. Les définitions de ressource volumineuses (comme celles avec des annotations ou des configurations étendues) peuvent nécessiter un temps de traitement plus important.
  • Contrôleurs personnalisés : les contrôleurs personnalisés qui surveillent les modifications apportées aux ressources (comme les contrôleurs Deployments ou StatefulSet) peuvent générer de nombreuses mises à jour lors de la mise à l’échelle ou du déploiement des modifications. Ces mises à jour peuvent contraindre les ressources du serveur d’API.

Pour en savoir plus, consultez la section Résoudre les problèmes de serveur d’API et d’etcd dans AKS.

Performances du plan de données

Le plan de données Kubernetes est chargé de gérer le trafic réseau entre les conteneurs et les services. Les problèmes liés au plan de données peuvent ralentir les temps de réponse, dégrader les performances et entraîner des temps d’arrêt de l’application. Il est important de surveiller attentivement les configurations de plan de données (comme la latence réseau, l’allocation des ressources, la densité du conteneur et les stratégies réseau) et de les optimiser, afin de garantir que vos applications conteneurisées s’exécutent correctement et efficacement.

Types de stockage

AKS recommande et utilise par défaut des disques de système d’exploitation éphémères. Les disques de système d’exploitation éphémères sont créés sur le stockage local de la machine virtuelle et ne sont pas enregistrés dans le stockage Azure distant (disques de système d’exploitation managés, par exemple). Ils offrent des temps de réinitialisation et de démarrage plus rapides, ce qui permet d’accélérer les opérations de cluster et de réduire la latence de lecture/écriture sur le disque de système d’exploitation des nœuds de l’agent AKS. Les disques de système d’exploitation éphémères sont particulièrement adaptés aux charges de travail sans état, dont les applications tolèrent la défaillance individuelle d’une machine virtuelle, mais ne tolèrent pas les temps de déploiement des machines virtuelles ni la réinitialisation des instances par une machine virtuelle individuelle. Seules certaines références SKU de machine virtuelle prennent en charge les disques de système d’exploitation éphémères. Vous devez donc vous assurer que la génération et la taille de la référence SKU souhaitée sont compatibles. Pour en savoir plus, consultez la section Disques de système d’exploitation éphémères dans Azure Kubernetes Service (AKS).

Si la charge de travail ne peut pas utiliser de disques de système d’exploitation éphémères, AKS utilise par défaut les disques de système d’exploitation SSD Premium. Si les disques de système d’exploitation SSD Premium ne sont pas compatibles avec la charge de travail, AKS sélectionne par défaut les disques SSD Standard. Actuellement, HDD Standard constitue le seul autre type de disque de système d’exploitation disponible. Pour en savoir plus, consultez la section Options de stockage dans Azure Kubernetes Service (AKS).

Le tableau offre une décomposition des cas d’usage recommandés pour les disques de système d’exploitation pris en charge dans AKS :

Type de disque du système d’exploitation Fonctionnalités clés Cas d’usage recommandé
Disques de système d’exploitation éphémères • Temps de réinitialisation et de démarrage plus rapides.
• Latence de lecture/écriture inférieure sur le disque de système d’exploitation des nœuds de l’agent AKS.
• Hautes performances et haute disponibilité.		 • Charges de travail d’entreprise exigeantes, comme SQL Server, Oracle, Dynamics, Exchange Server, MySQL, Cassandra, MongoDB, SAP Business Suite, etc.
• Charges de travail de production sans état nécessitant une haute disponibilité et une faible latence.
Disques de système d’exploitation SSD Premium • Performances constantes et latence faible.
• Haute disponibilité.		 • Charges de travail d’entreprise exigeantes, comme SQL Server, Oracle, Dynamics, Exchange Server, MySQL, Cassandra, MongoDB, SAP Business Suite, etc.
•• Charges de travail d’entreprise intensives en entrée/sortie (E/S).
Disques de système d’exploitation SSD Standard • Performances constantes.
• Disponibilité et latence améliorées comparé aux disques HDD Standard.		 • Serveurs web.
• Serveurs d’application avec opérations d’entrée/sortie par seconde (IOPS) réduites.
• Applications d’entreprise peu utilisées.
• Charges de travail de développement/test.
Disques HDD Standard • Coûts réduits.
• Variabilité en termes de performances et de latence.		 • Stockage de sauvegarde.
• Stockage de masse avec un accès peu fréquent.

IOPS et débit

Les opérations d’entrée/sortie par seconde (IOPS) renvoient au nombre d’opérations de lecture et d’écriture qu’un disque peut effectuer en une seconde. Le débit fait référence à la quantité de données qui peuvent être transférées pendant une période donnée.

Les disques de système d’exploitation sont chargés du stockage du système d’exploitation et de ses fichiers. Les machines virtuelles sont chargées de l’exécution des applications. Lorsque vous sélectionnez une machine virtuelle, assurez-vous que la taille et les performances du disque du système d’exploitation et celles de la référence SKU de la machine virtuelle sont analogues. Un écart de taille ou de performances peut provoquer des problèmes de performances et une contention des ressources. Par exemple, si le disque de système d’exploitation est bien plus petit que les machines virtuelles, il peut limiter la quantité d’espace disponible pour les données d’application et entraîner la saturation de l’espace disque du système. Si le disque de système d’exploitation enregistre des performances inférieures à celles des machines virtuelles, il peut devenir un goulot d’étranglement et limiter les performances globales du système. Assurez-vous que la taille et les performances sont équilibrées, afin de garantir des performances optimales dans Kubernetes.

Vous pouvez utiliser les étapes suivantes pour surveiller les métriques d’IOPS et de bande passante sur les disques de système d’exploitation dans le portail Azure :

  1. Accédez au portail Azure.
  2. Recherchez Groupe de machines virtuelles identiques et sélectionnez votre groupe de machines virtuelles identiques.
  3. Sous Supervision, sélectionnez Métriques.

Les disques de système d’exploitation éphémères peuvent fournir des IOPS et un débit dynamiques pour l’application, tandis que les disques managés sont associés à des IOPS et un débit limités. Pour plus d’informations, consultez Disques de système d’exploitation éphémères pour les machines virtuelles Azure.

Le disque Azure SSD Premium v2 est conçu pour les charges de travail d’entreprise gourmandes en E/S qui nécessitent des latences de disque inférieures à la milliseconde, ainsi que des IOPS et un débit élevés à faible coût. Il est adapté à un large éventail de charges de travail (comme SQL Server, Oracle, MariaDB, SAP, Cassandra, MongoDB, le Big Data et l’analytique, les jeux, etc.). Ce type de disque est l’option la plus performante actuellement disponible pour les volumes persistants.

Planification de pod

Les ressources de processeur et de mémoire allouées à une machine virtuelle affectent directement les performances des pods qui s’exécutent sur la machine virtuelle. Lorsqu’un pod est créé, un certain volume de ressources de mémoire et de processeur lui est attribué, lequel est utilisé pour exécuter l’application. Si les ressources de mémoire ou de processeur disponibles sur la machine virtuelle sont insuffisantes, cela peut ralentir ou même faire planter les pods. Si les ressources de mémoire ou de processeur disponibles sur la machine virtuelle sont trop nombreuses, elle peut altérer l’efficacité d’exécution des pods, gaspiller des ressources et augmenter les coûts. Nous recommandons de surveiller le nombre total de requêtes de pods sur les charges de travail au regard du nombre total de ressources allouables, et ce afin d’optimiser la prévisibilité et les performances de planification. Vous pouvez également utiliser --max-pods pour définir le nombre maximal de pods par nœud en fonction de la planification de la capacité.