Ce guide décrit l'architecture de référence utilisée pour déployer GDCV pour Bare Metal. Ce guide est destiné aux administrateurs de plate-forme qui souhaitent déployer GKE Enterprise sur une plate-forme Bare Metal dans une configuration géographique redondante à haute disponibilité. Pour mieux comprendre ce guide, vous devez maîtriser les concepts de base de GKE Enterprise, comme décrit dans la présentation technique de GKE Enterprise. Vous devez également connaître les concepts de base de Kubernetes et de Google Kubernetes Engine (GKE), comme décrit dans les principes de base de Kubernetes et la documentation GKE.
Ce guide propose un dépôt source GitHub qui inclut des scripts permettant de déployer l'architecture décrite. Ce guide décrit également les composants d'architecture qui accompagnent les scripts et les modules utilisés pour créer ces composants. Nous vous recommandons d'utiliser ces fichiers comme modèles pour créer des modules basés sur les bonnes pratiques et les règles de votre organisation.
GDCV pour le modèle d'architecture Bare Metal
Dans le guide "GKE Enterprise Architecture Foundations", l'architecture de la plate-forme est décrite en couches. Les ressources de chaque couche fournissent un ensemble spécifique de fonctions. Ces ressources sont détenues et gérées par un ou plusieurs personas. Comme le montre le schéma suivant, l'architecture de la plate-forme GKE Enterprise pour Bare Metal se compose des couches et des ressources suivantes :
- Infrastructure : cette couche comprend le stockage, le calcul et la mise en réseau, gérés à l'aide de constructions sur site.
- Gestion des données : dans le cadre de ce guide, la couche de gestion des données nécessite une base de données SQL gérée en dehors des clusters Kubernetes déployés.
- Couche de gestion des conteneurs : cette couche utilise des clusters GKE.
- Couche de gestion des services : cette couche utilise Anthos Service Mesh.
- Couche de gestion des règles : cette couche utilise Config Sync et Policy Controller.
- Couche de gestion des applications : cette couche utilise Cloud Build et Cloud Source Repositories.
- Couche d'observabilité : cette couche utilise les tableaux de bord de Google Cloud Observability et d'Anthos Service Mesh.
Chacune de ces couches est répétée dans la pile pour différents environnements de cycle de vie, tels que le développement, la préproduction et la production.
Les sections suivantes ne contiennent que des informations supplémentaires spécifiques à GDCV sur Bare Metal. Elles s'appuient sur leurs sections respectives dans le guide "GKE Enterprise Architecture Foundations". Nous vous recommandons de consulter le guide lorsque vous lisez cet article.
Mise en réseau
Pour en savoir plus sur les exigences de la configuration du réseau, consultez la section Configuration réseau requise.
Pour les équilibreurs de charge GDCV sur Bare Metal, deux options sont disponibles : groupée et manuelle.
En mode groupé, le logiciel d'équilibrage de charge L4 est déployé lors de la création du cluster. Les processus de l'équilibreur de charge peuvent s'exécuter sur un pool de nœuds de calcul dédié ou sur les mêmes nœuds que le plan de contrôle. Pour annoncer des adresses IP virtuelles, cet équilibreur de charge propose deux options :
- Protocole ARP (Address Resolution Protocol) : nécessite une connectivité de couche 2 entre les nœuds exécutant l'équilibreur de charge.
- Protocole BGP (Border Gateway Protocol) : utilise l'appairage pour connecter votre réseau de cluster (un système autonome) à un autre système autonome, tel qu'un réseau externe.
En mode manuel, vous configurez vos propres solutions d'équilibrage de charge pour le trafic du plan de contrôle et du plan de données. De nombreuses options matérielles et logicielles sont disponibles pour les équilibreurs de charge externes. Vous devez configurer un équilibreur de charge externe pour le plan de contrôle avant de créer un cluster Bare Metal. L'équilibreur de charge du plan de contrôle externe peut également être utilisé pour le trafic du plan de données, ou vous pouvez configurer un équilibreur de charge distinct pour le plan de données. Pour déterminer la disponibilité, l'équilibreur de charge doit pouvoir distribuer le trafic vers un pool de nœuds en fonction d'une vérification d'aptitude configurable.
Pour en savoir plus sur les équilibreurs de charge pour GDCV sur Bare Metal, consultez la page Présentation des équilibreurs de charge.
Architecture d'un cluster
GDCV sur Bare Metal est compatible avec plusieurs modèles de déploiement, ce qui permet de répondre à différents besoins en matière de disponibilité, d'isolation et d'empreinte des ressources. Ces modèles de déploiement sont abordés dans la section Choisir un modèle de déploiement.
Gestion des identités
GDCV sur Bare Metal utilise GKE Identity Service pour s'intégrer aux fournisseurs d'identité. Il est compatible avec OpenID Connect (OIDC) ainsi qu'avec le protocole LDAP (Lightweight Directory Access Protocol). Pour les applications et les services, Anthos Service Mesh peut être utilisé avec diverses solutions d'identité.
Pour en savoir plus sur la gestion des identités, consultez les pages suivantes : Gestion des identités avec OIDC dans GDCV sur Bare Metal et Procéder à l'authentification à l'aide d'OIDC ouConfigurer Anthos Identity Service avec LDAP.
Sécurité et gestion des règles
En ce qui concerne la sécurité et la gestion des règles pour GDCV sur Bare Metal, nous vous recommandons d'utiliser Config Sync et Policy Controller. Policy Controller vous permet de créer et d'appliquer des règles à vos clusters. Config Sync évalue les modifications et les applique à tous les clusters afin d'obtenir l'état approprié.
Services
Lorsque vous utilisez le mode groupé de GDCV pour Bare Metal pour l'équilibrage de charge, vous pouvez créer des services de type LoadBalancer. Lorsque vous créez ces services, GDCV sur Bare Metal attribue aux services une adresse IP à partir du pool d'adresses IP de l'équilibreur de charge configuré. Le type de service LoadBalancer permet d'exposer le service Kubernetes en dehors du cluster pour le trafic nord-sud.
Lors de l'utilisation de GDCV sur Bare Metal, un IngressGateway est également créé par défaut dans le cluster. Vous ne pouvez pas créer de services de type LoadBalancer pour GDCV sur Bare Metal en mode manuel. À la place, vous pouvez créer un objet Ingress qui utilise le composant IngressGateway ou créer des services de type NodePort et configurer manuellement votre équilibreur de charge externe pour utiliser le service Kubernetes comme backend.
Pour Service Management, également appelé trafic est-ouest, nous vous recommandons d'utiliser Anthos Service Mesh. Anthos Service Mesh est basé sur les API ouvertes d'Istio et offre une observabilité uniforme, l'authentification, le chiffrement, des contrôles précis du trafic ainsi que d'autres fonctionnalités et fonctions. Pour en savoir plus sur Service Management, consultez la page Anthos Service Mesh.
Persistance et gestion de l'état
GDCV sur Bare Metal dépend en grande partie de l'infrastructure existante pour le stockage éphémère, le stockage de volumes et le stockage PersistentVolume. Les données éphémères utilisent les ressources du disque local sur le nœud sur lequel le pod Kubernetes est planifié. Pour les données persistantes, GKE Enterprise est compatible avec l'interface de stockage de conteneurs (CSI), une API standard ouverte compatible avec de nombreux fournisseurs de stockage. Pour le stockage en production, nous vous recommandons d'installer un pilote CSI à partir d'un partenaire de stockage GKE Enterprise Ready. Pour obtenir la liste complète des partenaires de stockage GKE Enterprise Ready, consultez la page Partenaires de stockage GKE Enterprise Ready.
Pour en savoir plus sur le stockage, consultez la page Configurer le stockage.
Bases de données
GDCV sur Bare Metal ne fournit pas de fonctionnalités supplémentaires spécifiques à la base de données, en plus des fonctionnalités standards de la plate-forme GKE Enterprise. La plupart des bases de données s'exécutent sur un système de gestion de données externe. Les charges de travail sur la plate-forme GKE Enterprise peuvent également être configurées pour se connecter à n'importe quelle base de données externe accessible.
Observabilité
Google Cloud Observability collecte les journaux et les métriques de surveillance des clusters GDCV sur Bare Metal de manière semblable aux règles de collecte et de surveillance des clusters GKE. Par défaut, les journaux de cluster et les métriques de composants système sont envoyés à Cloud Monitoring.
Pour que Google Cloud Observability collecte les journaux et les métriques d'application, activez l'option clusterOperations.enableApplication dans le fichier YAML de configuration du cluster.
Pour en savoir plus sur l'observabilité, consultez la page Configurer la journalisation et la surveillance.
Cas d'utilisation : déploiement de Cymbal Bank
Dans ce guide, l'application Cymbal Bank/Bank of Anthos permet de simuler la planification, le déploiement de plate-forme et le processus de déploiement de l'application pour GDCV sur Bare Metal.
Le reste de ce document se compose de trois sections. La section Planification décrit les décisions prises en fonction des options décrites dans les sections des modèles d'architecture. La section Déploiement de plate-forme traite des scripts et des modules fournis par un dépôt source pour déployer la plate-forme GKE Enterprise. Enfin, dans la section Déploiement d'application, l'application Cymbal Bank est déployée sur la plate-forme.
Ce guide GDCV sur Bare Metal peut être utilisé pour le déploiement sur des hôtes autogérés ou des instances Compute Engine. À l'aide des ressources Google Cloud, n'importe qui peut suivre ce guide sans avoir besoin d'accéder au matériel physique. L'utilisation des instances Compute Engine n'est fournie qu'à titre de démonstration. N'utilisez PAS ces instances pour les charges de travail de production. Lorsque l'accès au matériel physique est disponible et que les mêmes plages d'adresses IP sont employées, vous pouvez utiliser le dépôt source fourni en l'état. Si l'environnement diffère de celui décrit dans la section Planification, vous pouvez modifier les scripts et les modules en conséquence. Le dépôt source associé contient des instructions pour les scénarios de matériel physique et d'instance Compute Engine.
Planification
La section suivante présente en détail les décisions architecturales prises lors de la planification et de la conception de la plate-forme pour le déploiement de l'application Bank of GKE Enterprise sur GDCV sur Bare Metal. Ces sections portent sur un environnement de production. Pour créer des environnements inférieurs tels que le développement ou la préproduction, vous pouvez utiliser des étapes similaires.
Projets Google Cloud
Lors de la création de projets dans Google Cloud pour GDCV sur Bare Metal, un projet hôte de parc est requis. Des projets supplémentaires sont recommandés pour chaque environnement ou fonction métier. Cette configuration de projet vous permet d'organiser les ressources en fonction du persona qui interagit avec elles.
Les sous-sections suivantes abordent les types de projet recommandés et les personas associés.
Projet de hub
Le projet de hub hub-prod est destiné aux administrateurs réseau. C'est dans ce projet que le centre de données sur site est connecté à Google Cloud, au moyen de la forme de connectivité hybride que vous avez sélectionnée. Pour en savoir plus sur les options de connectivité hybride, consultez la page Connectivité Google Cloud.
Projet hôte du parc
Le projet hôte du parc fleet-prod est destiné aux administrateurs de la plate-forme. Le projet est l'emplacement où les clusters GDCV sur Bare Metal sont enregistrés. Ce projet est également l'emplacement où se trouvent les ressources Google Cloud liées à la plate-forme. Ces ressources incluent Google Cloud Observability, Cloud Source Repositories, etc. Un projet Google Cloud donné ne peut être associé qu'à un seul parc (ou à aucun parc). Cette restriction renforce l'utilisation des projets Google Cloud pour assurer une isolation plus forte entre les ressources qui ne sont pas contrôlées ni consommées conjointement.
Projet d'application ou d'équipe
Le projet d'application ou d'équipe app-banking-prod est destiné aux développeurs. C'est dans ce projet que sont hébergées les ressources Google Cloud spécifiques à l'application ou à l'équipe. Le projet comprend tout, sauf les clusters GKE. En fonction du nombre d'équipes ou d'applications, il peut y avoir plusieurs instances de ce type de projet. La création de projets distincts pour différentes équipes vous permet de gérer séparément IAM, la facturation et les quotas pour chaque équipe.
Mise en réseau
Chaque cluster GDCV sur Bare Metal nécessite les sous-réseaux d'adresse IP suivants :
- Adresses IP des nœuds
- Adresses IP des pods Kubernetes
- Adresses IP du service/cluster Kubernetes
- Adresses IP des équilibreurs de charge (mode groupé)
Pour utiliser les mêmes plages d'adresses IP ne pouvant pas être routées pour les sous-réseaux de pod et de service Kubernetes de chaque cluster, sélectionnez une modèle réseau en mode île. Dans cette configuration, les pods peuvent communiquer directement entre eux au sein d'un cluster, mais ils ne sont pas accessibles directement depuis l'extérieur d'un cluster (à l'aide d'adresses IP de pod). Cette configuration forme une "île" au sein du réseau, qui n'est pas connectée au réseau externe. Les clusters forment un maillage de nœud à nœud complet entre les nœuds de cluster, ce qui permet à un pod d'atteindre directement les autres pods du cluster.
Attribution d'adresses IP
| Cluster | Nœud | Pod | Services | Équilibreur de charge |
|---|---|---|---|---|
| metal-admin-dc1-000-prod | 10.185.0.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | Non disponible |
| metal-user-dc1a-000-prod | 10.185.1.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | 10.185.1.3-10.185.1.10 |
| metal-user-dc1b-000-prod | 10.185.2.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | 10.185.2.3-10.185.2.10 |
| metal-admin-dc2-000-prod | 10.195.0.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | Non disponible |
| metal-user-dc2a-000-prod | 10.195.1.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | 10.195.1.3-10.195.1.10 |
| metal-user-dc2b-000-prod | 10.195.2.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | 10.195.2.3-10.195.2.10 |
En mode île, il est important de s'assurer que les sous-réseaux d'adresses IP choisis pour les pods et les services Kubernetes ne sont pas utilisés ou routables depuis le réseau de nœuds.
Configuration réseau requise
Afin de fournir un équilibreur de charge intégré pour GDCV sur Bare Metal qui ne nécessite aucune configuration, utilisez le mode d'équilibrage de charge groupé dans chaque cluster. Lorsque les charges de travail exécutent des services LoadBalancer, une adresse IP est attribuée à partir du pool d'équilibreur de charge.
Pour lire des informations détaillées sur les exigences et la configuration de l'équilibreur de charge groupé, consultez les pages Présentation des équilibreurs de charge et Configurer un équilibrage de charge groupé.
Architecture d'un cluster
Pour un environnement de production, nous vous recommandons d'utiliser un modèle de déploiement avec cluster d'administrateur et cluster d'utilisateur, avec un cluster d'administrateur et deux clusters d'utilisateur dans chaque emplacement géographique, afin d'obtenir la plus grande redondance et tolérance aux défaillances possibles dans GDCV sur Bare Metal.
Nous vous recommandons d'utiliser au moins quatre clusters d'utilisateur pour chaque environnement de production. Utilisez deux emplacements géographiquement redondants qui contiennent chacun deux clusters tolérants aux pannes. Chaque cluster tolérant aux pannes présente du matériel redondant et des connexions réseau redondantes. La diminution du nombre de clusters réduit la redondance ou la tolérance aux pannes de l'architecture.
Pour assurer la haute disponibilité, le plan de contrôle de chaque cluster utilise trois nœuds. Avec un minimum de trois nœuds de calcul par cluster d'utilisateur, vous pouvez répartir les charges de travail entre ces nœuds afin de réduire l'impact si un nœud se déconnecte. Le nombre et le dimensionnement des nœuds de calcul dépendent en grande partie du type et du nombre de charges de travail qui s'exécutent dans le cluster. Le dimensionnement recommandé pour chacun des nœuds est décrit dans la section Configurer le matériel pour GDCV sur Bare Metal.
Le tableau suivant indique le dimensionnement des nœuds recommandé pour les cœurs de processeur, la mémoire et le stockage sur disque local dans ce cas d'utilisation.
| Type de nœud | Processeurs/processeurs virtuels | Mémoire | Stockage |
|---|---|---|---|
| Plan de contrôle | 8 cœurs | 32 Gio | 256 Gio |
| Nœud de calcul | 8 cœurs | 64 Gio | 512 Gio |
Pour en savoir plus sur les prérequis et le dimensionnement des machines, consultez la page Prérequis pour les machines du nœud de cluster.
Gestion des identités
Pour la gestion des identités, nous vous recommandons une intégration d'OIDC via GKE Identity Service. Dans les exemples fournis dans le dépôt source, l'authentification locale est utilisée pour simplifier les exigences. Si OIDC est disponible, vous pouvez modifier l'exemple pour l'utiliser. Pour en savoir plus, consultez la page Gestion des identités avec OIDC dans GDCV sur Bare Metal.
Sécurité et gestion des règles
Dans le cas d'utilisation de Cymbal Bank, Config Sync et Policy Controller sont utilisés pour la gestion des règles. Un dépôt Cloud Source Repositories est créé pour stocker les données de configuration utilisées par Config Sync. L'opérateur ConfigManagement, utilisé pour installer et gérer Config Sync et Policy Controller, a besoin d'un accès en lecture seule au dépôt source de configuration. Pour accorder cet accès, utilisez une forme d'authentification acceptable. Dans cet exemple, un compte de service Google est utilisé.
Services
Dans le cas présent, Anthos Service Mesh fournit une base sur laquelle les services distribués sont construits. Par défaut, un IngressGateway est également créé dans le cluster qui gère les objets Ingress Kubernetes standards.
Persistance et gestion de l'état
Comme le stockage persistant dépend en grande partie de l'infrastructure existante, il n'est pas nécessaire pour ce cas d'utilisation. Dans d'autres cas, nous vous suggérons d'utiliser les options de stockage des partenaires de stockage GKE Enterprise. Si une option de stockage CSI est disponible, vous pouvez l'installer sur le cluster en suivant les instructions du fournisseur. Pour la démonstration de faisabilité et des cas d'utilisation avancés, vous pouvez utiliser des volumes locaux. Toutefois, dans la plupart des cas, nous vous déconseillons d'utiliser des volumes locaux dans les environnements de production.
Bases de données
De nombreuses applications avec état sur GDCV sur Bare Metal utilisent des bases de données comme magasin de persistance. Une application de base de données avec état doit avoir accès à une base de données pour fournir sa logique métier aux clients. Il n'existe aucune restriction quant au type de datastore utilisé par GDCV sur Bare Metal. Les décisions concernant le stockage des données doivent donc être prises par le développeur ou par les équipes de gestion de données associées. Étant donné que différentes applications peuvent nécessiter différents datastores, ceux-ci peuvent également être utilisés sans restriction. Les bases de données peuvent être gérées dans un cluster, sur site ou même dans le cloud.
L'application Cymbal Bank est une application avec état qui accède à deux bases de données PostgreSQL. L'accès à la base de données est configuré via des variables d'environnement. La base de données PostgreSQL doit être accessible à partir des nœuds exécutant les charges de travail, même si elle est gérée en externe depuis le cluster. Dans cet exemple, l'application accède à une base de données PostgreSQL externe existante. Pendant que l'application s'exécute sur la plate-forme, la base de données est gérée en externe. Par conséquent, la base de données ne fait pas partie de la plate-forme GKE Enterprise. Si une base de données PostgreSQL est disponible, utilisez-la. Si ce n'est pas le cas, créez et utilisez une base de données Cloud SQL pour l'application Cymbal Bank.
Observabilité
Chaque cluster du cas d'utilisation Cymbal Bank est configuré pour que Google Cloud Observability collecte les journaux et les métriques des composants système et des applications. Le programme d'installation de Google Cloud Console contient plusieurs tableaux de bord Cloud Monitoring, que vous pouvez afficher depuis la page Tableaux de bord Monitoring. Pour plus d'informations sur l'observabilité, consultez les pages Configurer la journalisation et la surveillance et Fonctionnement de Logging et Monitoring pour GDCV sur Bare Metal.
Déploiement de plate-forme
Pour en savoir plus, consultez la section Déployer la plate-forme de la documentation dans le dépôt source GitHub.
Déploiement d'applications
Pour en savoir plus, consultez la section Déployer l'application de la documentation dans le dépôt source GitHub.
Étapes suivantes
- Apprenez-en davantage sur Anthos Service Mesh, Config Sync et Policy Controller.
- Découvrez d'autres architectures de référence GKE Enterprise.
- Essayez GKE Enterprise sur Google Cloud avec l'exemple de déploiement GKE Enterprise.
- Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.