Optimiser l’utilisation et les coûts d’Azure Kubernetes Service (AKS)

Cet article décrit des méthodes pratiques pour optimiser l’utilisation et les coûts Azure Kubernetes Service (AKS) sur la mise à l’échelle, le dimensionnement de l’infrastructure, l’utilisation du GPU, l’architecture multilocataire et les remises Azure.

Pour la plupart des charges de travail de production, AKS Automatic est le point de départ recommandé, car il applique les valeurs par défaut prêtes pour la production, automatise les opérations de base et permet de réduire le surprovisionnement. AKS Standard reste le bon choix lorsque vous avez besoin d’une personnalisation plus approfondie de la plateforme.

Cet article traite des sujets suivants :

Choisir votre base de référence d’optimisation

Commencez par sélectionner le mode de cluster AKS qui correspond à votre modèle de coût et d’exploitation.

Scénario Mode cluster recommandé Pourquoi
La plupart des charges de travail de production dans lesquelles vous souhaitez optimiser les coûts avec une surcharge opérationnelle plus faible AKS Automatic Les valeurs par défaut prêtes pour la production préconfigurées, les opérations gérées et l’allocation de ressources efficace permettent de réduire les pertes et le temps passé à régler la plateforme.
Charges de travail nécessitant une configuration de cluster personnalisée étendue, des modules complémentaires spécialisés ou des contrôles de plateforme stricts AKS Standard Contrôle total sur la configuration du cluster et le modèle d’exploitation.
Équipes au début de leur maturité opérationnelle sur Kubernetes et axées sur une livraison rapide et prévisible AKS Automatic Réduit la complexité de la gestion de la plateforme afin que les équipes puissent se concentrer sur les applications.
Teams avec des processus d’ingénierie de plateforme établis et des normes architecturales spécifiques AKS Standard Prend en charge la personnalisation avancée et les modèles opérationnels personnalisés.

Pour plus d’informations, consultez Qu’est-ce que Azure Kubernetes Service (AKS) automatique ?

Avantages de coût automatiques d’AKS

AKS Automatic réduit les coûts de deux façons : il réduit les déchets de calcul par le biais de l’automatisation et réduit la surcharge opérationnelle de l’exécution de Kubernetes. Le tableau suivant récapitule les fonctionnalités qui ont un impact direct sur les coûts et la façon dont elles sont comparées à AKS Standard.

Les fonctionnalités préconfigurées sont toujours activées et ne peuvent pas être modifiées. Les fonctionnalités par défaut sont configurées pour vous, mais peuvent être ajustées. Les fonctionnalités facultatives sont disponibles pour configurer et ne sont pas activées par défaut.

Fonctionnalité AKS Automatic AKS Standard Impact sur les coûts
Autoprovisionnement des nœuds (NAP) Préconfiguré Facultatif Provisionne automatiquement des nœuds correctement dimensionnés pour les pods en attente, réduisant ainsi la capacité inutilisée et le surprovisionnement.
HPA (Horizontal Pod Autoscaler) Préconfiguré Facultatif Ajuste automatiquement le nombre de pods en fonction de la demande, évitant ainsi le gaspillage des ressources lorsque le trafic est faible.
Mise à l’échelle automatique basée sur les événements Kubernetes (KEDA) Préconfiguré Facultatif La mise à l’échelle pilotée par les événements élimine les réplicas inactifs en attente de travail.
Outil de mise à l’échelle automatique verticale des pods (VPA) Préconfiguré Facultatif Ajuste automatiquement les demandes et limites de ressources des pods en fonction de l’utilisation réelle au fil du temps.
Efficacité du bin-packing des pods Préconfiguré Réglage manuel Les pods sont empaquetés efficacement pour optimiser l’utilisation des nœuds, ce qui réduit le nombre total de nœuds nécessaires.
Prometheus géré + Container Insights Par défaut Facultatif Offre une visibilité immédiate sur les coûts dès le premier jour, sans nécessiter la mise en place d’une solution d’observabilité.
Mises à niveau automatiques du système d’exploitation du cluster et du nœud Préconfiguré Manuel ou facultatif Élimine la surcharge d’ingénierie liée à la mise à niveau et réduit le risque d’incidents de sécurité coûteux à partir de nœuds non corrigés.
Réparation automatique des nœuds Préconfiguré Préconfiguré Réduit les coûts liés aux temps d’arrêt dus à des nœuds défaillants sans intervention manuelle.
Groupe de ressources de nœud complètement managé Préconfiguré Verrouillage facultatif Empêche les modifications accidentelles ou non autorisées des ressources qui peuvent générer des coûts inattendus.
SLA de disponibilité (serveur API à 99,95 %) Incluses Payant (mise à niveau vers l’offre Standard) Aucun coût supplémentaire pour obtenir une garantie de temps de disponibilité assortie d’un engagement financier.
SLA de préparation des pods (99,9 % en moins de 5 min) Incluses Non disponible Comportement de mise à l’échelle prévisible sans investissement de fiabilité personnalisé.

