Partager via

Optimiser les coûts dans Azure Kubernetes Service (AKS)

  • Article

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 adapté et mise à l’échelle automatique dynamiques.
  • Réaliser des économies importantes 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 avant le 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 configurations de capacités d’UC, de mémoire et de réseau ait une forte influence sur la rentabilité d’une référence SKU, prenez en considération les types de machines virtuelles suivantes :

Famille de références SKU Description Cas d’usage
Machines virtuelles Azure Spot Azure Spot Les Virtual Machine Scale Sets rétablissent les pools de nœuds Spot et les déploient vers un domaine de défaut unique sans garantie de haute disponibilité ou de contrat de niveau de service. Les machines virtuelles Spot vous permettent de bénéficier de capacité Azure non utilisée avec des remises significatives (jusqu’à 90 % d’économies par rapport aux tarifs de 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 basés sur Ampere Altra Arm (Arm64) Les machines Arm64 consomment peu d’énergie et sont rentables, sans pour autant sacrifier la performance. Grâce à la prise en charge des pools de nœuds Arm64 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 optimisées pour le GPU 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 à processeur graphique (GPU) optimisé. 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 particulièrement adaptés aux charges de travail faisant appel à beaucoup de ressources de calcul, dont 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.

Passer en revue les options de stockage

Pour plus d’informations sur les options de stockage et les préoccupations connexes relatives aux coûts, consultez les articles suivants :

Utiliser des configurations prédéfinies de cluster

Il peut s’avérer compliqué de bien choisir la référence SKU de machine virtuelle, les régions, le bon nombre de nœuds, 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 architecture mutualisée harmonieuse, vous pouvez partager les clusters et l’infrastructure entre les équipes et les divisions opérationnelles 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 est impossible de faire confiance aux locataires de l’infrastructure partagée, il faut plus de planification 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 délais de déploiement et d’augmenter l’efficacité des opérations de mise à l’échelle. La diffusion en continu d’artefacts sur AKS vous permet de diffuser en continu des images conteneur à partir d’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. La définition de quotas de ressources empêche les espaces de noms individuels de consommer plus de ressources que celles qui leur ont été allouées. Les quotas de ressources sont utiles 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 petits clusters de développement/de test peuvent accumuler des coûts inutiles. Vous pouvez désactiver les clusters qui n’ont pas besoin de s’exécuter en permanence à l’aide de la fonctionnalité de démarrage et arrêt de cluster. Cette fonctionnalité permet d’arrêter tous les pools de nœuds système et utilisateur, ce qui vous évite de payer une capacité de calcul supplémentaire. L’état de votre cluster et des objets est préservé 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 zone de disponibilité Azure pour une durée quelconque. La capacité de réserve 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 bonne visibilité 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 plateformes. 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 au service Prometheus managé, qui permet 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.

Pour plus d’informations, consultez Meilleures pratiques Azure Monitor et Gestion des coûts pour Container Insights.

Log Analytics

Pour les journaux du plan de contrôle, envisagez de désactiver les catégories dont vous n’avez pas besoin et/ou d’utiliser l’API Journaux d’activité basiques, le cas échéant, pour réduire les coûts de Log Analytics. Pour plus d’informations, consultez Journaux de plan de contrôle/ressources Azure Kubernetes Service (AKS). Pour les journaux du plan de données ou les journaux d’application, envisagez d’ajuster les paramètres d’optimisation des coûts.

Optimiser les charges de travail via la mise à l’échelle automatique

Établir une ligne de base

Avant de configurer vos paramètres de mise à l’échelle automatique, vous pouvez utiliser le Test de charge Azure pour établir une base de référence pour votre application. Les tests de charge vous permettent de comprendre le comportement de votre application dans différentes conditions de trafic et d’identifier les goulots d’étranglement des performances. Une fois que vous avez une base de référence, vous pouvez configurer les paramètres de mise à l’échelle automatique pour assurer que votre application puisse gérer la charge attendue.

Activer la mise à l’échelle automatique d’application

Mise à l’échelle automatique verticale des pods

Les demandes et les limites qui se trouvent à un niveau d’utilisation plus élevé qu’en réalité peuvent 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. Le Vertical Pod Autoscaler (VPA) vous permet d’ajuster les besoins en ressources de processeur et de 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.

Autoscaler de pods horizontaux

Le Horizontal Pod Autoscaler (HPA) met à l’échelle de manière dynamique le nombre de réplicas de pods en fonction des métriques observées, 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 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 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 différents aspects de mise à l’échelle de la charge de travail.

Kubernetes event-driven autoscaling

Le module complémentaire Kubernetes Event-driven Autoscaler (KEDA) offre une flexibilité supplémentaire en matière de mise à l’échelle. Cette fonctionnalité 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 du cluster

Pour s’adapter à la demande de l’application, le 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. Lorsqu’aucun pod ne s’exécute sur les nœuds, le Cluster Autoscaler effectue un scale-down en réduisant le nombre de nœuds. 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 un cluster. Pour plus d’informations, consultez Meilleures pratiques et considérations relatives à Cluster Autoscaler.

Auto-approvisionnement des nœuds

Il se peut que les charges de travail complexes nécessitent plusieurs pools de nœuds avec des configurations différentes de taille de machine virtuelle pour répondre aux besoins de processeur et de 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 quelle est la configuration de machine virtuelle optimale en fonction des besoins en ressources de pods en attente, afin d’exécuter les charges de travail de la manière la plus efficace et la plus rentable possible.

Remarque

Pour plus d’informations sur les meilleures pratiques de mise à l’échelle, consultez Meilleures pratiques de performance et de mise à l’échelle des charges de travail petites et moyennes dans Azure Kubernetes Service (AKS) et Meilleures pratiques de performance et de 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 inenvisageables les réservations Azure, envisagez plutôt 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 centres de données.

Azure Hybrid Benefit

Azure Hybrid Benefit pour Azure Kubernetes Service (AKS) vous permet de maximiser 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 fondation FinOps a rendu publics plusieurs projets notables, dont :

  • FinOps Framework : modèle d’exploitation pour la pratique et l’implémentation des FinOps.
  • FOCUS Specification : spécification technique et norme ouverte pour l’utilisation, les coûts et les données de facturation du cloud à travers tous les fournisseurs de services cloud principaux.

É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 :