Netzwerke für Windows-Anwendungen verwalten und skalieren, die in verwalteten Kubernetes-Umgebungen ausgeführt werden

Last reviewed 2024-08-14 UTC

Diese Referenzarchitektur bietet eine hochverfügbare und skalierbare Lösung, die Cloud Service Mesh und Envoy-Gateways verwendet, um den Netzwerkverkehr für Windows-Anwendungen zu verwalten, die in Google Kubernetes Engine (GKE) ausgeführt werden. Darin wird beschrieben, wie Sie diesen Netzwerktraffic mithilfe eines Dienstes verwalten, der Traffic an Pods und an einen Open-Source-Proxy, der mit xDS kompatibel ist, weiterleiten kann. Eine solche Architektur kann dazu beitragen, die Kosten zu senken und die Netzwerkverwaltung zu verbessern.

Dieses Dokument richtet sich an Cloud-Architekten, Netzwerkadministratoren und IT-Experten, die für das Design und die Verwaltung von Windows-Anwendungen verantwortlich sind, die in GKE ausgeführt werden.

Architektur

Das folgende Diagramm zeigt eine Architektur für die Verwaltung von Netzwerken für Windows-Anwendungen, die in GKE ausgeführt werden, mit Cloud Service Mesh und Envoy-Gateways:

Daten fließen über einen internen Application Load Balancer und ein Envoy-Gateway.

Die Architektur umfasst die folgenden Komponenten:

  • Einen regionalen GKE-Cluster mit Windows- und Linux-Knotenpools.
  • Zwei Windows-Anwendungen, die in zwei separaten GKE-Pods ausgeführt werden.
  • Cloud Service Mesh erstellt und verwaltet die Traffic-Routen zu den NEGs für jeden GKE-Pod. Jede Route wird einer bestimmten scope zugeordnet. scope identifiziert 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 zum GKE-Cluster fungieren.
  • Envoy-Gateways, die auf Linux-Knoten ausgeführt werden. Die Gateways sind so konfiguriert, dass der Traffic über die entsprechenden Dienste an die Windows-Anwendungen weitergeleitet wird. Envoy ist so konfiguriert, dass mit dem Parameter scope die Konfigurationsdetails der relevanten Cloud Service Mesh-Dienste geladen werden.
  • Ein interner Application Load Balancer, der SSL-Traffic beendet und den gesamten externen eingehenden Traffic an die Envoy-Gateways weiterleitet.

Verwendete Produkte

In dieser Referenzarchitektur werden die folgenden Google Cloud und Drittanbieterprodukte verwendet:

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 Infrastruktur von Google 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 Anwendungs-Gateway.
  • Gateway API: Ein offizielles Kubernetes-Projekt, das sich auf das L4- und L7-Routing in Kubernetes konzentriert.

Anwendungsfall

Der Hauptanwendungsfall für diese Referenzarchitektur ist die Verwaltung des Netzwerkverkehrs für Windows-Anwendungen, die in GKE ausgeführt werden. Diese Architektur bietet folgende Vorteile:

Vereinfachte Netzwerkverwaltung: Cloud Service Mesh und Envoy-Gateways bieten eine vereinfachte Netzwerkverwaltung über eine zentrale Steuerungsebene, die den Netzwerk-Traffic zu Anwendungen verwaltet. Diese Anwendungen können entweder Linux- oder Windows-Anwendungen sein, die in GKE oder Compute Engine ausgeführt werden. Durch die Verwendung dieses vereinfachten Netzwerkverwaltungsschemas wird der Bedarf an manueller Konfiguration reduziert.

Verbesserte Skalierbarkeit und Verfügbarkeit: Mit Cloud Service Mesh und Envoy-Gateways können Sie Ihre Linux- und Windows-Anwendungen an Ihre sich ändernden Anforderungen anpassen. Sie können auch Envoy-Gateways verwenden, um die Hochverfügbarkeit Ihrer Anwendungen zu gewährleisten, indem Sie den Traffic auf mehrere Pods verteilen.

Verbesserte Sicherheit: Mit Envoy-Gateways können Sie Ihren Linux- und Windows-Anwendungen Sicherheitsfunktionen wie SSL-Terminierung, Authentifizierung und Ratenbegrenzung hinzufügen.

