Gerenciar e dimensionar a rede de aplicativos Windows executados em Kubernetes gerenciados
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Last reviewed 2024-08-14 UTC
Esta arquitetura de referência oferece uma solução altamente disponível e escalonável
que usa o
Cloud Service Mesh
e os
gateways Envoy
para gerenciar o tráfego de rede de aplicativos Windows executados no
Google Kubernetes Engine (GKE).
Ela explica como gerenciar esse tráfego de rede usando um serviço que pode rotear
o tráfego para pods e para um
proxy compatível com xDS de código aberto.
Usar uma arquitetura como essa pode ajudar a reduzir custos e melhorar o gerenciamento de rede.
Este documento é destinado a arquitetos de nuvem, administradores de rede e profissionais de TI
responsáveis por projetar e gerenciar aplicativos Windows
executados no GKE.
Arquitetura
O diagrama a seguir mostra uma arquitetura para gerenciar a rede de aplicativos Windows
executados no GKE usando
gateways do Envoy e Cloud Service Mesh:
A arquitetura inclui os seguintes componentes:
Um cluster regional do GKE com pools de nós do Windows e do Linux.
Dois aplicativos do Windows em execução em dois
pods do GKE separados.
Rotas HTTP que mapeiam para os serviços de back-end para o Cloud Service Mesh.
Pods de contêiner do Envoy
que funcionam como um gateway do Envoy para o cluster do GKE.
Gateways do Envoy que são executados em nós do Linux. Os gateways são configurados para direcionar o tráfego aos aplicativos Windows pelos serviços que correspondem a eles. O Envoy está configurado para usar o parâmetro scope
para carregar os detalhes de configuração dos serviços relevantes
do Cloud Service Mesh.
Esta arquitetura de referência usa os seguintes produtos do Google Cloud e de terceiros:
Produtos do Google Cloud
Cloud Load Balancing: um portfólio de balanceadores de carga globais, regionais, escalonáveis, globais e de alto desempenho.
Google Kubernetes Engine (GKE): um serviço do Kubernetes que pode ser usado para implantar
e operar aplicativos conteinerizados em escala usando a infraestrutura do Google.
Cloud Service Mesh: um pacote de ferramentas que monitora e gerencia uma
malha de serviço local confiável ou no Google Cloud.
Produtos terceirizados
Gateway do Envoy:
gerencia um proxy do Envoy como um gateway de aplicativo independente ou baseado no Kubernetes.
API Gateway: um projeto oficial do Kubernetes focado no roteamento L4 e L7 no Kubernetes.
Caso de uso
O principal caso de uso dessa arquitetura de referência é gerenciar o tráfego de rede
para aplicativos Windows executados no GKE. Essa arquitetura
oferece os seguintes benefícios:
Gerenciamento de rede simplificado: Cloud Service Mesh e gateways do Envoy
oferecem um gerenciamento de rede simplificado por meio de um sistema de controle
que gerencia o tráfego de rede para aplicativos. Esses aplicativos podem ser
Linux ou Windows executados no GKE ou
Compute Engine. O uso desse esquema simplificado de gerenciamento de rede reduz a
necessidade de configuração manual.
Escalonamento e disponibilidade aprimorados: para atender às demandas em mudança, use
o Cloud Service Mesh e gateways do Envoy para escalonar seus aplicativos
Linux e Windows. Também é possível usar gateways do Envoy para oferecer alta disponibilidade para
seus aplicativos com o balanceamento de carga do tráfego em vários pods.
Segurança aprimorada: use os gateways Envoy para adicionar recursos de segurança aos seus aplicativos Linux
e Windows, como terminação SSL, autenticação e limitação de taxa.
Custos reduzidos: os gateways Envoy e Cloud Service Mesh podem ajudar
a reduzir os custos de gerenciamento do tráfego de rede nos aplicativos Linux e Windows.
Considerações sobre o design
Esta seção fornece orientações para ajudar você a desenvolver uma arquitetura que atenda
aos seus requisitos específicos de segurança, confiabilidade, custo e eficiência.
Segurança
Rede segura: a arquitetura usa um balanceador de carga de aplicativo interno para
criptografar o tráfego de entrada para os contêineres do Windows. A criptografia em trânsito
ajuda a evitar o vazamento de dados.
Contêineres do Windows: ajudam a fornecer um ambiente seguro e
isolado para aplicativos conteinerizados.
Confiabilidade
Balanceamento de carga: a arquitetura usa várias camadas do Cloud Load Balancing para distribuir o tráfego entre os gateways do Envoy e os contêineres do Windows.
Tolerância a falhas: essa arquitetura é tolerante a falhas e não tem um ponto único de falha. Esse design ajuda a garantir que ele esteja sempre disponível,
mesmo que um ou mais componentes falhem.
Escalonamento automático: a arquitetura usa escalonamento automático para
escalonar o número de gateways do Envoy e contêineres do Windows com base na
carga. O escalonamento automático garante que os gateways e os aplicativos
podem lidar com picos de tráfego sem problemas de desempenho.
Monitoramento: a arquitetura usa o
Google Cloud Managed Service para Prometheus
e o Cloud Operations para monitorar a integridade dos gateways do Envoy e
dos contêineres do Windows. O monitoramento ajuda a identificar problemas precocemente e
antes que eles interrompam seus aplicativos.
Otimização de custos
Escolha os tipos de instância certos para suas cargas de trabalho: considere os seguintes fatores ao escolher os tipos de instância:
O número de vCPUs e a memória que seus aplicativos exigem
A carga de tráfego esperada para seus aplicativos
A necessidade de os usuários terem aplicativos altamente disponíveis
Usar o escalonamento automático: o escalonamento automático pode ajudar a economizar dinheiro ao
escalar automaticamente as cargas de trabalho do Windows vertical e horizontalmente.
O escalonamento vertical ajusta as solicitações e os limites de contêineres de acordo com
o uso do cliente.
Usar o Cloud Service Mesh e os gateways do Envoy:
o Cloud Service Mesh e os gateways do Envoy podem ajudar a economizar dinheiro ao rotear o tráfego de maneira eficiente para seus aplicativos Windows. Usar mais
o roteamento eficiente reduz a largura de banda necessária. Esse uso também pode ajudar a melhorar o desempenho desses aplicativos.
Usar redes de nuvem privada virtual (VPC) compartilhadas: as redes de nuvem privada virtual compartilhadas permitem compartilhar uma
VPC única em vários projetos. O compartilhamento pode ajudar a economizar dinheiro,
reduzindo o número de VPCs que você precisa criar e gerenciar.
Eficiência operacional
Vários domínios com um único balanceador de carga interno: a
arquitetura usa balanceadores de carga de aplicativo internos para descarregar o tráfego SSL. Cada proxy de destino
HTTPS pode oferecer suporte a vários certificados SSL
(até o máximo permitido)
para gerenciar vários aplicativos com domínios diferentes.
Infraestrutura como código (IaC): para gerenciar a infraestrutura, a
arquitetura pode ser implantada usando a IaC. A IaC ajuda a garantir que sua
infraestrutura seja consistente e repetível.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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"]]
