L'optimisation des coûts du cluster consiste à utiliser les ressources de manière économique sans compromettre la stabilité des charges de travail. Ce guide aborde la sélection des instances, les méthodes de facturation, l'Auto Scaling, l'ordonnancement des pods et la surveillance des coûts. Il vous fournit un cadre pratique pour mettre en place une démarche FinOps sur Alibaba Cloud.
Ce guide s'adresse aux administrateurs de clusters Container Service for Kubernetes (ACK). Les recommandations ne sont pas classées par ordre de priorité : appliquez-les selon vos besoins métier. Avant de commencer, familiarisez-vous avec les concepts Kubernetes suivants : ressources des pods et des conteneurs, namespaces, Auto Scaling (mise à l'échelle des charges de travail et mise à l'échelle des nœuds), ainsi que l'ordonnancement.
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 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. Sélectionnez ensuite les types d'instance et les méthodes de facturation offrant 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.
| 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 |
| Deep learning 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 travaux d'entraînement tolérants aux pannes |
| Traitement par lots, ETL, jobs événementiels | Tous | 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 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 les recommandations sur le choix des spécifications ECS pour les clusters ACK.
Utiliser des instances preemptible
Les instances preemptible sont des instances facturées selon la méthode de 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
Jobs ETL Big Data (par exemple, Apache Spark)
Traitement des transactions en file d'attente
Applications utilisant des API REST
Pour connaître les meilleures pratiques, consultez les meilleures pratiques pour les pools de nœuds basés sur des instances preemptible.
Utiliser les familles d'instances partagées
Les familles d'instances partagées conviennent aux développeurs individuels, aux sites web de petite et moyenne taille, aux applications web, aux environnements de développement, aux bases de données légères et aux applications d'entreprise légères. Étant donné que les ressources CPU sont partagées, les performances peuvent fluctuer sous une charge importante. Pour plus de détails, consultez les familles d'instances partagées.
Utiliser les 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 par rapport au paiement à l'utilisation. Les plans d'économies nécessitent un engagement de 1, 3 ou 5 ans. Consultez l'aperçu 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, un déploiement dans une région moins coûteuse peut réduire les dépenses. Pour consulter les tarifs par région, rendez-vous sur la page Elastic Compute Service.
Utiliser les clusters gérés ACK
Les clusters gérés ACK hébergent le plan de contrôle (nœuds maîtres) sur Alibaba Cloud : vous ne provisionnez que les nœuds de travail et ne payez aucun frais de ressource pour le plan de contrôle. Cela rend les clusters géré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 les 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é d'ordonnancement améliorées. Consultez l'aperçu des clusters ACK Pro.
Dimensionner correctement l'allocation des ressources des charges de travail
Configurer les demandes et limites de ressources
Définissez avec précision 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 résistance 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 le profilage des ressources.
Réexaminez continuellement 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 destinées à différentes équipes ou charges de travail, et définissez des quotas de ressources pour plafonner 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 sur la gestion des namespaces et des quotas de ressources.
Utiliser l'Auto Scaling pour réduire la capacité inactive
L'Auto Scaling 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 répondre à la demande de pointe.
ACK prend en charge deux niveaux d'Auto Scaling :
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 d'ordonnancement 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 limites de ressources ; configurez les checks de santé 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 programmée à des heures fixes | Configurez les demandes et limites de ressources ; configurez les checks de santé 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 stateful avec une demande de ressources stable ; dimensionnement correct du CPU et de la mémoire des pods basé sur 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 limites de ressources ; configurez les checks de santé 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 limites de ressources ; configurez les checks de santé des pods et la récupération automatique |
Mise à l'échelle des nœuds
Activez la mise à l'échelle des nœuds conjointement avec celle des charges de travail pour éviter les échecs d'ordonnancement 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 les solutions de mise à l'échelle : mise à l'échelle automatique et 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 l'Auto Scaling, ou moins de 100 nœuds par pool de nœuds ; modèles de trafic stables ou prévisibles | Configurez les demandes et 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 rapides 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 burst nécessitant de nombreux pods sur une courte période sans provisionner d'instances ECS | Consultez l'introduction à l'ordonnancement des nœuds virtuels et la comparaison des solutions ainsi que la procédure pour ordonnancer les pods sur des instances de conteneur élastiques |
Optimiser l'ordonnancement des pods
Surengagement dynamique des ressources
Lorsque des pods Guaranteed et Burstable partagent un cluster, les administrateurs d'applications configurent généralement une marge de sécurité des ressources pour chaque pod afin d'absorber les fluctuations de la charge de travail, laissant un écart entre les ressources demandées et celles effectivement utilisées. Le surengagement 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 excédant ce taux de redondance sont dynamiquement mises à disposition des pods BE. Le montant surengageable sur chaque nœud s'ajuste en temps réel en fonction de l'utilisation effective. Vous pouvez donner la priorité aux pods Best Effort (BE) lors de l'ordonnancement des pods sur le nœud.
Pour les scénarios de colocation où des pods Latency Sensitive (LS) et des pods BE gourmands en ressources partagent un nœud, configurez le surengagement des ressources pour les pods BE afin de permettre une gestion fine du CPU et de la mémoire. Consultez les rubriques sur l'activation du surengagement dynamique des ressources et la section prise en main.
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 d'un seul GPU : 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é 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 sur le partage de GPU.
Surveiller les coûts et identifier le gaspillage
Utiliser Cost Insights
Cost Insights vous permet de visualiser 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 alloue le coût total aux unités métier. Des tableaux de bord multidimensionnels vous permettent d'analyser les tendances historiques d'utilisation et d'identifier la source des frais inattendus. Consultez la rubrique 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 — afin d'é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 section relative aux méthodes de facturation et à l'utilisation des pods.
ACK fournit également des outils pour détecter les ressources liées au cluster qui sont inactives, 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 sur l'optimisation des ressources inactives.