Cette section décrit les contrôles utilisés sur la plate-forme de développement.
Identités, rôles et groupes de la plate-forme
L'accès aux services Google Cloud nécessite des identités Google Cloud. Le plan utilise la fonctionnalité Workload Identity du parc pour mettre en correspondance les comptes de service Kubernetes utilisés comme identités pour les pods, et les comptes de service Google Cloud qui contrôlent l'accès aux services Google Cloud. Pour vous protéger contre les escalades entre environnements, chaque environnement dispose d'un pool d'identité distinct (appelé ensemble de fournisseurs d'identité de confiance) pour ses comptes Workload Identity.
Personas de la plate-forme
Lorsque vous déployez le plan, vous créez trois types de groupes d'utilisateurs : une équipe en charge de la plate-forme de développement, une équipe de développement (une équipe par application) et une équipe de gestion des opérations de sécurité.
L'équipe en charge de la plate-forme de développement est responsable du développement et de la gestion de cette plate-forme. Les membres de cette équipe sont les suivants :
- Développeurs de la plate-forme de développement : ces membres de l'équipe développent le plan et l'intègrent aux systèmes existants. Cette équipe crée également des modèles d'application.
- Administrateur de la plate-forme de développement : cette équipe se charge des opérations suivantes :
- Approuver la création de nouvelles équipes de locataires
- Effectuer des tâches planifiées et non planifiées qui affectent plusieurs locataires, y compris :
- Approuver la promotion d'applications dans l'environnement hors production et l'environnement de production
- Coordonner les mises à jour de l'infrastructure
- Créer des plans de capacité au niveau de la plate-forme
Un locataire de la plate-forme de développement correspond à une équipe de développement logiciel qui est responsable du fonctionnement du logiciel. L'équipe locataire est composée de deux groupes : les développeurs d'applications et les opérateurs d'applications. Les tâches des deux groupes de l'équipe locataire sont les suivantes :
- Développeurs d'applications : cette équipe écrit et débogue le code d'application. Ils sont également appelés ingénieurs logiciels ou développeurs full stack. Voici quelques responsabilités qui leur sont imputées :
- Effectuer des tests et des contrôles d'assurance qualité sur un composant d'application lors de son déploiement dans l'environnement de développement
- Gérer les ressources cloud appartenant à l'application (telles que les bases de données et les buckets de stockage) dans l'environnement de développement
- Concevoir des schémas pour les bases de données ou le stockage qui seront utilisés par des applications
- Opérateurs d'applications ou ingénieurs en fiabilité des sites (SRE) : cette équipe gère la fiabilité des applications exécutées dans les environnements de production, tout en assurant une mise en production sécurisée des modifications apportées par les développeurs d'applications. Ils sont parfois appelés opérateurs de service, ingénieurs système ou administrateurs système. Voici quelques responsabilités qui leur sont imputées :
- Planifier les besoins en capacité au niveau de l'application
- Créer des règles d'alerte et définir des objectifs de niveau de service (SLO) pour les services
- Diagnostiquer les problèmes liés aux services à l'aide des journaux et des métriques spécifiques à cette application
- Répondre aux alertes et aux pages, par exemple lorsqu'un service ne respecte pas ses SLO
- Travailler avec un groupe ou plusieurs groupes de développeurs d'applications
- Approuver le déploiement de nouvelles versions en production
- Gérer les ressources cloud appartenant à l'application dans des environnements hors production et de production (par exemple, des sauvegardes et des mises à jour de schémas)
Structure organisationnelle de la plate-forme
Le plan d'application d'entreprise utilise la structure organisationnelle fournie par le plan de base de l'entreprise. Le schéma suivant montre comment les projets du plan d'application d'entreprise s'intègrent à la structure du plan de base.
Projets de la plate-forme
Le tableau suivant décrit les projets autres que ceux fournis par le plan de base, dont le plan d'application a besoin pour déployer des ressources, des configurations et des applications.
| Dossier | Projet | Description |
|---|---|---|
|
|
Contient le pipeline d'infrastructure mutualisée permettant de déployer l'infrastructure locataire. |
|
Contient la fabrique d'applications, qui permet de créer une architecture d'application à locataire unique, et des pipelines d'intégration et de déploiement continus (CI/CD). Ce projet contient également Config Sync qui permet de configurer le cluster GKE. |
|
|
Contient les pipelines CI/CD de l'application, qui se trouvent dans des projets indépendants afin de distinguer les équipes de développement. Il existe un pipeline pour chaque application. |
|
|
|
Contient les clusters GKE pour la plate-forme de développement et la logique utilisée pour enregistrer des clusters pour la gestion de parc. |
( |
Contient des services d'application à locataire unique, tels que des bases de données ou d'autres services gérés utilisés par une équipe de développement. |
Architecture des clusters de la plate-forme
Le plan déploie les applications dans trois environnements : développement, hors production et production. Chaque environnement est associé à un parc. Dans ce plan, un parc est un projet qui inclut un ou plusieurs clusters. Toutefois, les parcs peuvent également regrouper plusieurs projets. Un parc fournit une limite de sécurité logique pour le contrôle administratif. Un parc permet de regrouper et de normaliser des clusters Kubernetes de manière logique, et facilite l'administration de l'infrastructure.
Le schéma suivant montre deux clusters GKE créés dans chaque environnement pour déployer des applications. Les deux clusters agissent comme des clusters GKE identiques dans deux régions différentes afin d'offrir une résilience multirégionale. Pour exploiter les fonctionnalités du parc, le plan utilise le concept d'uniformité dans les objets d'espace de noms, les services et les identités.
Le plan d'application d'entreprise utilise des clusters GKE avec des espaces privés activés via l'accès Private Service Connect au plan de contrôle et les pools de nœuds privés pour supprimer les éventuelles surfaces d'attaque provenant d'Internet. Ni les nœuds du cluster, ni le plan de contrôle ne possèdent un point de terminaison public. Les nœuds des clusters exécutent Container-Optimized OS pour limiter la surface d'attaque, et utilisent des nœuds GKE protégés pour limiter la capacité d'un pirate informatique à usurper l'identité d'un nœud.
L'accès administrateur aux clusters GKE est activé via la passerelle Connect. Lors du déploiement du plan, une instance Cloud NAT est utilisée pour chaque environnement afin d'accorder aux pods et à Config Sync un mécanisme permettant d'accéder aux ressources sur Internet telles que GitHub. L'accès aux clusters GKE est contrôlé par une autorisation Kubernetes RBAC basée sur Google Groupes pour GKE. Les groupes vous permettent de contrôler les identités à l'aide d'un système central de gestion des identités contrôlé par les administrateurs d'identité.
Composants GKE Enterprise de la plate-forme
La plate-forme de développement utilise des composants GKE Enterprise pour vous permettre de créer, de diffuser et de gérer le cycle de vie de vos applications. Les composants GKE Enterprise utilisés dans le déploiement du plan sont les suivants :
- GKE pour la gestion des conteneurs
- Policy Controller pour la gestion et l'application des règles
- Anthos Service Mesh pour la gestion des services
- Autorisation binaire pour l'attestation des images de conteneurs
- GKE Gateway Controller pour le contrôleur de passerelle multicluster des clusters GKE
Gestion des parcs de la plate-forme
Les parcs vous permettent de gérer plusieurs clusters GKE de manière unifiée. La gestion des équipes du parc permet aux administrateurs de plate-forme de provisionner et de gérer plus facilement les ressources d'infrastructure pour les locataires de la plate-forme de développement. Les locataires ont un contrôle limité sur les ressources de leur propre espace de noms, y compris leurs applications, leurs journaux et leurs métriques.
Pour provisionner des sous-ensembles de ressources de parc par équipe, les administrateurs peuvent utiliser les niveaux d'accès d'équipe. Les niveaux d'accès d'équipe vous permettent de définir des sous-ensembles de ressources de parc par équipe, chacun d'eux étant associé à un ou plusieurs clusters membres du parc.
Les espaces de noms du parc permettent de contrôler qui a accès à des espaces de noms spécifiques dans votre parc. L'application utilise deux clusters GKE déployés dans un parc, avec trois niveaux d'accès d'équipe comportant chacun un espace de noms du parc.
Le schéma suivant montre les ressources de parc et de niveau d'accès correspondant aux exemples de clusters dans un environnement, telles que mises en œuvre par le plan.
Mise en réseau de la plate-forme
Pour la mise en réseau, les clusters GKE sont déployés dans un VPC partagé créé dans le cadre du plan de base de l'entreprise. Les clusters GKE nécessitent l'attribution de plusieurs plages d'adresses IP dans les environnements de développement, hors production et de production. Chaque cluster GKE utilisé par le plan nécessite des plages d'adresses IP distinctes allouées aux nœuds, aux pods, aux services et au plan de contrôle. Les instances AlloyDB pour PostgreSQL requièrent également des plages d'adresses IP distinctes.
Le tableau suivant décrit les sous-réseaux VPC et les plages d'adresses IP utilisés dans les différents environnements pour déployer les clusters du plan. Pour l'environnement de développement de la région 2 du cluster GKE de l'application, le plan ne déploie qu'un seul espace d'adresses IP, même si un espace d'adresses IP est alloué aux deux clusters GKE de développement.
| Ressource | Type de plage d'adresses IP | Développement | Hors production | Production |
|---|---|---|---|---|
Région 1 du cluster GKE de l'application |
Plage d'adresses IP principale |
10.0.64.0/24 |
10.0.128.0/24 |
10.0.192.0/24 |
Plage d'adresses IP des pods |
100.64.64.0/24 |
100.64.128.0/24 |
100.64.192.0/24 |
|
Plage d'adresses IP du service |
100.0.80.0/24 |
100.0.144.0/24 |
100.0.208.0/24 |
|
Plage d'adresses IP du plan de contrôle GKE |
10.16.0.0/21 |
10.16.8.0/21 |
10.16.16.0/21 |
|
Région 2 du cluster GKE de l'application |
Plage d'adresses IP principale |
10.1.64.0/24 |
10.1.128.0/24 |
10.1.192.0/24 |
Plage d'adresses IP des pods |
100.64.64.0/24 |
100.64.128.0/24 |
100.64.192.0/24 |
|
Plage d'adresses IP du service |
100.1.80.0/24 |
100.1.144.0/24 |
100.1.208.0/24 |
|
Plage d'adresses IP du plan de contrôle GKE |
10.16.0.0/21 |
10.16.8.0/21 |
10.16.16.0/21 |
|
AlloyDB pour PostgreSQL |
Plage d'adresses IP de la base de données |
10.9.64.0/18 |
10.9.128.0/18 |
10.9.192.0/18 |
Si vous devez concevoir votre propre schéma d'allocation d'adresses IP, consultez les pages Gestion des adresses IP dans GKE et Planification des adresses IPv4 GKE.
DNS de la plate-forme
Le plan utilise Cloud DNS pour GKE afin de fournir une résolution DNS pour les pods et les services Kubernetes. Cloud DNS pour GKE est un DNS géré qui ne nécessite pas de fournisseur DNS hébergé par le cluster.
Dans le plan, Cloud DNS est configuré pour le champ d'application à l'échelle du VPC. Le champ d'application à l'échelle du VPC permet aux services de tous les clusters GKE d'un projet de partager une même zone DNS. Une seule zone DNS permet de résoudre les services sur les clusters, et les VM ou les pods en dehors du cluster peuvent résoudre les services du cluster.
Pare-feu de la plate-forme
GKE crée automatiquement des règles de pare-feu lors de la création de clusters GKE, de services GKE, de pare-feu GKE Gateway et de pare-feu GKE Ingress permettant aux clusters de fonctionner dans vos environnements. La priorité de toutes les règles de pare-feu créées automatiquement est de 1 000. Ces règles sont nécessaires, car le plan de base de l'entreprise dispose d'une règle par défaut pour bloquer le trafic dans le VPC partagé.
Accès de la plate-forme aux services Google Cloud
Étant donné que les applications de plan utilisent des clusters privés, l'accès privé à Google fournit un accès aux services Google Cloud.
Haute disponibilité de la plate-forme
Le plan a été conçu de manière à être résilient aux pannes zonales et régionales. Les ressources nécessaires au bon fonctionnement des applications sont réparties dans deux régions. Vous choisissez les régions dans lesquelles vous souhaitez déployer le plan. Les ressources qui ne se trouvent pas dans le chemin critique pour diffuser la charge et y répondre ne représentent qu'une seule région ou sont globales. Le tableau suivant décrit les ressources et l'emplacement dans lequel elles sont déployées.
Emplacement |
Région 1 |
Région 2 |
Monde |
|---|---|---|---|
Environnements avec des ressources dans cet emplacement |
|
|
|
Projets avec ressources dans cet emplacement |
|
|
|
Types de ressources dans cet emplacement |
|
|
|
Le tableau suivant récapitule la manière dont les différents composants réagissent à une panne régionale ou zonale, et comment vous pouvez atténuer ces effets.
Champ d'application de la défaillance |
Effets sur les services externes |
Effets sur la base de données | Effets sur la création et le déploiement | Effets sur les pipelines Terraform |
|---|---|---|---|---|
Une zone de la région 1 |
Disponible. |
Disponible. L'instance de secours devient active sans RPO. |
Disponible, une modification manuelle peut s'avérer nécessaire. Vous devrez peut-être redémarrer toute commande |
Disponible, une modification manuelle peut s'avérer nécessaire. Vous devrez peut-être redémarrer toute commande |
Une zone de la région 2 |
Disponible. |
Disponible. |
Disponible. |
Disponible, une modification manuelle peut s'avérer nécessaire. Vous devrez peut-être redémarrer toute commande |
Région 1 |
Disponible. |
Modification manuelle nécessaire. Un opérateur doit promouvoir le cluster secondaire manuellement. |
Indisponible. |
Indisponible. |
Région 2 |
Disponible. |
Disponible. |
Disponible, une modification manuelle peut s'avérer nécessaire. Les builds restent disponibles. Vous devrez peut-être déployer de nouveaux builds manuellement. Les builds existants risquent de ne pas aboutir. |
Disponible. |
Une interruption affectant le fournisseur de services cloud ne constitue qu'une source de temps d'arrêt. La haute disponibilité dépend également des processus et des opérations qui contribuent à réduire les risques d'erreurs. Le tableau suivant décrit toutes les décisions prises dans le plan concernant la haute disponibilité et les motifs de ces décisions.
| Décision du plan | Impact sur la disponibilité |
|---|---|
Gestion des changements |
|
Utiliser GitOps et l'IaC |
Compatible avec l'examen des modifications par des pairs et permet de rétablir rapidement les configurations précédentes. |
Promouvoir progressivement les modifications dans les environnements |
Réduit l'impact des erreurs logicielles et de configuration. |
Rendre les environnements hors production et de production similaires |
Garantit que les différences ne retardent pas la découverte d'une erreur. Les deux environnements sont birégionaux. |
Modifier les ressources répliquées dans une région à la fois dans un environnement |
Garantit que les problèmes non détectés par la promotion progressive n'affectent que la moitié de l'infrastructure d'exécution. |
Modifier un service dans une région à la fois dans un environnement |
Garantit que les problèmes non détectés par la promotion progressive n'affectent que la moitié des instances répliquées du service. |
Infrastructure de calcul répliquée |
|
Utiliser un plan de contrôle de cluster régional |
Le plan de contrôle régional est disponible lors de la mise à niveau et du redimensionnement. |
Créer un pool de nœuds multizone |
Un pool de nœuds de cluster comporte au moins trois nœuds répartis sur trois zones. |
Configurer un réseau VPC partagé |
Le réseau VPC partagé couvre deux régions. Une défaillance régionale n'affecte que le trafic réseau vers et depuis les ressources de la région défaillante. |
Répliquer le registre d'images |
Les images sont stockées dans Artifact Registry, qui est configuré pour la réplication dans plusieurs régions afin qu'une panne intervenant dans une région cloud n'empêche pas le scaling à la hausse de l'application dans la région qui subsiste. |
Services répliqués |
|
Déployer des instances répliquées de services dans deux régions |
En cas de panne régionale, un service Kubernetes reste disponible dans les environnements de production et hors production. |
Utiliser des mises à jour progressives pour modifier les services d'une région |
Vous pouvez mettre à jour les services Kubernetes à l'aide d'un modèle de déploiement par mise à jour progressive, qui réduit les risques et les temps d'arrêt. |
Configurer trois instances répliquées dans une région pour chaque service |
Un service Kubernetes comporte au moins trois instances répliquées (pods) pour assurer les mises à jour progressives dans les environnements de production et hors production. |
Répartir les pods du déploiement dans plusieurs zones |
Les services Kubernetes sont répartis sur des VM situées dans différentes zones à l'aide d'un stanza d'anti-affinité. L'interruption d'un nœud ou la panne d'une zone entière peut être tolérée sans générer de trafic interrégional supplémentaire entre les services dépendants. |
Stockage répliqué |
|
Déployer des instances de base de données multizones |
AlloyDB pour PostgreSQL offre une haute disponibilité dans une région. Les nœuds redondants de son instance principale sont situés dans deux zones différentes de la région. L'instance principale conserve la disponibilité régionale en déclenchant un basculement automatique vers la zone de secours si la zone active rencontre un problème. Le stockage régional permet de garantir la durabilité des données en cas de perte d'une zone. |
Répliquer les bases de données entre différentes régions |
AlloyDB pour PostgreSQL utilise la réplication interrégionale pour fournir des fonctionnalités de reprise après sinistre. La base de données réplique de manière asynchrone les données de votre cluster principal dans des clusters secondaires situés dans des régions Google Cloud distinctes. |
Opérations |
|
Provisionner les applications de manière à ce qu'elles gèrent une charge deux fois supérieure à celle attendue |
Si un cluster échoue (par exemple, en raison d'une interruption de service régionale), la partie du service qui s'exécute dans le cluster restant peut absorber complètement la charge. |
Réparer automatiquement les nœuds |
Les clusters sont configurés avec la réparation automatique des nœuds. Si les vérifications d'état consécutives d'un nœud échouent de manière répétée sur une période prolongée, GKE lance un processus de réparation pour ce nœud. |
Assurez-vous que les mises à niveau du pool de nœuds sont sensibles aux applications. |
Les déploiements définissent un budget d'interruptions de pods avec |
Redémarrer automatiquement les services bloqués |
Le déploiement qui sauvegarde un service définit une vérification d'activité, qui identifie et redémarre les processus d'interblocage. |
Vérifier que les instances répliquées sont prêtes |
Le déploiement qui sauvegarde un service définit une vérification d'aptitude qui identifie le moment où une application est prête à être diffusée après le démarrage. Une vérification d'aptitude élimine la nécessité d'effectuer des vérifications manuelles ou d'attendre des délais prédéfinis lors des mises à jour progressives et des mises à niveau des pools de nœuds. |
L'architecture de référence est conçue pour les applications ayant des exigences de haute disponibilité zonales et régionales. Assurer une haute disponibilité entraîne des coûts (par exemple, des coûts liés aux instances de secours ou à la réplication interrégionale). La section Alternatives décrit plusieurs façons de limiter ces coûts.
Quotas de plate-forme, limites de performances et limites de scaling
Vous pouvez contrôler les quotas, les performances et le scaling des ressources sur la plate-forme de développement. La liste suivante décrit certains éléments à prendre en compte :
- L'infrastructure de base nécessite de nombreux projets, et chaque locataire supplémentaire nécessite quatre projets. Vous devrez peut-être demander un quota de projet supplémentaire avant de déployer et d'ajouter des locataires.
- Le nombre de ressources MultiClusterGateway est limité à 100 pour chaque projet. Chaque service Kubernetes Web sur la plate-forme de développement nécessite une ressource MultiClusterGateway.
- Cloud Logging impose une limite de 100 buckets dans un projet. L'accès aux journaux par locataire dans le plan repose sur un bucket pour chaque locataire.
- Pour créer plus de 20 locataires, vous pouvez demander une augmentation du quota du projet pour les ressources de champ d'application et d'espace de noms au niveau du champ d'application. Pour savoir comment afficher des quotas, consultez la page Afficher et gérer les quotas. Utilisez un filtre pour rechercher les types de quotas
gkehub.googleapis.com/global-per-project-scopesetgkehub.googleapis.com/global-per-project-scope-namespaces.
Étapes suivantes
- Découvrez l'architecture des services (document suivant de cette série).