Geringere Kosten: Sowohl Cloud Service Mesh als auch Envoy-Gateways können dazu beitragen, die Kosten für die Verwaltung des Netzwerkverkehrs für Linux- und Windows-Anwendungen zu senken.

Designaspekte

Dieser Abschnitt enthält eine Anleitung zum Entwickeln einer Architektur, die Ihren spezifischen Anforderungen an Sicherheit, Zuverlässigkeit, Kosten und Effizienz entspricht.

Sicherheit

  • Sichere Netzwerkverbindung: Die Architektur verwendet einen internen Application Load Balancer, um eingehenden Traffic zu den Windows-Containern zu verschlüsseln. Die Verschlüsselung während der Übertragung trägt dazu bei, Datenverluste zu verhindern.
  • Windows-Container: Windows-Container bieten eine sichere und isolierte Umgebung für containerisierte Anwendungen.

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 und hat keinen Single Point of Failure. So ist sie immer verfügbar, auch wenn eine oder mehrere Komponenten ausfallen.
  • Autoscaling: Die Architektur verwendet Autoscaling, um die Anzahl der Envoy-Gateways und Windows-Container automatisch an die Last anzupassen. Mit Autoscaling wird dafür gesorgt, dass die Gateways und die Anwendungen auch bei Trafficspitzen keine Leistungsprobleme haben.
  • Monitoring: In der Architektur werden Google Cloud Managed Service for Prometheus und Cloud Operations verwendet, um den Zustand der Envoy-Gateways und Windows-Container zu überwachen. Durch die Überwachung können Sie Probleme frühzeitig erkennen und möglicherweise verhindern, dass sie Ihre Anwendungen beeinträchtigen.

Kostenoptimierung

  • Wählen Sie die richtigen Instanztypen für Ihre Arbeitslasten aus: Berücksichtigen Sie bei der Auswahl von Instanztypen die folgenden Faktoren:
    • Die Anzahl der vCPUs und der Arbeitsspeicher, die für Ihre Anwendungen erforderlich sind
    • Die erwartete Traffic-Last für Ihre Anwendungen
    • Nutzer benötigen hochverfügbare Anwendungen

  • Autoscaling verwenden: Mit Autoscaling können Sie Kosten sparen, indem Sie Ihre Windows-Arbeitslasten automatisch vertikal und horizontal skalieren.

    • Beim vertikalen Skalieren werden Containeranfragen und ‑limits entsprechend der Kundennutzung angepasst.

    • Beim horizontalen Skalieren werden Kubernetes-Pods hinzugefügt oder entfernt, um die Nachfrage zu decken.

  • Cloud Service Mesh- und Envoy-Gateways verwenden: Cloud Service Mesh- und Envoy-Gateways können Ihnen helfen, Geld zu sparen, indem sie Traffic effizient an Ihre Windows-Anwendungen weiterleiten. Durch effizienteres Routing können Sie die benötigte Bandbreite reduzieren. Außerdem kann die Leistung dieser Anwendungen verbessert werden.

  • Freigegebene VPC-Netzwerke (Virtual Private Cloud) verwenden: Mit freigegebenen VPC-Netzwerken können Sie eine einzelne VPC für mehrere Projekte freigeben. Durch die gemeinsame Nutzung können Sie Geld sparen, da Sie weniger VPCs erstellen und verwalten müssen.

Operative Effizienz

  • Mehrere Domains mit einem einzelnen internen Load Balancer: In der Architektur werden interne Application Load Balancer verwendet, um SSL-Traffic auszulagern. Jeder HTTPS-Zielproxy kann mehrere SSL-Zertifikate (bis zum unterstützten Maximum) unterstützen, um mehrere Anwendungen mit unterschiedlichen Domains zu verwalten.
  • Infrastructure as Code (IaC): Zur Verwaltung der Infrastruktur kann die Architektur mit IaC bereitgestellt werden. IaC trägt dazu bei, dass Ihre Infrastruktur konsistent und wiederholbar ist.

Bereitstellung

Informationen zum Bereitstellen dieser Architektur finden Sie unter Windows-Anwendungen bereitstellen, die in einer verwalteten Kubernetes-Umgebung ausgeführt werden.

Nächste Schritte

Beitragende

Autor: Eitan Eibschutz | Staff Technical Solutions Consultant

Weitere Beitragende: