Übersicht über das Dienstnetzwerk

Auf dieser Seite wird beschrieben, wie Sie Dienste in Google Kubernetes Engine (GKE) bereitstellen. Auf dieser Seite finden Sie eine Anleitung zu den Aspekten des Service-Netzwerks und der in GKE vorhandenen Service-Netzwerkfunktionen.

Übersicht über das Dienstnetzwerk

In einem Service-Netzwerk werden Anwendungen so veröffentlicht, dass die zugrunde liegende Inhaberschaft, die Implementierung oder die Umgebung der Anwendung, die die Clients nutzen, abstrahiert wird. In der einfachsten Form ist ein Service ein sicherer, einheitlicher und verfügbarer Endpunkt, über den auf eine Anwendung zugegriffen wird.

Clients und Anwendungen haben unterschiedliche Anforderungen dazu, wie sie kommunizieren können und sollten. Dies kann so einfach sein, wie Ihre Anwendung im Kubernetes-Cluster verfügbar zu machen, damit Pods sie nutzen können, oder so kompliziert wie das Weiterleiten von Traffic von Internetclients auf der ganzen Welt. GKE bietet viele Möglichkeiten für die Bereitstellung von Anwendungen als Services, die Ihren spezifischen Anwendungsfällen entsprechen.

Bestandteile eines Service

Das Freigeben einer Anwendung für Clients betrifft drei Hauptbestandteile eines Service:

  • Frontend: Das Frontend des Load-Balancers definiert den Bereich, in dem Clients auf den Load-Balancer zugreifen und Traffic an ihn senden können. Dies ist der Netzwerkspeicherort, der den Traffic überwacht. Er hat ein Netzwerk, eine bestimmte Region (oder ein Subnetz innerhalb des Netzwerks), eine oder mehrere IP-Adressen im Netzwerk, Ports, bestimmte Protokolle sowie TLS-Zertifikate, die für die Herstellung sicherer Verbindungen bereitgestellt werden.

  • Routing und Load-Balancing: Routing und Load-Balancing definieren, wie Sie Ihren Traffic verarbeiten und weiterleiten. Sie können Traffic anhand von Parametern wie Protokollen, HTTP-Headern und HTTP-Pfaden an Services weiterleiten. Je nach verwendetem Load-Balancer wird der Traffic möglicherweise ausgeglichen, um eine niedrigere Latenz und erhöhte Ausfallsicherheit für Ihre Kunden zu gewährleisten.

  • Back-Ends: Die Load-Balancer-Back-Ends werden durch den Typ der Endpunkte, der Plattform und der Back-End-Service-Discovery-Integration definiert. GKE verwendet die Service-Discovery-Integration, um Load-Balancer-Back-Ends dynamisch zu aktualisieren, wenn die Verfügbarkeit von GKE-Endpunkte beginnt und endet.

Das folgende Diagramm veranschaulicht diese Konzepte für internen und externen Traffic:

In diesem Diagramm überwacht der externe Application Load Balancer über Hunderte von Google-PoPs (Points of Presence) auf der ganzen Welt Traffic im öffentlichen Internet. Dieses globale Frontend ermöglicht das Beenden von Traffic am Netzwerkrand in der Nähe von Clients, bevor der Traffic auf die Back-Ends in einem Google-Rechenzentrum verteilt wird.

Der interne Application Load Balancer überwacht den Bereich Ihres VPC-Netzwerks, sodass private Kommunikation intern möglich ist. Diese Load-Balancer-Attribute machen verschiedene Arten von Anwendungsfällen möglich.

Informationen zum GKE-Load-Balancing

