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 der Google Kubernetes Engine (GKE) ausgeführt werden. Dort wird erläutert, wie Sie diesen Netzwerkverkehr mithilfe eines Dienstes verwalten, der Traffic an Pods und an einen Open-Source-xDS-kompatiblen Proxy weiterleiten kann. Die Verwendung einer solchen 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 der GKE ausgeführt werden.

Architektur

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

Die 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. Diese scope identifiziert eindeutig ein Cloud Service Mesh-Ingress-Gateway.
  • HTTP-Routen, die den Back-End-Diensten für Cloud Service Mesh zugeordnet sind.
  • Envoy-Container-Pods, die als Envoy-Gateway zum GKE-Cluster dienen.
  • 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 die Konfigurationsdetails der entsprechenden Cloud Service Mesh-Dienste mit dem Parameter scope 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 Anwendungsgateway.
  • Gateway API: Ein offizielles Kubernetes-Projekt, das sich auf L4- und L7-Routing in Kubernetes konzentriert.

Anwendungsfall

Der Hauptanwendungsfall für diese Referenzarchitektur besteht darin, den Netzwerkverkehr für Windows-Anwendungen zu verwalten, die in GKE ausgeführt werden. Diese Architektur bietet folgende Vorteile:

Vereinfachte Netzwerkverwaltung: Cloud Service Mesh und Envoy-Gateways ermöglichen eine vereinfachte Netzwerkverwaltung über eine zentrale Steuerebene, die den Netzwerkverkehr zu Anwendungen verwaltet. Diese Anwendungen können Linux- oder Windows-Anwendungen sein, die in GKE oder Compute Engine ausgeführt werden. Durch dieses vereinfachte Netzwerkverwaltungsschema ist weniger manuelle Konfiguration erforderlich.

Erhöhte Skalierbarkeit und Verfügbarkeit: Mit Cloud Service Mesh und Envoy-Gateways können Sie Ihre Linux- und Windows-Anwendungen skalieren, um sich an sich ändernde Anforderungen anzupassen. Sie können auch Envoy-Gateways verwenden, um eine hohe Verfügbarkeit für Ihre Anwendungen zu gewährleisten, indem Sie den Traffic über mehrere Pods hinweg ausbalancieren.

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

Reduzierte 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 Netzwerke: In der Architektur wird ein interner Application Load Balancer verwendet, um eingehenden Traffic an die Windows-Container zu verschlüsseln. Die Verschlüsselung während der Übertragung trägt dazu bei, Datenlecks zu verhindern.
  • Windows-Container: Windows-Container bieten eine sichere und isolierte Umgebung für containerisierte Anwendungen.

Zuverlässigkeit

  • Load Balancing: Die Architektur verwendet mehrere Cloud Load Balancing-Ebenen, 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 die Verfügbarkeit auch dann gewährleistet, wenn eine oder mehrere Komponenten ausfallen.
  • Autoscaling: Bei dieser Architektur wird die Anzahl der Envoy-Gateways und Windows-Container basierend auf der Last automatisch mithilfe von Autoscaling skaliert. Mit Autoscaling wird dafür gesorgt, dass die Gateways und Anwendungen Trafficspitzen bewältigen können, ohne dass es zu Leistungsproblemen kommt.
  • 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 Monitoring können Sie Probleme frühzeitig erkennen und so möglicherweise 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-Last für Ihre Anwendungen
    • Die Notwendigkeit für Nutzer, hochverfügbare Anwendungen zu haben

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

    • Bei der vertikalen Skalierung werden Containeranfragen und -limits an die Nutzung durch den Kunden angepasst.

    • Bei der horizontalen Skalierung werden Kubernetes-Pods hinzugefügt oder entfernt, um die Nachfrage zu erfüllen.

  • 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. Mit einem effizienteren Routing können Sie die Bandbreite, die Sie erwerben müssen, 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 Freigabe können Sie Geld sparen, da die Anzahl der VPCs, die Sie erstellen und verwalten müssen, reduziert wird.

Operative Effizienz

  • Mehrere Domains mit einem einzigen internen Load Balancer: In dieser Architektur werden interne Application Load Balancer verwendet, 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. Mit IaC können Sie dafür sorgen, dass Ihre Infrastruktur konsistent und wiederholbar ist.

Bereitstellung

Informationen zum Bereitstellen dieser Architektur finden Sie unter Windows-Anwendungen in einer verwalteten Kubernetes-Umgebung bereitstellen.

Nächste Schritte

Beitragende

Autor: Eitan Eibschutz | Technical Solutions Consultant

Weitere Beitragende: