Ce document décrit la hiérarchie des ressources Google Distributed Cloud (GDC) sous air gap et la façon dont les ressources sont gérées dans une instance sous air gap. Pour en savoir plus sur la gestion des ressources dans plusieurs zones, consultez la présentation multizone.
La hiérarchie des ressources GDC a deux objectifs :
- Fournir une hiérarchie de propriété, qui lie le cycle de vie d'une ressource à son parent immédiat dans la hiérarchie
- Fournir des points de liaison et un héritage pour les stratégies de contrôle des accès et les règles d'administration
La hiérarchie des ressources GDC ressemble au système de fichiers des systèmes d'exploitation : il s'agit d'un moyen d'organiser et de gérer des entités de manière hiérarchique. En général, chaque ressource a un seul parent. Cette organisation hiérarchique des ressources vous permet de définir des stratégies de contrôle des accès, telles que Identity and Access Management (IAM), qui sont héritées par les ressources enfants.
Pour en savoir plus sur les bonnes pratiques d'organisation de vos limites d'accès, consultez Concevoir des limites d'accès entre les ressources.
Structure des ressources en détail
Les entités suivantes sont des types de ressources reconnus dans la hiérarchie des ressources GDC :
Les ressources GDC sont organisées de manière hiérarchique. La plupart des ressources de la hiérarchie des ressources ont un seul parent. L'exception ne s'applique qu'à la ressource la plus élevée. Au niveau le plus bas de la hiérarchie, les ressources de service sont les composants fondamentaux sur lesquels reposent tous les services GDC.
Une organisation se trouve au sommet de la hiérarchie des ressources GDC. Toutes les ressources appartenant à une organisation sont regroupées sous la ressource d'organisation. Cela permet de centraliser la visibilité et le contrôle sur l'ensemble des ressources appartenant à une organisation.
Les projets et les clusters Kubernetes partagés sont de portée organisationnelle. Elles peuvent être associées les unes aux autres pour organiser les ressources de service. Toutefois, les projets et les clusters partagés fonctionnent indépendamment les uns des autres. Cette flexibilité offre de nombreuses options différentes pour organiser les services et les charges de travail. Par exemple, vous pouvez disposer d'un cluster partagé dédié à un seul projet. De même, un cluster partagé peut s'étendre sur plusieurs projets.
Les ressources de service sont des entités qui doivent appartenir à un projet et ne peuvent pas être partagées entre plusieurs projets. Les ressources de service incluent, par exemple, les machines virtuelles (VM), les clusters Kubernetes standards, les bases de données, les buckets de stockage et les sauvegardes. La plupart de ces ressources de niveau inférieur ont des ressources de projet comme parents.
Le diagramme suivant présente un exemple de hiérarchie des ressources GDC :
Pour en savoir plus sur les bonnes pratiques concernant l'organisation de la hiérarchie de vos ressources afin de gérer au mieux vos charges de travail, consultez Concevoir la séparation des charges de travail des utilisateurs.
Organisation
La ressource Organisation représente une unité administrative ou une fonction commerciale, comme une entreprise, et constitue la ressource de premier niveau dans la hiérarchie des ressources GDC. Une organisation définit une limite de sécurité qui englobe les ressources d'infrastructure à administrer ensemble afin que les utilisateurs puissent déployer des charges de travail d'application. Les organisations sont mondiales et couvrent toutes les zones d'un univers. Dans une organisation, les ressources de service telles que les VM et les volumes de stockage sont regroupées de manière logique par projets.
Tous les projets, clusters et ressources de service appartiennent à votre organisation plutôt qu'à leurs créateurs. Cela signifie qu'aucun type de ressource d'une organisation n'est supprimé si l'utilisateur qui l'a créé quitte l'organisation. Au lieu de cela, tous les types de ressources suivent le cycle de vie de l'organisation dans GDC.
Les stratégies de contrôle des accès IAM appliquées à la ressource "Organisation" s'appliquent à l'ensemble de la hiérarchie sur toutes les ressources de l'organisation. Pour en savoir plus sur l'attribution de règles et d'autorisations à l'échelle de l'organisation, consultez les sections Règles d'administration et IAM.
Projet
Un projet est une unité de location que chaque service doit intégrer. Les projets permettent de regrouper logiquement les ressources de service. Les projets sont globaux et couvrent toutes les zones d'un univers.
Les projets permettent de segmenter les ressources de service au sein d'une organisation et fournissent une limite de cycle de vie et de règles pour la gestion des ressources. Les ressources de service d'un projet ne peuvent jamais survivre au projet lui-même ni être déplacées d'un projet à un autre. Le contrôle est donc disponible pendant toute la durée de vie d'une ressource. Par conséquent, vous devez déployer des ressources de n'importe quel type dans un espace de noms de projet.
Un projet est considéré comme un espace de noms Kubernetes approprié qui s'étend sur plusieurs clusters partagés d'une organisation. L'uniformité d'espace de noms considère tous les espaces de noms portant un nom donné comme le même espace de noms pour tous les clusters partagés au sein d'une même organisation. L'espace de noms unique a un propriétaire cohérent pour l'ensemble des clusters partagés. Les fournisseurs de services créent des services à portée de projet en créant des composants de plan de contrôle et de plan de données dans l'espace de noms.
L'espace de noms d'un projet héberge les éléments suivants :
- API de service à portée de projet.
- Configurations des règles au niveau du projet, telles que les rôles et les liaisons de rôle.
Vous ne pouvez associer un projet qu'à un sous-ensemble de clusters partagés dans une organisation. Vous pouvez déployer des charges de travail conteneurisées sur ces clusters partagés dans un espace de noms de projet. Le concept d'uniformité d'espace de noms s'applique à l'espace de noms du projet sur ces clusters partagés. Les règles à portée d'espace de noms, telles que les règles d'accès basé sur les rôles (RBAC), s'appliquent à tous ces espaces de noms.
Pour en savoir plus sur les projets, consultez la présentation des projets.
Cluster Kubernetes partagé
Un cluster Kubernetes est un ensemble de nœuds qui exécutent des charges de travail conteneurisées dans GKE sur GDC. Vous pouvez provisionner des clusters Kubernetes pour répondre aux besoins de calcul de vos applications.
Un cluster partagé est une configuration de cluster à l'échelle de l'organisation, qui doit être associée à un ou plusieurs projets. La configuration de cluster standard est une autre configuration de cluster qui ne fonctionne que dans un seul projet, mais qui est considérée comme une ressource de service dans la hiérarchie des ressources. Ces configurations de cluster Kubernetes sont conçues pour créer une architecture Kubernetes offrant des options de gestion des conteneurs dans les environnements de développement logiciel, tels que les environnements de test, de développement et de production. Pour en savoir plus sur les bonnes pratiques de séparation des charges de travail de conteneurs, consultez Concevoir la séparation des charges de travail.
Pour en savoir plus sur les différents types de clusters dans GDC, consultez Configurations de cluster Kubernetes.
Les clusters partagés subdivisent les ressources d'infrastructure en pools isolés qui peuvent être utilisés par les projets d'une organisation. Les clusters sont également séparés logiquement les uns des autres pour fournir différents domaines de défaillance et garanties d'isolation. L'application des règles par organisation garantit que les clusters partagés peuvent être partagés entre les équipes et les utilisateurs tout en maintenant les garanties de performances et de ressources. De plus, les règles d'administration permettent aux charges de travail de VM de s'exécuter en parallèle des charges de travail de conteneurs sans introduire de complexité opérationnelle.
Les clusters sont utiles pour les instances dans lesquelles vous devez déployer des charges de travail conteneurisées. Toutefois, avec l'option de déploiement de charges de travail basées sur des VM, l'existence d'un cluster Kubernetes n'est pas requise dans GDC.
Les clusters sont une ressource zonale uniquement et ne peuvent pas s'étendre sur plusieurs zones. Pour exploiter des clusters dans un déploiement multizone, vous devez les déployer manuellement dans chaque zone.
Pour en savoir plus sur les clusters Kubernetes, consultez la présentation des clusters Kubernetes.
Ressource de service
Les ressources de service incluent de nombreuses entités, telles que :
- VM
- Clusters Kubernetes standards
- Bases de données
- Buckets de stockage
- Charges de travail conteneurisées
- Sauvegardes
Les ressources de service doivent appartenir à un projet et ne peuvent pas être partagées entre plusieurs projets. Ce cycle de vie spécifique au projet signifie que les ressources de service d'un projet ne peuvent jamais survivre au projet lui-même, ce qui garantit un contrôle pendant toute la durée de vie de la ressource.
Les ressources de service peuvent être déployées de manière globale ou zonale, selon leur type. Consultez la documentation du service spécifique pour obtenir des informations sur les options de déploiement multizones. Les ressources de service sont activées par défaut et peuvent être désactivées à l'aide d'une règle d'administration.