Zum Bereitstellen von Anwendungen außerhalb eines GKE-Clusters bietet GKE einen integrierten GKE-Ingress-Controller und einen GKE-Dienstcontroller, die Load-Balancer im Auftrag von GKE-Nutzern bereitstellen. Dies ist mit der VM-Load-Balancing-Infrastruktur identisch, abgesehen davon, dass der Lebenszyklus vollständig automatisiert ist und von GKE gesteuert wird. Die GKE-Netzwerk-Controller bieten containernatives Pod-IP-Load-Balancing über strikte, höherstufige Schnittstellen, die den Standards von Ingress und Service API entsprechen.

Das folgende Diagramm zeigt, wie die GKE-Netzwerk-Controller die Erstellung von Load-Balancern automatisieren:

Wie im Diagramm dargestellt, stellt ein Infrastruktur- oder Anwendungsadministrator ein deklaratives Manifest für seinen GKE-Cluster bereit. Ingress- und Service-Controller schauen nach GKE-Netzwerkressourcen wie Ingress-Objekten und stellen Load-Balancer (einschließlich IP-Adressen, Firewallregeln usw.) auf Grundlage des Manifests bereit.

Der Controller verwaltet weiterhin den Load-Balancer und Back-Ends auf der Grundlage von Umgebungs- und Trafficänderungen. Aus diesem Grund wird das GKE-Load-Balancing zu einem dynamischen und selbstverwalteten Load-Balancer mit einer entwicklerorientierten Schnittstelle.

Methode zum Freigeben der Anwendung auswählen

Wenn Sie sich für eine Methode zum Bereitstellen Ihrer Anwendung in GKE entscheiden, sind das Clientnetzwerk, das Protokoll und die Regionalität der Anwendung die wichtigsten Faktoren. Mit den Ingress- und Service-Controllern von GKE können Sie Ihre Anwendungen unter Berücksichtigung dieser Faktoren bereitstellen.

In den folgenden Abschnitten werden nicht alle Aspekte des Anwendungsnetzwerks abgedeckt. Die Betrachtung der folgenden Faktoren kann Ihnen jedoch helfen zu ermitteln, welche Lösungen für Ihre Anwendungen am besten geeignet sind. In den meisten GKE-Umgebungen werden viele verschiedene Arten von Anwendungen mit jeweils speziellen Anforderungen gehostet. Wahrscheinlich werden Sie in einem Cluster also mehrere verwenden.

Einen detaillierten Vergleich der Ingress-Funktionen finden Sie unter Ingress-Konfiguration.

Clientnetzwerk

Ein Clientnetzwerk bezieht sich auf das Netzwerk, von dem aus Ihre Anwendungsclients auf die Anwendung zugreifen. Dies wirkt sich darauf aus, wo das Frontend Ihres Load-Balancers etwas überwachen soll. Beispiel: Clients können sich innerhalb desselben GKE-Clusters wie die Anwendung befinden. In diesem Fall greifen sie von innerhalb des Clusternetzwerks auf Ihre Anwendung zu, um ihnen die Nutzung des nativen ClusterIP-Load-Balancings von Kubernetes zu ermöglichen.

Clients können auch interne Netzwerkclients sein, die von innerhalb der Virtual Private Cloud (VPC) oder von einem lokalen Netzwerk über ein Cloud Interconnect auf Ihre Anwendung zugreifen.

Clients können auch extern sein und über das öffentliche Internet auf Ihre Anwendung zugreifen. Jede Art von Netzwerk legt eine andere Load-Balancing-Topologie fest.

In GKE können Sie zwischen internen und externen Load-Balancern wählen. Intern bezieht sich auf das VPC-Netzwerk, ein internes privates Netzwerk, das nicht direkt über das Internet zugänglich ist. Extern bezieht sich auf das öffentliche Internet. ClusterIP-Services sind intern in einen einzelnen GKE-Cluster vorhanden, sodass sie einem noch kleineren Netzwerk als dem VPC-Netzwerk zugeordnet sind.

In der folgenden Tabelle erhalten Sie einen Überblick über die für interne und externe Netzwerke verfügbaren Lösungen.

