Ce document présente les bonnes pratiques pour concevoir la hiérarchie et la séparation des charges de travail dans Google Distributed Cloud (GDC) air-gapped à l'aide d'organisations, de projets et de clusters Kubernetes. Ces conseils permettent d'équilibrer l'utilisation efficace des ressources, l'isolation des charges de travail et la facilité d'utilisation.
Concevoir des organisations pour l'isolation physique et logique entre les clients
La ressource Organization est la racine de toutes les ressources appartenant à un seul client. Le contrôle des accès précis entre les charges de travail au sein d'une organisation peut être défini par des liaisons de rôles et des règles de réseau. Pour en savoir plus, consultez
Gestion de l'authentification et des accès.
Chaque organisation au sein d'une zone GDC fournit une isolation physique pour l'infrastructure de calcul et une isolation logique pour la mise en réseau, le stockage et d'autres services. Les utilisateurs d'une organisation n'ont pas accès aux ressources d'une autre organisation, sauf s'ils y sont explicitement autorisés. La connectivité réseau d'une organisation à une autre n'est pas autorisée par défaut, sauf si elle est explicitement configurée pour autoriser le transfert de données sortant d'une organisation et le transfert de données entrant dans une autre.
Définir le champ d'application des charges de travail pouvant partager une organisation
Le champ d'application d'une organisation dans le contexte de votre entreprise peut varier en fonction de la façon dont votre entreprise définit les limites de confiance. Certaines entreprises peuvent préférer créer plusieurs ressources d'organisation pour différentes entités de l'entreprise. Par exemple, chaque service de l'entreprise peut être un client indépendant de GDC avec une organisation indépendante si les services nécessitent une séparation physique et administrative complète de leurs charges de travail.
En général, nous vous recommandons de regrouper plusieurs charges de travail dans une seule organisation en fonction des signaux suivants :
- Les charges de travail peuvent partager des dépendances. Par exemple, il peut s'agir d'une source de données partagée, d'une connectivité entre les charges de travail ou d'un outil de surveillance partagé.
- Les charges de travail peuvent partager une racine de confiance administrative. Le même administrateur peut être considéré comme fiable avec un accès privilégié à toutes les charges de travail de l'organisation.
- Les charges de travail sont autorisées à partager l'infrastructure physique sous-jacente avec d'autres charges de travail de la même organisation, à condition qu'une séparation logique suffisante soit en place.
- Le même responsable du budget est responsable des budgets des charges de travail dans leur ensemble. Pour en savoir plus sur l'affichage des coûts agrégés de l'organisation ou l'analyse détaillée par charge de travail, consultez la page Facturation.
- Les exigences de disponibilité des charges de travail doivent respecter vos exigences de haute disponibilité pour la distance multizone.
Concevoir des projets pour l'isolation logique entre les charges de travail
Au sein d'une organisation, nous vous recommandons de provisionner plusieurs projets pour créer une séparation logique entre les ressources. Les projets d'une même organisation peuvent partager l'infrastructure physique sous-jacente, mais ils sont utilisés pour séparer les charges de travail avec une limite logique basée sur les règles de Identity and Access Management (IAM) et les règles de réseau.
Lorsque vous concevez des limites de projet, pensez au plus grand ensemble de fonctionnalités pouvant être partagées par les ressources, telles que les liaisons de rôles, les règles de réseau, ou les exigences d'observabilité. Regroupez les ressources pouvant partager cette fonctionnalité dans un projet, puis déplacez les ressources qui ne peuvent pas partager cette fonctionnalité vers un autre projet.
En termes Kubernetes, un projet est un espace de noms Kubernetes réservé à tous les clusters d'une organisation. Bien qu'un espace de noms soit réservé sur plusieurs clusters, cela ne signifie pas qu'un pod est automatiquement planifié sur tous les clusters. Un pod planifié sur un cluster particulier reste planifié sur ce cluster.
Le schéma suivant montre comment une liaison de rôle est appliquée à un projet qui s'étend sur plusieurs clusters.
Les liaisons de rôles sont définies au niveau du projet pour déterminer qui peut faire quoi sur quel type de ressource. Les charges de travail telles que les VM ou les pods sont déployées dans un projet, et l'accès à ces charges de travail est régi par la liaison de rôle. La liaison de rôle s'applique de manière cohérente aux charges de travail basées sur des VM et aux charges de travail basées sur des conteneurs, quel que soit le cluster sur lequel elles sont déployées.
Le schéma suivant montre comment les règles de réseau gèrent l'accès entre les projets.
La communication entre les projets Backend Project, Frontend Project et Database Project est désactivée. Toutefois, les ressources de chaque projet peuvent communiquer entre elles.
Les règles de réseau sont définies au niveau du projet pour autoriser de manière sélective l'accès réseau entre les ressources. Par défaut, toutes les ressources d'un même projet sont autorisées à communiquer entre elles sur le réseau interne, et une ressource d'un projet ne peut pas communiquer avec une ressource d'un autre projet. Ce comportement des règles de réseau s'applique que les ressources soient déployées ou non sur le même cluster.
Vous pouvez également définir une ressource personnalisée ProjectNetworkPolicy pour activer la communication entre les projets. Cette règle est définie pour chaque projet afin d'autoriser le trafic entrant provenant d'autres projets. Le schéma suivant illustre une ressource personnalisée ProjectNetworkPolicy définie pour le Backend Project afin d'activer le transfert de données entrant depuis le Frontend Project et le Database Project.
De plus, la pile de surveillance collecte des métriques dans l'ensemble de l'organisation, mais vous pouvez filtrer et interroger à différents niveaux de la hiérarchie des ressources. Vous pouvez interroger des métriques avec des entités telles qu'un cluster ou un espace de noms.
Créer des projets par environnement de développement logiciel
Pour chaque charge de travail, nous vous recommandons de créer des projets distincts pour chaque 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, vous pouvez disposer d'environnements de développement logiciel pour les tests, le développement et la production. La séparation de vos environnements de développement logiciel vous permet de définir des liaisons de rôles et des règles de réseau de manière précise, de sorte que les modifications apportées à un projet utilisé pour un environnement hors production n'aient pas d'incidence sur l'environnement de production.
Accorder des liaisons de rôles au niveau des ressources dans les projets
En fonction de la structure et des exigences de votre équipe, vous pouvez autoriser les développeurs à modifier n'importe quelle ressource du projet qu'ils gèrent ou exiger un contrôle des accès plus précis. Dans un projet, vous accordez des liaisons de rôles précises pour permettre aux développeurs individuels d'accéder à certaines ressources du projet, mais pas à toutes. Par exemple, une équipe peut avoir un administrateur de base de données qui doit gérer la base de données, mais pas modifier d'autres ressources, tandis que les développeurs de logiciels de l'équipe ne doivent pas être autorisés à modifier la base de données.
Concevoir des clusters pour l'isolation logique des opérations Kubernetes
Un cluster Kubernetes n'est pas une limite de locataire stricte, car les liaisons de rôles et les règles de réseau s'appliquent aux projets, et non aux clusters Kubernetes. Il existe une relation "plusieurs à plusieurs" entre les clusters Kubernetes et les projets. Vous pouvez avoir plusieurs clusters Kubernetes dans un seul projet ou un seul cluster Kubernetes qui s'étend sur plusieurs projets.