Note

Étant donné que les outils de mise à l’échelle tels que HPA, KEDA et VPA sont préconfigurés dans AKS Automatic, les équipes n’entraînent pas le coût d’installation, de test et de maintenance de la configuration de ces fonctionnalités elles-mêmes. Dans AKS Standard, chacune de ces fonctionnalités nécessite une configuration manuelle et un réglage continu.

Mise à l’échelle automatique

Mise à l’échelle automatique horizontale des pods

Le Horizontal Pod Autoscaler (HPA) surveille la demande en ressources et met automatiquement à jour une ressource de workload afin d’ajuster le nombre de pods en fonction de la demande. La réponse à une charge accrue consiste à déployer davantage de pods. Si la charge diminue et que le nombre de pods est supérieur au minimum configuré, le mécanisme d'autoscaling indique à la ressource de calcul de réduire le nombre de pods.

L’API Metrics obtient les données de kubelet toutes les 60 secondes, et HPA vérifie l’API Metrics toutes les 15 secondes pour toute modification nécessaire par défaut. Cela signifie que le HPA est mis à jour toutes les 60 secondes. Lorsque vous configurez l'HPA pour un déploiement, vous définissez le nombre minimal et maximal de réplicas qui peuvent s’exécuter et les métriques utilisées par l'HPA pour déterminer quand effectuer la mise à l'échelle.

Tip

Dans AKS Automatic, HPA est préconfiguré et prêt à être utilisé sans configuration supplémentaire. Dans AKS Standard, vous configurez HPA manuellement sur chaque charge de travail.

Pour plus d'informations, consultez mise à l'échelle automatique des pods horizontaux et mise à l'échelle automatique des pods dans AKS.

Mise à l’échelle automatique basée sur les événements Kubernetes

La mise à l’échelle automatique basée sur les événements Kubernetes (KEDA) applique la mise à l’échelle automatique pilotée par les événements à vos charges de travail. KEDA fonctionne avec HPA et peut étendre les fonctionnalités sans remplacement ni duplication.

Tip

Dans AKS Automatic, KEDA est préconfiguré et activé sur le cluster. Dans AKS Standard, vous installez et configurez manuellement le module complémentaire KEDA.

Vous pouvez utiliser le module complémentaire KEDA pour AKS pour mettre à l’échelle vos applications et tirer parti d’un catalogue complet de scalers Azure KEDA. Pour plus d’informations, consultez Mise à l’échelle automatique des applications avec le module complémentaire KEDA et l’installation du module complémentaire KEDA pour AKS.

Mise à l’échelle automatique verticale des pods

La mise à l’échelle automatique de pod verticale (VPA) définit automatiquement les demandes de ressources et les limites des conteneurs par charge de travail en fonction de l’utilisation passée. Le VPA libère le processeur et la mémoire des pods pour garantir une utilisation efficace de vos clusters AKS. Au fil du temps, le VPA fournit des recommandations pour l’utilisation des ressources.

Tip

Dans AKS Automatic, VPA est préconfiguré et activé sur le cluster. Dans AKS Standard, vous activez et configurez manuellement VPA.

Pour plus d’informations, consultez Mise à l’échelle automatique verticale des pods dans Azure Kubernetes Service (AKS) et Utiliser l’outil de mise à l’échelle automatique verticale des pods (VPA) dans Azure Kubernetes Service (AKS).

Dimensionnement correct d’un cluster

Taille appropriée de votre cluster

Dimensionner correctement vos clusters pour optimiser les coûts et les performances. Redimensionnez manuellement un cluster en ajoutant ou en supprimant des nœuds pour répondre aux besoins de vos applications. Vous pouvez également effectuer une mise à l’échelle automatique de votre cluster pour ajuster automatiquement le nombre de nœuds en fonction de l’évolution des demandes.

