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é des opérations.
Concevoir des organisations pour isoler physiquement et logiquement les clients
La ressource Organization est la racine de toutes les ressources appartenant à un même client. Le contrôle précis des accès entre les charges de travail d'une organisation peut être défini à l'aide de liaisons de rôle et de règles réseau. Pour en savoir plus, consultez Gestion de l'authentification et des accès.
Chaque organisation 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 si l'accès leur a été explicitement accordé. 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 sortantes d'une organisation et le transfert de données entrantes vers 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 d'une 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 même 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 autorisé à accéder aux privilèges pour 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 de charge de travail agrégés. Pour savoir comment afficher les coûts agrégés pour l'organisation ou une analyse précise 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 isoler logiquement 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 stratégies IAM (Identity and Access Management) et les stratégies réseau.
Lorsque vous concevez des limites de projet, pensez à l'ensemble de fonctionnalités le plus étendu qui peut être partagé par les ressources, telles que les liaisons de rôle, les règles réseau ou les exigences d'observabilité. Regroupez les ressources pouvant partager cette fonctionnalité dans un projet et déplacez celles qui ne le peuvent pas vers un autre projet.
En termes Kubernetes, un projet est un espace de noms Kubernetes réservé à tous les clusters d'une organisation. Même si un espace de noms est 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ôle sont définies au niveau du projet pour déterminer qui peut effectuer quelle action 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 l'association de rôle. L'association de rôle s'applique de manière cohérente aux charges de travail basées sur des VM et à celles basées sur des conteneurs, quel que soit le cluster dans 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 projets entre 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 au 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 Backend Project afin d'activer le transfert de données depuis Frontend Project et Database Project.
De plus, la pile de surveillance collecte des métriques dans toute 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éploiement
Pour chaque charge de travail, nous vous recommandons de créer des projets distincts pour la production, le développement et tout autre environnement de déploiement dont vous avez besoin. En séparant vos environnements de déploiement de production et de développement, vous pouvez définir des liaisons de rôle et des règles réseau de manière précise. Ainsi, les modifications apportées à un projet utilisé pour le développement n'ont pas d'impact sur l'environnement de production.
Attribuer des liaisons de rôles au niveau des ressources dans les projets
Selon la structure et les exigences de votre équipe, vous pouvez autoriser les développeurs à modifier n'importe quelle ressource dans le projet qu'ils gèrent, ou vous pouvez exiger contrôle des accès plus précis. Dans un projet, vous accordez des liaisons de rôle précises pour permettre à des 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. De même, les développeurs de logiciels de l'équipe ne doivent pas être autorisés à modifier la base de données.
Concevoir des clusters pour isoler logiquement les opérations Kubernetes
Un cluster Kubernetes n'est pas une limite de locataire stricte, car les liaisons de rôle 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 même projet ou un seul cluster Kubernetes qui s'étend sur plusieurs projets.