Planification des workloads GKE : stratégies pour gérer les ressources sous contraintes

En optant pour Google Kubernetes Engine (GKE), vous avez choisi un environnement d’exécution de conteneurs hautement managé qui prend en charge, pour vous, toutes les opérations chronophages et complexes, depuis les mises à jour automatiques jusqu'à la gestion simplifiée des nœuds. Dit autrement, vous avez misé sur une efficacité maximale. Cette dernière, intrinsèque à tous services managés, vous permet de vous concentrer davantage sur vos applications, sans vous soucier de l’infrastructure sous-jacente. Dans un monde idéal, combiner cette gestion entièrement automatisée aux capacités avancées d’autoscaling de GKE garantit une gestion optimale des workloads à tout instant. Vos applications s’adaptent en temps réel, accédant aux ressources nécessaires au bon moment, sans effort.

Malheureusement, la réalité sur le terrain est toujours un peu plus complexe et nous impose de relever quelques défis supplémentaires. Certes, GKE met à disposition un autoscaling efficient reposant sur quatre piliers complémentaires (Horizontal Pod Autoscaler ‘HPA’, Vertical Pod Autoscaler ‘VPA’, Cluster Autoscaler et le provisionnement automatique des nœuds ou Node Auto Provisioning). Des fondations qui font automatiquement évoluer les workloads et l’infrastructure en fonction des besoins. Mais orchestrer une plateforme vraiment efficiente pour des workloads en perpétuelle évolution exige bien plus que la simple capacité à « passer automatiquement à l’échelle ». Il faut aussi jongler avec l'optimisation des coûts, la disponibilité des ressources, la vitesse de provisioning, les performances et la flexibilité opérationnelle. Tous ces facteurs impactent – et contraignent parfois – la gestion de la répartition des workloads sur GKE. Difficile alors d’y voir clair : Quelle stratégie adopter ? Quels compromis accepter ? Choisir la meilleure voie devient un vrai exercice d’équilibriste.

Dans cet article, nous allons nous concentrer spécifiquement sur le « scheduler GKE » (planificateur GKE) et les facteurs qui peuvent influencer ses décisions de répartition des workloads quand les ressources sont limitées. Nous verrons comment anticiper et concevoir des solutions pour ces situations en s'appuyant sur les différentes fonctionnalités GKE et les options de configuration de workloads appropriées.

Un problème d’optimisation sous contraintes, avant tout

En pratique, une planification efficace de la gestion des ressources sur GKE ne consiste pas à chercher LA solution parfaite. Il faut plutôt envisager le problème sous l’angle d’une optimisation multi-critères sous contraintes. Dans la plupart des cas, il s'agit moins de surmonter des limitations strictes que de trouver le meilleur compromis entre des priorités qui peuvent entrer en concurrence :

• Coût : vous voulez réduire les dépenses d'infrastructure globales, optimiser l'utilisation des ressources, éviter le sur-provisionnement et privilégier les solutions rentables.
• Performance : vous voulez vous assurer que les workloads respectent leurs SLO en fonction de leur importance pour l'entreprise.
• Flexibilité et agilité : vous voulez pouvoir réagir aux variations de charge de vos workloads en attribuant la bonne capacité au bon moment.

Pour faire les bons arbitrages et configurer efficacement GKE, vous devez d’abord identifier vos préférences et fixer vos seuils de tolérance sur chacune de ces dimensions.

Les briques de base de GKE

Sans être le seul facteur en jeu, l'autoscaling et sa configuration jouent un rôle clé dans la planification des workloads. La configuration de la montée en charge est spécifique à chaque environnement. Nous avons documenté certaines bonnes pratiques pour vous guider.

Sur GKE, l’autoscaling s’exerce sur quatre axes :

• Horizontal Pod Autoscaler (HPA) - ajuste le nombre de répliques de pods
• Vertical Pod Autoscaler (VPA)  - ajuste les demandes de ressources des pods en fonction de l'utilisation réelle
• Cluster Autoscaler (CA) - ajuste automatiquement le nombre de nœuds
• Node Auto Provisioner (NAP)  - ajuste la taille des pools de nœuds selon les besoins des workloads.

Quand la capacité devient contrainte, il est primordial de connaître précisément ce que vos workloads demandent et consomment comme ressources. Le scheduler GKE s'appuie sur la valeur resource.request  de chaque pod pour décider où placer les workloads de façon optimale. Si cette valeur n'est pas définie, le scheduler risque de positionner vos pods sur des nœuds sous-dimensionnés, ce qui provoque des préemptions en cascade et donc de l’instabilité. Le paramétrage correct des requests reste donc essentiel : n’hésitez pas à consulter notre documentation détaillée sur ce sujet.

