Ce document présente la gestion des charges de travail dans Google Distributed Cloud (GDC) air-gapped. 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.
Ce document s'adresse aux administrateurs informatiques du groupe des administrateurs de plate-forme, chargés de gérer les ressources de leur organisation, et aux développeurs d'applications du groupe des opérateurs d'applications, chargés de développer et de gérer les applications dans un univers GDC.
Pour en savoir plus, consultez la documentation sur les audiences pour les environnements isolés GDC.
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. Le diagramme suivant illustre la séparation des charges de travail au niveau du plan de données de votre organisation.
Les charges de travail basées sur des VM fonctionnent dans une VM. À l'inverse, les charges de travail de conteneur fonctionnent dans un cluster Kubernetes. La séparation fondamentale entre les VM et les clusters Kubernetes fournit des limites d'isolation entre vos charges de travail de VM et vos charges de travail de conteneurs. Pour en savoir plus, consultez la section Hiérarchie des ressources.
Les sections suivantes présentent les différences entre chaque type de charge de travail et leur cycle de vie de déploiement.
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 comporter de nombreuses charges de travail de VM. Les VM sont une ressource enfant d'un projet. 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. Un cluster Kubernetes se compose des types de nœuds suivants :
Nœud du plan de contrôle : exécute les services de gestion, tels que la planification, etcd et un serveur d'API.
Nœud de calcul : exécute vos pods et vos applications de conteneur.
Les clusters Kubernetes peuvent être associés à un ou plusieurs projets, mais ils ne sont pas une ressource enfant d'un projet. Il s'agit d'une différence fondamentale entre les clusters Kubernetes et les VM. Une VM est une ressource enfant d'un projet, tandis que les clusters Kubernetes fonctionnent comme une ressource enfant d'une organisation, ce qui leur permet de s'associer à plusieurs projets.
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 Charges de travail de conteneurs dans GDC.
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 pour chaque environnement de développement logiciel
- Créer moins de clusters, mais plus grands
- Créer moins de pools de nœuds, mais de plus grande taille, dans un cluster
Tenez compte de chaque bonne pratique pour concevoir un cluster résilient pour le cycle de vie de votre charge de travail de conteneur.
Créer des clusters distincts par environnement de développement logiciel
En plus d'utiliser des projets distincts par environnement de développement logiciel, nous vous recommandons de concevoir des clusters Kubernetes distincts par environnement de développement logiciel. Un environnement de développement logiciel est une zone de votre univers GDC destinée à toutes les opérations correspondant à une phase désignée du cycle de vie. Par exemple, si votre organisation dispose de deux environnements de développement logiciel nommés development et production, vous pouvez créer un ensemble distinct de clusters Kubernetes pour chaque environnement et associer des projets à chaque cluster en fonction de vos besoins. Nous recommandons que les clusters Kubernetes dans les cycles de vie de préproduction et de production soient associés à plusieurs projets.
Les clusters définis pour chaque environnement de développement logiciel supposent que les charges de travail d'un environnement de développement logiciel peuvent partager des clusters. Vous attribuez ensuite des projets au cluster Kubernetes de l'environnement approprié. Un cluster Kubernetes peut être subdivisé en plusieurs pools de nœuds ou utiliser des rejets pour isoler les charges de travail.
En séparant les clusters Kubernetes par environnement de développement logiciel, 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 hors production.
Le schéma suivant présente un exemple de conception de cluster Kubernetes pour plusieurs charges de travail qui s'étendent sur des projets, des clusters, des environnements de développement logiciel et des classes de machines.
Cette architecture type suppose que les charges de travail dans un environnement de développement logiciel de production et de développement peuvent partager des clusters. Chaque environnement dispose d'un ensemble distinct de clusters Kubernetes, qui sont ensuite subdivisés en plusieurs pools de nœuds pour répondre aux différentes exigences en matière 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 différentes configurations de cluster, 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 schéma suivant montre un exemple où plusieurs clusters sont configurés par environnement de développement logiciel en raison d'exigences telles que les opérations de conteneur décrites dans la section précédente.
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éveloppement logiciel et des opérations de conteneur. Chaque cluster supplémentaire entraîne une consommation de ressources supplémentaire, comme 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.
Étapes suivantes
- Hiérarchie des ressources
- Créer une application de conteneur à haute disponibilité
- Créer une application de VM à haute disponibilité