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. Une telle architecture peut contribuer à 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'IT 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
ClusterIP
et 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 itinéraire est mappé à un
scope
spécifique. Lescope
identifie 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 qui leur correspondent. Envoy est configuré afin d'utiliser le paramètre
scope
pour charger les détails de configuration des services Cloud Service Mesh concernés. - Un équilibreur de charge d'application interne qui interrompt le 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 Google Cloud et tiers suivants :
Produits Google Cloud
- 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
- Passerelle Envoy : 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 est de 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 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 des passerelles Envoy pour assurer une haute disponibilité à 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é
- Réseau sécurisé: 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 permettent de 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 pour 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 types d'instances adaptés à 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 dont vos applications ont besoin ;
- 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.
L'autoscaling vertical ajuste les demandes et les limites des conteneurs en fonction de l'utilisation du client.
- Automatisez l'ajustement vertical avec l'autoscaling de pods vertical.
Le scaling horizontal ajoute ou supprime des pods Kubernetes pour répondre à la demande.
- Automatisez l'autoscaling 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. Cela 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 à économiser de l'argent 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 cible HTTPS peut prendre en charge plusieurs certificats SSL (jusqu'au nombre maximal accepté) 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 la page Déployer des applications Windows exécutées sur Kubernetes géré.
Étape suivante
- Découvrez les produits Google Cloud 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