This reference architecture provides a highly available and scalable solutionthat usesCloud Service Mesh andEnvoy gateways to manage network traffic for Windows applications that run onGoogle Kubernetes Engine (GKE).It explains how to manage that network traffic by using a service that can routetraffic to Pods and to anopen-source xDS-compliant proxy.Using an architecture like this can help to reduce costs and improve network management.

This document is intended for cloud architects, network administrators and ITprofessionals who are responsible for designing and managing Windows applicationsrunning on GKE.

Architecture

The following diagram shows an architecture for managing networking for Windowsapplications running on GKE usingCloud Service Mesh and Envoy gateways:

The architecture includes the following components:

• A regional GKE cluster with both Windows and Linux node pools.
• Two Windows applications running in two separateGKE Pods.
  • Each application is exposed by aClusterIP-type KubernetesService and anetwork endpoint group (NEG).
• Cloud Service Mesh creates and manages the traffic routes tothe NEGs for each GKE Pod. Each route is mapped to aspecificscope. Thatscopeuniquely identifies a Cloud Service Mesh ingress gateway.
• HTTP routes that map to the backend services forCloud Service Mesh.
• Envoy container Pods that act as an Envoy Gateway to the GKE cluster.
• Envoy gateways that run on Linux nodes. The gateways are configured todirect traffic to the Windows applications through the services thatcorrespond to those applications. Envoy is configured to use thescopeparameter to load the configuration details of the relevantCloud Service Mesh services.
• Aninternal Application Load Balancer that terminates SSL traffic and directs all external incoming traffic tothe Envoy gateways.

Products used

This reference architecture uses the following Google Cloud and third-partyproducts:

Google Cloud products

• Cloud Load Balancing: A portfolio of high performance, scalable, global andregional load balancers.
• Google Kubernetes Engine (GKE): A Kubernetes service that you can use to deployand operate containerized applications at scale using Google's infrastructure.
• Cloud Service Mesh: A suite of tools that helps you monitor andmanage a reliable service mesh on-premises or on Google Cloud.

Third-party products

• Envoy Gateway:Manages an Envoy proxy as a standalone or Kubernetes-based application gateway.
• Gateway API:An official Kubernetes project focused on L4 and L7 routing in Kubernetes.

Use case

The main use case for this reference architecture is to manage network trafficfor Windows applications that run on GKE. This architectureprovides the following benefits:

Simplified network management: Cloud Service Mesh and Envoygateways provide simplified network management through a centralized controlplane that manages network traffic to applications. These applications can beeither Linux or Windows applications that run on GKE orCompute Engine. Using this simplified network management scheme reduces theneed for manual configuration.

Enhanced scalability and availability: To meet your changing demands, useCloud Service Mesh and Envoy gateways to scale your Linux and Windowsapplications. You can also use Envoy gateways to provide high availability foryour applications by load balancing traffic across multiple Pods.

Improved security: Use Envoy gateways to add security features to your Linuxand Windows applications, such as SSL termination, authentication, and ratelimiting.

Reduced costs: Both Cloud Service Mesh and Envoy gateways can helpreduce the costs of managing network traffic for Linux and Windowsapplications.

Design considerations

This section provides guidance to help you develop an architecture that meetsyour specific requirements for security, reliability, cost, and efficiency.

Security

• Secured networking: The architecture uses an internal Application Load Balancer toencrypt incoming traffic to the Windows containers. Encryption in transithelps to prevent data leakage.
• Windows containers: Windows containers help provide a secure andisolated environment for containerized applications.

Reliability

• Load balancing: The architecture uses multiple layers of Cloud Load Balancing to distribute traffic across the Envoy gateways and the Windowscontainers.
• Fault tolerance: This architecture is fault tolerant with no singlepoint of failure. This design helps to ensure that it's always available,even if one or more of the components fails.
• Autoscaling: The architecture uses autoscaling to automaticallyscale the number of Envoy gateways and Windows containers based on theload. Autoscaling helps to ensure that the gateways, and the applications,can handle spikes in traffic without experiencing performance issues.
• Monitoring: The architecture usesGoogle Cloud Managed Service for Prometheus and Cloud Operations to monitor the health of the Envoy gateways andWindows containers. Monitoring helps you identify issues early andpotentially prevent them from disrupting your applications.

Cost optimization

• Choose the right instance types for your workloads: Consider thefollowing factors when choosing instance types:
  • The number of vCPUs and memory your applications require
  • The expected traffic load for your applications
  • The need for users to have highly available applications

• Use autoscaling: Autoscaling can help you save money byautomatically scaling your Windows workloads vertically and horizontally.

  • Vertical scaling tunes container requests and limits accordingto customer use.

    • Automate vertical scaling withvertical Pod autoscaling.

  • Horizontal scaling adds or removes Kubernetes Pods to meet demand.

    • Automate horizontal scaling withhorizontal Pod autoscaling.

• Use Cloud Service Mesh and Envoy gateways:Cloud Service Mesh and Envoy gateways can help you save money byefficiently routing traffic to your Windows applications. Using moreefficient routing can help reduce the amount of bandwidth you mustpurchase. It can also help improve the performance of those applications.

• Use shared Virtual Private Cloud (VPC) networks: Shared Virtual Private Cloud networks let you share asingle VPC across multiple projects. Sharing can help you save money byreducing the number of VPCs that you need to create and manage.

Operational efficiency

• Multiple domains with a single internal load balancer: Thearchitecture uses internal Application Load Balancers to offload SSL traffic. Each HTTPS targetproxy can support multiple SSL certificates(up to the supported maximum)to manage multiple applications with different domains.
• Infrastructure as Code (IaC): To manage the infrastructure, thearchitecture can be deployed using IaC. IaC helps to ensure that yourinfrastructure is consistent and repeatable.

Deployment

To deploy this architecture, seeDeploy Windows applications running on managed Kubernetes.

What's next

• Learn more about the Google Cloud products used in this design guide:
  • GKE networking best practices
  • Best practices for running cost effective Kubernetes applications on GKE
  • Cloud Service Mesh control plane observability
  • Using self-managed SSL certificates with load balancers
• For more reference architectures, diagrams, and best practices, explore theCloud Architecture Center.

Contributors

Author:Eitan Eibschutz | Staff Technical Solutions Consultant

Other contributors:

• John Laham | Solutions Architect
• Kaslin Fields | Developer Advocate
• Maridi (Raju) Makaraju | Supportability Tech Lead
• Valavan Rajakumar | Key Enterprise Architect
• Victor Moreno | Product Manager, Cloud Networking