La ressource "organization" représente une unité administrative ou une fonction métier qui partage le même pool de ressources et les mêmes règles. Google Distributed Cloud (GDC) sous air gap offre une isolation physique entre les organisations grâce à des fonctionnalités multilocataires au niveau matériel. Chaque organisation possède également ses propres composants de plan de contrôle pour ses services, qui ne sont pas partagés avec d'autres organisations. Toutes les ressources, telles que les projets, les clusters et les services, appartiennent à une organisation plutôt qu'à leurs créateurs. Par conséquent, les ressources ne sont pas supprimées si l'utilisateur qui les a créées quitte l'organisation. En revanche, tous les types de ressources suivent le cycle de vie de l'organisation. Pour en savoir plus, consultez la hiérarchie des ressources GDC.
Connectivité réseau externe
Pour être utile, une organisation a besoin d'être connectée à des réseaux externes. Cela permet aux administrateurs de plate-forme (AP) et aux opérateurs d'application (OA) de gérer l'organisation et ses ressources, et aux utilisateurs finaux de consommer les services déployés dans celle-ci. Dans GDC, toute connectivité externe est fournie par des interconnexions.
Lorsqu'une organisation est créée, elle n'est pas automatiquement associée à un réseau. En tant qu'opérateur, vous devez effectuer des étapes de configuration supplémentaires pour associer une organisation à une interconnexion existante ou en provisionner une nouvelle et dédiée. Cela implique généralement :
- Ajouter l'organisation à un
AttachmentGroup. - Créer des ressources
Interconnectpour de nouvelles connexions physiques ou logiques. - Définir des ressources
RoutePolicypour annoncer les routes réseau de l'organisation au réseau externe.
Les organisations offrent des fonctionnalités réseau améliorées, y compris la possibilité pour les organisations disposant d'interconnexions dédiées d'utiliser des adresses IP externes qui se chevauchent, ce qui simplifie la gestion des adresses IP.
Pour obtenir des informations détaillées sur les concepts et les procédures de configuration, consultez la présentation d'Interconnect.
Modèles de connectivité d'interconnexion
Les interconnexions GDC sont compatibles avec deux configurations principales qui correspondent à différentes exigences en matière de sécurité et de gestion des adresses IP.
Connectivité réseau externe partagée
Ce modèle permet à plusieurs organisations de se connecter à une zone GDC via un réseau externe commun. Dans cette configuration, l'opérateur d'infrastructure (IO) gère généralement la connexion physique et l'appairage BGP. Une exigence clé est que les adresses IP externes utilisées par chaque organisation doivent être uniques sur le réseau partagé. Ce modèle est plus simple à gérer pour les environnements avec un domaine de confiance commun.
Connectivité réseau externe dédiée
Ce modèle s'adresse aux organisations qui ont besoin d'un degré d'isolation plus élevé et qui se connectent à un réseau externe distinct. Grâce à une connectivité dédiée, le PA peut gérer le peering BGP, ce qui lui offre plus de contrôle.
L'un des principaux avantages de ce modèle est la possibilité pour les organisations d'utiliser des adresses IP externes qui se chevauchent. Cette fonctionnalité simplifie la gestion des adresses IP en supprimant la nécessité de résoudre les conflits de plages d'adresses IP pour tous les locataires de l'univers GDC.
Pour obtenir des informations détaillées sur les concepts et les procédures de configuration, consultez la présentation de l'interconnexion.
Architectures d'organisation
GDC propose deux architectures pour les organisations :
- Architecture de l'organisation GDC sous air gap (version 1)
- Architecture GDC air-gapped Org v2 (organisation v2)
En apparence, les organisations dotées de l'une ou l'autre architecture sont provisionnées, utilisées et exploitées de manière similaire. Toutefois, les architectures de cluster, de réseau et de stockage sous-jacentes sont différentes pour chaque type d'organisation.
Architecture de l'organisation GDC sous air gap v1
Une organisation v1 se compose de deux clusters :
- Cluster d'administrateur de l'organisation : exécute les composants du plan de contrôle des services gérés et Marketplace pour l'organisation. Il héberge également certains services d'infrastructure essentiels.
- Cluster système : exécute les charges de travail des machines virtuelles (VM) et certaines charges de travail du plan de données des services gérés pour l'organisation. Le nombre de nœuds de calcul dépend de l'utilisation du cluster.
Le PA et l'AO sont parfois nécessaires pour accéder à ces types de clusters afin de déployer des charges de travail et de gérer le système.
Le stockage des clusters virtuels est géré par un pilote CSI spécifique au fournisseur à l'intérieur du cluster.
Architecture GDC sous air gap Org v2
Une organisation v2 se compose d'un cluster appelé cluster d'infrastructure d'organisation, qui exécute les composants du plan de contrôle et du plan de données de l'organisation. Ce cluster héberge également le serveur d'API de gestion sur lequel tous les services et charges de travail non conteneurisés sont déployés. Le serveur de l'API Management fournit une couche permettant aux administrateurs de projet et aux administrateurs d'organisation de déployer des charges de travail, mais pas d'interagir directement avec le cluster d'infrastructure de l'organisation.
Le stockage des clusters virtuels est géré par un pilote CSI proxy qui permet au pilote CSI du cluster d'infrastructure de l'organisation de gérer les opérations.
Les composants Mise en réseau, y compris la gestion des adresses IP, le reroutage d'entrée et de sortie, et la structure VRF, offrent des améliorations par rapport à l'architecture de l'organisation v1 pour la sécurité et la facilité d'utilisation du système.
Nouveautés pour les organisations de la version 2
L'architecture de l'organisation v2 introduit des modifications dans plusieurs composants par rapport à l'architecture de l'organisation v1.
Architecture de l'API et du cluster
L'architecture de l'organisation v2 ne fournit qu'un seul cluster pour l'organisation, au lieu des deux clusters fournis dans l'architecture précédente. La réduction du nombre de clusters permet une utilisation plus élastique des ressources matérielles.
Il existe également une séparation réseau entre le plan de contrôle et le plan de données, qui n'était pas disponible pour les organisations de la version 1. Le serveur de l'API de gestion, ou plan de contrôle, peut désormais être exposé sur un réseau client différent de celui auquel le plan de données est exposé. Cette séparation offre une couche d'isolation supplémentaire facultative entre le provisionnement des ressources cloud et leur consommation. Vos administrateurs et développeurs doivent être connectés aux deux réseaux externes.
Stockage
La nouvelle architecture d'organisation v2 supprime les identifiants de stockage NetApp du cluster utilisateur en déployant le pilote CSI KubeVirt au lieu du pilote CSI NetApp Trident qui était utilisé dans l'architecture précédente. Cette mise à jour du pilote CSI réduit davantage les droits d'accès direct aux baies de stockage.
Mise en réseau
Les améliorations réseau suivantes sont disponibles pour les organisations v2 :
- Chiffrement de nœud à nœud
- Cluster dédié à la gestion du trafic réseau
- Mise en réseau simplifiée des VM
- Utilisation et gestion plus efficaces des adresses IP
Chiffrement de nœud à nœud
L'architecture d'organisation v2 fournit un chiffrement entre les nœuds bare metal de l'organisation afin que tout le trafic réseau des clients soit chiffré lorsqu'il quitte le nœud physique. Cela empêche les commutateurs réseau d'avoir une visibilité sur le trafic non chiffré.
Cluster dédié à la gestion du trafic réseau
Le cluster de périmètre est un cluster virtuel évolutif qui gère tout le trafic entrant et sortant (nord/sud) de l'organisation. Ce cluster permet également à votre univers GDC de passer à des options de système virtuel de détection et de prévention des intrusions (IDPS) plus évolutives à l'avenir.
Mise en réseau simplifiée des VM
L'architecture de l'organisation v2 fait converger deux interfaces par VM de l'architecture précédente vers une seule interface. Les VM sont déplacées vers un modèle de réseau de cloud privé virtuel (VPC) par défaut, ce qui signifie qu'elles sont connectées au réseau au niveau de la couche 3 (L3).
Les clients peuvent également définir leurs propres sous-réseaux, ce qui n'est pas compatible avec les organisations v1.
Utilisation et gestion efficaces des adresses IP
L'architecture d'organisation v2 autorise les adresses IP externes qui se chevauchent pour les organisations. Les adresses IP externes qui se chevauchent permettent aux organisations de se connecter directement aux réseaux des clients, ce qui élimine le besoin d'un grand espace d'adresses IP externes unique aligné sur toutes les organisations de l'univers GDC.
Les adresses IP sont également fournies par organisation au lieu d'être ancrées à un seul sous-réseau parent à portée zonale. Cette fonctionnalité permet aux administrateurs de spécifier leurs propres adresses IP, au lieu de vous demander, en tant qu'opérateur, d'en spécifier une. Cette fonctionnalité offre une meilleure élasticité et isolation aux organisations qui souhaitent une forte isolation du réseau en ne partageant pas de supernet parent.
Pour les organisations v1, une adresse IP NAT de sortie était requise par projet, par cluster utilisateur et par organisation. Pour les organisations v2, cette exigence est considérablement améliorée et passe à une par projet et par organisation. Cette modification permet d'utiliser plus efficacement les adresses IP fournies par les clients.
Différences fonctionnelles entre les organisations v1 et v2
Une organisation de version 2 offre les mêmes fonctionnalités qu'une organisation de version 1. Les seules fonctionnalités qui ne sont pas disponibles dans une organisation de version 2 sont les suivantes :
- Vertex AI
- CLI du service de base de données
Quelle architecture les organisations multizones utiliseront-elles ?
Dans un univers GDC multizone, si vous étendez une organisation existante à une nouvelle zone, l'organisation de la nouvelle zone doit utiliser la même architecture que la zone existante. Par conséquent, l'utilisation de différentes architectures d'organisation par zone n'est pas acceptée.
Provisionner une organisation v2
Lorsque vous provisionnez une organisation, les organisations V2 sont créées par défaut pour les clients non soumis à des procédures d'accréditation.
Toutefois, les organisations v2 apportent un changement architectural important. Pour les déploiements clients soumis à accréditation, l'architecture d'organisation v1 reste la valeur par défaut jusqu'à ce que l'architecture d'organisation v2 soit accréditée.
L'architecture par défaut de l'organisation est contrôlée par un indicateur de fonctionnalité configuré lorsque vous déployez une zone.
Forcer l'architecture de l'organisation
Dans de rares cas, vous pouvez remplacer le comportement de provisionnement par défaut et choisir d'imposer une architecture d'organisation spécifique en ajoutant le champ spec.compatibilityOptions.architectureOverridePolicy à votre ressource Organization lors du processus de provisionnement. Pour en savoir plus, consultez la page Créer une organisation client.
Il est déconseillé de remplacer l'architecture par défaut de votre organisation, sauf si vous avez une bonne raison de forcer un comportement spécifique.
Par exemple, vous pouvez forcer une organisation v1 si vous rencontrez un problème important avec une organisation v2 qui bloque une tâche. De même, vous pouvez forcer une organisation v2 si vous avez besoin d'une accréditation et d'une seule organisation v2 pour lancer le processus d'accréditation. Ces indicateurs de remplacement doivent être supprimés lorsqu'ils ne sont plus strictement nécessaires pour éviter le provisionnement futur de l'organisation avec la mauvaise architecture.
Qu'adviendra-t-il des organisations v1 existantes ?
Les organisations existantes créées avant GDC air-gapped 1.14.2 conservent la même architecture, même si la zone GDC est mise à niveau vers la version 1.14.2 ou ultérieure. Bien qu'aucune mise à niveau sur place ne soit disponible pour convertir les organisations v1 en organisations v2, les fonctionnalités existantes dans les organisations v1 continueront d'être prises en charge jusqu'à la future obsolescence de l'architecture des organisations v1.
Il est possible que les nouvelles fonctionnalités ne soient ajoutées qu'aux organisations v2. Nous vous recommandons donc de migrer vos charges de travail de vos organisations v1 vers la nouvelle architecture d'organisation v2 dès que possible. Un seul univers GDC isolé peut contenir simultanément les deux architectures d'organisation, ce qui facilite la transition.