Architecture de référence GKE Enterprise : Google Distributed Cloud Virtual pour Bare Metal

Last reviewed 2023-08-15 UTC

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 :

Modèle mental de GDCV sur Bare Metal montrant les couches abordées dans le document.

  1. Infrastructure : cette couche comprend le stockage, le calcul et la mise en réseau, gérés à l'aide de constructions sur site.
  2. 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.
  3. Couche de gestion des conteneurs : cette couche utilise des clusters GKE.
  4. Couche de gestion des services : cette couche utilise Anthos Service Mesh.
  5. Couche de gestion des règles : cette couche utilise Config Sync et Policy Controller.
  6. Couche de gestion des applications : cette couche utilise Cloud Build et Cloud Source Repositories.
  7. 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 :

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 :

  1. Adresses IP des nœuds
  2. Adresses IP des pods Kubernetes
  3. Adresses IP du service/cluster Kubernetes
  4. 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 environnem