Ce document décrit la hiérarchie des ressources Google Distributed Cloud (GDC) isolées et la façon dont les ressources sont gérées dans une instance isolée. Pour en savoir plus sur la gestion des ressources dans plusieurs zones, consultez la présentation multizone.
La hiérarchie des ressources GDC à 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 concernant l'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 n'ont qu'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 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 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 dédié à un seul projet. De même, un cluster peut s'étendre sur plusieurs projets.
Les ressources de service sont des entités qui doivent appartenir à un projet ou à un cluster, et ne peuvent pas être partagées entre des projets ou des clusters. Les ressources de service incluent, par exemple, les machines virtuelles (VM), 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 votre hiérarchie de ressources pour une gestion optimale des 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. En revanche, 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 stratégies 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 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 d'une même organisation. L'espace de noms unique a un propriétaire cohérent sur l'ensemble des clusters. 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 d'une organisation. Vous pouvez déployer des charges de travail conteneurisées sur ces clusters 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. Les règles à portée d'espace de noms, telles que les règles d'accès basées 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
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. Les clusters sont de portée organisationnelle et doivent être associés à un ou plusieurs projets.
Les clusters 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 permet de partager des clusters entre les équipes et les utilisateurs tout en garantissant les performances et les 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 conteneur 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 des 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 déployer manuellement des clusters dans chaque zone.
Pour en savoir plus sur les clusters Kubernetes, consultez la section Gérer les clusters Kubernetes.
Ressource de service
Les ressources de service incluent de nombreuses entités, telles que :
- VM
- Bases de données
- Buckets de stockage
- Charges de travail conteneurisées
- Sauvegardes
Les ressources de service doivent appartenir à un projet ou, éventuellement, à un cluster pour les charges de travail conteneurisées. Elles ne peuvent pas être partagées entre les projets. Cela signifie que les ressources de service d'un projet ne peuvent jamais survivre au projet lui-même, ce qui garantit que le contrôle est disponible 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.