Tip

AKS Automatic active Managed Prometheus et Container Insights par défaut. Vous bénéficiez donc d’une visibilité immédiate sur l’utilisation des ressources dès le premier jour. Dans AKS Standard, vous configurez l’observabilité séparément. La visibilité anticipée vous aide à réagir aux signes de surprovisionnement avant qu’ils ne se transforment en gaspillage durable.

Pour plus d’informations, consultez Redimensionner des clusters Azure Kubernetes Service (AKS).

Mise à l’échelle automatique du cluster

À l’aide de l’autoscaler de cluster, vous pouvez redimensionner automatiquement les pools de nœuds en fonction de l’utilisation des ressources et des contraintes associées. Par exemple, effectuez une mise à l’échelle vers le haut pour programmer des pods en attente, ou une mise à l’échelle vers le bas pour réduire les coûts liés aux nœuds inutilisés. Le profil d'autoscaler de cluster est un ensemble de paramètres que vous pouvez ajuster pour contrôler le comportement de l'autoscaler de cluster.

Pour plus d’informations, consultez la vue d’ensemble de la mise à l’échelle automatique du cluster dans Azure Kubernetes Service (AKS) et Utiliser la mise à l’échelle automatique du cluster dans Azure Kubernetes Service (AKS).

Auto-approvisionnement des nœuds

L’autoprovisionnement de nœud (NAP), basé sur Karpenter, approvisionne l’infrastructure de taille appropriée pour les pods en attente et améliore l’efficacité de l’empaquetage des compartiments.

  • Dans AKS Automatic, l’autoprovisionnement de nœud fait partie de l’expérience managée.
  • Dans AKS Standard, l’autoprovisionnement de nœud est disponible lorsque vous avez besoin de cette fonctionnalité avec un modèle de cluster personnalisé.

Pour plus d’informations, consultez le provisionnement automatique de nœud dans Azure Kubernetes Service (AKS).

Optimisations GPU

Partitionnement et partage GPU

Le partitionnement GPU permet de combattre la sous-utilisation en fractionnant ou en partageant des GPU sur plusieurs charges de travail. Les sections suivantes couvrent différentes façons de partitionner et de partager des GPU dans AKS.

Découpage temporel

L’opérateur GPU NVIDIA permet le découpage temporel des GPU dans les clusters Kubernetes. En utilisant le découpage temporel, un administrateur système peut définir un ensemble de répliques d’un GPU, chacune pouvant être attribuée indépendamment à un pod pour exécuter des charges de travail. Vous pouvez appliquer des configurations de segmentation temporelle à l'échelle globale du cluster et des configurations spécifiques à chaque nœud.

Capture d’écran d’un exemple de graphique visuel montrant le découpage temporel GPU.

Pour plus d’informations, consultez le découpage temporel des GPU dans Kubernetes.

Service multiprocesseur (MPS)

Un seul processus peut ne pas utiliser toutes les capacités de mémoire et de bande passante de calcul disponibles sur un GPU. Le service multiprocesseur (MPS) permet le partitionnement logique de la mémoire et des ressources de calcul entre les charges de travail. Il permet également aux exécutions de noyaux et aux copies mémoire issues de différents processus de se chevaucher sur le GPU. MPS vous permet d’obtenir une utilisation plus élevée du GPU et des temps d’exécution plus courts.

Capture d’écran d’un exemple de graphique visuel montrant le service multiprocesseur GPU (MPS).

Pour plus d’informations, consultez MpS (Multi-Process Service).

GPU à instances multiples (MIG)

Les GPU multi-instances vous permettent de partitionner des GPU basés sur les architectures NVIDIA Ampere et ultérieures en instances GPU distinctes et sécurisées pour les applications CUDA.

Capture d’écran d’un exemple de graphique visuel montrant des GPU multi-instances (MIG).

Pour plus d’informations, consultez l’opérateur GPU avec MIG et créez un pool de nœuds GPU à plusieurs instances dans Azure Kubernetes Service (AKS).

Mutualisation

L’architecture mutualisée désigne le partage de l’infrastructure entre plusieurs locataires, équipes et unités commerciales. Le tableau suivant présente différentes façons d’implémenter l’architecture mutualisée dans AKS :

