Choisir la taille et le champ d'application des clusters Google Kubernetes Engine

Cet article présente les critères à prendre en compte pour déterminer les charges de travail à exécuter sur un cluster partagé Google Kubernetes Engine et comment définir la taille appropriée du cluster.

En utilisant des conteneurs au lieu de machines virtuelles, vous pouvez intégrer davantage de charges de travail sur la même infrastructure tout en les isolant les unes des autres.

Les applications et les conteneurs dans lesquels elles s'exécutent ont des exigences différentes en matière de processeur et de mémoire. En tant que plate-forme d'orchestration de conteneurs, Kubernetes planifie les conteneurs sur plusieurs machines afin de répondre à ces besoins. L'optimisation de l'utilisation des machines dépend des charges de travail et des machines disponibles pour les planifier.

Vous pourriez vous attendre à ce que les clusters plus grands qui exécutent une multitude de charges de travail offrent une meilleure utilisation des ressources que les clusters plus petits qui n'en exécutent que quelques-unes. Cependant, le partage des clusters sur de nombreuses charges de travail différentes peut engendrer des difficultés et des contraintes supplémentaires, susceptibles de l'emporter sur les avantages potentiels.

Google Kubernetes Engine est compatible avec des tailles de clusters très variées. La taille minimale d'un cluster est définie selon le nombre de zones qu'il couvre : une pour un cluster zonal et trois pour un cluster régional. La taille maximale d'un cluster Google Kubernetes Engine est définie comme suit :

  • 50 clusters par zone
  • 5 000 nœuds par cluster
  • 110 pods par nœud
  • 300 000 conteneurs

Dans ces limites, vous décidez de la taille appropriée pour un cluster. Les sections suivantes présentent les critères et les compromis à prendre en compte.

Déterminer la taille d'un cluster Google Kubernetes Engine

Mobilité des charges de travail

Kubernetes tente de planifier les pods entre les nœuds de manière à optimiser l'utilisation des ressources disponibles. La planification prend non seulement en compte le choix des machines sur lesquelles exécuter un pod pour la première fois, mais également les budgets d'interruption de pod. Kubernetes peut également replanifier les pods en cours d'exécution pour optimiser l'utilisation. L'optimisation est toutefois limitée si les charges de travail utilisent certaines fonctionnalités, telles que les suivantes :

Si vous disposez d'un grand nombre de charges de travail limitées par l'une de ces fonctionnalités, l'allocation des pods sur les nœuds sera essentiellement statique. L'impossibilité de planifier librement des pods signifie non seulement que l'utilisation n'est peut-être pas optimale, mais également que l'autoscaling du cluster sera moins efficace. Dans le pire des cas, il se peut même que Kubernetes ne puisse pas replanifier les pods en cas de défaillance d'un nœud, même si des ressources de calcul sont disponibles.

Pour obtenir un niveau d'utilisation élevé, laissez Kubernetes planifier librement les pods. Si cela n'est pas possible, envisagez d'utiliser des clusters plus petits, spécifiques à une charge de travail. Si vous pouvez anticiper la façon dont les pods seront alloués aux nœuds en tenant compte de leurs contraintes, vous pouvez choisir une taille de machine adaptée aux exigences relatives à la capacité de processeur et de mémoire de vos conteneurs. Pour assurer la redondance, configurez des pools de nœuds. Ainsi, les charges de travail peuvent être transférées vers d'autres nœuds en cas de défaillance d'un nœud ou d'une zone, tout en respectant les différentes contraintes.

Uniformité des charges de travail

Lorsque vos charges de travail sont parfaitement uniformes et que tous les conteneurs nécessitent la même capacité de processeur et de mémoire, Kubernetes peut planifier les charges de travail de manière fluide entre les nœuds. Cependant, plus la charge de travail est variée, plus il est difficile de trouver une allocation qui ne gaspille pas de ressources en raison de la fragmentation. Les clusters plus grands ont tendance à offrir une meilleure utilisation des ressources pour les charges de travail variées.

Élasticité des charges de travail

Dans la plupart des cas, la charge de travail du cluster n'est pas statique. Des déploiements peuvent être ajoutés ou supprimés, et surtout, le nombre de pods en cours d'exécution est susceptible d'évoluer si vous utilisez l'autoscaling horizontal des pods.

Si vos charges de travail varient, activez la fonctionnalité Autoscaler de cluster. Ainsi, Google Kubernetes Engine essaie d'atteindre la capacité requise en ajoutant ou en supprimant des nœuds du pool de nœuds sous-jacent de manière dynamique. Lorsque la capacité d'une machine est nettement supérieure à la capacité supplémentaire nécessaire, vous ne bénéficiez que d'une faible utilisation au départ si vous ajoutez une machine au pool de nœuds. Cet effet peut être négligeable pour un grand cluster, mais important pour les clusters plus petits. Pour limiter les frais, utilisez de plus grands clusters ou des machines plus petites.

Champ d'application d'un cluster Google Kubernetes Engine

Régionalité des charges de travail

