Cette architecture de référence fournit une solution à disponibilité élevée et évolutive qui utilise Cloud Service Mesh et des passerelles Envoy pour gérer le trafic réseau des applications Windows exécutées sur Google Kubernetes Engine (GKE). Elle explique comment gérer ce trafic réseau à l'aide d'un service pouvant acheminer le trafic vers les pods et vers un proxy compatible xDS Open Source. L'utilisation d'une architecture de ce type peut vous aider à réduire les coûts et à améliorer la gestion du réseau.
Ce document est destiné aux architectes cloud, aux administrateurs réseau et aux professionnels de l'informatique chargés de concevoir et de gérer des applications Windows exécutées sur GKE.
Architecture
Le schéma suivant illustre une architecture de gestion de la mise en réseau pour les applications Windows exécutées sur GKE à l'aide de Cloud Service Mesh et des passerelles Envoy :
L'architecture comprend les composants suivants :
- Un cluster GKE régional avec des pools de nœuds Windows et Linux.
- Deux applications Windows exécutées dans deux pods GKE distincts.
- Chaque application est exposée par un service Kubernetes de type
ClusterIPet un groupe de points de terminaison du réseau (NEG).
- Chaque application est exposée par un service Kubernetes de type
- Cloud Service Mesh crée et gère les routes de trafic vers les NEG pour chaque pod GKE. Chaque route est mappée à un
scopespécifique. Lescopeidentifie de manière unique une passerelle d'entrée Cloud Service Mesh. - Des routes HTTP mappées aux services de backend de Cloud Service Mesh.
- Un pod de conteneur Envoy qui sert de passerelle Envoy au cluster GKE.
- Des passerelles Envoy qui s'exécutent sur des nœuds Linux. Les passerelles sont configurées pour diriger le trafic vers les applications Windows via les services correspondant à ces applications. Envoy est configuré afin d'utiliser le paramètre
scopepour charger les détails de configuration des services Cloud Service Mesh concernés. - Un équilibreur de charge d'application interne qui met fin au trafic SSL et dirige tout le trafic entrant externe vers les passerelles Envoy.
Produits utilisés
Cette architecture de référence utilise les produits suivants Google Cloud et des produits tiers :
Google Cloud Produits
- Cloud Load Balancing : portefeuille d'équilibreurs de charge hautes performances, évolutifs, mondiaux et régionaux.
- Google Kubernetes Engine (GKE) : service Kubernetes que vous pouvez utiliser pour déployer et exploiter des applications conteneurisées à grande échelle, à l'aide de l'infrastructure de Google.
- Cloud Service Mesh : suite d'outils qui vous aide à surveiller et à gérer un maillage de services fiable sur site ou sur Google Cloud.
Produits tiers
- Envoy Gateway: gère un proxy Envoy en tant que passerelle d'application autonome ou basée sur Kubernetes.
- API Gateway : projet Kubernetes officiel axé sur le routage L4 et L7 dans Kubernetes.
Cas d'utilisation
Le principal cas d'utilisation de cette architecture de référence consiste à gérer le trafic réseau des applications Windows exécutées sur GKE. Cette architecture offre les avantages suivants :
Gestion simplifiée du réseau : les passerelles Cloud Service Mesh et Envoy simplifient la gestion du réseau via un plan de contrôle centralisé qui gère le trafic réseau vers les applications. Ces applications peuvent être des applications Linux ou Windows exécutées sur GKE ou Compute Engine. L'utilisation de ce schéma de gestion de réseau simplifié réduit le besoin de configuration manuelle.
Évolutivité et disponibilité améliorées : pour répondre à l'évolution de vos besoins, utilisez Cloud Service Mesh et les passerelles Envoy pour faire évoluer vos applications Linux et Windows. Vous pouvez également utiliser les passerelles Envoy pour assurer la haute disponibilité de vos applications en équilibrant la charge du trafic sur plusieurs pods.
Sécurité améliorée : utilisez les passerelles Envoy pour ajouter des fonctionnalités de sécurité à vos applications Linux et Windows, telles que la terminaison SSL, l'authentification et la limitation du débit.
Réduction des coûts : les passerelles Cloud Service Mesh et Envoy peuvent toutes deux réduire les coûts de gestion du trafic réseau pour les applications Linux et Windows.
Considérations de conception
Cette section fournit des conseils pour vous aider à développer une architecture répondant à vos exigences spécifiques en termes de sécurité, de fiabilité, de coût et d'efficacité.
Sécurité
- Mise en réseau sécurisée : l'architecture utilise un équilibreur de charge d'application interne pour chiffrer le trafic entrant vers les conteneurs Windows. Le chiffrement en transit permet d'éviter les fuites de données.
- Conteneurs Windows : les conteneurs Windows contribuent à fournir un environnement sécurisé et isolé pour les applications conteneurisées.
Fiabilité
- Équilibrage de charge : l'architecture utilise plusieurs couches de Cloud Load Balancing pour répartir le trafic entre les passerelles Envoy et les conteneurs Windows.
- Tolérance aux pannes : cette architecture est tolérante aux pannes sans point de défaillance unique. Cette conception permet de garantir qu'elle est toujours disponible, même en cas de défaillance d'un ou de plusieurs composants.
- Autoscaling : l'architecture utilise l'autoscaling pour adapter automatiquement le nombre de passerelles Envoy et de conteneurs Windows en fonction de la charge. L'autoscaling permet de s'assurer que les passerelles et les applications peuvent gérer les pics de trafic sans rencontrer de problèmes de performances.
- Surveillance : l'architecture utilise Google Cloud Managed Service pour Prometheus et Cloud Operations afin de surveiller l'état des passerelles Envoy et des conteneurs Windows. La surveillance vous aide à identifier les problèmes à un stade précoce et à éviter qu'ils n'interrompent vos applications.
Optimisation des coûts
- Choisissez les bons types d'instances pour vos charges de travail : tenez compte des
facteurs suivants lorsque vous choisissez des types d'instances :
- Le nombre de vCPU et la quantité de mémoire requis par vos applications
- La charge de trafic attendue pour vos applications
- La nécessité de la part des utilisateurs de disposer d'applications à disponibilité élevée
Utiliser l'autoscaling : l'autoscaling peut vous aider à réaliser des économies en effectuant un scaling automatique vertical et horizontal de vos charges de travail Windows.
Le scaling vertical ajuste les requêtes et les limites des conteneurs en fonction de l'utilisation du client.
- Automatisez le scaling vertical avec l'autoscaling vertical des pods.
Le scaling horizontal ajoute ou supprime des pods Kubernetes pour répondre à la demande.
- Automatisez le scaling horizontal avec l'autoscaling horizontal des pods.
Utiliser les passerelles Cloud Service Mesh et Envoy : les passerelles Cloud Service Mesh et Envoy peuvent vous aider à réaliser des économies en acheminant efficacement le trafic vers vos applications Windows. L'utilisation d'un routage plus efficace peut vous aider à réduire la quantité de bande passante que vous devez acheter. Elle peut également améliorer les performances de ces applications.
Utiliser des réseaux VPC (Virtual Private Cloud) partagés : les réseaux cloud privés virtuels partagés vous permettent de partager un seul VPC entre plusieurs projets. Le partage peut vous aider à réaliser des économies en réduisant le nombre de VPC que vous devez créer et gérer.
Efficacité opérationnelle
- Plusieurs domaines avec un seul équilibreur de charge interne : l'architecture utilise des équilibreurs de charge d'application internes pour décharger le trafic SSL. Chaque proxy HTTPS cible peut accepter plusieurs certificats SSL (jusqu'au maximum autorisé) pour gérer plusieurs applications avec des domaines différents.
- Infrastructure as Code (IaC) : pour gérer l'infrastructure, l' architecture peut être déployée à l'aide de l'IaC. L'IaC permet de s'assurer que votre infrastructure est cohérente et reproductible.
Déploiement
Pour déployer cette architecture, consultez Déployer des applications Windows exécutées sur Kubernetes géré.
Étape suivante
- Découvrez les Google Cloud produits utilisés dans ce guide de conception :
- Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Cloud Architecture Center.
Contributeurs
Auteur : Eitan Eibschutz | Consultant solutions techniques pour le personnel
Autres contributeurs :
- John Laham | Architecte de solutions
- Kaslin Fields | Developers Advocate
- Maridi (Raju) Makaraju | Supportability Tech Lead
- Valavan Rajakumar | Architecte d'entreprise principal
- Victor Moreno | Responsable produit, Mise en réseau cloud