Scénarios de planification des workloads sous contraintes

« Mais alors, quelles sont mes alternatives pour obtenir une plateforme à la fois performante et efficace quand la capacité est contrainte ? », vous demandez-vous certainement.
Passons ici en revue quelques situations courantes et explorons les différents leviers à votre disposition pour optimiser les coûts, la performance et la flexibilité.

Scénario 1 - Capacité fixe ou limitée : comment garantir les ressources aux workloads prioritaires ?

Dans ce scénario, le nombre de nœuds disponibles est considéré comme statique mais les workloads continuent à évoluer en fonction de la demande. Vous devez donc réserver des ressources pour les workloads critiques et définir explicitement des ordres de priorité (afin d’éviter qu’un service essentiel ne soit évincé par des charges moins stratégiques).

La Solution : des classes de priorité des workloads et des taints (altérations) / tolérances

Les Classes de priorité instaurent une hiérarchie d’importance des workloads : le scheduler accorde la préséance aux workloads en fonction de leur niveau de criticité. Comme l’illustre le schéma ci-dessus, lorsque les ressources se raréfient, le scheduler évince (préempte) les workloads de priorité basse (en bleu) pour libérer les ressources nécessaires à ceux de priorité supérieure (en rouge).

Les Taints et Tolérances servent à réserver et garantir la capacité. Les « Taints » sont des marqueurs appliqués aux nœuds pour indiquer qu’ils ne doivent pas accepter de charges de travail supplémentaires. Ce sont en quelque sorte des « interdictions par défaut » : pour simplifier, un « taint » interdit l’installation d’un pod sur le nœud « tainté » sauf s’il possède une autorisation spéciale. Les Tolérances permettent de définir ces « autorisations spéciales » : ce sont des paramètres ajoutés aux pods pour leur permettre d’être placés sur des nœuds taintés.
Dit autrement, ces marqueurs empêchent le placement de workloads sur des nœuds inappropriés et réservent l’intégralité des ressources de certains nœuds « taintés » (par exemple dotés de GPU ou de SSD ultra-rapide) à des workloads spécifiquement autorisés. Tant qu’un pod n’a pas la « tolérance » (l’autorisation spéciale) qui force le « taint » (l’interdiction par défaut) du nœud, il ne pourra jamais y être placé, même si sa classe de priorité est plus élevée que celle des pods autorisés. C’est donc la garantie qu’une capacité précieuse (un GPU, un SSD ultra performant, etc.) ne sera jamais consommée par inadvertance par des workloads non prévus à cet effet.

Scénario 2 - Pics soudains de trafic : comment scaler sans dégradation des performances ni erreurs ?

Dans ce scénario, le défi consiste à placer sans délai, le plus rapidement possible, de nouveaux workloads sur un cluster capable de s’étendre horizontalement à la volée. Même si GKE propose des fonctionnalités telles que container-optimized compute et image streaming, qui réduisent considérablement le temps de provisionnement des nouveaux nœuds, la planification des pods reste toujours beaucoup plus rapide que le redimensionnement de nœuds. Le différentiel de vitesse — les pods démarrent en quelques secondes alors que l’ajout d’un nœud prend beaucoup plus de temps — peut provoquer des goulets d’étranglement sur les ressources et dégrader le SLO.

La Solution : Le provisionnement des Pods (Placeholder pods ou Pods de Réserve) et les profils d’autoscaling

• Les Placeholder pods (ou balloon pods), autrement dit les Pods Réservés, permettent d’avoir en permanence de la capacité disponible sans le cluster. Lorsqu’un pic soudain survient et que de nouveaux pods doivent être placés, ces pods « balloon » sont évincés (préemptés) afin de libérer immédiatement la capacité qu’ils retenaient et y déployer tout aussi rapidement les nouveaux pods requis. L’autoscaler du cluster provisionne ensuite de nouveaux nœuds pour reloger les balloon pods évincés et, si nécessaire, ajouter encore de la capacité.
• Les profils d’autoscaling permettent de régler la mise hors service des nœuds selon des objectifs de coût ou de performance. Dit autrement, ces profils indiquent comment et quand les nœuds du cluster doivent être supprimés afin d’opérer un « scale-down » automatique. GKE propose deux profils d’autoscaling, applicables au niveau du cluster : balanced et optimize-utilization. Le profil balanced réduit la taille des nœuds de façon moins agressive qu’optimize-utilization, maintenant ainsi les nœuds disponibles plus longtemps : un nouveau pic de demande ne pâtira donc pas du temps de création de nœuds. Optimize-utilization, en revanche, supprime les nœuds plus rapidement pour maximiser l’utilisation des ressources et réduire les coûts.

