Le diagramme suivant illustre l'architecture de haut niveau déployée par le plan pour un environnement unique. Vous déployez cette architecture dans trois environnements distincts: production, hors production et développement.
Ce schéma comprend les éléments suivants:
- Cloud Load Balancing répartit le trafic des applications entre les régions entre les objets du service Kubernetes. Derrière chaque service se trouve un regroupement logique de pods associés.
- Anthos Service Mesh permet aux services Kubernetes de communiquer entre eux.
- Les services Kubernetes sont regroupés en locataires, qui sont représentés par des espaces de noms Kubernetes. Les locataires sont une abstraction qui représente plusieurs utilisateurs et charges de travail fonctionnant dans un cluster, avec un contrôle RBAC distinct pour le contrôle des accès. Chaque locataire dispose également de son propre projet pour les ressources cloud spécifiques aux locataires, telles que les bases de données, les buckets de stockage et les abonnements Pub/Sub.
- Espaces de noms avec leurs propres identités pour accéder aux services pairs et aux ressources cloud. L'identité est cohérente sur le même espace de noms dans différents clusters en raison de la fonctionnalité Workload Identity du parc. Chaque environnement dispose d'un pool d'identités de charge de travail distinct pour limiter l'élévation des privilèges entre les environnements.
- Chaque service dispose d'un pipeline dédié qui compile et déploie ce service. Le même pipeline est utilisé pour déployer le service dans l'environnement de développement, puis pour le déployer dans l'environnement hors production, et enfin déployer le service dans l'environnement de production.
Principales décisions en termes d'architecture pour la plate-forme de développeur
Le tableau suivant décrit les décisions d'architecture mises en œuvre par le plan.
| Zone de décision | Décision | Motif |
|---|---|---|
Déployer dans plusieurs régions |
Autoriser la disponibilité des applications en cas de pannes régionales. |
|
Déploiement sur le plan de base de l'entreprise. |
Utilise la structure organisationnelle et les contrôles de sécurité fournis par la base. |
|
Utilisez les trois dossiers d'environnement configurés dans la base : |
Isoler les environnements ayant des contrôles d'accès différents. |
|
Empaqueter et déployer des applications en tant que conteneurs |
Séparation des responsabilités, opérations efficaces et portabilité des applications |
|
Exécuter des applications sur des clusters GKE |
Utiliser un service de conteneurs géré créé par l'entreprise qui a créé les conteneurs. |
|
Répliquer et exécuter des conteneurs d'applications dans une configuration en mode actif/actif |
Obtenir une disponibilité plus élevée et des déploiements progressifs rapides pour améliorer la vitesse de développement. |
|
Provisionnez l'environnement de production avec deux clusters GKE dans deux régions différentes. |
Atteindre une disponibilité plus élevée qu'une seule région cloud. |
|
Provisionnez l'environnement hors production avec deux clusters GKE dans deux régions différentes. |
Intègre par étape les modifications des paramètres interrégionaux, tels que les équilibreurs de charge, avant le déploiement en production. |
|
Provisionnez l'environnement de développement avec une seule instance de cluster GKE. |
Permet de réduire les coûts. |
|
Configurer des plans de contrôle à disponibilité élevée pour chaque cluster GKE. |
S'assurer que le plan de contrôle du cluster est disponible lors de la mise à niveau et du redimensionnement. |
|
Utilisez le concept d'uniformité sur l'ensemble des espaces de noms, services et identités dans chaque cluster GKE. |
S'assurer que les objets Kubernetes portant le même nom dans différents clusters sont traités de la même manière. Cette normalisation permet de faciliter l'administration des ressources de parc. |
|
Activez les espaces d'adresses IP privées pour les clusters GKE via l'accès Private Service Connect au plan de contrôle et les pools de nœuds privés. |
Protection de l'API du cluster Kubernetes contre les attaques. |
|
Activez l'accès administrateur aux clusters GKE via la passerelle Connect. |
Utilisation d'une commande pour récupérer les identifiants d'accès à plusieurs clusters. Utilisation des groupes et des fournisseurs d'identité tiers pour gérer l'accès aux clusters. |
|
Utiliser Cloud NAT pour fournir aux pods GKE un accès aux ressources avec des adresses IP publiques. |
Amélioration de la stratégie de sécurité globale du cluster, car les pods ne sont pas directement exposés à Internet, mais peuvent toujours accéder aux ressources Web. |
|
Configuration des nœuds pour qu'ils utilisent Container-Optimized OS et les nœuds GKE protégés. |
Limiter la surface d'attaque des nœuds |
|
Associez chaque environnement à un parc GKE. |
Autoriser la gestion des ensembles de clusters GKE en tant qu'unité. |
|
Utiliser le pipeline d'infrastructure de base pour déployer l'usine de application, le pipeline au niveau du parc et le pipeline d'infrastructure mutualisée. |
Fournir un mécanisme contrôlable, auditable et reproductible pour déployer une infrastructure d'application. |
|
Configurer des clusters GKE à l'aide des fonctionnalités de gestion de configuration et de stratégie GKE Enterprise. |
Fournir un service qui permet la configuration en tant que code pour les clusters GKE. |
|
Utiliser une usine d'applications pour déployer les pipelines CI/CD d'application utilisés dans le plan. |
Fournir un modèle reproductible pour déployer des pipelines d'applications plus facilement. |
|
Utiliser un pipeline CI/CD d'application pour créer et déployer les composants d'application du plan. |
Fournir un mécanisme contrôlable, auditable et reproductible pour déployer des applications. |
|
Configurer le pipeline CI/CD de l'application pour qu'il utilise Cloud Build, Cloud Deploy et Artifact Registry. |
Utiliser les services gérés de compilation et de déploiement pour optimiser la sécurité, l'évolutivité et la simplicité. |
|
Utiliser des conteneurs immuables dans tous les environnements et signez les conteneurs avec l'autorisation binaire. |
Fournir une provenance claire du code et assurez-vous que le code a été testé dans tous les environnements. |
|
Utiliser Google Cloud Observability, qui inclut Cloud Logging et Cloud Monitoring. |
Simplifier vos opérations en utilisant un service géré intégré de Google Cloud. |
|
Activer Container Threat Detection (un service dans Security Command Center) pour surveiller l'intégrité des conteneurs. |
Utiliser un service géré qui renforce la sécurité en surveillant en permanence les conteneurs. |
|
Contrôle de l'accès aux clusters GKE à l'aide du contrôle des accès basé sur les rôles (RBAC) Kubernetes, basé sur Google Groupes pour GKE. |
Renforcer la sécurité en associant le contrôle des accès aux identités Google Cloud |
|
Utiliser un compte de service Kubernetes unique pour chaque service Kubernetes. Ce compte agit en tant que compte de service IAM via Workload Identity. |
Améliorer la sécurité en minimisant les autorisations nécessaires à chaque service. |
|
Exposer des services via l'API GKE Gateway. |
Simplifier la gestion des configurations en fournissant une approche déclarative et basée sur les ressources pour la gestion des règles d'entrée et des configurations d'équilibrage de charge. |
|
Exécuter des services en tant que services distribués via Anthos Service Mesh avec Certificate Authority Service. |
Fournir une sécurité améliorée en appliquant l'authentification entre les services et une tolérance automatique aux pannes en redirigeant le trafic hors des services non opérationnels. |
|
Utiliser la réplication interrégionale pour AlloyDB pour PostgreSQL. |
Assurer la haute disponibilité dans la couche de base de données. |
|
Les instances de VPC partagé sont configurées dans chaque environnement, et les clusters GKE sont créés dans les projets de service. |
Le VPC partagé offre une gestion centralisée de la configuration du réseau tout en conservant la séparation des environnements. |
|
Utiliser Cloud Load Balancing dans une configuration multicluster et multirégionale. |
Fournir une adresse IP Anycast unique pour accéder aux clusters GKE régionalisés afin d'offrir des services à haute disponibilité et à faible latence. |
|
Utiliser des connexions HTTPS pour permettre aux clients d'accéder aux services. Rediriger toutes les requêtes HTTP client vers HTTPS. |
Protéger les données sensibles en transit et empêchez les attaques de type MITM. |
|
Utiliser le gestionnaire de certificats pour gérer les certificats publics. |
Gérer les certificats de manière unifiée. |
|
Protéger l'interface Web avec Google Cloud Armor. |
Renforcer la sécurité en vous protégeant contre les failles courantes des applications Web et les attaques volumétriques. |
Vos décisions peuvent différer du plan. Pour en savoir plus sur les alternatives, consultez la section Alternatives aux recommandations par défaut.
Étapes suivantes
- Découvrez les contrôles de plate-forme de développeur (document suivant de cette série).