Ce document vous aide à parcourir la documentation Google Kubernetes Engine (GKE) pour trouver des consignes et des recommandations sur l'optimisation des coûts. GKE offre de nombreuses fonctionnalités d'autoscaling et de planification que vous pouvez utiliser pour réduire les coûts des clusters tout en maintenant la stabilité des applications.
Pour obtenir une présentation consolidée 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 vous aligner sur les exigences des applications et de l'entreprise. Au-delà de la définition de la mise en réseau, de la sécurité, du 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 les coûts 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 pour définir une relation unifiée qui détermine à la fois la fiabilité et les dépenses cloud. Les coûts faibles et la haute fiabilité sont attendus, mais à mesure que vous effectuez un scaling, la complexité de la gestion de ce compromis augmente.
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 mettre en œuvre les bonnes pratiques d'optimisation des coûts à l'aide de Compute Advisor (aperçu). Pour en savoir plus, consultez Utiliser Compute Advisor.
Utiliser 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 Présentation de GKE Autopilot.
Comprendre le fonctionnement de l'autoscaling
Les contrôleurs d'autoscaling GKE ajustent les ressources de manière dynamique lorsque les requêtes de trafic changent.
Ajouter et supprimer des pods en fonction des métriques d'utilisation
Un HorizontalPodAutoscaler (AHP) ajoute et supprime des pods en fonction du processeur ou de métriques personnalisées.
Pour comprendre et configurer l'autoscaling horizontal des pods, consultez la documentation GKE suivante :
- Concepts d'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 une mémoire tampon qui gère les pics de trafic pendant le démarrage des pods de répliques 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 requêtes 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 charges de travail maximales sont inconnues.
Pour comprendre et configurer l'autoscaling vertical des pods, consultez la documentation GKE suivante :
- Concepts d'autoscaling vertical des pods
- Effectuer un scaling des requêtes et limites de ressources de conteneurs
Laissez 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 les ajustements de dimensionnement 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 effectuer un scaling des 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 minimal 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 de la réduction des pools de nœuds sous-utilisés.
Pour comprendre et configurer l'autoscaler de cluster, 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 restantes sur les nœuds surdimensionnés.
Pour comprendre et configurer la création automatique de pools de nœuds, consultez la documentation GKE suivante :
Checklist pour l'autoscaling
Caractéristiques de l'infrastructure
Alignez le matériel du cluster, l'emplacement et les règles de réseau des nœuds 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 l'emplacement 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 allant jusqu'à 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
Mapper des familles de machines et des paramètres de système d'exploitation efficaces
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'a pas d'incidence sur vos utilisateurs, exécutez des charges de travail de 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 à une remise sur engagement d'utilisation
Achetez des remises sur engagement d'utilisation pour bénéficier de tarifs fortement réduits (jusqu'à 70%) pour les ressources de calcul de base sur une période d'un ou trois ans.
Pour en savoir plus, consultez Remises sur engagement d'utilisation basées sur les ressources.
Tenir compte des coûts de mise en réseau
Les clusters GKE régionaux et multizones améliorent la fiabilité des applications, mais peuvent générer des coûts de sortie réseau interzone internes.
Pour minimiser et contrôler les coûts de mise en réseau, tenez compte des éléments suivants :
- Transferts de données interzone : bien que les clusters régionaux augmentent la disponibilité en répartissant les charges de travail sur plusieurs 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 de réseau interzone et réduire les frais généraux 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 des clusters et le trafic entrant
Pour optimiser la résolution DNS des clusters 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 à effectuer un scaling de CoreDNS et réduit les coûts globaux de GKE.
Pour le trafic entrant, l'équilibrage de charge natif en conteneurs via des NEG achemine le trafic directement vers les adresses IP des pods au lieu des groupes d'instances. Ce routage direct facilite la redirection progressive du trafic lors des actions de scaling des pods.
Pour en savoir plus, consultez les pages suivantes :
- 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 Kubernetes ResourceQuota standards par espace de noms dans des clusters mutualisés pour verrouiller les seuils de forme du processeur et de la mémoire, et empêcher les équipes individuelles de planifier des charges de travail non conformes qui déclenchent des frais de calcul inattendus.
Pour en savoir plus, consultez Espaces de noms dans la documentation Kubernetes.
Mettre en œuvre 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 d'admission pour rejeter les ressources mal configurées.
Pour en savoir plus, consultez les ressources suivantes :
Bloquer les manifestes non conformes dans les pipelines CI/CD
Validez la conformité des règles de coûts plus tôt dans votre cycle de vie de développement.
Intégrez des scripts de validation (tels que l'analyse kpt) dans les vérifications de pré-commit ou de requête d'extraction pour auditer et bloquer les 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 CI.
Checklist pour l'infrastructure
Optimisation des applications et des charges de travail
Configurez vos charges de travail pour qu'elles utilisent les ressources de manière efficace et réduisent les frais généraux opérationnels.
Spécifier des demandes et des limites de mémoire correspondantes
Spécifiez des requêtes précises de processeur et de mémoire de conteneur avant le déploiement. Pour le processeur, configurez les requêtes afin de respecter vos objectifs de niveau de service, mais laissez les limites illimitées. 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 Kubernetes.
Accélérer les délais de démarrage des conteneurs
Réduisez au maximum la taille des images de conteneur pour minimiser les délais de téléchargement des images.
Configurer des PDB
Spécifiez un objet PodDisruptionBudget (PDB) pour les instances répliquées d'application afin de limiter les interruptions volontaires et d'assurer la stabilité lorsque GKE effectue un scaling à la baisse ou lorsque des mises à niveau de nœuds se produisent.
Pour en savoir plus, consultez la section Spécifier un budget d'interruption pour votre application.
Définir des vérifications d'aptitude et d'activité significatives
Configurez des vérifications d'aptitude et d'activité pour tous les conteneurs afin de vous assurer que GKE achemine le trafic uniquement vers les pods prêts et redémarre les instances en échec, ce qui évite la perte de trafic lors de l'autoscaling.
Pour plus d'informations, consultez la section Configurer des vérifications d'activité, d'aptitude et de démarrage Probes.
Configurer l'arrêt progressif des applications
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 des hooks preStop.
Pour en savoir plus, consultez Arrêt et arrêt progressif des VM préemptives.
Mettre en œuvre des nouvelles tentatives avec un intervalle exponentiel entre les tentatives
Mettez en œuvre des nouvelles tentatives avec un intervalle exponentiel entre les tentatives au niveau de l'application ou du maillage de services pour gérer les échecs temporaires ou les préemptions potentielles des VM Spot.
Pour en savoir plus, consultez Nouvelles tentatives 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 manière 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 établir 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 l'attribution des coûts GKE pour obtenir une visibilité sur les demandes de ressources des charges de travail et les coûts associés. L'attribution des coûts attribue les coûts des clusters 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 provoquent des pics de facturation, effectuer des refacturations et optimiser les demandes de ressources.
Pour en savoir plus, consultez Obtenez 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 de journaux et de métriques
L'activation de Cloud Logging et de Cloud Monitoring pour vos clusters entraîne des coûts. Des volumes élevés d'ingestion de journaux et de métriques personnalisées peuvent entraîner des frais inattendus. Auditez 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 avant expiration de la limite d'écriture des journaux, consultez les ressources suivantes :
Surveiller l'état du serveur de métriques
Surveillez l'état du déploiement du serveur de métriques, car les contrôleurs d'autoscaling intégrés de GKE s'appuient sur lui pour récupérer les métriques de processeur et de mémoire.
Pour en savoir plus, consultez Résoudre les problèmes liés à l'autoscaling horizontal des pods.
Encourager une culture de réduction des coûts
Fournissez aux développeurs un 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 coûts de l'entreprise.
Pour en savoir plus sur la culture d'efficacité des coûts organisationnels, consultez Instaurer une culture de l'économie.
Checklist pour la référence et la visibilité des coûts
Utiliser Compute Advisor
Compute Advisor est une interface basée sur l'IA dans la Google Cloud console, optimisée par Gemini, qui vous aide à concevoir des architectures résilientes et économiques architectures pour GKE.
Compute Advisor fournit des conseils de disponibilité en temps quasi réel pour les VM Flex-start 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 de disponibilité pour les charges de travail qui nécessitent des ressources à la demande.
Pour accéder à Gemini dans la Google Cloud console, procédez comme suit :
-
Dans la Google Cloud console, accédez à la page Présentation.
-
Dans la section Concevez votre infrastructure avec Compute Advisor, envoyez un prompt. Gemini commence à générer une réponse.
-
Pour générer des recommandations architecturales, exécutez l'un des exemples de prompts suivants dans Compute Advisor. Lorsque vous cliquez sur les boutons **Exécuter le prompt dans Compute Advisor**, le Google Cloud chargement de la console 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 des clusters GKE et des 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 ce prompt 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 s'il est préférable d'utiliser le mode GKE Autopilot ou Standard pour une charge de travail par lot dont les besoins en ressources sont variables, utilisez ce prompt pour obtenir une recommandation :
Recommend whether to use GKE Autopilot or Standard mode for a batch processing workload with highly variable resource demands.
Étape suivante
Pour en savoir plus sur les principes architecturaux et la culture organisationnelle nécessaires à l'efficacité des coûts, consultez Bonnes pratiques pour l'exécution d'applications Kubernetes à coût maîtrisé sur GKE.