Type d’architecture mutualisée Niveau multilocataire Densité des pods du cluster Affectation des coûts Cas d’usage idéal Risques potentiels
Cluster dédié Architecture mutualisée stricte inférieur Le plus facile Limites complètes de l'isolation sécuritaire et allocation simple des coûts • L’expansion du cluster à grande échelle ajoute aux coûts de charge de gestion
• Densité de pods inférieure et plus de ressources surprovisionnées
Pool de nœuds dédiés Multilocataire souple Moyenne Moyenne Densité moyenne des pods • Nécessite une approbation entre les locataires
• Nécessite des configurations de cluster supplémentaires, telles que les stratégies réseau, la gestion des quotas, le contrôle d’accès en fonction du rôle (RBAC), etc.
Espace de noms dédié Multilocataire souple Plus haut Plus difficile Partage d’infrastructure pour optimiser l’utilisation des ressources • Non sécurisé pour les environnements hostiles par défaut
• Nécessite des configurations de cluster supplémentaires, telles que les stratégies réseau, la gestion des quotas, le contrôle d’accès en fonction du rôle (RBAC), etc.

Cluster dédié

Avec le modèle multilocataire à clusters dédié, les clusters sont dédiés à une seule charge de travail ou équipe.

Capture d’écran d’un exemple de graphique montrant la multitenance d’un cluster dédié.

Le tableau suivant présente les avantages et inconvénients de l’utilisation d’un cluster dédié :

Avantages Inconvénients
• Méthode d’isolation plus simple
• Allocation de coûts et rétrofacturation simples
• Idéal pour les cas où les locataires ne font pas confiance les uns aux autres (souvent du point de vue de la sécurité et du partage des ressources)		 • Gestion élevée et surcharge financière
• En général, basse densité de pods et ressources surapprovisionnées

Pool de nœuds dédiés

Avec la fonctionnalité multilocataire des pools de nœuds dédiés, les clusters sont partagés par de nombreux clients.

Capture d’écran d’un exemple de graphique visuel montrant une architecture mutualisée avec un pool de nœuds dédié.

Le tableau suivant présente les avantages et inconvénients de l’utilisation d’un pool de nœuds dédié :

Avantages Inconvénients
• Densité moyenne des pods
• Une infrastructure partagée
• Appliquer des balises Azure aux pools de nœuds dédiés à un seul locataire (les balises se propagent aux nœuds et persistent via des mises à niveau)		 • Nécessite une approbation entre les locataires
• Nécessite des configurations de cluster supplémentaires, telles que les stratégies réseau, la gestion des quotas, le contrôle d’accès en fonction du rôle (RBAC), etc.

Espace de noms dédié

Avec la mutualisation par espaces de noms dédiés , les clusters sont partagés par de nombreux locataires, les espaces de noms servant de frontière d’isolation.

Capture d’écran d’un exemple de graphique visuel montrant une architecture mutualisée avec un espace de noms dédié.

Le tableau suivant présente les avantages et inconvénients de l’utilisation d’un espace de noms dédié :

Avantages Inconvénients
Densité de pod supérieure
• Meilleur emballage de conteneur
• Partage de l’infrastructure pour optimiser l’utilisation des ressources		 • Non sécurisé pour les environnements hostiles par défaut
• Nécessite des mesures de sécurité supplémentaires si tous les locataires ne sont pas dignes de confiance

Remises Azure

Pour réaliser des économies plus loin, tirez parti des remises Azure telles que les plans d’épargne Azure, les instances réservées et les avantages hybrides Azure.

Type de remise Azure Détails
Plans d’épargne Azure • Engagement initial de 1 à 3 ans
• Jusqu’à 65 % d’économies par rapport au paiement à l’utilisation
• Flexible, sans restriction liée à la famille de références SKU ou à la région
• Idéal pour les charges de travail avec des coûts constants et des ressources disponibles dans différentes régions et SKU
Instances réservées • Engagement initial de 1 à 3 ans
• Économisez jusqu’à 72% par rapport au paiement à l’utilisation
• Limité à des familles et régions spécifiques de référence SKU
• Idéal pour les charges de travail stables s’exécutant en continu (sans modification inattendue de la référence SKU ou de la région)
Avantages hybrides Azure • Apportez vos propres licences Windows Server et SQL Server locales à Azure
• Utiliser toutes les licences locales éligibles qui ont un abonnement Software Assurance (SA) actif ou éligible

Contenu connexe

Pour en savoir plus sur les coûts AKS et AKS Automatic, consultez les articles suivants :

  • Last updated on