Concevoir la séparation des charges de travail

Ce document présente la gestion des charges de travail dans Google Distributed Cloud (GDC) sous air gap. Voici les sujets abordés :

Bien que certains modèles de déploiement de charge de travail soient recommandés, il n'est pas obligatoire de les suivre exactement comme indiqué. Chaque univers GDC présente des exigences et des considérations uniques qui doivent être satisfaites au cas par cas.

Où déployer les charges de travail

Sur la plate-forme GDC, les opérations de déploiement des charges de travail de machines virtuelles (VM) et des charges de travail de conteneurs sont différentes. Cette section présente les différences et indique où déployer chaque ressource.

Charges de travail basées sur des VM

Vous pouvez créer des VM pour héberger vos charges de travail basées sur des VM. Vous disposez de nombreuses options de configuration pour la forme et la taille de votre VM afin de répondre au mieux aux exigences de votre charge de travail basée sur une VM. Vous devez créer une VM dans un projet, qui peut contenir de nombreuses VM et charges de travail de VM. Pour en savoir plus, consultez la présentation des VM.

Les projets contenant uniquement des charges de travail basées sur des VM ne nécessitent pas de cluster Kubernetes. Par conséquent, vous n'avez pas besoin de provisionner de clusters Kubernetes pour les charges de travail basées sur des VM.

Charges de travail basées sur des conteneurs

Vous pouvez déployer des charges de travail basées sur des conteneurs sur un pod d'un cluster Kubernetes. Les clusters Kubernetes peuvent être associés à un ou plusieurs projets, mais ils ne sont pas une ressource enfant d'un projet. Nous vous recommandons de n'associer les clusters qu'aux projets de l'environnement de déploiement approprié. Par exemple, un cluster pour les charges de travail de production est associé à un projet pour les charges de travail de production.

Pour la planification des pods dans un cluster Kubernetes, GDC adopte les concepts généraux de Kubernetes en matière de planification, de préemption et d'éviction. Les bonnes pratiques concernant la planification des pods dans un cluster varient en fonction des exigences de votre charge de travail.

Pour en savoir plus sur les clusters Kubernetes, consultez la présentation des clusters Kubernetes. Pour en savoir plus sur la gestion de vos conteneurs dans un cluster Kubernetes, consultez Présentation des charges de travail de conteneur.

Bonnes pratiques pour concevoir des clusters Kubernetes

Cette section présente les bonnes pratiques à suivre pour concevoir des clusters Kubernetes :

Créer des clusters distincts par environnement de déploiement

En plus d'utiliser des projets distincts par environnement de déploiement, nous vous recommandons de concevoir des clusters Kubernetes distincts par environnement de déploiement. En séparant le cluster Kubernetes et le projet par environnement, vous isolez la consommation de ressources, les règles d'accès, les événements de maintenance et les modifications de configuration au niveau du cluster entre vos charges de travail de production et de non-production.

Le schéma suivant montre un exemple de conception de cluster Kubernetes pour plusieurs charges de travail qui s'étendent sur des projets, des clusters, des environnements de déploiement et des classes de machines.

Configuration de GDC

Cette architecture exemple suppose que les charges de travail d'un environnement de déploiement sont autorisées à partager des clusters. Chaque environnement de déploiement possède un ensemble distinct de clusters Kubernetes. Vous attribuez ensuite des projets au cluster Kubernetes de l'environnement de déploiement approprié. Un cluster Kubernetes peut être subdivisé en plusieurs pools de nœuds pour répondre à différentes exigences en termes de classe de machines.

Vous pouvez également concevoir plusieurs clusters Kubernetes pour les opérations de conteneur, comme dans les scénarios suivants :

  • Vous avez épinglé certaines charges de travail à une version spécifique de Kubernetes. Vous gérez donc différents clusters à différentes versions.
  • Vous avez des charges de travail qui nécessitent des configurations de cluster différentes, comme la stratégie de sauvegarde. Vous créez donc plusieurs clusters avec des configurations différentes.
  • Vous exécutez des copies d'un cluster en parallèle pour faciliter les mises à niveau de version disruptives ou une stratégie de déploiement bleu-vert.
  • Vous créez une charge de travail expérimentale qui risque de limiter le serveur d'API ou d'autres points de défaillance uniques dans un cluster. Vous l'isolez donc des charges de travail existantes.

Le diagramme suivant montre un exemple où plusieurs clusters sont configurés par environnement de déploiement en raison d'exigences telles que les opérations de conteneur décrites dans la section précédente.

Configuration de GDC

Créer moins de clusters

Pour une utilisation efficace des ressources, nous vous recommandons de concevoir le plus petit nombre possible de clusters Kubernetes qui répondent à vos exigences en matière de séparation des environnements de déploiement et des opérations de conteneur. Chaque cluster supplémentaire entraîne une consommation de ressources supplémentaire, par exemple des nœuds de plan de contrôle supplémentaires. Par conséquent, un grand cluster avec de nombreuses charges de travail utilise les ressources de calcul sous-jacentes plus efficacement que de nombreux petits clusters.

Lorsque plusieurs clusters ont des configurations similaires, la surveillance de la capacité des clusters et la planification des dépendances entre les clusters entraînent une charge de maintenance supplémentaire.

Si un cluster approche de sa capacité maximale, nous vous recommandons d'ajouter des nœuds à un cluster plutôt que d'en créer un.

Créer moins de pools de nœuds dans un cluster

Pour une utilisation efficace des ressources, nous vous recommandons de concevoir moins de pools de nœuds, mais de plus grande taille, dans un cluster Kubernetes.

La configuration de plusieurs pools de nœuds est utile lorsque vous devez planifier des pods qui nécessitent une classe de machine différente de celle des autres. Créez un pool de nœuds pour chaque classe de machine requise par vos charges de travail et définissez la capacité des nœuds sur l'autoscaling pour permettre une utilisation efficace des ressources de calcul.