Pour réduire la latence, améliorer la disponibilité ou respecter les réglementations, vous devrez peut-être exécuter des charges de travail dans une région spécifique, ou bien plusieurs régions. Un cluster Google Kubernetes Engine s'exécute dans une seule région ou une seule zone. Par conséquent, le nombre de régions nécessaires à l'exécution des charges de travail détermine le nombre minimal de clusters Google Kubernetes Engine dont vous avez besoin.

Criticité des charges de travail

Lorsqu'un incident affecte une charge de travail critique, l'équipe chargée des opérations doit en être avertie afin de pouvoir commencer à résoudre le problème. Mais que se passe-t-il si un cluster exécute des charges de travail critiques et non critiques ? En cas d'incident, il se peut que vous n'arriviez pas à déterminer immédiatement si les charges de travail non critiques ou critiques sont affectées. Bien que Kubernetes vous permette de classer les charges de travail par priorité, il est préférable de n'exécuter que des charges de travail avec un niveau de criticité similaire sur le même cluster.

Détection de services et communication

Les charges de travail qui s'exécutent sur le même cluster peuvent s'appuyer sur les fonctionnalités de détection de services et d'équilibrage de charge de Kubernetes. Si les charges de travail doivent communiquer entre les clusters, vous devrez peut-être utiliser des registres de services ou des équilibreurs de charge externes pour vous assurer que ces charges de travail peuvent se découvrir et s'atteindre mutuellement.

En ce qui concerne la découverte et la communication des services, il est généralement plus facile de gérer des charges de travail dépendantes (par exemple, une interface et une application backend) dans un seul et même cluster, plutôt que dans des clusters dédiés plus petits.

Gestion de l'authentification et des accès

Dans Google Cloud, la gestion des accès est assurée au niveau des projets. La modélisation des projets en fonction de la structure d'équipe d'une organisation constitue par conséquent une pratique courante recommandée.

Les clusters Google Kubernetes Engine font partie d'un projet. Vous ne pouvez pas les partager entre plusieurs projets. Par conséquent, un cluster Google Kubernetes Engine est également soumis à la configuration de la gestion de l'authentification et des accès (IAM) de votre projet.

L'alignement des clusters, des équipes et des projets simplifie la gestion des rôles et des autorisations. Dans la plupart des cas, IAM vous permet de bénéficier du niveau de précision dont vous avez besoin pour gérer l'accès à Kubernetes, sans qu'il soit nécessaire de configurer un autre contrôle des accès basé sur les rôles (RBAC) directement dans Kubernetes.

Toutefois, si vous devez partager un cluster entre plusieurs équipes, le projet GCP parent du cluster doit également être réparti sur plusieurs équipes. Dans ce cas, les rôles fournis par IAM peuvent ne pas être suffisamment spécifiques pour gérer les accès à Google Kubernetes Engine. Vous devez donc gérer une configuration RBAC supplémentaire (au niveau de l'espace de noms) dans Kubernetes. La gestion de la configuration RBAC à deux emplacements (IAM et Kubernetes) accroît la complexité d'administration. Il est donc préférable de définir le champ d'application du cluster de manière à pouvoir gérer l'intégralité du contrôle des accès dans IAM.

Maintenance

Bien que Google Kubernetes Engine soit un service entièrement géré, vous devez envisager quelques opérations de maintenance :

  • Sélectionner une version de Kubernetes
  • Sélectionner un modèle de mise à niveau (manuel ou programmé) et des intervalles de maintenance
  • Lancer des mises à niveau
  • Modifier les paramètres du pool de nœuds

Toutes ces activités peuvent affecter les charges de travail exécutées sur le cluster. Si celui-ci est partagé entre plusieurs équipes, ces dernières peuvent avoir du mal à se mettre d'accord sur le moment opportun pour effectuer ces tâches. Pour éviter les problèmes de planification, limitez le nombre d'équipes impliquées dans les activités de maintenance du cluster.

Réseau

Un cluster Google Kubernetes Engine appartient à un seul cloud privé virtuel (VPC) et à un seul sous-réseau, quel que soit le nombre de pools de nœuds qu'il utilise. Si les exigences liées à la connectivité indiquent que les charges de travail doivent s'exécuter dans différents VPC ou sous-réseaux, vous devez créer des clusters distincts (au moins un par VPC ou sous-réseau).

Surveillance et journalisation

Étant donné que la configuration de la surveillance et de la journalisation s'applique à l'ensemble d'un cluster Google Kubernetes Engine, exécutez plusieurs charges de travail sur un seul cluster si leurs exigences en matière de journalisation et de surveillance sont identiques.

Facturation

Google Cloud gère la facturation par projet. Pour les charges de travail partagées sur un même cluster et, par conséquent, sur un même projet Google Cloud, il est difficile de déterminer la part de chaque charge de travail dans le coût total. Si vous avez besoin d'une facturation par charge de travail, utilisez des clusters Google Kubernetes Engine dédiés et des projets Google Cloud dédiés.

Étapes suivantes