這項參考架構的主要用途是管理在 GKE 上執行的 Windows 應用程式網路流量。這項架構具有下列優點：
簡化網路管理：Cloud Service Mesh 和 Envoy 閘道提供集中式控制層，可管理應用程式的網路流量，進而簡化網路管理作業。這些應用程式可以是 Linux 或 Windows 應用程式，在 GKE 或 Compute Engine 上執行。使用這項簡化的網路管理機制，可減少手動設定的需求。
提升擴充性和可用性：為滿足不斷變化的需求，請使用 Cloud Service Mesh 和 Envoy 閘道，擴充 Linux 和 Windows 應用程式。您也可以使用 Envoy 閘道，在多個 Pod 之間平衡負載流量，為應用程式提供高可用性。
提升安全性：使用 Envoy 閘道為 Linux 和 Windows 應用程式新增安全防護功能，例如 SSL 終止、驗證和速率限制。
降低成本：Cloud Service Mesh 和 Envoy 閘道都能協助降低管理 Linux 和 Windows 應用程式網路流量的成本。
設計須知
本節提供指引，協助您開發符合特定安全性、可靠性、成本和效率需求的架構。
安全性
安全網路：此架構使用內部應用程式負載平衡器，加密傳入 Windows 容器的流量。傳輸中加密功能可防止資料外洩。
Windows 容器：Windows 容器可為容器化應用程式提供安全且獨立的環境。
可靠性
負載平衡：這項架構使用多層 Cloud Load Balancing，在 Envoy 閘道和 Windows 容器之間分配流量。
容錯能力：這個架構具備容錯能力，不會出現單點故障。即使一或多個元件故障，也能確保系統一律可用。
自動調度資源：這項架構會使用自動調度資源功能，根據負載自動調整 Envoy 閘道和 Windows 容器的數量。自動調度資源有助於確保閘道和應用程式能應付流量高峰，不會發生效能問題。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2024-08-14 (世界標準時間)。"],[[["\u003cp\u003eThis architecture provides a scalable and highly available solution for managing network traffic for Windows applications on Google Kubernetes Engine (GKE) using Cloud Service Mesh and Envoy gateways.\u003c/p\u003e\n"],["\u003cp\u003eThe design leverages an internal Application Load Balancer, Cloud Service Mesh, and Envoy gateways to simplify network management, enhance scalability, and improve security for Windows applications on GKE.\u003c/p\u003e\n"],["\u003cp\u003eThis solution uses multiple layers of Cloud Load Balancing, autoscaling, and monitoring to provide fault tolerance and ensure that applications remain available and can handle traffic spikes.\u003c/p\u003e\n"],["\u003cp\u003eCost optimization strategies, such as using shared Virtual Private Cloud networks, autoscaling, and efficient traffic routing with Cloud Service Mesh and Envoy gateways, are included in the design.\u003c/p\u003e\n"],["\u003cp\u003eThe architecture emphasizes operational efficiency through Infrastructure as Code (IaC) and the ability to manage multiple domains with a single internal load balancer.\u003c/p\u003e\n"]]],[],null,["# Manage and scale networking for Windows applications that run on managed Kubernetes\n\nThis reference architecture provides a highly available and scalable solution\nthat uses\n[Cloud Service Mesh](/traffic-director/docs/overview)\nand\n[Envoy gateways](https://gateway.envoyproxy.io/)\nto manage network traffic for Windows applications that run on\n[Google Kubernetes Engine (GKE)](/kubernetes-engine/docs/concepts/kubernetes-engine-overview).\nIt explains how to manage that network traffic by using a service that can route\ntraffic to Pods and to an\n[open-source xDS-compliant proxy](https://www.envoyproxy.io/docs/envoy/latest/api/api).\nUsing an architecture like this can help to reduce costs and improve network management.\n\nThis document is intended for cloud architects, network administrators and IT\nprofessionals who are responsible for designing and managing Windows applications\nrunning on GKE.\n\nArchitecture\n------------\n\nThe following diagram shows an architecture for managing networking for Windows\napplications running on GKE using\nCloud Service Mesh and Envoy gateways:\n\nThe architecture includes the following components:\n\n- A regional GKE cluster with both Windows and Linux node pools.\n- Two Windows applications running in two separate GKE Pods.\n - Each application is exposed by a `ClusterIP`-type Kubernetes Service and a [network endpoint group (NEG)](/load-balancing/docs/negs).\n- Cloud Service Mesh creates and manages the traffic routes to the NEGs for each GKE Pod. Each route is mapped to a specific `scope`. That `scope` [uniquely identifies a Cloud Service Mesh ingress gateway](/service-mesh/docs/service-routing/set-up-ingress-gateway#config-gateway).\n- HTTP routes that map to the backend services for Cloud Service Mesh.\n- [Envoy](https://www.envoyproxy.io/docs/envoy/latest/intro/what_is_envoy) container Pods that act as an Envoy Gateway to the GKE cluster.\n- Envoy gateways that run on Linux nodes. The gateways are configured to direct traffic to the Windows applications through the services that correspond to those applications. Envoy is configured to use the `scope` parameter to load the configuration details of the relevant Cloud Service Mesh services.\n- An [internal Application Load Balancer](/load-balancing/docs/l7-internal) that terminates SSL traffic and directs all external incoming traffic to the Envoy gateways.\n\nProducts used\n-------------\n\nThis reference architecture uses the following Google Cloud and third-party\nproducts:\n\n### Google Cloud products\n\n- [Cloud Load Balancing](https://cloud.google.com/load-balancing): A portfolio of high performance, scalable, global and regional load balancers.\n- [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine): A Kubernetes service that you can use to deploy and operate containerized applications at scale using Google's infrastructure.\n- [Cloud Service Mesh](https://cloud.google.com/service-mesh): A suite of tools that helps you monitor and manage a reliable service mesh on-premises or on Google Cloud.\n\n### Third-party products\n\n- [Envoy Gateway](https://gateway.envoyproxy.io/): Manages an Envoy proxy as a standalone or Kubernetes-based application gateway.\n- [Gateway API](https://gateway-api.sigs.k8s.io/): An official Kubernetes project focused on L4 and L7 routing in Kubernetes.\n\nUse case\n--------\n\nThe main use case for this reference architecture is to manage network traffic\nfor Windows applications that run on GKE. This architecture\nprovides the following benefits:\n\n**Simplified network management**: Cloud Service Mesh and Envoy\ngateways provide simplified network management through a centralized control\nplane that manages network traffic to applications. These applications can be\neither Linux or Windows applications that run on GKE or\nCompute Engine. Using this simplified network management scheme reduces the\nneed for manual configuration.\n\n**Enhanced scalability and availability**: To meet your changing demands, use\nCloud Service Mesh and Envoy gateways to scale your Linux and Windows\napplications. You can also use Envoy gateways to provide high availability for\nyour applications by load balancing traffic across multiple Pods.\n\n**Improved security**: Use Envoy gateways to add security features to your Linux\nand Windows applications, such as SSL termination, authentication, and rate\nlimiting.\n\n**Reduced costs**: Both Cloud Service Mesh and Envoy gateways can help\nreduce the costs of managing network traffic for Linux and Windows\napplications.\n\nDesign considerations\n---------------------\n\nThis section provides guidance to help you develop an architecture that meets\nyour specific requirements for security, reliability, cost, and efficiency.\n\n### Security\n\n- **Secured networking**: The architecture uses an internal Application Load Balancer to encrypt incoming traffic to the Windows containers. Encryption in transit helps to prevent data leakage.\n- **Windows containers**: Windows containers help provide a secure and isolated environment for containerized applications.\n\n### Reliability\n\n- **Load balancing**: The architecture uses multiple layers of Cloud Load Balancing to distribute traffic across the Envoy gateways and the Windows containers.\n- **Fault tolerance**: This architecture is fault tolerant with no single point of failure. This design helps to ensure that it's always available, even if one or more of the components fails.\n- **Autoscaling**: The architecture uses autoscaling to automatically scale the number of Envoy gateways and Windows containers based on the load. Autoscaling helps to ensure that the gateways, and the applications, can handle spikes in traffic without experiencing performance issues.\n- **Monitoring** : The architecture uses [Google Cloud Managed Service for Prometheus](/stackdriver/docs/managed-prometheus) and Cloud Operations to monitor the health of the Envoy gateways and Windows containers. Monitoring helps you identify issues early and potentially prevent them from disrupting your applications.\n\n### Cost optimization\n\n- **Choose the right instance types for your workloads** : Consider the following factors when choosing instance types:\n - The number of vCPUs and memory your applications require\n - The expected traffic load for your applications\n - The need for users to have highly available applications\n- **Use autoscaling**: Autoscaling can help you save money by\n automatically scaling your Windows workloads vertically and horizontally.\n\n - Vertical scaling tunes container requests and limits according\n to customer use.\n\n - Automate vertical scaling with [vertical Pod autoscaling](/kubernetes-engine/docs/concepts/verticalpodautoscaler).\n - Horizontal scaling adds or removes Kubernetes Pods to meet demand.\n\n - Automate horizontal scaling with [horizontal Pod autoscaling](/kubernetes-engine/docs/concepts/horizontalpodautoscaler).\n- **Use Cloud Service Mesh and Envoy gateways**:\n Cloud Service Mesh and Envoy gateways can help you save money by\n efficiently routing traffic to your Windows applications. Using more\n efficient routing can help reduce the amount of bandwidth you must\n purchase. It can also help improve the performance of those applications.\n\n- **Use shared Virtual Private Cloud (VPC) networks**: Shared Virtual Private Cloud networks let you share a\n single VPC across multiple projects. Sharing can help you save money by\n reducing the number of VPCs that you need to create and manage.\n\n### Operational efficiency\n\n- **Multiple domains with a single internal load balancer** : The architecture uses internal Application Load Balancers to offload SSL traffic. Each HTTPS target proxy can support multiple SSL certificates ([up to the supported maximum](/load-balancing/docs/quotas#target_proxies)) to manage multiple applications with different domains.\n- **Infrastructure as Code (IaC)**: To manage the infrastructure, the architecture can be deployed using IaC. IaC helps to ensure that your infrastructure is consistent and repeatable.\n\nDeployment\n----------\n\nTo deploy this architecture, see\n[Deploy Windows applications running on managed Kubernetes](/architecture/manage-and-scale-windows-networking/deployment).\n\nWhat's next\n-----------\n\n- Learn more about the Google Cloud products used in this design guide:\n - [GKE networking best practices](/kubernetes-engine/docs/best-practices/networking)\n - [Best practices for running cost effective Kubernetes applications on GKE](/architecture/best-practices-for-running-cost-effective-kubernetes-applications-on-gke#observe_your_gke_clusters_and_watch_for_recommendations)\n - [Cloud Service Mesh control plane observability](/traffic-director/docs/control-plane-observability)\n - [Using self-managed SSL certificates with load balancers](/load-balancing/docs/ssl-certificates/self-managed-certs)\n- For more reference architectures, diagrams, and best practices, explore the [Cloud Architecture Center](/architecture).\n\nContributors\n------------\n\nAuthor: [Eitan Eibschutz](https://www.linkedin.com/in/eitaneibschutz) \\| Staff Technical Solutions Consultant\n\nOther contributors:\n\n- [John Laham](https://www.linkedin.com/in/lahamjohn) \\| Solutions Architect\n- [Kaslin Fields](https://www.linkedin.com/in/kaslinfields) \\| Developer Advocate\n- [Maridi (Raju) Makaraju](https://www.linkedin.com/in/mmraju) \\| Supportability Tech Lead\n- [Valavan Rajakumar](https://www.linkedin.com/in/valavanr) \\| Key Enterprise Architect\n- [Victor Moreno](https://www.linkedin.com/in/vimoreno) \\| Product Manager, Cloud Networking\n\n\u003cbr /\u003e"]]
