Linux ノードで実行される Envoy ゲートウェイ。ゲートウェイは、それらのアプリケーションに対応するサービスを通じて Windows アプリケーションにトラフィックを転送するように構成されています。Envoy は、scope パラメータを使用して関連する Cloud Service Mesh サービスの構成の詳細を読み込むように構成されています。
このリファレンス アーキテクチャの主なユースケースは、GKE で実行される Windows アプリケーションのネットワーク トラフィックの管理です。このアーキテクチャには次のような利点があります。
ネットワーク管理の簡素化: Cloud Service Mesh と Envoy ゲートウェイは、アプリケーションへのネットワーク トラフィックを管理する一元化されたコントロール プレーンにより、ネットワーク管理を簡素化します。これらのアプリケーションは、GKE または Compute Engine で実行される Linux または Windows アプリケーションです。この簡素化されたネットワーク管理方法により、手動構成の必要性が軽減されます。
スケーラビリティと可用性の向上: 変化する需要に対応するため、Cloud Service Mesh と Envoy ゲートウェイを使用して Linux アプリケーションと Windows アプリケーションをスケーリングします。Envoy ゲートウェイを使用して、複数の Pod 間でトラフィックをロードバランスすることで、アプリケーションの高可用性を実現することもできます。
セキュリティの強化: Envoy ゲートウェイにより、SSL 終端、認証、レート制限などのセキュリティ機能を Linux アプリケーションと Windows アプリケーションに追加します。
コスト削減: Cloud Service Mesh と Envoy ゲートウェイの両方を使用すると、Linux アプリケーションと Windows アプリケーションのネットワーク トラフィックの管理にかかる費用を削減できます。
自動スケーリング: このアーキテクチャでは、自動スケーリングを使用し、負荷に応じて Envoy ゲートウェイと Windows コンテナの数を自動的にスケーリングします。自動スケーリングにより、ゲートウェイとアプリケーションはパフォーマンスを低下させることなく、トラフィックの急増に対応できます。
モニタリング: このアーキテクチャでは、Google Cloud Managed Service for Prometheus と Cloud Operations を使用して、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 UTC。"],[[["\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"]]
