Optimiser les coûts dans Azure Kubernetes Service (AKS)
L’optimisation des coûts consiste à maximiser la valeur des ressources et à réduire les dépenses inutiles au sein de votre environnement cloud. Ce processus implique d’identifier des options de configuration avantageuses et à mettre en œuvre les meilleures pratiques pour améliorer l’efficacité opérationnelle. Un environnement AKS peut être optimisé pour réduire les coûts tout en prenant en compte les exigences de performances et de fiabilité.
Cet article porte sur les points suivants :
- Sélection de l’infrastructure stratégique
- Dimensionnement dynamique et adapté et mise à l’échelle automatique
- Réaliser des économies substantielles avec les remises Azure
- Monitoring holistique et pratiques FinOps
Préparer l’environnement d’application
Évaluer la famille de références SKU
Il est important d’évaluer les besoins en ressources de votre application préalablement au déploiement. Les besoins en infrastructure des petites charges de travail de développement sont différents de ceux des charges de travail volumineuses prêtes pour la production. Bien que la combinaison des capacités en processeur, mémoire et réseau ait une forte influence sur le rapport coût/efficacité d’une référence SKU, prenez en considération les types de machines virtuelles suivants :
- Azure Spot Virtual Machines - Les pools de nœuds spot sont adossés à des groupes de machines virtuelles identiques Azure Spot et déployés sur un domaine d’erreur unique sans aucune garantie de haute disponibilité ou SLA. Les machines virtuelles spot vous permettent de tirer parti de la capacité Azure non utilisée avec des remises significatives (jusqu’à 90 % d’économies par rapport aux tarifs du paiement à l’utilisation). Si Azure a besoin de récupérer de la capacité, l’infrastructure Azure exclut les nœuds spot. Idéal pour les environnements de développement/test, les charges de travail capables de gérer les interruptions comme les travaux de traitement par lots, ainsi que les charges de travail flexibles quant à l’heure d’exécution.
- Processeurs Arm Ampere Altra (ARM64) - Si les machines virtuelles ARM64 consomment peu d’énergie et offrent un bon rapport coût/efficacité, elles ne sacrifient pas pour autant les performances. Du fait de la prise en charge des pools de nœuds AMR64 dans AKS, vous pouvez créer des nœuds d’agents Ubuntu ARM64 voire combiner des nœuds d’architecture Intel et ARM au sein d’un même cluster. Ces machines virtuelles ARM sont non seulement conçues pour exécuter les charges de travail dynamiques et évolutives avec efficacité, mais elles peuvent offrir un rapport coût/performances 50 % plus avantageux que les machines virtuelles x86 équivalentes dans le cas des charges de travail de scale-out. Idéal pour les serveurs web ou d’applications, les bases de données open source, les applications natives cloud, les serveurs de jeux, etc.
- Références SKU à GPU optimisée - Selon la nature de votre charge de travail, envisagez d’utiliser des références SKU de machines virtuelles optimisées pour le calcul, à mémoire optimisée, à stockage optimisé voire à unité de traitement graphique (GPU) optimisée. Les tailles de machines virtuelles à GPU sont des machines virtuelles spécialisées disponibles avec des GPU uniques, multiples et fractionnaires. Les pools de nœuds Linux avec GPU sur AKS sont tout indiqués pour les charges de travail faisant appel à beaucoup de ressources de calcul comme le rendu graphique, l’entraînement de modèles volumineux et l’inférence.
Remarque
Le coût du calcul varie selon les régions. Si vous envisagez d’exécuter des charges de travail dans une région moins coûteuse, pensez aux possibles conséquences de la latence et des coûts de transfert de données. Pour plus d’informations sur les références SKU de machines virtuelles et leurs caractéristiques, consultez Tailles des machines virtuelles dans Azure.
Utiliser des configurations prédéfinies de cluster
Il n’est pas évident de choisir dès le départ la référence SKU de machine virtuelle, les régions, le nombre de nœuds adéquats ainsi que d’autres options de configuration. Les configurations prédéfinies de cluster disponibles dans le portail Azure permettent de s’affranchir de ce premier enjeu en proposant des configurations recommandées pour différents environnements d’application qui sont soucieuses des coûts tout en étant performantes. La configuration prédéfinie Dev/Test est idéale pour développer de nouvelles charges de travail ou tester celles existantes. La configuration prédéfinie Économie de production est idéale pour gérer le trafic de production tout en étant soucieuse des coûts, si vos charges de travail peuvent tolérer les interruptions. Les fonctionnalités non critiques sont désactivées par défaut et les valeurs prédéfinies peuvent être modifiées à tout moment.
Envisager la multilocation
AKS offre une certaine flexibilité quant à la manière d’exécuter les clusters multilocataires et d’isoler les ressources. Pour une multilocation harmonieuse, les clusters et l’infrastructure peuvent être partagés entre les équipes et les divisions opérationnelle via l’isolation logique. Les espaces de noms Kubernetes forment la limite d’isolation logique pour les charges de travail et les ressources. Le fait de partager l’infrastructure a pour effet de réduire la surcharge de gestion des clusters tout en améliorant l’utilisation des ressources et la densité des pods au sein du cluster. Pour plus d’informations sur la multilocation dans AKS et pour déterminer si elle répond bien aux besoins de votre organisation, consultez Considérations relatives à AKS pour l’architecture multilocataires et Concevoir des clusters pour la multilocation.
Avertissement
Les environnements Kubernetes ne sont pas entièrement sécurisés face à la multilocation hostile. S’il n’est pas possible de considérer des locataires de l’infrastructure partagée comme dignes de confiance, une planification supplémentaire est nécessaire pour empêcher les locataires d’impacter la sécurité d’autres services.
Envisagez d’instaurer des limites d’isolation physique. Dans ce modèle, les équipes ou charges de travail sont affectées à leur propre cluster. La contrepartie sera une surcharge en matière de gestion et de coûts.
Créez des applications natives Cloud
Alléger autant que possible votre conteneur
Alléger un conteneur consiste à optimiser la taille et l’empreinte en ressources de l’application conteneurisée. Vérifiez que votre image de base est réduite au minimum et qu’elle contient uniquement les dépendances nécessaires. Supprimez les bibliothèques et packages inutiles. Une image conteneur plus petite permet d’écourter les temps de déploiement et d’augmenter l’efficacité des opérations de mise à l’échelle. Pour passer au cran supérieur, la diffusion en continu d’artefacts sur AKS vous permet de diffuser en continu des images conteneur depuis Azure Container Registry (ACR). Seule la couche nécessaire au démarrage initial du pod est extraite, ce qui réduit le temps d’extraction des images volumineuses, de quelques minutes à quelques secondes.
Appliquer des quotas de ressources
Les quotas de ressources offrent un moyen de réserver et de limiter les ressources à l’échelle d’un projet ou d’une équipe de développement. Les quotas sont définis au niveau d’un espace de noms et peuvent être définis pour les ressources de calcul, les ressources de stockage et le nombre d’objets. Lorsque vous définissez des quotas de ressources, les espaces de noms individuels ne peuvent pas consommer plus de ressources que celles qui leur ont été allouées. Cela est particulièrement important dans le cas des clusters multilocataires dont l’infrastructure est partagée par les équipes.
Utiliser le démarrage/arrêt de cluster
Lorsqu’ils sont laissés sans surveillance, les clusters de développement et de test de petite taille génèrent inutilement des dépenses importantes. Désactivez les clusters qui n’ont pas besoin de s’exécuter en permanence avec le démarrage/arrêt de cluster. Tous les pools de nœuds système et utilisateur sont alors arrêtés, ce qui vous évite de payer pour une capacité de calcul superflue. Tous les objets et l’état du cluster sont préservés au redémarrage du cluster.
Utiliser les réservations de capacité
Les réservations de capacité vous permettent de réserver de la capacité de calcul dans une région ou une zone de disponibilité Azure pour quelque durée que ce soit. La capacité réservée peut alors être utilisée immédiatement jusqu’à la suppression de la réservation. En associant un groupe de réservations de capacité existant à un pool de nœuds, vous pouvez assurer la capacité allouée à votre pool de nœuds et éviter de possibles pics de tarification à la demande pendant les périodes de forte demande de calcul.
Surveiller votre environnement et les dépenses
Accroître la visibilité avec Microsoft Cost Management
Microsoft Cost Management offre un large éventail de fonctionnalités pour faciliter le budgétisation cloud, les prévisions et la visibilité des coûts tant à l’intérieur qu’à l’extérieur du cluster. Une visibilité appropriée est essentielle pour déchiffrer les tendances en matière de dépenses, identifier les possibilités d’optimisation et accroître la responsabilisation parmi les développeurs d’applications et les équipes de plateforme. Activez le module complémentaire d’analyse des coûts AKS pour décomposer de manière précise les coûts de cluster par constructions Kubernetes avec les catégories Calcul, Réseau et Stockage Azure.
Azure Monitor
Si vous ingérez des données de métriques via Container Insights, nous vous recommandons de passer aux métriques Prometheus managées, qui permettent de réduire considérablement les coûts. Vous pouvez désactiver les métriques Container Insights à l’aide de la règle de collecte de données (DCR) et déployer le module complémentaire Prometheus managé, qui prend en charge la configuration via Azure Resource Manager, Azure CLI, le portail Azure et Terraform.
Si vous vous appuyez sur l’ingestion de journaux, nous vous recommandons également d’utiliser l’API Journaux d’activité basiques pour réduire les coûts liés à Log Analytics. Pour plus d’informations, consultez Meilleures pratiques Azure Monitor et Gestion des coûts pour Container Insights.
Optimiser les charges de travail via la mise à l’échelle automatique
Activer la mise à l’échelle automatique d’application
Mise à l’échelle automatique verticale des pods
Lorsque les demandes et les limites se trouvent un niveau bien plus élevé que l’utilisation réelle, cela peut se traduire par un surapprovisionnement des charges de travail et un gaspillage de ressources. À l’inverse, des demandes et des limites trop faibles peuvent entraîner des problèmes de limitation et de charge de travail en raison d’un manque de mémoire. VPA (Vertical Pod Autoscaler) vous permet d’ajuster les besoins en ressources processeur et mémoire de vos pods. VPA fournit des valeurs recommandées pour les demandes et les limites en ressources processeur et mémoire en fonction de l’utilisation historique des conteneurs, que vous pouvez définir manuellement ou mettre à jour automatiquement. Idéal pour les applications dont les demandes en ressources sont fluctuantes.
Mise à l’échelle automatique horizontale des pods
HPA (Horizontal Pod Autoscaler) met à l’échelle de manière dynamique le nombre de réplicas de pods en fonction d’une métrique observée telle que l’utilisation du processeur ou de la mémoire. Pendant les périodes de forte demande, HPA effectue un scale-out, ajoutant ainsi des réplicas de pods afin de répartir la charge de travail. Pendant les périodes de faible demande, HPA effectue un scale-in. Autrement dit, le nombre de réplicas est réduit afin de préserver les ressources. Idéal pour les applications dont les demandes en ressources sont prévisibles.
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.
Mise à l'échelle automatique basée sur les événements Kubernetes
Le module complémentaire KEDA (Kubernetes Event-driven Autoscaler) offre une flexibilité supplémentaire en matière de mise à l’échelle, qui est basée sur diverses métriques pilotées par les événements qui s’alignent sur le comportement de votre application. Par exemple, pour une application web, KEDA peut surveiller le trafic de requêtes HTTP entrantes et ajuster le nombre de réplicas de pods pour garantir la réactivité de l’application. Pour les travaux de traitement, KEDA peut mettre à l’échelle l’application en fonction de la longueur de la file d’attente des messages. La prise en charge managée est fournie pour tous les outils de mise à l’échelle Azure.
Activer la mise à l’échelle automatique de l’infrastructure
Mise à l’échelle automatique de cluster
Pour s’adapter à la demande de l’application, Cluster Autoscaler surveille les pods qui ne peuvent pas être planifiés en raison de contraintes de ressources et met à l’échelle le nombre de nœuds dans le pool de nœuds en conséquence. Quand aucun pod ne s’exécute sur les nœuds, Cluster Autoscaler effectue un scale-down en réduisant le nombre de nœuds. Notez que les paramètres de profil de Cluster Autoscaler s’appliquent à tous les pools de nœuds visés par une mise à l’échelle automatique dans le cluster. Pour plus d’informations, consultez Meilleures pratiques et considérations relatives à Cluster Autoscaler.
Approvisionnement automatique des nœuds
Les charges de travail complexes peuvent nécessiter plusieurs pools de nœuds présentant des configurations de taille de machine virtuelle différentes pour répondre aux besoins en processeur et en mémoire. La sélection et la gestion précises de plusieurs configurations de pool de nœuds ajoutent de la complexité et de la surcharge opérationnelle. L’approvisionnement automatique de nœuds (NAP) simplifie le processus de sélection de références SKU et décide, en fonction des besoins en ressources du pod en attente, quelle est la configuration de machine virtuelle optimale pour exécuter les charges de travail de la manière la plus efficace et la plus économique possible.
Remarque
Pour prendre connaissance des autres meilleures pratiques de mise à l’échelle, consultez Meilleures pratiques concernant les performances et la mise à l’échelle des charges de travail petites et moyennes dans Azure Kubernetes Service (AKS) et Meilleures pratiques concernant les performances et la mise à l’échelle des charges de travail volumineuses dans Azure Kubernetes Service (AKS).
Profiter des remises Azure
Réservations Azure
Si votre charge de travail est prévisible et qu’elle s’inscrit dans la durée, envisagez d’acheter une réservation Azure pour réduire un peu plus vos coûts en ressources. D’une durée d’un ou trois ans, les réservations Azure offrent une remise qui peut atteindre 72 % par rapport aux tarifs du paiement à l’utilisation pour le calcul. Les réservations s’appliquent automatiquement aux ressources correspondantes. Idéal pour les charges de travail destinées à s’exécuter dans les mêmes références SKU et les mêmes régions sur une longue période.
Plan d’économies Azure
Si vous avez des dépenses stables mais que votre utilisation de ressources disparates dans les différentes références SKU et régions rend les réservations Azure inenvisageables, optez pour un plan d’économies Azure. À l’instar des réservations Azure, les plans d’économies Azure ont une durée d’un ou trois ans et s’appliquent automatiquement aux ressources qui se trouvent dans le champ d’application des avantages. Vous vous engagez à dépenser un montant horaire fixe sur les ressources de calcul, indépendamment de la référence SKU ou de la région. Idéal pour les charges de travail qui utilisent différentes ressources et/ou différentes régions de centre de données.
Azure Hybrid Benefit
Azure Hybrid Benefit pour Azure Kubernetes Service (AKS) vous permet d’optimiser vos licences locales sans coût supplémentaire. Utilisez des licences locales remplissant les conditions requises disposant également d’une Software Assurance (SA) active ou un abonnement remplissant les conditions requises pour bénéficier de machines virtuelles Windows sur Azure à un coût réduit.
Adopter le FinOps pour créer une culture d’économie de coûts
Le FinOps (opérations financières) est une discipline qui combine la responsabilité financière avec la gestion et l’optimisation du cloud. Elle vise à favoriser le rapprochement entre les équipes de finances, d’exploitation et d’ingénierie afin de mieux comprendre et contrôler les coûts liés au cloud. La FinOps Foundation a rendu publics plusieurs projets notables :
- FinOps Framework : modèle d’exploitation pour la pratique et l’implémentation du FinOps.
- FOCUS Specification : spécification technique et standard ouvert pour l’utilisation du cloud, les coûts et les données de facturation entre tous les fournisseurs de services cloud de premier plan.
Étapes suivantes
L’optimisation des coûts est un effort répétitif de tous les instants. Pour en savoir plus, consultez les recommandations et les conseils suivants en matière d’architecture :