Ce document vous aide à parcourir la documentation de Google Kubernetes Engine (GKE) pour trouver des consignes et des recommandations concernant l'optimisation des coûts. GKE offre de nombreuses fonctionnalités d'autoscaling et de planification que vous pouvez utiliser pour minimiser les coûts des clusters tout en maintenant la stabilité des applications.
Pour obtenir un aperçu consolidé de toutes les bonnes pratiques GKE, consultez Bonnes pratiques pour GKE.Vous devez déjà connaître les éléments suivants :
Présentation
Lorsque vous implémentez GKE, vous devez tenir compte de différents aspects techniques pour répondre aux exigences des applications et de l'entreprise. En plus de définir la mise en réseau, la sécurité, le stockage et d'autres aspects techniques, vous devez évaluer les coûts et les performances pour répondre aux besoins de l'entreprise. Au lieu de traiter le coût et les performances comme des entités distinctes, vous devez les intégrer dès les premières étapes de la planification de l'infrastructure afin de définir une relation unifiée qui détermine à la fois la fiabilité et les dépenses cloud. On s'attend à des coûts faibles et à une fiabilité élevée, mais à mesure que vous évoluez, la gestion de ce compromis devient plus complexe.
Pour réduire les coûts et assurer la stabilité des applications, vous pouvez définir ou ajuster les fonctionnalités GKE suivantes :
- Configuration GKE
- Configuration de la charge de travail
- Référence et visibilité des coûts
Vous pouvez également découvrir et appliquer les bonnes pratiques d'optimisation des coûts à l'aide de Compute Advisor (preview). Pour en savoir plus, consultez Utiliser Compute Advisor.
Utilisez GKE Autopilot
Pour les petits environnements de bac à sable ou de développement, sélectionnez les clusters Autopilot. Dans Autopilot, GKE gère les nœuds de manière dynamique et vous n'êtes facturé que pour la capacité de pod demandée, ce qui vous permet d'éviter les frais liés aux VM, au système d'exploitation des nœuds et aux frais généraux du système.
Pour en savoir plus, consultez la présentation de GKE Autopilot.
Comprendre le fonctionnement de l'autoscaling
Les contrôleurs d'autoscaling GKE ajustent dynamiquement les ressources en fonction de l'évolution des demandes de trafic.
Ajouter et supprimer des pods en fonction des métriques d'utilisation
Un HorizontalPodAutoscaler (AHP) ajoute et supprime des pods en fonction des métriques personnalisées ou du processeur.
Pour comprendre et configurer l'autoscaling horizontal des pods, consultez la documentation GKE suivante :
- Concepts de l'autoscaling horizontal des pods
- Configurer l'autoscaling horizontal des pods
- Afficher les événements de l'autoscaler horizontal de pods
- Exposer des métriques d'application personnalisées pour l'autoscaling
Configurez un seuil d'utilisation cible (par exemple, 70% ou 80%) pour maintenir un tampon qui gère les pics de trafic pendant le démarrage des pods d'instances répliquées supplémentaires.
Effectuer un scaling de vos pods en fonction des métriques d'utilisation
Utilisez VerticalPodAutoscaler (VPA) pour dimensionner de manière dynamique les demandes de ressources de processeur et de mémoire des conteneurs pour les charges de travail qui n'utilisent pas l'autoscaling horizontal des pods ou lorsque les pics de charge de travail sont inconnus.
Pour comprendre et configurer l'autoscaling vertical des pods, consultez la documentation GKE suivante :
- Concepts de l'autoscaling vertical des pods
- Effectuer un scaling des demandes et des limites de ressources des conteneurs
Conservez le VPA en mode Off (recommandation uniquement) pendant au moins 24 heures (idéalement une semaine) dans des environnements de type production pour capturer des modèles de trafic représentatifs. Pour éviter des ajustements de taille erratiques, spécifiez des limites minimales et maximales explicites dans votre objet VerticalPodAutoscaler avant d'activer les modes Initial ou Auto.
Automatiser le scaling de l'infrastructure à l'aide de l'autoscaler de cluster
Pour faire évoluer les nœuds de calcul sous-jacents en fonction de la simulation de planification active plutôt que des charges de métriques, activez l'autoscaler de cluster dans les pools de nœuds GKE Standard. Spécifiez les paramètres de nœud minimum pour prendre en charge la capacité de base de nuit.
Configurez toujours un objet PodDisruptionBudget (PDB) pour les pods système et d'application. Cette configuration permet de s'assurer que l'autoscaler de cluster ne provoque pas involontairement d'interruption de service lors de la consolidation ou du scaling à la baisse des pools de nœuds sous-utilisés.
Pour comprendre et configurer Cluster Autoscaler, consultez la documentation GKE suivante :
- À propos de l'autoscaling des clusters GKE
- Procédez à l'autoscaling d'un cluster.
- Afficher les événements de l'autoscaler de cluster
Déployer des pools de nœuds dynamiques à l'aide de la création automatique de pools de nœuds
Activez la création automatique de pools de nœuds pour générer automatiquement des pools de nœuds GKE personnalisés dont les formes, le nombre de processeurs ou les limites de mémoire correspondent précisément aux paramètres de planification des pods en attente. Cette fonctionnalité minimise les ressources inutilisées sur les nœuds surdimensionnés.
Pour comprendre et configurer la création automatique de pools de nœuds, consultez la documentation GKE suivante :
Check-list de l'autoscaling
Caractéristiques de l'infrastructure
Alignez le matériel, l'emplacement et les règles de réseau des nœuds de votre cluster sur les priorités d'optimisation des coûts.
Sélectionner les types de machines appropriés
Sélectionnez les types de machines appropriés pour votre cluster en fonction de l'emplacement de vos utilisateurs et de celui des données auxquelles votre cluster doit accéder.
Pour en savoir plus, consultez le Guide des ressources de familles de machines et guide comparatif.
Déployer des charges de travail tolérantes aux pannes sur des VM Spot
Utilisez des VM Spot pour exécuter des charges de travail sans état, tolérantes aux pannes ou par lot avec une remise pouvant atteindre 91% par rapport aux instances de VM à la demande.
Pour en savoir plus, consultez la documentation GKE suivante :
- Concepts liés aux VM Spot
- Exécuter des charges de travail tolérantes aux pannes à moindre coût avec des VM Spot
- Exécuter des charges de travail tolérantes aux pannes à moindre coût avec des pods Spot
Mappez les familles de machines efficaces et les paramètres du système d'OS.
Personnalisez les paramètres de machine du pool de nœuds avec des profils d'instance économiques (par exemple, les architectures de VM E2).
Pour en savoir plus sur le dimensionnement des nœuds, la configuration des délais de préemption des VM Spot et la configuration du noyau, consultez À propos des pools de nœuds.
Sélectionner la région appropriée
Lorsque la latence n'affecte pas vos utilisateurs, exécutez les charges de travail du cluster dans des régions Compute Engine dont les coûts d'exploitation sont inférieurs.
Pour en savoir plus, consultez Bonnes pratiques pour la sélection des régions Compute Engine.
S'inscrire à la remise sur engagement d'utilisation
Souscrivez des remises sur engagement d'utilisation pour bénéficier de prix fortement réduits (jusqu'à 70%) pour les ressources de calcul de référence sur une période d'un ou trois ans.
Pour en savoir plus, consultez Remises sur engagement d'utilisation basées sur les ressources.
Prenez en compte les coûts de mise en réseau.
Les clusters GKE régionaux et multizonaux améliorent la fiabilité des applications, mais peuvent générer des coûts de sortie réseau internes entre les zones.
Pour minimiser et contrôler les coûts de mise en réseau, tenez compte des points suivants :
- Transferts de données interzones : bien que les clusters régionaux augmentent la disponibilité en répartissant les charges de travail entre les zones, des coûts sont associés aux données transférées entre ces zones.
Pour plus d'informations, consultez la page Tous les tarifs de mise en réseau.
Déployer des clusters à zone unique pour les environnements hors production
Dans les environnements hors production, pour éviter les frais réseau entre zones et réduire la surcharge des VM, déployez des clusters à zone unique au lieu de clusters régionaux ou multizones.
Pour en savoir plus, consultez À propos des choix de configuration des clusters.
Optimiser les chemins de résolution DNS du cluster et le trafic entrant
Pour optimiser la résolution DNS du cluster et le trafic entrant, vous pouvez déployer NodeLocal DNSCache et des groupes de points de terminaison du réseau (NEG).
Lorsque vous exécutez des charges de travail gourmandes en DNS, NodeLocal DNSCache exécute un démon DNS local sur chaque nœud. Cette configuration empêche les charges de requêtes élevées d'épuiser CoreDNS, ce qui évite d'avoir à le mettre à l'échelle et réduit les coûts globaux de GKE.
Pour le trafic d'entrée, l'équilibrage de charge natif en conteneurs via des NEG achemine le trafic directement vers les adresses IP des pods plutôt que vers les groupes d'instances. Ce routage direct facilite la redirection fluide du trafic lors des actions de scaling des pods.
Pour en savoir plus, consultez :
- Configurer NodeLocal DNSCache
- Présentation de l'équilibrage de charge natif en conteneurs
- Configurer Ingress pour les équilibreurs de charge d'application externes
Appliquer des quotas de ressources par espace de noms
Déployez des objets ResourceQuota Kubernetes standards par espace de noms dans des clusters mutualisés pour verrouiller les seuils de forme de processeur et de mémoire, et empêcher les équipes individuelles de planifier des charges de travail non conformes qui entraînent des frais de calcul inattendus.
Pour en savoir plus, consultez la section Espaces de noms dans la documentation de Kubernetes.
Implémenter des audits Policy Controller
Déployez Policy Controller pour auditer et appliquer de manière dynamique la conformité des clusters aux normes de l'entreprise. Policy Controller utilise le contrôle des admissions pour refuser les ressources mal configurées.
Pour en savoir plus, consultez les ressources suivantes :
Bloquer les fichiers manifestes non conformes dans les pipelines CI/CD
Validez la conformité aux règles relatives aux coûts plus tôt dans votre cycle de développement.
Intégrez des scripts de validation (tels que l'analyse kpt) dans les vérifications avant commit ou de demande d'extraction pour auditer et bloquer les fichiers manifestes non conformes avant qu'ils n'atteignent le cluster.
Pour en savoir plus, consultez Valider des applications par rapport aux règles de l'entreprise dans un pipeline de CI.
Check-list de l'infrastructure
Optimisation des applications et des charges de travail
Configurez vos charges de travail pour utiliser efficacement les ressources et réduire les frais généraux d'exploitation.
Spécifier des demandes et des limites de mémoire correspondantes
Spécifiez des demandes précises de processeur et de mémoire pour les conteneurs avant le déploiement. Pour le processeur, configurez les demandes pour répondre à vos objectifs de niveau de service (SLO), mais laissez les limites sans restriction. Pour la mémoire, assurez-vous que l'allocation demandée correspond à la limite de mémoire.
Pour en savoir plus, consultez Redimensionner les ressources de processeur et de mémoire attribuées aux conteneurs dans la documentation de Kubernetes.
Accélérer le démarrage des conteneurs
Réduisez au maximum la taille des images de conteneurs pour minimiser les temps de téléchargement.
Configurer les PDB
Spécifiez un objet PodDisruptionBudget (PDB) pour les répliques d'application afin de limiter les interruptions volontaires et d'assurer la stabilité lorsque GKE réduit la capacité ou lorsque des mises à niveau de nœuds ont lieu.
Pour en savoir plus, consultez Spécifier un budget d'interruption pour votre application.
Définir des vérifications d'aptitude et d'activité pertinentes
Configurez des vérifications d'aptitude et d'activité pour tous les conteneurs afin de vous assurer que GKE n'achemine le trafic que vers les pods prêts et redémarre les instances défaillantes, ce qui évite les pertes de trafic lors de l'autoscaling.
Pour en savoir plus, consultez Configurer des vérifications d'activité, d'aptitude et de démarrage.
Configurer l'arrêt progressif de l'application
Préparez les conteneurs à l'arrêt progressif en écoutant le signal SIGTERM, en finalisant les requêtes en cours avant de quitter ou en configurant les hooks preStop.
Pour en savoir plus, consultez Arrêt et arrêt progressif des VM préemptives.
Implémenter des nouvelles tentatives avec un intervalle exponentiel entre les tentatives
Implémentez des nouvelles tentatives avec intervalle exponentiel entre les tentatives au niveau de l'application ou du maillage de services pour gérer les défaillances temporaires ou les préemptions potentielles de VM Spot.
Pour en savoir plus, consultez Retries dans la documentation Istio.
Checklist pour l'optimisation des applications et des charges de travail
Référence et visibilité des coûts
Pour optimiser les coûts, vous devez d'abord avoir une visibilité sur vos dépenses GKE et sur la façon dont elles sont allouées. Cette visibilité vous aide à attribuer les coûts aux équipes et aux unités commerciales qui les génèrent.
La documentation GKE suivante explique comment obtenir une visibilité approfondie sur la facturation, la consommation de ressources et les métriques de référence de GKE.
Activer l'attribution des coûts GKE
Activez la répartition des coûts GKE pour obtenir de la visibilité sur les requêtes de ressources des charges de travail et les coûts associés. L'attribution des coûts attribue les coûts du cluster aux espaces de noms et aux libellés Kubernetes de vos charges de travail.
Exportez ces informations vers BigQuery pour analyser les données dans Cloud Billing. Utilisez cette analyse pour identifier les charges de travail qui entraînent des pics de facturation, effectuer des rétrofacturations et optimiser les requêtes de ressources.
Pour en savoir plus, consultez Obtenir des insights clés sur vos dépenses pour l'allocation des ressources GKE et les coûts de vos clusters.
Examiner les volumes d'ingestion des journaux et des métriques
L'activation de Cloud Logging et Cloud Monitoring pour vos clusters entraîne des coûts. L'ingestion de volumes élevés de journaux et de métriques personnalisées peut entraîner des frais inattendus. Vérifiez de manière centralisée les niveaux de journalisation et les métriques personnalisées ingérés.
Pour en savoir plus sur la résolution des problèmes liés à une utilisation élevée de l'API Logging ou aux délais d'expiration des limites d'écriture des journaux, consultez les ressources suivantes :
Surveiller l'état du serveur de métriques
Surveillez l'état du déploiement Metrics Server, car les contrôleurs d'autoscaling intégrés de GKE s'appuient sur celui-ci pour récupérer les métriques d'utilisation du processeur et de la mémoire.
Pour en savoir plus, consultez Résoudre les problèmes liés à l'autoscaling horizontal de pods.
Promouvoir une culture de l'économie
Donnez aux développeurs l'accès aux tableaux de bord des dépenses cloud et mettez en place une formation FinOps pour aligner les décisions architecturales sur les budgets de l'entreprise.
Pour en savoir plus sur la culture d'optimisation des coûts dans une organisation, consultez Diffuser la culture d'optimisation des coûts.
Checklist de la visibilité et de la référence des coûts
Utiliser Compute Advisor
Compute Advisor est une interface optimisée par l'IA dans la consoleGoogle Cloud , optimisée par Gemini, qui vous aide à concevoir des architectures résilientes et économiques pour GKE.
Compute Advisor fournit des conseils sur la disponibilité en temps quasi réel pour les VM à démarrage flexible et les VM Spot, tout en vérifiant les règles et les quotas de ressources de votre organisation avant le déploiement. Compute Advisor ne fournit pas de conseils sur la disponibilité pour les charges de travail qui nécessitent des ressources à la demande.
Pour accéder à Gemini dans la console Google Cloud , procédez comme suit :
-
Dans la console Google Cloud , accédez à la page Présentation.
-
Dans la section Concevez votre infrastructure avec Compute Advisor, envoyez une requête. Gemini commence à générer une réponse.
-
Pour générer des recommandations architecturales, exécutez l'un des exemples de requêtes suivants dans Compute Advisor. Lorsque vous cliquez sur les boutons Exécuter la requête dans Compute Advisor, le chargement de la console Google Cloud peut prendre plus de 15 secondes :
Autoscaling et bin packing :
Cas d'utilisation : pour maximiser le bin packing et minimiser le surcoût lié aux processeurs inactifs, utilisez ce prompt pour configurer une stratégie d'autoscaling de cluster GKE et de pools de nœuds.
Configure a GKE cluster to use autoscaler and node pool strategy to maximize bin packing and minimize idle CPU overhead.Gouvernance de l'architecture mutualisée :
Cas d'utilisation : pour que les espaces de noms de développement ne dépassent pas les limites du budget, utilisez cette requête pour rédiger une règle ResourceQuota pour un cluster GKE mutualisé.
Draft a ResourceQuota policy for a multi-tenant GKE cluster to keep development namespaces within budget bounds.Optimisation des charges de travail :
Cas d'utilisation : pour vous aider à décider d'utiliser le mode GKE Autopilot ou Standard pour une charge de travail par lot avec des besoins en ressources variables, utilisez cette requête pour obtenir une recommandation :
Recommend whether to use GKE Autopilot or Standard mode for a batch processing workload with highly variable resource demands.
Étapes suivantes
Pour en savoir plus sur les principes architecturaux et la culture organisationnelle nécessaires à la rentabilité, consultez Bonnes pratiques pour l'exécution d'applications Kubernetes à coût maîtrisé sur GKE.