Netzwerktyp Verfügbare Lösungen
Intern ClusterIP-Dienst
NodePort-Dienst
Interner LoadBalancer-Dienst
Interner Ingress
Extern NodePort-Dienst1
Externer LoadBalancer-Dienst
Externer Ingress
Multi-Cluster-Ingress

1 Öffentliche GKE-Cluster stellen jedem GKE-Knoten öffentliche und private IP-Adressen zur Verfügung, damit NodePort-Dienste intern und extern zugänglich sind.

Protokoll

Ein Protokoll ist die Sprache, in der Ihre Clients mit der Anwendung sprechen. Anwendungen für Sprachverarbeitung oder Gaming und Anwendungen mit niedriger Latenz verwenden häufig TCP oder UDP direkt und benötigen dann Load-Balancer, die in Schicht 4 detailliert gesteuert werden können. Andere Anwendungen nutzen HTTP, HTTPS, gRPC oder HTTP2 und erfordern Load-Balancer mit ausdrücklicher Unterstützung dieser Protokolle. Durch die Angabe von Protokollanforderungen wird außerdem definiert, welche Arten von Methoden der Anwendungsfreigabe am besten geeignet sind.

In GKE können Sie Schicht-4-Load-Balancer konfigurieren, die den Traffic basierend auf Netzwerkinformationen wie Port und Protokoll weiterleiten, sowie Schicht-7-Load-Balancer, die über Anwendungsinformationen wie Clientsitzungen verfügen. Jeder der Load-Balancer hat eine spezifische Protokollunterstützung, wie in der folgenden Tabelle dargestellt:

Schichten Protokolle Verfügbare Lösungen
L4 TCP
UDP		 ClusterIP-Dienst
NodePort-Dienst
Interner LoadBalancer-Dienst
Externer LoadBalancer-Dienst
L7 HTTP
HTTPS
HTTP2 		Interner Ingress
Externer Ingress
Multi-Cluster-Ingress

Anwendungsregionalität

Die Anwendungsregionalität bezieht sich auf den Grad, in dem Ihre Anwendung auf mehr als eine Region oder einen GKE-Cluster verteilt wird. Das Hosten einer einzelnen Instanz einer Anwendung hat andere Anforderungen als das Hosten redundanter Instanzen einer Anwendung in zwei unabhängigen GKE-Clustern. Wenn Sie eine geografisch verteilte Anwendung in fünf GKE-Clustern hosten, um Arbeitslasten näher am Endnutzer zu platzieren, benötigen Sie ein größeres Multi-Cluster- und multiregionales Bewusstsein für den Load-Balancer.

Sie können die Regionalität der GKE-Load-Balancing-Lösungen in zwei Bereiche unterteilen:

  • Back-End-Bereich (oder Clusterbereich): Dieser Bereich gibt an, ob ein Load-Balancer Traffic an Back-Ends über mehrere GKE-Cluster senden kann. Multi-Cluster-Ingress bietet die Möglichkeit, eine einzelne virtuelle IP-Adresse zur Verfügung zu stellen, die Traffic an Pods aus verschiedenen Clustern und Regionen weiterleitet.

  • Frontend-Bereich: Dieser Bereich bezieht sich darauf, ob eine IP des Load-Balancers innerhalb einer einzelnen Region oder in mehreren Regionen überwacht wird. Alle externen Load-Balancer überwachen das Internet, das von Natur aus multiregional ist, aber einige interne Load-Balancer überwachen nur innerhalb einer Region.

In der folgenden Tabelle werden die GKE-Load-Balancing-Lösungen dieser beiden Dimensionen aufgeschlüsselt.