Les compute classes (définies ci-après) permettent aussi de réduire le nombre de nœuds de façon ciblée, workload par workload. Elles permettent de définir des règles de consolidation (seuil d’utilisation, délai d’inactivité, etc.) qui déterminent quand un nœud peut être supprimé pour un workload donné.

Scénario 3 : Comment ajouter des nœuds dans un cluster quand le type de nœud souhaité n’est pas disponible ?

Dans ce scénario, vous souhaitez étendre votre cluster sans savoir si le type de nœud requis ou préféré, tel un accélérateur hardware ou une VM spot, sera réellement disponible.

La Solution : GKE custom compute classes (ou classes de calcul personnalisées). 

• Les « compute classes » permettent de définir des types de nœuds préférés et de secours lorsque vous étendez votre cluster. Vous pouvez fixer des priorités pour des propriétés précises de nœuds (CPU, accélérateurs hardware), pour des caractéristiques globales (famille de VM, minimum CPU/Mémoire, instances Spot), ou même pour un type d’instance exact (par ex. : n4-standard-16).
  Ces « compute classes » assurent en outre une migration active vers la meilleure option disponible : si un nœud de priorité supérieure (comme une VM Spot) se libère après le déploiement, les workloads se réalignent automatiquement dessus.
  Si votre organisation profite déjà de remises “Committed Use Discounts” (CUD) basées sur les ressources (engagement de facturation sur un volume précis de vCPU/RAM contre un tarif réduit), vous pouvez configurer vos « compute classes » pour consommer en priorité ces ressources déjà payées avant de solliciter d’autres types de nœuds. Et pour gagner encore en souplesse entre familles de machines, régions et plateformes de calcul, envisagez à terme de basculer vers les CUD flexibles.

Scénario 4 : Que faire quand les ressources matérielles souhaitées ne sont pas disponibles dans une région ?

Dans ce scénario, la capacité requise par le workload est à la fois très spécifique et fortement sollicitée. Il se peut même que ces ressources ne soient pas disponibles dans une région donnée, même en jonglant avec les compute classes. Un casse-tête fréquent pour les applications IA, qui ont besoin d’une infrastructure ultra-performante et d’accélérateurs GPU ou TPU rarement disponibles en grande quantité.

La Solution : Multi-Cluster Orchestrator et Multi-Cluster Gateway

• Multi-Cluster Orchestrator est un projet open-source dont l’objectif est de « simplifier les déploiements multi-cluster, optimiser l’utilisation des ressources et les coûts et renforcer la fiabilité, la scalabilité et les performances des workloads ». Intégré à GKE, cet outil permet aux ingénieurs plateforme de localiser les ressources au sein des régions Google Cloud, puis de déclencher automatiquement le provisionnement d’un cluster dans la région où ces ressources sont disponibles.
• Multi-Cluster Gateway est une solution réseau pour GKE qui s’appuie sur l’API Kubernetes Gateway pour piloter le trafic applicatif entre plusieurs clusters, potentiellement répartis sur plusieurs régions. Elle simplifie considérablement l’exposition des services et l’équilibrage de charge dans des environnements GKE géographiquement distribués.

Combinées, ces deux solutions permettent une orchestration fluide des workloads dans un environnement multi-régions et offrent une résilience accrue face aux limitations de capacité de certaines régions cloud.

Conclusion et pour aller plus loin

GKE fournit aux ingénieurs plateforme un arsenal complet d’outils pour optimiser l’allocation des ressources, même lorsqu’ils sont confrontés à des contraintes de capacité. Pour que la planification de ressources soit réellement efficace et holistique, il faut connaître ses workloads sur le bout des doigts : criticité, profils d’usage, besoins de ressources spécifiques (CPU, mémoire, GPU, etc.). Travailler en environnement contraint peut être un formidable levier pour maîtriser les coûts… à condition de savoir préserver le niveau de performances.

Pour affiner votre démarche, n’hésitez pas à exploiter les ressources suivantes :

• Apprenez à interpréter les indicateurs clés du cluster GKE et des workloads — comme le taux d’utilisation ou le bon dimensionnement (rightsizing) — pour mieux anticiper les besoins en capacité. Ces indicateurs constituent la base de toute planification solide.
• Surveillez les événements de mise à l’échelle (scaling), tels que les échecs de planification de pods et les changements du nombre de nœuds/pods, à l’aide du tableau de bord « Unschedulable Pods ».
• Découvrez la nouvelle fonctionnalité « GKE Horizontal Pod Autoscaling Observability Events », qui permet d’accéder aux journaux des décisions prises par l’autoscaler HPA. Un outil précieux pour analyser les événements de scaling et affiner la conception de votre plateforme en fonction des comportements observés.