Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
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 l’identification des options de configuration rentables et l’implémentation des 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 :
- En commençant par AKS Automatic pour une optimisation des coûts intégrée.
- Monitoring holistique et pratiques FinOps.
- Sélection de l’infrastructure stratégique.
- Dimensionnement adapté et mise à l’échelle automatique dynamiques.
- Réaliser des économies importantes avec les remises Azure.
Commencez avec AKS Automatic pour une optimisation des coûts intégrée
AKS Automatic est un mode de cluster qui préconfigure la plupart des pratiques d’optimisation des coûts décrites dans cet article. Si vous créez un cluster, envisagez AKS Automatic pour réduire l’effort d’ingénierie, le risque de configuration et la surcharge opérationnelle en cours qui conduit à des dépenses cloud inutiles.
AKS Automatic fournit les fonctionnalités d’optimisation des coûts suivantes par défaut, sans aucune configuration supplémentaire :
| Capability | Analyse coût-bénéfice |
|---|---|
| Auto-approvisionnement des nœuds (NAP) | Sélectionne automatiquement la référence SKU de machine virtuelle la plus économique pour chaque charge de travail en fonction des demandes de ressources de pod réelles. Élimine la gestion manuelle des pools de nœuds et le surprovisionnement. |
| Mise à l’échelle automatique des charges de travail (VPA, HPA et KEDA) | Tous les mécanismes de mise à l’échelle automatique des charges de travail sont activés par défaut ; les pods et les nœuds s’adaptent donc dynamiquement à la demande réelle plutôt qu’à des hypothèses de charge de pointe. |
| Emballage efficace des compartiments | Les pods sont planifiés pour optimiser l’utilisation des nœuds, ce qui réduit le nombre total de nœuds requis pour servir vos charges de travail. |
| Prometheus managé | Prometheus géré est la plateforme de métriques par défaut. Vous évitez le coût plus élevé des métriques Container Insights sans aucun effort de migration. |
| Protections de déploiement | Les contrôles Azure Policy imposent des demandes et des limites de ressources à tous les pods en mode de mise en application, empêchant ainsi toute consommation incontrôlée des ressources et tout surprovisionnement à l’échelle du cluster. |
Pour les charges de travail qui nécessitent AKS Standard, le reste de cet article décrit chacune de ces pratiques et explique comment les configurer manuellement. Lorsque AKS Automatic fournit une pratique par défaut, une note indique qu’aucune étape supplémentaire n’est nécessaire.
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 plusieurs projets notables, tels que l’Infrastructure FinOps et la Spécification FOCUS.
Pour plus d’informations, consultez Qu’est-ce que FinOps ?
Sélectionner une infrastructure et une configuration de cluster rentables
Évaluer la famille de références SKU
Remarque
Si vous utilisez AKS Automatic, node auto-provisioning (NAP) sélectionne automatiquement la référence SKU de machine virtuelle la plus économique pour chaque charge de travail en fonction de ses demandes de ressources. Vous n’avez pas besoin d’évaluer, de créer ou de gérer manuellement des pools de nœuds.
Il est important d’évaluer les besoins en ressources de votre application avant le déploiement. Les charges de travail de développement de faible envergure ont des besoins en infrastructure différents de ceux des charges de travail destinées à 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 | Descriptif | Idéal pour |
|---|---|---|
| Machines virtuelles Azure Spot | Les groupes identiques de machines virtuelles Azure Spot sous-tendent les pools de nœuds Spot et sont déployés dans un seul domaine d’erreur, sans garantie de haute disponibilité ni d’accord de niveau de service (SLA). Les machines virtuelles Spot vous permettent de tirer parti de la capacité de Azure non utilisée avec des remises significatives (jusqu’à 90% par rapport aux prix de paiement à l’utilisation). Si Azure a besoin de récupérer de la capacité, l’infrastructure Azure exclut les nœuds spot. | Environnements de développement/test, charges de travail qui peuvent gérer des interruptions telles que des travaux de traitement par lots et des charges de travail avec un temps d’exécution flexible. |
| Processeurs ARM (Arm64) | Les machines virtuelles Arm64 sont efficaces et rentables sans compromettre les performances. Avec la prise en charge du pool de nœuds Arm64 dans AKS, vous pouvez créer des nœuds d’agent Ubuntu Arm64 et combiner des nœuds d’architecture Intel et Arm au sein d’un cluster. Ces machines virtuelles sont conçues pour exécuter efficacement des charges de travail dynamiques et évolutives, et peuvent offrir jusqu’à 50 % de meilleur rapport prix-performances que des machines virtuelles comparables basées sur x86 pour les charges de travail évolutives horizontalement. | Serveurs web ou d’applications, bases de données open source, applications natives cloud, 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 machine virtuelle optimisées en mémoire, optimisées en mémoire ou optimisées par GPU. Les tailles de machine virtuelle 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 :
- Meilleures pratiques relatives au stockage et aux sauvegardes dans Azure Kubernetes Service (AKS)
- Options de stockage pour les applications dans AKS (Azure Kubernetes Service)
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. Configurations prédéfinies de cluster dans le portail Azure déchargent ce défi initial en fournissant des configurations recommandées pour différents environnements d’application qui sont conscients des coûts et performants. La présélection Dev/Test est la meilleure solution pour développer de nouvelles charges de travail ou tester des charges de travail existantes. La présélection Économie de production est la meilleure solution pour traiter le trafic de production d’une manière sensible aux coûts si vos charges de travail peuvent tolérer des interruptions. Les fonctionnalités non critiques sont désactivées par défaut et vous pouvez modifier les valeurs prédéfinies à tout moment.
Pour une approche plus complète qui dépasse les présélections statiques, envisagez AKS Automatic. AKS Automatic gère entièrement les pools de nœuds à l’aide de l’approvisionnement automatique de nœuds (NAP), qui dimensionne en permanence l’infrastructure de taille appropriée à vos demandes de charge de travail réelles. Il active également, par défaut, tous les mécanismes de mise à l’échelle automatique des charges de travail et impose la gouvernance des ressources au moyen de garde-fous de déploiement, autant d’avantages supplémentaires que les configurations prédéfinies du cluster n’offrent pas.
Envisager la multilocation
AKS offre une flexibilité dans la façon dont vous exécutez des clusters multilocataires et isolez 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. L’ajout de la gestion et de la surcharge financière est un compromis.
Réduire les déchets de ressources par le biais de la configuration de l’application et du cluster
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. Artifact Streaming sur AKS vous permet de diffuser en continu des images conteneur à partir de 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
Remarque
Les clusters automatiques AKS appliquent automatiquement les demandes de ressources et les limites de tous les pods par le biais de protections de déploiement, qui sont activées en mode d’application par défaut. Cela empêche la consommation et le surprovisionnement des ressources non contrôlées sans nécessiter de configuration de stratégie manuelle. Pour les clusters AKS Standard, configurez les quotas de ressources au niveau de l’espace de noms, comme décrit dans cette section.
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 sur un espace de noms et peuvent être définis sur 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 alloués. 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 assistance, les petits clusters de développement et 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 la capacité de calcul dans une région ou une zone de disponibilité Azure pendant toute durée. 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
Remarque
Les clusters automatiques AKS utilisent Prometheus géré comme plateforme de métriques par défaut. Les métriques Container Insights ne sont pas activées par défaut. Si vous utilisez AKS Automatic, cette optimisation des coûts est déjà en place et aucune procédure de migration n’est nécessaire.
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.
Analyse des logs
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.
Vous pouvez également utiliser les transformations dans Azure Monitor pour filtrer ou modifier les journaux du plan de contrôle et du plan de données avant qu’ils ne soient envoyés à Log Analytics dans un espace de travail. Pour plus d’informations sur la création d’une transformation, consultez Créer une transformation dans Azure Monitor.
Recommandations de coûts Azure Advisor
Les recommandations relatives aux coûts AKS dans Azure Advisor fournissent des recommandations pour vous aider à réaliser une rentabilité sans sacrifier la fiabilité. Advisor analyse vos configurations de ressources et recommande des solutions d’optimisation. Pour plus d’informations, consultez Obtenir des recommandations sur les coûts d’Azure Kubernetes Service (AKS) dans Azure Advisor.
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
Remarque
Les clusters automatiques AKS ont la fonctionnalité VPA activée par défaut. Si vous utilisez AKS Standard, consultez Utilisez l’autoscaler de pod vertical dans Azure Kubernetes Service (AKS) pour activer et configurer VPA.
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 avec des demandes de ressources fluctuantes. Le mode de recommandation uniquement de vPA permet aux équipes de passer en revue les suggestions de ressources sans les appliquer automatiquement. Ce mode peut être activé pendant les tests, et les recommandations de VPA peuvent être utilisées pour définir la demande et les limites du processeur et de la mémoire pour les environnements de production.
Mise à l’échelle automatique horizontale des pods
Remarque
Les clusters automatiques AKS ont HPA activé par défaut. Si vous utilisez AKS Standard, configurez HPA sur vos charges de travail, comme décrit dans la mise à l’échelle automatique des 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 avec des demandes de ressources 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.
Mise à l’échelle automatique basée sur les événements Kubernetes
Remarque
Les clusters automatiques AKS ont KEDA activé par défaut. Si vous utilisez AKS Standard, consultez Installez le module complémentaire KEDA à l’aide de Azure CLI pour activer KEDA.
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. KEDA vous permet également d’effectuer un scale-down vers 0 réplicas, particulièrement utile pour les charges de travail sporadiques pilotées par les événements, le Machine Learning périodique (ML) ou les charges de travail GPU, ainsi que les environnements de développement/test ou de faible trafic.
Activer la mise à l’échelle automatique de l’infrastructure
Mise à l’échelle automatique du cluster
Remarque
Dans AKS Automatic, la mise à l’échelle des nœuds est gérée par le provisionnement automatique de nœud (NAP), qui est préconfiguré par défaut. Pour AKS Standard sans NAP, configurez l’autoscaler de cluster comme décrit dans cette section.
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.
Provisionnement automatique de nœuds
Remarque
Dans AKS Automatic, l’approvisionnement automatique de nœud (NAP) est préconfiguré par défaut. AKS sélectionne automatiquement la référence SKU de machine virtuelle optimale pour chaque charge de travail, sans création manuelle de pool de nœuds ou sélection de référence SKU requise. Pour les clusters AKS Standard, suivez les étapes décrites dans Activer ou désactiver NAP dans AKS pour activer NAP.
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. Provisionnement automatique des nœuds (NAP) simplifie le processus de sélection des SKU et détermine la configuration optimale de la machine virtuelle en fonction des besoins en ressources des 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 SKU et régions pendant une période prolongée.
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 centre de données.
Avantages hybrides d'Azure
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.
É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 :
- Qu’est-ce qu’AKS Automatic ? - Obtenir l’optimisation des coûts intégrée par défaut avec une expérience de cluster entièrement managée.
- Microsoft Azure Well-Architected Framework pour AKS : principes de conception axés sur l’optimisation des coûts
- Guide d’architecture de référence pour AKS
- Optimiser les coûts de calcul sur AKS
- Techniques d’optimisation des coûts AKS