Back-End-Bereich
(Clusterbereich)		 Verfügbare Lösungen
Single-Cluster ClusterIP-Dienst
NodePort-Dienst
Interner LoadBalancer-Dienst
Externer LoadBalancer-Dienst
Interner Ingress
Externer Ingress
Multi-Cluster Multi-Cluster-Ingress
Frontend-Bereich Verfügbare Lösungen
Regional ClusterIP-Dienst
Interner Ingress
Global ClusterIP-Dienst
NodePort-Dienst
Interner LoadBalancer-Dienst
Externer LoadBalancer-Dienst
Externer Ingress
Multi-Cluster-Ingress

Andere Lösungen für die Anwendungsfreigabe

Die oben aufgeführten Lösungen sind nicht die einzigen verfügbaren Lösungen für die Anwendungsfreigabe. Die folgenden Lösungen können auch GKE-Load-Balancer ersetzen oder ergänzen.

Ingress innerhalb des Clusters

Clusterinterner Ingress bezieht sich auf Software-Ingress-Controller, deren Ingress-Proxys im Kubernetes-Cluster gehostet werden. Dies unterscheidet sich von GKE-Ingress-Controllern, die ihre Load-Balancing-Infrastruktur getrennt vom Kubernetes-Cluster hosten und verwalten. Diese Lösungen von Drittanbietern werden häufig vom Clusteroperator bereitgestellt und selbst verwaltet. istio-ingressgateway und nginx-ingress sind zwei Beispiele für häufig verwendete und Open-Source-Controller für clusterinternen Ingress.

Die Controller für clusterinternen Ingress entsprechen in der Regel der Spezifikation für Kubernetes-Ingress und bieten unterschiedliche Funktionen und Nutzerfreundlichkeit. Die Open-Source-Lösungen erfordern wahrscheinlich eine genauere Verwaltung und ein höheres technisches Fachwissen, aber sie können auch Ihren Anforderungen entsprechen, wenn sie spezielle Funktionen bereitstellen, die Ihre Anwendungen erfordern. Außerdem gibt es viele Ingress-Lösungen für Unternehmen, die auf der Open-Source-Community basieren und erweiterte Features und Enterprise-Support bieten.

Eigenständige Netzwerk-Endpunktgruppen (NEGs)

GKE-Ingress- und -Service-Controller bieten automatisierte, deklarative und Kubernetes-native Methoden zur Bereitstellung von Cloud Load Balancing. Es gibt auch gültige Anwendungsfälle für die manuelle Bereitstellung von Load-Balancern für GKE-Back-Ends, z. B. direkte und detailliertere Kontrolle über den Load-Balancer oder Load-Balancing zwischen Container- und VM-Back-Ends.

Eigenständige NEGs bieten die Möglichkeit, dass Pod-Back-End-IPs dynamisch für eine NEG aktualisiert werden, aber das Front-End des Load-Balancers manuell bereitgestellt wird. Dies bietet maximale und direkte Kontrolle über den Load-Balancer und behält dynamische Back-Ends bei, die vom GKE-Cluster gesteuert werden.

Service Mesh

Service Meshes bieten ein clientseitiges Load-Balancing über eine zentrale Steuerungsebene. Traffic Director und Anthos Service Mesh ermöglichen das Load-Balancing von internem Traffic über GKE-Cluster in verschiedenen Regionen sowie auch zwischen Containern und VMs. Dies verwischt die Grenze zwischen internem Load-Balancing (Ost-West-Traffic) und Anwendungsfreigabe (Nord-Süd-Traffic). Aufgrund der Flexibilität und der Reichweite moderner Service Mesh-Steuerungsebenen ist es immer wahrscheinlicher, dass Client und Server im selben Service Mesh-Bereich liegen. Die vorherigen GKE-Lösungen für Ingress und Dienste stellen im Allgemeinen Load-Balancer des mittleren Proxys für Clients bereit, die keine eigenen Sidecar-Proxys haben. Wenn sich jedoch Client und Server im selben Mesh-Netzwerk befinden, kann die Anwendungsfreigabe über das Mesh und nicht das Load-Balancing des mittleren Proxys gesteuert werden.

Nächste Schritte