L'optimisation des coûts d'un cluster consiste à utiliser les ressources de manière économique sans compromettre la stabilité des charges de travail. Ce guide couvre la sélection des instances, les méthodes de facturation, la mise à l'échelle automatique, la planification des pods et la surveillance des coûts. Il vous offre un cadre pratique pour mettre en place une démarche FinOps sur Alibaba Cloud.
Ce guide s'adresse aux administrateurs des clusters Container Service for Kubernetes (ACK). Les recommandations ne sont pas classées par ordre de priorité : appliquez-les en fonction de vos besoins métier. Avant de commencer, assurez-vous de maîtriser les concepts Kubernetes suivants : pods et ressources des conteneurs, namespaces, mise à l'échelle automatique (mise à l'échelle des charges de travail et mise à l'échelle des nœuds), ainsi que la planification.
Rubriques connexes :
Pour garantir la stabilité des applications, combinez ces recommandations avec les configurations suggérées pour la création de clusters haute disponibilité et les configurations de charge de travail recommandées.
Si votre cluster ACK Pro compte plus de 500 nœuds ou 10 000 pods, suivez les recommandations pour l'utilisation de clusters à grande échelle.
Pour mettre en place un système FinOps et définir des objectifs stratégiques en matière de coûts, consultez la rubrique relative à Cost Suite. Le FinOps (Finance + DevOps) regroupe un ensemble de pratiques de gestion financière du cloud qui aident les équipes à estimer, suivre et optimiser les coûts des ressources cloud.
Choisir les types d'instance et les méthodes de facturation
Avant de créer un cluster, évaluez les besoins en ressources de vos charges de travail et sélectionnez les types d'instance et les méthodes de facturation qui offrent le meilleur compromis entre performances et coûts.
Adapter les types d'instance aux profils de charge de travail
Le tableau suivant résume les profils de charge de travail courants, ainsi que les types d'instance et les méthodes de facturation recommandés pour chacun d'eux.
| Profil de charge de travail | Type d'instance recommandé | Méthode de facturation recommandée | Notes |
|---|---|---|---|
| Services web et bases de données (stables, exécution longue) | À usage général (par exemple, série ecs.g) | Abonnement ou plan d'économies | Cycle de vie prévisible ; l'abonnement et les plans d'économies réduisent le coût unitaire |
| Mise en cache distribuée (forte consommation de mémoire) | Optimisée pour la mémoire (ratio vCPU/mémoire de 1:8) | Abonnement ou paiement à l'utilisation | Les instances optimisées pour la mémoire améliorent l'utilisation du CPU à moindre coût pour les applications gourmandes en mémoire |
| Apprentissage profond et entraînement de modèles | Accélérée par GPU | Paiement à l'utilisation ou instances preemptible | Ratio GPU/vCPU : de 1:8 à 1:12 ; utilisez des instances preemptible pour les tâches d'entraînement tolérantes aux pannes |
| Traitement par lots, ETL, tâches événementielles | Tout type | Preemptible | Jusqu'à 90 % moins cher que le paiement à l'utilisation ; adapté aux charges de travail sans état et tolérantes aux pannes |
| Environnements de développement/test et petits sites web | Familles d'instances partagées | Paiement à l'utilisation | Prix inférieur ; les performances peuvent fluctuer ; non adapté à la production |
| Pics de trafic et promotions e-commerce | À usage général | Paiement à l'utilisation | Flexible ; aucun engagement préalable requis |
Évitez les types d'instance disposant de 2 vCPU et de 4 Go de mémoire ou moins dans les environnements de production afin de prévenir les goulots d'étranglement et la fragmentation des ressources. Consultez la rubrique Recommandations de spécifications ECS pour les clusters ACK pour plus de détails.
Pour obtenir des conseils généraux sur la sélection des instances, consultez la rubrique Suggestions sur le choix des spécifications ECS pour les clusters ACK.
Utiliser des instances preemptible
Les instances preemptible sont des instances facturées au paiement à l'utilisation dont le prix varie en fonction de l'inventaire en temps réel. Elles permettent de réduire les coûts totaux jusqu'à 90 % par rapport aux instances classiques en paiement à l'utilisation.
Les instances preemptible peuvent être récupérées après leur expiration. Utilisez-les uniquement pour des charges de travail sans état et tolérantes aux pannes, telles que :
Traitement par lots et apprentissage automatique
Tâches ETL Big Data (par exemple, Apache Spark)
Traitement des transactions en file d'attente
Applications utilisant des API REST
Pour connaître les bonnes pratiques, consultez la rubrique Bonnes pratiques pour les pools de nœuds basés sur des instances preemptible.
Utiliser des familles d'instances partagées
Les familles d'instances partagées conviennent aux développeurs individuels, aux sites web et applications web de petite et moyenne taille, aux environnements de développement, aux bases de données légères et aux applications d'entreprise légères. Comme les ressources CPU sont partagées, les performances peuvent fluctuer sous forte charge. Pour plus de détails, consultez la rubrique relative aux familles d'instances partagées.
Utiliser des plans d'économies
Pour les instances ECS ou les instances de conteneur élastiques exécutées sur de longues périodes, souscrivez à des plans d'économies afin de bénéficier de tarifs réduits en paiement à l'utilisation. Les plans d'économies nécessitent un engagement de 1, 3 ou 5 ans. Consultez la rubrique Présentation des plans d'économies et la procédure d'achat et d'application des plans d'économies.
Choisir une région
Les prix des instances ECS varient selon la région. Si vos charges de travail peuvent tolérer une latence réseau plus élevée, le déploiement dans une région moins coûteuse permet de réduire les dépenses. Pour consulter les tarifs par région, rendez-vous sur la page Elastic Compute Service.
Utiliser des clusters ACK managés
Les clusters ACK managés hébergent le plan de contrôle (nœuds master) sur Alibaba Cloud : vous ne provisionnez que les nœuds worker et ne payez aucun frais de ressource pour le plan de contrôle. Cela rend les clusters managés plus rentables que les clusters dédiés.
Pour les charges de travail à grande échelle nécessitant une stabilité et une sécurité élevées, utilisez des clusters ACK Pro. Les clusters ACK Pro sont couverts par des SLA avec clauses d'indemnisation et offrent une fiabilité, une sécurité et une capacité de planification améliorées. Consultez la rubrique Présentation des clusters ACK Pro.
Dimensionner correctement l'allocation des ressources des charges de travail
Configurer les demandes et les limites de ressources
Définissez précisément les demandes et les limites de ressources. Des demandes trop élevées gaspillent de la capacité, tandis que des demandes trop faibles risquent de compromettre la stabilité lors des pics de charge. Utilisez les données historiques d'utilisation des conteneurs et les résultats des tests de charge pour calibrer ces valeurs.
Utilisez le profilage des ressources pour générer des suggestions de spécifications de ressources pour les conteneurs à partir des données d'utilisation historiques. Le profilage des ressources réduit la complexité du réglage des paramètres de ressources et améliore l'utilisation globale. Consultez la rubrique relative au profilage des ressources.
Réexaminez régulièrement les demandes et les limites de ressources au fur et à mesure que votre application évolue, car les configurations précises au moment du déploiement peuvent devenir obsolètes avec le temps.
Gérer les namespaces et les quotas de ressources
Dans les clusters multi-locataires, utilisez des namespaces pour isoler les ressources des différentes équipes ou charges de travail et définissez des quotas de ressources pour limiter la consommation par namespace. Les types de quotas configurables incluent le CPU, la mémoire, le stockage et le nombre de pods. Consultez la rubrique relative à la gestion des namespaces et des quotas de ressources.
Utiliser la mise à l'échelle automatique pour réduire la capacité inactive
La mise à l'échelle automatique est l'un des moyens les plus efficaces de réduire les coûts du cluster. Augmentez le nombre de pods pendant les heures de pointe pour gérer le trafic, et réduisez-le pendant les heures creuses afin de ne payer que ce que vous utilisez, sans surprovisionner pour la demande de pointe.
ACK prend en charge deux niveaux de mise à l'échelle automatique :
Mise à l'échelle des charges de travail : ajuste le nombre de pods ou l'allocation des ressources des pods au niveau de la charge de travail
Mise à l'échelle des ressources de calcul : ajuste le nombre de nœuds ou provisionne des nœuds virtuels en fonction de la demande de planification des pods
Mise à l'échelle des charges de travail
| Solution | Quand l'utiliser | Points clés à considérer |
|---|---|---|
| Horizontal Pod Autoscaling (HPA) | Services avec un trafic fluctuant ; mise à l'échelle basée sur l'utilisation du CPU, de la mémoire ou des métriques personnalisées | Configurez les demandes et les limites de ressources ; configurez les contrôles d'intégrité des pods et la récupération automatique ; assurez-vous que Metrics Server est en cours d'exécution |
| Cron Horizontal Pod Autoscaling (CronHPA) | Modèles de trafic prévisibles ; mise à l'échelle planifiée à des heures fixes | Configurez les demandes et les limites de ressources ; configurez les contrôles d'intégrité des pods et la récupération automatique ; si vous utilisez HPA et CronHPA conjointement, évitez les conflits — consultez la rubrique Rendre CronHPA compatible avec HPA |
| Vertical Pod Autoscaling (VPA) | Applications avec état ayant une demande de ressources stable ; ajustement du CPU et de la mémoire des pods en fonction de l'utilisation historique | Configurez les budgets de perturbation de pod (PDB) ; assurez-vous que Metrics Server est en cours d'exécution ; examinez les précautions relatives à VPA |
| Adaptive Horizontal Pod Autoscaling (AHPA) | Charges de travail avec des cycles de trafic récurrents ; mise à l'échelle proactive avant les pics basée sur les modèles historiques | Configurez les demandes et les limites de ressources ; configurez les contrôles d'intégrité des pods et la récupération automatique |
| Kubernetes Event-driven Autoscaling (KEDA) | Charges de travail événementielles consommant depuis Kafka, MySQL, PostgreSQL, RabbitMQ ou MongoDB ; transcodage vidéo/audio, streaming de données | Configurez les demandes et les limites de ressources ; configurez les contrôles d'intégrité des pods et la récupération automatique |
Mise à l'échelle des nœuds
Activez la mise à l'échelle des nœuds conjointement avec la mise à l'échelle des charges de travail pour éviter les échecs de planification des pods lorsque les ressources des nœuds du cluster sont insuffisantes. Pour choisir entre la mise à l'échelle automatique des nœuds et la mise à l'échelle instantanée des nœuds, consultez la rubrique Solutions de mise à l'échelle : mise à l'échelle automatique des nœuds et mise à l'échelle instantanée des nœuds.
| Solution | Quand l'utiliser | Points clés à considérer |
|---|---|---|
| Mise à l'échelle automatique des nœuds | Clusters avec moins de 20 pools de nœuds activés pour la mise à l'échelle automatique, ou moins de 100 nœuds par pool de nœuds ; modèles de trafic stables ou prévisibles | Configurez les demandes et les limites de ressources ; configurez les budgets de perturbation de pod (PDB) |
| Mise à l'échelle instantanée des nœuds | Besoins de mise à l'échelle à grande échelle ou rapide dépassant les limites de la mise à l'échelle automatique des nœuds | Examinez les limites de la mise à l'échelle instantanée des nœuds avant l'activation |
| Nœuds virtuels | Charges de travail explosives nécessitant de nombreux pods sur une courte période sans provisionner d'instances ECS | Consultez l'introduction à la planification des nœuds virtuels et la comparaison des solutions et la procédure de planification des pods sur des instances de conteneur élastiques |
Optimiser la planification des pods
Surcommitment dynamique des ressources
Lorsque des pods Guaranteed et Burstable partagent un cluster, les administrateurs d'applications configurent généralement une marge de ressources pour chaque pod afin d'absorber les fluctuations de la charge de travail, ce qui laisse un écart entre les ressources demandées et leur utilisation réelle. Le surcommitment dynamique des ressources vous permet de récupérer cette capacité inutilisée pour les pods Best Effort (BE).
Configurez un taux de redondance des ressources pour définir la quantité de marge à préserver. Les ressources au-delà du taux de redondance sont mises à disposition dynamiquement pour les pods BE. La quantité surengageable sur chaque nœud s'ajuste en temps réel en fonction de l'utilisation effective. Vous pouvez prioriser les pods Best Effort (BE) lors de la planification des pods sur le nœud.
Pour les scénarios de colocalisation où des pods Latency Sensitive (LS) et des pods BE gourmands en ressources partagent un nœud, configurez le surcommitment des ressources pour les pods BE afin d'activer une gestion fine du CPU et de la mémoire. Consultez les rubriques Activer le surcommitment dynamique des ressources et Premiers pas.
Partage de GPU
Exécutez plusieurs conteneurs sur un seul GPU pour réduire les coûts liés aux GPU.
Deux modes sont disponibles :
Partage de GPU unique : chaque pod demande un GPU et occupe une partie de ses ressources. Adapté aux scénarios d'inférence de modèles.
Partage de plusieurs GPU : chaque pod demande plusieurs GPU, avec la même quantité de ressources allouée depuis chacun. Adapté au développement et à l'entraînement distribués de modèles.
Configurez les politiques de partage et d'isolation des GPU — par exemple, regroupez plusieurs pods sur un seul GPU ou répartissez-les sur plusieurs GPU. Consultez la rubrique relative au partage de GPU.
Surveiller les coûts et identifier le gaspillage
Utiliser Cost Insights
Cost Insights vous permet de consulter l'utilisation des ressources et les coûts pour les clusters, les départements ou les applications au sein d'un cycle de gouvernance des coûts spécifié. Cette fonctionnalité utilise un modèle de données de coût pour estimer le coût de chaque pod — la plus petite unité déployable dans ACK — et attribue le coût total aux unités métier. Des tableaux de bord multidimensionnels vous permettent d'analyser les tendances d'utilisation historiques et d'identifier la source des frais inattendus. Consultez la rubrique relative à Cost Insights.
Détecter les ressources inactives
Analysez périodiquement et libérez les ressources inactives — y compris le CPU, la mémoire, le stockage et les ressources réseau — pour éviter de payer pour une capacité non utilisée.
Utilisez Cost Insights pour identifier les pods inactifs et ajustez les politiques d'allocation des ressources en conséquence. Consultez la rubrique relative aux méthodes de facturation et à l'utilisation des pods.
ACK fournit également des outils pour détecter les ressources inactives liées au cluster, telles que les instances Elastic Compute Service (ECS), les volumes Elastic Block Storage (EBS), les instances Classic Load Balancer (CLB) et les adresses IP élastiques (EIP). Consultez la rubrique relative à l'optimisation des ressources inactives.