Diese Referenzarchitektur bietet eine hochverfügbare und skalierbare Lösung, die Cloud Service Mesh und Envoy-Gateways verwendet, um den Netzwerktraffic für Windows-Anwendungen zu verwalten, die in Google Kubernetes Engine (GKE) ausgeführt werden. Es wird erläutert, wie Sie diesen Netzwerktraffic mithilfe eines Dienstes verwalten, der Traffic an Pods und an einen xDS-kompatiblen Open-Source-Proxy weiterleiten kann. Mit einer solchen Architektur können Sie die Kosten senken und die Netzwerkverwaltung verbessern.
Dieses Dokument richtet sich an Cloud-Architekten, Netzwerkadministratoren und IT-Fachleute, die für das Entwerfen und Verwalten von in GKE ausgeführten Windows-Anwendungen verantwortlich sind.
Architektur
Das folgende Diagramm zeigt eine Architektur zum Verwalten von Netzwerken für Windows-Anwendungen, die in GKE mit Cloud Service Mesh und Envoy-Gateways ausgeführt werden:
Die Architektur umfasst die folgenden Komponenten:
- Ein regionaler GKE-Cluster mit Windows- und Linux-Knotenpools.
- Zwei Windows-Anwendungen, die in zwei separaten GKE-Pods ausgeführt werden.
- Jede Anwendung wird von einem Kubernetes-Dienst des Typs
ClusterIP
und einer Netzwerk-Endpunktgruppe (NEG) bereitgestellt.
- Jede Anwendung wird von einem Kubernetes-Dienst des Typs
- Cloud Service Mesh erstellt und verwaltet die Trafficrouten zu den NEGs für jeden GKE-Pod. Jede Route ist einem bestimmten
scope
zugeordnet. Diesescope
kennzeichnet ein Cloud Service Mesh-Ingress-Gateway eindeutig. - HTTP-Routen, die den Back-End-Diensten für Cloud Service Mesh zugeordnet sind.
- Envoy-Container-Pods, die als Envoy-Gateway für den GKE-Cluster dienen.
- Envoy-Gateways, die auf Linux-Knoten ausgeführt werden. Die Gateways sind so konfiguriert, dass der Traffic über die Dienste, die diesen Anwendungen entsprechen, an die Windows-Anwendungen geleitet wird. Envoy ist so konfiguriert, dass der Parameter
scope
zum Laden der Konfigurationsdetails der relevanten Cloud Service Mesh-Dienste verwendet wird. - Einem internen Application Load Balancer, der SSL-Traffic beendet und den gesamten eingehenden Traffic an die Envoy-Gateways weiterleitet.
Verwendete Produkte
Diese Referenzarchitektur verwendet die folgenden Google Cloud - und Drittanbieterprodukte:
Google Cloud Produkte
- Cloud Load Balancing: Ein Portfolio von leistungsstarken, skalierbaren, globalen und regionalen Load-Balancern
- Google Kubernetes Engine (GKE): Ein Kubernetes-Dienst, mit dem Sie Containeranwendungen in großem Maßstab mithilfe der Google-Infrastruktur bereitstellen und betreiben können.
- Cloud Service Mesh: Eine Reihe von Tools, mit denen Sie ein zuverlässiges Service Mesh lokal oder in Google Cloud überwachen und verwalten können.
Produkte von Drittanbietern
- Envoy Gateway: verwaltet einen Envoy-Proxy als eigenständiges oder Kubernetes-basiertes Anwendungsgateway.
- Gateway API: Ein offizielles Kubernetes-Projekt, das sich auf L4- und L7-Routing in Kubernetes konzentriert.
Anwendungsfall
Diese Referenzarchitektur wird hauptsächlich für die Verwaltung des Netzwerktraffics von Windows-Anwendungen verwendet, die in GKE ausgeführt werden. Diese Architektur bietet folgende Vorteile:
Vereinfachte Netzwerkverwaltung: Cloud Service Mesh- und Envoy-Gateways vereinfachen die Netzwerkverwaltung über eine zentrale Steuerungsebene, mit der der Netzwerktraffic zu Anwendungen verwaltet wird. Diese Anwendungen können Linux- oder Windows-Anwendungen sein, die in GKE oder Compute Engine ausgeführt werden. Die Verwendung dieses vereinfachten Schemas zur Netzwerkverwaltung reduziert die Notwendigkeit einer manuellen Konfiguration.
Verbesserte Skalierbarkeit und Verfügbarkeit: Verwenden Sie Cloud Service Mesh- und Envoy-Gateways zur Skalierung Ihrer Linux- und Windows-Anwendungen, um Ihren sich ändernden Anforderungen gerecht zu werden. Sie können außerdem Envoy-Gateways verwenden, um Hochverfügbarkeit für Ihre Anwendungen zu bieten, indem Sie Traffic über mehrere Pods verteilen.
Verbesserte Sicherheit: Verwenden Sie Envoy-Gateways, um Ihren Linux- und Windows-Anwendungen Sicherheitsfunktionen wie SSL-Terminierung, Authentifizierung und Ratenbegrenzung hinzuzufügen.
Reduzierte Kosten: Sowohl Cloud Service Mesh- als auch Envoy-Gateways können dazu beitragen, die Kosten für die Verwaltung des Netzwerktraffics für Linux- und Windows-Anwendungen zu senken.
Designaspekte
Dieser Abschnitt enthält Anleitungen zur Entwicklung einer Architektur, die Ihren spezifischen Anforderungen an Sicherheit, Zuverlässigkeit, Kosten und Effizienz entspricht.
Sicherheit
- Gesicherte Netzwerke: Die Architektur verwendet einen internen Application Load Balancer, um eingehenden Traffic zu den Windows-Containern zu verschlüsseln. Durch die Verschlüsselung während der Übertragung lassen sich Datenverluste vermeiden.
- Windows-Container: Windows-Container bieten eine sichere und isolierte Umgebung für Containeranwendungen.
Zuverlässigkeit
- Load-Balancing: Die Architektur verwendet mehrere Ebenen von Cloud Load Balancing, um den Traffic auf die Envoy-Gateways und die Windows-Container zu verteilen.
- Fehlertoleranz: Diese Architektur ist fehlertolerant, es gibt keinen Single Point of Failure. Dieses Design sorgt dafür, dass die Komponente immer verfügbar ist, selbst wenn eine oder mehrere Komponenten ausfallen.
- Autoscaling: Die Architektur verwendet Autoscaling, um die Anzahl der Envoy-Gateways und Windows-Container basierend auf der Last automatisch zu skalieren. Mit Autoscaling wird sichergestellt, dass die Gateways und die Anwendungen Trafficspitzen ohne Leistungsprobleme bewältigen können.
- Monitoring: Die Architektur verwendet Google Cloud Managed Service for Prometheus und Cloud Operations, um den Zustand der Envoy-Gateways und Windows-Container zu überwachen. Monitoring hilft Ihnen, Probleme frühzeitig zu erkennen und möglicherweise zu verhindern, dass sie Ihre Anwendungen beeinträchtigen.
Kostenoptimierung
- Die richtigen Instanztypen für Ihre Arbeitslasten auswählen: Berücksichtigen Sie bei der Auswahl der Instanztypen die folgenden Faktoren:
- Die Anzahl der vCPUs und der Arbeitsspeicher, die Ihre Anwendungen benötigen
- Die erwartete Traffic-Auslastung für Ihre Anwendungen
- Die Notwendigkeit, hochverfügbare Anwendungen zu haben
Autoscaling verwenden: Mit Autoscaling können Sie Geld sparen, indem Ihre Windows-Arbeitslasten automatisch vertikal und horizontal skaliert werden.
Bei der vertikalen Skalierung werden Containeranfragen und -limits entsprechend der Kundennutzung abgestimmt.
- Automatisieren Sie die vertikale Skalierung mit vertikalem Pod-Autoscaling.
Bei der horizontalen Skalierung werden Kubernetes-Pods je nach Bedarf hinzugefügt oder entfernt.
- Automatisieren Sie die horizontale Skalierung mit horizontalem Pod-Autoscaling.
Cloud Service Mesh- und Envoy-Gateways verwenden: Mit Cloud Service Mesh- und Envoy-Gateways können Sie Geld sparen, indem Sie Traffic effizient an Ihre Windows-Anwendungen weiterleiten. Durch effizienteres Routing müssen Sie weniger Bandbreite kaufen. Außerdem lässt sich damit die Leistung dieser Anwendungen verbessern.
Freigegebene VPC-Netzwerke (Virtual Private Cloud): Mit freigegebenen Virtual Private Cloud-Netzwerken können Sie eine einzelne VPC für mehrere Projekte freigeben. Durch die Freigabe können Sie Geld sparen, da die Anzahl der VPCs reduziert wird, die erstellt und verwaltet werden müssen.
Operative Effizienz
- Mehrere Domains mit einem einzelnen internen Load-Balancer: Die Architektur verwendet interne Application Load Balancer, um SSL-Traffic auszulagern. Jeder HTTPS-Zielproxy kann mehrere SSL-Zertifikate unterstützen (bis zum unterstützten Maximum), um mehrere Anwendungen mit unterschiedlichen Domains zu verwalten.
- Infrastruktur als Code (IaC): Zur Verwaltung der Infrastruktur kann die Architektur mit IaC bereitgestellt werden. IaC sorgt dafür, dass Ihre Infrastruktur einheitlich und wiederholbar ist.
Bereitstellung
Informationen zum Bereitstellen dieser Architektur finden Sie unter In einer verwalteten Kubernetes-Umgebung ausgeführte Windows-Anwendungen bereitstellen.
Nächste Schritte
- Weitere Informationen zu den in diesem Designleitfaden Google Cloud verwendeten Produkten:
- Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.
Beitragende
Autor: Eitan Eibschutz | Staff Technical Solutions Consultant
Weitere Beitragende:
- 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