Google Distributed Cloud permet de gérer plusieurs modèles de déploiement afin de répondre à différents besoins en termes de disponibilité, d'isolation et d'empreinte des ressources. Cette page définit les concepts que tous les modèles de déploiement partagent et décrit chaque modèle de déploiement.
Cette page s'adresse aux administrateurs, aux architectes et aux opérateurs qui définissent les solutions informatiques et l'architecture du système conformément à la stratégie de l'entreprise, en collaboration avec les personnes concernées principales. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud, consultez la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.
Clusters d'utilisateur
Un cluster d'utilisateur est un cluster Kubernetes qui exécute vos charges de travail conteneurisées. Il se compose de nœuds de plan de contrôle et de nœuds de calcul. Google Distributed Cloud est compatible avec un ou plusieurs clusters utilisateur. Les clusters d'utilisateur doivent contenir un ou plusieurs nœuds de calcul qui exécutent des charges de travail d'utilisateur.
Clusters d'administrateur
Un cluster d'administrateur est un cluster Kubernetes qui gère un ou plusieurs clusters d'utilisateur. Votre cluster d'administrateur peut effectuer les tâches suivantes :
- Créer des clusters d'utilisateur
- Mettre à niveau des clusters d'utilisateurs
- Mettre à jour des clusters d'utilisateurs
- Supprimer des clusters d'utilisateur
Pour créer un cluster utilisateur, votre cluster administrateur configure les composants Google Distributed Cloud sur le plan de contrôle et les nœuds de calcul du cluster utilisateur. Votre cluster d'administrateur ne comporte que des nœuds de plan de contrôle, car les composants Google Distributed Cloud s'exécutent sur ces nœuds.
Votre cluster d'administrateur contient les types de données sensibles suivants :
- Identifiants SSH : permettent d'activer l'installation à distance
- Clés de compte de service Google Cloud : permettent d'accéder à des fonctionnalités telles que Container Registry
Pour protéger les données sensibles, limitez l'accès à votre cluster d'administrateur.
Haute disponibilité
Vous pouvez exécuter des clusters d'administrateur ou d'utilisateur en mode haute disponibilité (HA, high availability). Ce mode nécessite au moins trois nœuds (nombre impair) de plan de contrôle exécutés dans votre cluster. Si vous exécutez un cluster en mode standard, votre cluster ne nécessite qu'un nœud de plan de contrôle.
Pour éviter d'avoir un point de défaillance unique, utilisez le mode haute disponibilité pour les déploiements de production. Utilisez le mode standard pour les environnements non critiques, par exemple un environnement de test, dans lequel vous pouvez recréer le cluster en cas d'échec du nœud de plan de contrôle unique. Un cluster d'utilisateur haute disponibilité doit comporter au moins deux nœuds de calcul en cas de défaillance d'un nœud de calcul.
Lorsque vous mettez à niveau vos clusters, un déploiement à haute disponibilité réduit également le risque que le cluster devienne inaccessible en cas d'erreur.
Modèles de déploiement
Google Distributed Cloud est compatible avec les modèles de déploiement suivants pour répondre à différentes exigences:
- Déploiement de clusters d'administrateur et d'utilisateur
- Déploiement de clusters hybrides
- Déploiement de clusters autonomes
Déploiement de clusters d'administration et d'utilisateurs
Utilisez ce modèle de déploiement si vous disposez de plusieurs clusters dans un même centre de données que vous souhaitez gérer depuis un emplacement centralisé, et pour des déploiements plus importants nécessitant une isolation entre différentes équipes ou entre des charges de travail de développement et de production.
Ce modèle de déploiement se compose des clusters suivants :
- Un cluster d'administrateur : point de gestion central qui fournit une API pour gérer les clusters d'utilisateur. Votre cluster d'administrateur n'exécute que des composants de gestion.
- Un ou plusieurs clusters d'utilisateur : contiennent les nœuds du plan de contrôle et les nœuds de calcul qui exécutent des charges de travail d'utilisateur.
Ce modèle répond aux exigences suivantes :
- Il fournit une API et un plan de contrôle centralisé pour gérer le cycle de vie de vos clusters d'utilisateurs.
- Il permet d'isoler les différentes équipes.
- Il permet d'isoler les charges de travail de développement et de production.
- Vous n'avez pas besoin de partager les identifiants SSH et les clés de compte de service avec les propriétaires de clusters.
- Vous pouvez intégrer votre déploiement à vos propres plans de contrôle.
Empreinte
Un déploiement de cluster d'administrateur et d'utilisateur nécessite les nœuds suivants:
Cluster d'administrateur
- Un nœud de plan de contrôle pour un mode standard
- Au moins trois nœuds de plan de contrôle pour la haute disponibilité
Clusters d'utilisateur : vous pouvez configurer la haute disponibilité pour chaque cluster d'utilisateur indépendamment.
Nœuds de plan de contrôle :
- Un nœud de plan de contrôle pour un mode standard
- Au moins trois nœuds de plan de contrôle pour la haute disponibilité
Nœuds de calcul :
- Un ou plusieurs nœuds de calcul pour le mode standard
- Au moins deux nœuds de calcul pour la haute disponibilité
Déploiement de clusters hybrides
Ce modèle de déploiement est un déploiement multicluster spécialisé. Un cluster hybride est un cluster d'administrateur qui peut exécuter des charges de travail utilisateur. Votre cluster hybride gère toujours d'autres clusters d'utilisateur.
Fonctionnalités de ce modèle :
- L'allocation d'un ensemble de machines pour un cluster d'administration est souvent inutile, car les clusters d'administration utilisent relativement peu de ressources. Le déploiement du cluster hybride vous permet de récupérer la capacité inutilisée sur ces machines, car il vous permet d'exécuter des charges de travail d'utilisateur au sein du cluster d'administration.
- Le cluster d'administrateur contient des données sensibles, telles que les identifiants SSH (utilisés par le cluster d'administrateur pour gérer les clusters d'utilisateurs sur les machines distantes) et les clés de compte de service Google Cloud (utilisées par le cluster d'administrateur pour accéder aux services Google Cloud en tant que Cloud Storage). Les déploiements de clusters hybrides exécutent des charges de travail d'utilisateur au sein du cluster d'administrateur, ce qui expose potentiellement les données sensibles du cluster d'administrateur aux charges de travail des utilisateurs.
Empreinte
Un déploiement de cluster hybride nécessite les nœuds suivants :
Cluster hybride
Nœuds de plan de contrôle :
- Un nœud de plan de contrôle pour un mode standard
- Au moins trois nœuds de plan de contrôle pour la haute disponibilité
Nœuds de calcul :
- Un ou plusieurs nœuds de calcul pour le mode standard
- Au moins deux nœuds de calcul pour la haute disponibilité et selon le type de charge de travail
Clusters d'utilisateur : vous pouvez configurer la haute disponibilité pour chaque cluster d'utilisateur indépendamment.
Nœuds de plan de contrôle :
- Un nœud de plan de contrôle pour un mode standard
- Au moins trois nœuds de plan de contrôle pour la haute disponibilité
Nœuds de calcul :
- Un ou plusieurs nœuds de calcul pour le mode standard
- Au moins deux nœuds de calcul pour la haute disponibilité
Déploiement de clusters autonomes
Ce modèle de déploiement dispose d'un cluster unique qui sert de cluster d'utilisateur et de cluster d'administrateur.
Ce modèle présente les avantages suivants :
- Il ne nécessite pas de cluster d'administrateur distinct.
- Il est compatible avec le profil de périphérie, qui a considérablement réduit les besoins en ressources système. Il est recommandé pour les appareils de périphérie présentant des contraintes de ressources élevées.
Ce modèle présente des inconvénients pour la sécurité, car les charges de travail peuvent s'exécuter sur un cluster contenant les données sensibles suivantes:
- Identifiants SSH
- Clés de compte de service Google Cloud
Utilisez ce modèle si vous remplissez l'une des conditions suivantes :
- Vous gérez tous les clusters indépendamment.
- Vous disposez d'un petit nombre de nœuds de calcul.
- Vous ne faites fonctionner qu'une seule équipe.
- Vous n'exécutez qu'un seul type de charge de travail.
Ce modèle fonctionne bien dans les situations suivantes :
- Chaque cluster est géré indépendamment avec des clés SSH et des identifiants Google Cloud différents
- Les clusters s'exécutent dans des partitions isolées du réseau, séparées des réseaux non approuvés.
- Les clusters s'exécutent dans des emplacements périphériques
Empreinte
Un déploiement de cluster autonome nécessite les nœuds suivants :
Nœuds de plan de contrôle :
- Un nœud de plan de contrôle pour un mode standard
- Au moins trois nœuds de plan de contrôle pour la haute disponibilité
Nœuds de calcul :
- Un ou plusieurs nœuds de calcul pour le mode standard
- Au moins deux nœuds de calcul pour la haute disponibilité
Profil Edge
Les clusters autonomes sont compatibles avec un profil de périphérie, qui réduit la consommation de ressources du cluster. Vous activez le profil Edge lorsque vous créez un cluster autonome en définissant profile dans le fichier de configuration du cluster sur edge. Le profil de périphérie est recommandé pour les appareils de périphérie présentant des contraintes de ressources restrictives. Pour connaître les exigences matérielles associées au profil de périphérie, consultez la section Ressources nécessaires pour les clusters autonomes utilisant le profil de périphérie.
Dans un cluster autonome configuré pour utiliser le profil Edge, les nœuds du plan de contrôle sont automatiquement configurés pour accepter les charges de travail utilisateur. Cela signifie que vous n'avez pas besoin d'un pool de nœuds de calcul. Toutefois, la réduction de l'empreinte en exécutant des charges de travail sur le plan de contrôle affaiblit la sécurité et l'isolement des ressources entre le plan de contrôle et le plan de données. Si l'empreinte réduite vaut la peine, vous pouvez configurer un cluster autonome avec le profil Edge pour qu'il s'exécute sur un nœud de plan de contrôle unique ou sur plusieurs nœuds de plan de contrôle pour une haute disponibilité.