Auf dieser Seite erfahren Sie, wie Sie einen Kubernetes-Service erstellen, der von einer zonalen Netzwerk-Endpunktgruppe (NEG) unterstützt wird.
Informationen zu den Vorteilen, Anforderungen und Einschränkungen des containernativen Load-Balancing finden Sie unter Containernatives Load-Balancing.
Übersicht
Eine Netzwerk-Endpunktgruppe (NEG) stellt eine Gruppe von Back-Ends dar, für die ein Load-Balancer die Bereitstellung übernimmt. NEGs sind Listen mit IP-Adressen, die von einem NEG-Controller verwaltet und von Google Cloud-Load-Balancern verwendet werden. NEG-IP-Adressen können primäre oder sekundäre IP-Adressen einer VM sein, d. h. es kann sich um Pod-IP-Adressen handeln. Dadurch wird das containernative Load-Balancing aktiviert, das Traffic von einem Google Cloud-Load-Balancer direkt an Pods sendet.
Im folgenden Diagramm wird gezeigt, welche Kubernetes API-Objekte welchen Compute Engine-Objekten entsprechen.
Ingress mit NEGs
Wenn NEGs mit GKE Ingress verwendet werden, erleichtert der Ingress-Controller das Erstellen aller Aspekte des L7-Load-Balancers. Dazu gehören das Erstellen der virtuellen IP-Adresse, Weiterleitungsregeln, Systemdiagnosen, Firewallregeln usw.
Ingress ist die empfohlene Methode für den Einsatz von containernativem Load-Balancing, da es viele Features bietet, die das Verwalten von NEGs vereinfachen. Eigenständige NEGs sind dann eine Option, wenn von Ingress verwaltete NEGs nicht für Ihren Anwendungsfall geeignet sind.
Eigenständige NEGs
Wenn NEGs mit Load-Balancer bereitgestellt werden, die nicht von Ingress bereitgestellt werden, werden sie als eigenständige NEGs betrachtet. Eigenständige NEGs werden über den NEG-Controller bereitgestellt und verwaltet, aber die Weiterleitungsregeln, Systemdiagnosen und andere Load-Balancing-Objekte werden manuell bereitgestellt.
Eigenständige NEGs stehen mit containernativem Ingress-Load-Balancing nicht in Konflikt.
Die folgende Abbildung zeigt die Unterschiede bei der Bereitstellung der Load-Balancing-Objekte in den jeweiligen Szenarien:
Gehackte NEGs verhindern
Bei eigenständigen NEGs sind Sie für die Verwaltung der Lebenszyklen von NEGs und der Ressourcen für den Load-Balancer verantwortlich. NEGs können auf folgende Arten gehackt werden:
- Wenn ein GKE-Dienst gelöscht wird, wird für die zugeordnete NEG keine automatische Speicherbereinigung ausgeführt, wenn ein Back-End-Dienst weiterhin auf die NEG verweist. Damit die NEG gelöscht werden kann, entfernen Sie den Verweis für die NEG aus dem Back-End-Dienst.
- Beim Löschen eines Clusters werden eigenständige NEGs nicht gelöscht.
Anwendungsfälle für eigenständige NEGs
Für eigenständige NEGs gibt es mehrere kritische Verwendungszwecke. Sie sind sehr flexibel. Beim Ingress (egal ob mit oder ohne NEGs verwendet) verhält es sich gegensätzlich, da dieses einen bestimmten Satz von Load-Balancing-Objekten definiert, die nach bestimmten Kriterien für eine einfache Verwendung ausgewählt wurden.
Zu den Anwendungsfällen für eigenständige NEGs gehören folgende:
Heterogene Services von Containern und VMs
NEGs können sowohl VM- als auch Container-IP-Adressen enthalten. Dies bedeutet, dass eine einzelne virtuelle IP-Adresse auf ein Back-End verweisen kann, das sowohl aus Kubernetes-Arbeitslasten als auch aus Nicht-Kubernetes-Arbeitslasten besteht. Dies macht es auch möglich, vorhandene Arbeitslasten zu einem GKE-Cluster zu migrieren.
Eigenständige NEGs können auf VM-IP-Adressen verweisen, sodass Load-Balancers manuell so konfiguriert werden können, dass sie auf Back-Ends verweisen, die sowohl VMs als auch Container für dieselbe Service-VIP enthalten.
Benutzerdefinierte Ingress-Controller
Sie können einen benutzerdefinierten Ingress-Controller (oder keinen Ingress-Controller) verwenden, um Load-Balancer zu konfigurieren, die auf eigenständige NEGs abzielen.
Traffic Director mit GKE verwenden
Traffic Director mit GKE. Traffic Director verwendet eigenständige NEGs, um containernatives Load-Balancing für das verwaltete Service Mesh bereitzustellen.
TCP-Proxy-Load-Balancing mit GKE verwenden
Sie können eigenständige NEGs verwenden, um die Last mit dem TCP-Proxy-Load-Balancer, der von Kubernetes/GKE nicht nativ unterstützt wird, direkt auf Container zu verteilen.
Pod-Bereitschaft
Readiness-Gates sind ein Erweiterungs-Feature von Kubernetes, mit dem zusätzliches Feedback oder zusätzliche Signale in den PodStatus eingefügt werden können, damit der Pod in den Status "Bereit" wechseln kann. Der NEG-Controller verwaltet ein benutzerdefiniertes Readiness-Gate, damit der vollständige Netzwerkpfad vom Compute Engine-Load-Balancer zum Pod funktioniert. Die Funktionsweise von Pod-Readiness-Gates in GKE wird unter Containernatives Load-Balancing erläutert.
Wird Ingress mit NEGs verwendet, stellt es Compute Engine-Systemdiagnosen im Namen des Load-Balancers bereit und verwaltet sie. Eigenständige NEGs treffen jedoch keine Annahmen hinsichtlich Compute Engine-Systemdiagnosen, da erwartet wird, dass sie separat bereitgestellt und verwaltet werden. Compute Engine-Systemdiagnosen sollten immer zusammen mit dem Load-Balancer konfiguriert werden, um zu verhindern, dass Traffic an Back-Ends gesendet wird, die noch nicht empfangsbereit sind. Wenn der NEG kein Systemdiagnosestatus zugeordnet ist (normalerweise, weil keine Systemdiagnose konfiguriert ist), markiert der NEG-Controller den Readiness Gate-Wert des Pods dann als "True", wenn der entsprechende Endpunkt in der NEG programmiert wurde.
Voraussetzungen
Eigenständige NEGs sind in GKE 1.10 und höher verfügbar. Pod-Bereitschaftsfeedback ist für eigenständige NEGs in Version 1.16.4 und höher aktiviert.
Der Cluster muss VPC-nativ sein. Weitere Informationen finden Sie unter VPC-native Cluster mithilfe von Alias-IP-Adressen erstellen.
In Ihrem Cluster muss HTTP-Load-Balancing aktiviert sein. Für GKE-Cluster ist das HTTP-Load-Balancing standardmäßig aktiviert. Sie dürfen es nicht deaktivieren.
Vorbereitung
Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:
- Achten Sie darauf, dass die Google Kubernetes Engine API aktiviert ist. Aktivieren Sie Google Kubernetes Engine API
- Prüfen Sie, ob das Cloud SDK installiert ist.
Mit den folgenden Methoden können Sie die gcloud
-Einstellungen festlegen:
- Verwenden Sie
gcloud init
, wenn Sie die Standardeinstellungen ansehen möchten. - Verwenden Sie
gcloud config
, um Ihre Projekt-ID, Zone und Region individuell festzulegen.
gcloud init verwenden
Wenn Sie die Fehlermeldung One of [--zone, --region] must be supplied: Please specify
location
erhalten, führen Sie diesen Abschnitt aus.
-
Führen Sie
gcloud init
aus und folgen Sie der Anleitung:gcloud init
Wenn Sie SSH auf einem Remote-Server verwenden, können Sie mit dem Flag
--console-only
verhindern, dass mit dem Befehl ein Browserfenster geöffnet wird:gcloud init --console-only
- Folgen Sie der Anleitung, um
gcloud
zur Verwendung Ihres Google Cloud-Kontos zu autorisieren. - Erstellen Sie eine neue Konfiguration oder wählen Sie eine vorhandene aus.
- Wählen Sie ein Google Cloud-Projekt aus.
- Wählen Sie eine Compute Engine-Standardzone aus.
gcloud config verwenden
- Legen Sie Ihre standardmäßige Projekt-ID fest:
gcloud config set project project-id
- Wenn Sie mit zonalen Clustern arbeiten, legen Sie die Compute-Standardzone fest:
gcloud config set compute/zone compute-zone
- Wenn Sie mit regionalen Clustern arbeiten, legen Sie die Standardregion für Compute Engine fest:
gcloud config set compute/region compute-region
- Aktualisieren Sie
gcloud
auf die neueste Version:gcloud components update
Eigenständige NEGs verwenden
In der folgenden Anleitung wird gezeigt, wie Sie eigenständige NEGs mit einem externen HTTP-Load-Balancer in GKE verwenden.
Dazu müssen mehrere Objekte erstellt werden:
- Ein Deployment, das Pods erstellt und verwaltet.
- Ein Service, der eine NEG erstellt.
- Ein Load-Balancer, der mit der Compute Engine API erstellt wurde. Wenn Sie NEGs mit Ingress verwenden, gilt dies nicht. In diesem Fall erstellt und konfiguriert Ingress den Load-Balancer für Sie. Bei eigenständigen NEGs sind Sie dafür verantwortlich, die NEGs mit dem Back-End-Service zu verknüpfen, um die Pods mit dem Load-Balancer zu verbinden. Der Load-Balancer besteht aus mehreren Komponenten, wie im folgenden Diagramm dargestellt:
VPC-nativen Cluster erstellen
Damit containernatives Load-Balancing verwendet werden kann, müssen Sie einen Cluster mit aktivierten Alias-IP-Adressen erstellen. Auf diesen Cluster muss Folgendes zutreffen:
- Er muss in Google Kubernetes Engine Version 1.16.4 oder höher ausgeführt werden.
- Es muss ein VPC-nativer Cluster sein.
- Das HTTP-Load-Balancing-Add-on muss aktiviert sein. Für GKE-Cluster ist das HTTP-Load-Balancing standardmäßig aktiviert und darf nicht deaktiviert werden.
Mithilfe des folgenden Befehls wird in der Zone us-central1-a
der Cluster neg-demo-cluster mit einem automatisch bereitgestellten Subnetzwerk erstellt:
gcloud container clusters create neg-demo-cluster \
--enable-ip-alias \
--create-subnetwork="" \
--network=default \
--zone=us-central1-a \
--cluster-version version
Dabei muss die Cluster-version mindestens 1.16.4 sein.
Deployment erstellen
Die folgenden Manifeste legen das Deployment neg-demo-app fest, das drei Instanzen eines HTTP-Containerservers ausführt. Der HTTP-Server antwortet auf Anfragen mit dem Hostnamen des Anwendungsservers, dem Namen des Pods, auf dem der Server ausgeführt wird.
Wir empfehlen die Verwendung von Arbeitslasten, bei denen Feedback zur Pod-Bereitschaft zum Einsatz kommt, falls dies in der von Ihnen verwendeten GKE-Version verfügbar ist. Weitere Informationen finden Sie oben im Abschnitt Pod-Bereitschaft. Im Abschnitt Anforderungen finden Sie die GKE-Versionsanforderungen für die Verwendung von Feedback zur Pod-Bereitschaft. Unter Umständen müssen Sie ein Upgrade Ihres Clusters durchführen, um das Feedback zur Pod-Bereitschaft verwenden zu können.
mithilfe von Pod-Bereitschaftsfeedback
apiVersion: apps/v1 kind: Deployment metadata: labels: run: neg-demo-app # Label for the Deployment name: neg-demo-app # Name of Deployment spec: replicas: 3 selector: matchLabels: run: neg-demo-app template: # Pod template metadata: labels: run: neg-demo-app # Labels Pods from this Deployment spec: # Pod specification; each Pod created by this Deployment has this specification containers: - image: k8s.gcr.io/serve_hostname:v1.4 # Application to run in Deployment's Pods name: hostname
mithilfe von hartcodierter Verzögerung
apiVersion: apps/v1 kind: Deployment metadata: labels: run: neg-demo-app # Label for the Deployment name: neg-demo-app # Name of Deployment spec: minReadySeconds: 60 # Number of seconds to wait after a Pod is created and its status is Ready replicas: 3 selector: matchLabels: run: neg-demo-app template: # Pod template metadata: labels: run: neg-demo-app # Labels Pods from this Deployment spec: # Pod specification; each Pod created by this Deployment has this specification containers: - image: k8s.gcr.io/serve_hostname:v1.4 # Application to run in Deployment's Pods name: hostname
Speichern Sie dieses Manifest als neg-demo-app.yaml
und erstellen Sie dann das Deployment dadurch, dass Sie folgenden Befehl ausführen:
kubectl apply -f neg-demo-app.yaml
Service erstellen
Das folgende Manifest legt den Service neg-demo-svc fest.
- Jeder Pod mit dem Label
run: neg-demo-app
ist Mitglied dieses Services. - Der Service hat ein ServicePort-Feld mit dem Port 80.
- Die Anmerkung
cloud.google.com/neg
gibt an, dass Port 80 einer NEG zugeordnet wird. Das optionale Feldname
gibt an, dass die NEG neg-name genannt wird. Wird das Feldname
weggelassen, wird automatisch ein eindeutiger Name generiert. Weitere Informationen finden Sie unter NEGs benennen. - Für jeden Mitglieds-Pod ist ein Container erforderlich, der den TCP-Port 9376 beobachtet.
apiVersion: v1
kind: Service
metadata:
name: neg-demo-svc
annotations:
cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "neg-name"}}}'
spec:
type: ClusterIP
selector:
run: neg-demo-app # Selects Pods labelled run: neg-demo-app
ports:
- port: 80
protocol: TCP
targetPort: 9376
Speichern Sie dieses Manifest als neg-demo-svc.yaml
und erstellen Sie dann den Dienst, indem Sie folgenden Befehl ausführen:
kubectl apply -f neg-demo-svc.yaml
Eine NEG wird innerhalb weniger Minuten nach der Erstellung des Services erstellt.
Diensttypen
In diesem Beispiel wird zwar ein ClusterIP
-Service verwendet, aber alle fünf Servicetypen unterstützen eigenständige NEGs. Wir empfehlen den Standardtyp ClusterIP
.
NEGs benennen
Sie können den Namen der NEG angeben oder einen Namen automatisch zuweisen lassen. Die Angabe von NEG-Namen vereinfacht spätere Schritte, da Sie die Namen der NEGs im Voraus kennen, ohne danach suchen zu müssen. Sie müssen jedoch dafür sorgen, dass NEG-Namen in einer bestimmten Region eindeutig sind, da andernfalls Fehler beim Erstellen auftreten. Automatisch generierte NEG-Namen sind immer eindeutig.
Sie können NEG-Namen nur in der GKE-Version 1.18.10-gke.600 und höher festlegen. Automatisch generierte NEG-Namen werden in früheren Versionen verwendet.
Name angeben
Verwenden Sie das Feld name
in der Annotation cloud.google.com/neg
des Dienstes, um einen NEG-Namen anzugeben:
cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "neg-name"}}}'
Ersetzen Sie neg-name durch den Namen der NEG. Der NEG-Name muss in seiner Region eindeutig sein.
Automatisch generierten Namen verwenden
Wenn Sie einen automatisch generierten Namen verwenden möchten, lassen Sie das Feld name
weg:
cloud.google.com/neg: '{"exposed_ports": {"80":{}}}'
Der automatisch generierte Name hat folgendes Format: k8s1-cluster-uid-namespace-service-port-random-hash
Mehreren NEGs Ports zuordnen
Ein Service kann mehr als einen Port im Blick behalten. Definitionsgemäß haben NEGs nur eine IP-Adresse und einen Port. Wenn Sie also einen Service mit mehreren Ports angeben, wird für jeden Port eine NEG erstellt.
Das Format der Anmerkung cloud.google.com/neg
lautet:
cloud.google.com/neg: '{
"exposed_ports":{
"service-port-1":{},
"service-port-2":{},
"service-port-3":{},
...
}'
Dabei steht service-port-n für unterschiedliche Portnummern, die auf vorhandene Serviceports des Services verweisen. Für jeden aufgeführten Serviceport erstellt der NEG-Controller eine NEG in jeder Zone, die der Cluster belegt.
NEG-Status abrufen
Verwenden Sie diesen Befehl, um die Status der Services des Clusters abzurufen:
kubectl get service neg-demo-svc -o yaml
Dieser Befehl gibt den Status der NEGs in folgendem Format aus:
cloud.google.com/neg-status: '{
"network-endpoint-groups":{
"service-port-1": "neg-name-1",
"service-port-1": "neg-name-2",
...
},
"zones":["zone-1", "zone-2", ...]
}
Dabei ist jedes Element in der network-endpoint-groups
-Zuordnung ein Dienstport (service-port-1) und der Name der entsprechenden verwalteten NEGs (z. B. neg-name-1). Die Liste zones
enthält jede Zone (z. B. zone-1), die eine NEG enthält.
Im folgenden Beispiel sehen Sie die vollständige Ausgabe des Befehls:
apiVersion: v1
kind: Service
metadata:
annotations:
cloud.google.com/neg: '{"exposed_ports": {"80":{}}}'
cloud.google.com/neg-status: '{"network_endpoint_groups":{"80":"k8s1-cca197ad-default-neg-demo-app-80-4db81e02"},"zones":["us-central1-a", "us-central1-b"]}'
labels:
run: neg-demo-app
name: neg-demo-app
namespace: default
selfLink: /api/v1/namespaces/default/services/neg-demo-app
...
spec:
clusterIP: 10.0.14.252
ports:
- port: 80
protocol: TCP
targetPort: 9376
selector:
run: neg-demo-app
sessionAffinity: None
status:
loadBalancer: {}
In diesem Beispiel zeigt die Anmerkung, dass der Serviceport 80 für die NEGs mit dem Namen k8s1-cca197ad-default-neg-demo-app-80-4db81e02
in den Zonen us-central1-a
und us-central1-b
verfügbar gemacht wurde.
NEG-Erstellung validieren
Eine NEG wird innerhalb weniger Minuten nach der Erstellung des Services erstellt. Wenn Pods vorhanden sind, die dem im Servicemanifest angegebenen Label entsprechen, enthält die NEG ab ihrem Erstellen die IP-Adressen der Pods.
Es gibt zwei Möglichkeiten, zu prüfen, ob die NEG erstellt und korrekt konfiguriert ist. In GKE 1.18.6-gke.6400 und höher speichert eine benutzerdefinierte Ressource ServiceNetworkEndpointGroup
Statusinformationen zu NEGs, die vom Dienstüberwacher erstellt wurden. In vorherigen Versionen müssen Sie die NEGs direkt prüfen.
ServiceNetworkEndpointGroup
-Ressource
Listen Sie die NEGs in einem Cluster auf. Rufen Sie dazu alle ServiceNetworkEndpointGroup
-Ressourcen ab:
kubectl get svcneg
Überwachen Sie den Status einer NEG. Prüfen Sie dazu den Status der ServiceNetworkEndpointGroup
-Ressource:
kubectl get svcneg neg-name -o yaml
Ersetzen Sie neg-name durch den Namen der einzelnen NEG, die Sie prüfen möchten.
Die Ausgabe dieses Befehls enthält einen Statusabschnitt, der Fehlermeldungen enthalten kann. Einige Fehler werden als Dienstereignis gemeldet. Weitere Details erhalten Sie, wenn Sie das Dienstobjekt abfragen:
kubectl describe service service-name
Ersetzen Sie service-name durch den Namen des entsprechenden Dienstes.
Wenn Sie bestätigen möchten, dass der NEG-Controller die NEG erfolgreich synchronisiert, prüfen Sie das Statusfeld der ServiceNetworkEndpointGroup
-Ressource auf eine Bedingung mit type:Synced
. Die Zeit der letzten Synchronisierung befindet sich im Feld status.lastSyncTime
.
ServiceNetworkEndpointGroup
-Ressourcen gibt es nur in GKE 1.18 und höher.
NEGs direkt prüfen
Prüfen Sie, ob die NEG vorhanden ist, indem Sie die NEGs in Ihrem Google Cloud-Projekt auflisten und prüfen, ob eine NEG mit dem von Ihnen erstellten Service übereinstimmt. Der Name der NEG hat folgendes Format: k8s1-cluster-uid-namespace-service-port-random-hash
Verwenden Sie diesen Befehl, um die NEGs aufzulisten:
gcloud compute network-endpoint-groups list
Die Ausgabe sieht in etwa so aus:
NAME LOCATION ENDPOINT_TYPE SIZE
k8s1-70aa83a6-default-my-service-80-c9710a6f us-central1-a GCE_VM_IP_PORT 3
Diese Ausgabe zeigt, dass die SIZE
der NEG 3 ist, was bedeutet, dass sie drei Endpunkte hat, die den drei Pods im Deployment entsprechen.
Identifizieren Sie die einzelnen Endpunkte mit diesem Befehl:
gcloud compute network-endpoint-groups list-network-endpoints \
k8s1-70aa83a6-default-my-service-80-c9710a6f
Die Ausgabe zeigt drei Endpunkte, wobei jeder Endpunkt die IP-Adresse und den Port eines Pods hat:
INSTANCE IP_ADDRESS PORT
gke-standard-cluster-3-default-pool-4cc71a15-qlpf 10.12.1.43 9376
gke-standard-cluster-3-default-pool-4cc71a15-qlpf 10.12.1.44 9376
gke-standard-cluster-3-default-pool-4cc71a15-w9nk 10.12.2.26 9376
Load-Balancer an eigenständige NEGs anhängen
Nachdem Sie Ihre NEGs erstellt haben, können Sie diese als Back-Ends für die folgenden Arten von Load-Balancern verwenden:
- einen externen HTTP(S)-Load-Balancer
- ein internen HTTP(S)-Load-Balancer
- ein SSL-Proxy-Load-Balancer
- ein TCP-Proxy-Load-Balancer
Die folgenden Beispiele zeigen, wie das geht:
- Externen HTTP(S)-Load-Balancer an eigenständige NEGs anhängen
- Internen HTTP(S)-Load-Balancer an eigenständige NEGs anhängen
Externen HTTP(S)-Load-Balancer an eigenständige NEGs anhängen
In den folgenden Schritten wird gezeigt, wie Sie mit der Compute Engine API einen externen HTTP-Load-Balancer erstellen.
Erstellen Sie Firewallregeln. Load-Balancer benötigen Zugriff auf Clusterendpunkte, um Systemdiagnosen durchzuführen. Mit diesem Befehl werden Firewallregeln erstellt, die diesen Zugriff erlauben:
gcloud compute firewall-rules create fw-allow-health-check-and-proxy \ --network=network-name \ --action=allow \ --direction=ingress \ --target-tags=gke-node-network-tags \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --rules=tcp:9376
Dabei sind gke-node-network-tags die Netzwerk-Tags der GKE-Knoten und network-name ist das Netzwerk, in dem der Cluster ausgeführt wird.
Wenn Sie für Ihre Knoten keine benutzerdefinierten Netzwerk-Tags erstellt haben, generiert GKE die Tags automatisch. Sie können diese automatisch generierten Tags einsehen, indem Sie die Knoten mit folgendem Befehl prüfen:
gcloud compute instances describe node-name
Erstellen Sie für den Load-Balancer eine globale virtuelle IP-Adresse:
gcloud compute addresses create hostname-server-vip \ --ip-version=IPV4 \ --global
Erstellen Sie eine Systemdiagnose. Diese wird vom Load-Balancer verwendet, um die Aktivität einzelner Endpunkte innerhalb der NEG zu erkennen.
gcloud compute health-checks create http http-basic-check \ --use-serving-port
Erstellen Sie einen Back-End-Service, der angibt, dass es sich um einen globalen externen HTTP(S)-Load-Balancer handelt:
gcloud compute backend-services create my-bes \ --protocol HTTP \ --health-checks http-basic-check \ --global
Erstellen Sie eine URL-Zuordnung und einen Zielproxy für den Load-Balancer. Dieses Beispiel ist sehr einfach, da die in dieser Anleitung verwendete
serve_hostname
-Anwendung nur einen Endpunkt hat und keine URLs enthält.gcloud compute url-maps create web-map \ --default-service my-bes
gcloud compute target-http-proxies create http-lb-proxy \ --url-map web-map
Erstellen Sie eine Weiterleitungsregel. Dadurch wird der Load-Balancer erstellt.
gcloud compute forwarding-rules create http-forwarding-rule \ --address=hostname-server-vip \ --global \ --target-http-proxy=http-lb-proxy \ --ports=80
hostname-server-vip ist die IP-Adresse, die für den Load-Balancer verwendet werden soll. Sie können für diesen Zweck eine neue statische externe IP-Adresse reservieren. Sie können auch die Option
--address
weglassen. Es wird dann automatisch eine sitzungsspezifische IP-Adresse zugewiesen.
Checkpoint
Folgende Ressourcen haben Sie bisher erstellt:
- eine externe virtuelle IP-Adresse
- Weiterleitungsregeln
- Firewallregeln
- einen Ziel-HTTP-Proxy
- eine URL-Zuordnung der Compute Engine-Systemdiagnose
- einen Back-End-Service
- eine Compute Engine-Systemdiagnose
Die Beziehung zwischen diesen Ressourcen ist im folgenden Diagramm dargestellt:
Diese Ressourcen bilden zusammen einen Load-Balancer. Im nächsten Schritt fügen Sie dem Load-Balancer Back-Ends hinzu.
Einer der hier gezeigten Vorteile eigenständiger NEGs ist, dass die Lebenszyklen des Load-Balancers und des Back-Ends voneinander völlig unabhängig sein können. Der Load-Balancer kann weiter ausgeführt werden, nachdem die Anwendung, ihre Services oder der GKE-Cluster gelöscht wurden. Sie können neue NEGs oder mehrere NEGs zum Load-Balancer hinzufügen und daraus entfernen, ohne die vorgeschalteten Load-Balancer-Objekte zu ändern.
Back-Ends zum Load-Balancer hinzufügen
Um die NEG mit dem Load-Balancer zu verbinden, verwenden Sie den Befehl gcloud compute backend-services
add-backend
und fügen diese als Back-End des Back-End-Dienstes my-bes hinzu:
gcloud compute backend-services add-backend my-bes --global \
--network-endpoint-group network-endpoint-group-name \
--network-endpoint-group-zone network-endpoint-group-zone \
--balancing-mode RATE --max-rate-per-endpoint 5
Dabei gilt:
- network-endpoint-group-name ist der Name der Netzwerk-Endpunktgruppe. Der Name ist entweder der Name, den Sie beim Erstellen der NEG angegeben haben oder ein automatisch generierter Name. Wenn Sie keinen Namen für die NEG angegeben haben, können Sie den automatisch generierten Namen anhand der folgenden Anleitung ermitteln.
- network-endpoint-group-zone ist die Zone, in der sich die Netzwerk-Endpunktgruppe befindet. Weiter unten finden Sie eine Anleitung zum Abrufen dieses Werts.
Verwenden Sie diesen Befehl, um den Namen und den Standort der NEG abzurufen:
gcloud compute network-endpoint-groups list
Die Ausgabe sieht in etwa so aus:
NAME LOCATION ENDPOINT_TYPE SIZE
k8s1-70aa83a6-default-my-service-80-c9710a6f us-central1-a GCE_VM_IP_PORT 3
In dieser Beispielausgabe lautet der Name der NEG k8s1-70aa83a6-default-my-service-80-c9710a6f
und befindet sich in der Zone us-central1-a
.
Einem Back-End-Service können mehrere NEGs hinzugefügt werden. Für globale Back-End-Services wie my-bes sind NEG-Back-Ends in mehreren Regionen möglich, während regionale Back-End-Services nur Back-Ends in einer einzelnen Region haben können.
Funktionieren des Load-Balancers prüfen
Es gibt zwei Möglichkeiten, zu prüfen, ob der von Ihnen eingerichtete Load-Balancer funktioniert: Prüfen Sie, ob die Systemdiagnose richtig konfiguriert ist und meldet, dass der Load-Balancer fehlerfrei ist, oder greifen Sie auf die Anwendung zu und prüfen Sie deren Antwort.
Systemdiagnosen prüfen
Prüfen Sie, ob der Back-End-Service der Systemdiagnose und den Netzwerk-Endpunktgruppen zugeordnet ist und ob die einzelnen Endpunkte fehlerfrei sind.
Prüfen Sie mit diesem Befehl, ob der Back-End-Service mit Ihrer Systemdiagnose und Ihrer Netzwerk-Endpunktgruppe verknüpft ist:
gcloud compute backend-services describe my-bes --global
Die Ausgabe sollte in etwa so aussehen:
backends:
- balancingMode: RATE
capacityScaler: 1.0
group: ... /networkEndpointGroups/k8s1-70aa83a6-default-my-service-80-c9710a6f
...
healthChecks:
- ... /healthChecks/http-basic-check
...
name: my-bes
...
Prüfen Sie als Nächstes den Status der einzelnen Endpunkte:
gcloud compute backend-services get-health my-bes --global
Der Abschnitt status:
der Ausgabe sollte in etwa so aussehen:
status:
healthStatus:
- healthState: HEALTHY
instance: ... gke-standard-cluster-3-default-pool-4cc71a15-qlpf
ipAddress: 10.12.1.43
port: 50000
- healthState: HEALTHY
instance: ... gke-standard-cluster-3-default-pool-4cc71a15-qlpf
ipAddress: 10.12.1.44
port: 50000
- healthState: HEALTHY
instance: ... gke-standard-cluster-3-default-pool-4cc71a15-w9nk
ipAddress: 10.12.2.26
port: 50000
Auf die Anwendung zugreifen
Greifen Sie über die IP-Adresse des Load-Balancers auf die Anwendung zu, um zu prüfen, ob alles funktioniert.
Rufen Sie zuerst die virtuelle IP-Adresse des Load-Balancers ab:
gcloud compute addresses describe hostname-server-vip --global | grep "address:"
Die Ausgabe enthält eine IP-Adresse. Senden Sie als Nächstes eine Anfrage an diese IP-Adresse (in diesem Beispiel 34.98.102.37
):
curl 34.98.102.37
Die Antwort der serve_hostname
-Anwendung sollte neg-demo-app
lauten.
Internen HTTP(S)-Load-Balancer an eigenständige NEGs anhängen
Dieser Abschnitt enthält Anweisungen zum Konfigurieren des internen HTTP(S)-Load-Balancings für die Services, die in eigenständigen GKE-Pods ausgeführt werden.
Nur-Proxysubnetz konfigurieren
Das Nur-Proxysubnetz ist für alle internen HTTP(S)-Load-Balancer in der Region des Load-Balancers vorgesehen, in diesem Beispiel us-west1
.
Console
Wenn Sie die GCP Console verwenden, können Sie das Nur-Proxy-Subnetz auch später über die Load-Balancing-UI erstellen.
gcloud
Erstellen Sie das Nur-Proxysubnetz mit dem Befehl gcloud compute networks subnets create:
gcloud compute networks subnets create proxy-only-subnet \ --purpose=INTERNAL_HTTPS_LOAD_BALANCER \ --role=ACTIVE \ --region=us-west1 \ --network=lb-network \ --range=10.129.0.0/23
API
Erstellen Sie das Nur-Proxysubnetz mit der Methode subnetworks.insert
und ersetzen Sie project-id dabei durch Ihre Projekt-ID.
POST https://compute.googleapis.com/compute/projects/project-id/regions/us-west1/subnetworks
{
"name": "proxy-only-subnet",
"ipCidrRange": "10.129.0.0/23",
"network": "projects/project-id/global/networks/lb-network",
"region": "projects/project-id/regions/us-west1",
"purpose": "INTERNAL_HTTPS_LOAD_BALANCER",
"role": "ACTIVE"
}
Firewallregeln konfigurieren
Dieses Beispiel verwendet die folgenden Firewallregeln:
fw-allow-ssh
: eine Regel für eingehenden Traffic, die für die Instanzen mit Load-Balancing gilt und eingehende SSH-Verbindungen an TCP-Port 22 von jeder Adresse aus ermöglicht. Sie können einen restriktiveren IP-Quellbereich für diese Regel auswählen. Geben Sie dazu beispielsweise nur die IP-Bereiche des Systems an, von dem aus Sie SSH-Sitzungen initiieren. In diesem Beispiel wird das Ziel-Tagallow-ssh
verwendet, um die VMs zu identifizieren, auf welche die Firewallregel angewendet wird.fw-allow-health-check
: eine Regel für eingehenden Traffic, die für die Instanzen mit Load-Balancing gilt und TCP-Traffic von den Google Cloud-Systemen für Systemdiagnosen zulässt (in130.211.0.0/22
und35.191.0.0/16
). In diesem Beispiel wird das Ziel-Tagload-balanced-backend
verwendet, um die Instanzen zu identifizieren, auf die sie angewendet werden soll.fw-allow-proxies
: eine Regel für eingehenden Traffic, die für die Instanzen mit Load-Balancing gilt und TCP-Traffic über Port80
,443
und8000
von den verwalteten Proxys des internen HTTP(S)-Load-Balancers zulässt. In diesem Beispiel wird das Ziel-Tagload-balanced-backend
verwendet, um die Instanzen zu identifizieren, auf die sie angewendet werden soll.
Ohne diese Firewallregeln blockiert die Standardregel zum Ablehnen von eingehendem Traffic den eingehenden Traffic zu den Back-End-Instanzen.
Console
- Rufen Sie in der Google Cloud Console die Seite "Firewallregeln" auf.
Zur Seite "Firewallregeln" - Klicken Sie auf Firewallregel erstellen, um die Regel zu erstellen, die eingehende SSH-Verbindungen zulässt:
- Name:
fw-allow-ssh
- Netzwerk:
lb-network
- Trafficrichtung: Eingehend
- Aktion bei Übereinstimmung: Zulassen
- Ziele: Angegebene Ziel-Tags
- Ziel-Tags:
allow-ssh
- Quellfilter:
IP ranges
- Quell-IP-Bereiche:
0.0.0.0/0
- Protokolle und Ports:
- Wählen Sie Angegebene Protokolle und Ports aus.
- Prüfen Sie
tcp
und geben Sie22
für die Portnummer ein.
- Name:
- Klicken Sie auf Erstellen.
- Klicken Sie ein zweites Mal auf Firewallregel erstellen, um die Regel zum Zulassen von Google Cloud-Systemdiagnosen zu erstellen:
- Name:
fw-allow-health-check
- Netzwerk:
lb-network
- Trafficrichtung: Eingehend
- Aktion bei Übereinstimmung: Zulassen
- Ziele: Angegebene Ziel-Tags
- Ziel-Tags:
load-balanced-backend
- Quellfilter:
IP ranges
- Quell-IP-Bereiche:
130.211.0.0/22
und35.191.0.0/16
- Protokolle und Ports:
- Wählen Sie Angegebene Protokolle und Ports aus.
- Prüfen Sie
tcp
und geben Sie80
ein.
Sie sollten diese Regeln nur auf Protokolle und Ports beschränken, die mit den von Ihren Systemdiagnosen verwendeten übereinstimmen. Wenn Sietcp:80
für das Protokoll und den Port verwenden, kann Google Cloud Ihre VMs über HTTP an Port 80 kontaktieren, aber nicht über HTTPS an Port 443.
- Name:
- Klicken Sie auf Erstellen.
- Klicken Sie ein drittes Mal auf Firewallregel erstellen, um die Regel zu erstellen, die Verbindungen von den Proxyservern des Load-Balancers zu den Back-Ends zulässt:
- Name:
fw-allow-proxies
- Netzwerk:
lb-network
- Trafficrichtung: Eingehend
- Aktion bei Übereinstimmung: Zulassen
- Ziele: Angegebene Ziel-Tags
- Ziel-Tags:
load-balanced-backend
- Quellfilter:
IP ranges
- Quell-IP-Bereiche:
10.129.0.0/23
- Protokolle und Ports:
- Wählen Sie Angegebene Protokolle und Ports aus.
- Prüfen Sie
tcp
und geben Sie80, 443, 8000
für die Portnummern ein.
- Name:
- Klicken Sie auf Erstellen.
gcloud
Erstellen Sie die Firewallregel
fw-allow-ssh
, um SSH-Verbindungen zu VMs mit dem Netzwerk-Tagallow-ssh
zu ermöglichen. Wenn Siesource-ranges
weglassen, bezieht Google Cloud die Regel auf jede Quelle.gcloud compute firewall-rules create fw-allow-ssh \ --network=lb-network \ --action=allow \ --direction=ingress \ --target-tags=allow-ssh \ --rules=tcp:22
Erstellen Sie die Regel
fw-allow-health-check
, um Google Cloud-Systemdiagnosen zuzulassen. In diesem Beispiel wird der gesamte TCP-Traffic von Systemdiagnosetests zugelassen. Sie können jedoch Ihren Anforderungen entsprechend eine kleinere Gruppe von Ports konfigurieren:gcloud compute firewall-rules create fw-allow-health-check \ --network=lb-network \ --action=allow \ --direction=ingress \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --target-tags=load-balanced-backend \ --rules=tcp
Erstellen Sie die Regel
fw-allow-proxies
, um Verbindungen von den Proxys des internen HTTP(S)-Load-Balancers zu Ihren Back-Ends zuzulassen.gcloud compute firewall-rules create fw-allow-proxies \ --network=lb-network \ --action=allow \ --direction=ingress \ --source-ranges=10.129.0.0/23 \ --target-tags=load-balanced-backend \ --rules=tcp:80,tcp:443,tcp:8000
API
Erstellen Sie die Firewallregel fw-allow-ssh
, indem Sie eine POST
-Anfrage an die Methode firewalls.insert
senden und dabei project-id durch Ihre Projekt-ID ersetzen.
POST https://compute.googleapis.com/compute/v1/projects/project-id/global/firewalls
{
"name": "fw-allow-ssh",
"network": "projects/project-id/global/networks/lb-network",
"sourceRanges": [
"0.0.0.0/0"
],
"targetTags": [
"allow-ssh"
],
"allowed": [
{
"IPProtocol": "tcp",
"ports": [
"22"
]
}
],
"direction": "INGRESS"
}
Erstellen Sie die Firewallregel fw-allow-health-check
, indem Sie eine POST
-Anfrage an die Methode firewalls.insert
senden und dabei project-id durch Ihre Projekt-ID ersetzen.
POST https://compute.googleapis.com/compute/v1/projects/project-id/global/firewalls
{
"name": "fw-allow-health-check",
"network": "projects/project-id/global/networks/lb-network",
"sourceRanges": [
"130.211.0.0/22",
"35.191.0.0/16"
],
"targetTags": [
"load-balanced-backend"
],
"allowed": [
{
"IPProtocol": "tcp"
}
],
"direction": "INGRESS"
}
Erstellen Sie die fw-allow-proxies
-Firewallregel, um TCP-Traffic im Proxy-Subnetz mit der Methode firewalls.insert
zuzulassen. Ersetzen Sie dabei project-id durch Ihre Projekt-ID.
POST https://compute.googleapis.com/compute/v1/projects/{project}/global/firewalls
{
"name": "fw-allow-proxies",
"network": "projects/project-id/global/networks/lb-network",
"sourceRanges": [
"10.129.0.0/23"
],
"targetTags": [
"load-balanced-backend"
],
"allowed": [
{
"IPProtocol": "tcp",
"ports": [
"80"
]
},
{
"IPProtocol": "tcp",
"ports": [
"443"
]
},
{
"IPProtocol": "tcp",
"ports": [
"8000"
]
}
],
"direction": "INGRESS"
}
Load-Balancer konfigurieren
Verwenden Sie für die IP-Adresse der Weiterleitungsregel ein Back-End-Subnetz. Wenn Sie das Nur-Proxy-Subnetz verwenden, schlägt das Erstellen der Weiterleitungsregel fehl.
Console
Load-Balancer-Typ auswählen
- Öffnen Sie in der Google Cloud Console die Seite "Load-Balancing".
Zur Seite „Load-Balancing“ - Klicken Sie unter HTTP(S)-Load-Balancing auf Konfiguration starten.
- Wählen Sie Nur zwischen meinen VMs aus. Diese Einstellung bedeutet, dass der Load-Balancer intern ist.
- Klicken Sie auf Weiter.
Load-Balancer vorbereiten
- Geben Sie
l7-ilb-gke-map
als Name für den Load-Balancer ein. - Wählen Sie
us-west1
als Region aus. - Wählen Sie
lb-network
als Netzwerk aus. - Lassen Sie das Fenster geöffnet, um fortzufahren.
Nur-Proxy-Subnetz reservieren
Reservieren Sie beim internen HTTP-Load-Balancing ein Proxy-Subnetz:
- Klicken Sie auf Subnetz reservieren.
- Geben Sie im Feld Name
proxy-only-subnet
ein. - Geben Sie
10.129.0.0/23
als IP-Adressbereich ein. - Klicken Sie auf Hinzufügen.
Back-End-Service konfigurieren
- Klicken Sie auf Back-End-Konfiguration.
- Wählen Sie im Menü Back-End-Service erstellen oder auswählen die Option Back-End-Service erstellen aus.
- Legen Sie als Name für den Back-End-Service
l7-ilb-gke-backend-service
fest. - Wählen Sie unter Back-End-Typ Netzwerk-Endpunktgruppen aus.
- Gehen Sie auf der Karte Neues Back-End des Abschnitts Back-Ends folgendermaßen vor:
- Legen Sie die Netzwerk-Endpunktgruppe auf die NEG fest, die von GKE erstellt wurde. Informationen zum Abrufen des NEG-Namens finden Sie unter NEG-Erstellung validieren.
- Geben Sie eine maximale Rate von
5
RPS pro Endpunkt ein. Google Cloud überschreitet diesen Höchstwert bei Bedarf. - Klicken Sie auf Fertig.
- Wählen Sie im Abschnitt Systemdiagnose die Option Systemdiagnose erstellen mit den folgenden Parametern aus:
- Name:
l7-ilb-gke-basic-check
- Protokoll: HTTP
- Portspezifikation: Bereitstellungsport
- Klicken Sie auf Speichern und Fortfahren.
- Name:
- Klicken Sie auf Erstellen.
URL-Zuordnung konfigurieren
- Klicken Sie auf Host- und Pfadregeln. Vergewissern Sie sich, dass der l7-ilb-gke-backend-service der einzige Back-End-Service für alle nicht übereinstimmenden Hosts und alle nicht übereinstimmenden Pfade ist.
Front-End konfigurieren
Bei HTTP:
- Klicken Sie auf Front-End-Konfiguration.
- Klicken Sie auf Front-End-IP und Port hinzufügen.
- Legen Sie als Name l7-ilb-gke-forwarding-rule fest.
- Legen Sie als Protokoll HTTP fest.
- Legen Sie als Subnetz backend-subnet fest.
- Wählen Sie unter Interne IP-Adresse die Option Statische interne IP-Adresse reservieren aus.
- Geben Sie im angezeigten Feld die folgenden Informationen ein:
- Name: l7-ilb-gke-ip
- Wählen Sie im Abschnitt Statische IP-Adresse die Option Selbst auswählen aus.
- Geben Sie im Abschnitt Benutzerdefinierte IP-Adresse
10.1.2.199
ein. - Klicken Sie auf Reservieren.
- Legen Sie als Port
80
fest. - Klicken Sie auf Fertig.
Bei HTTPS:
Wenn Sie HTTPS zwischen dem Client und dem Load-Balancer verwenden, benötigen Sie eine oder mehrere SSL-Zertifikatsressourcen, um den Proxy zu konfigurieren. Informationen zum Erstellen von SSL-Zertifikatressourcen finden Sie unter SSL-Zertifikate. Von Google verwaltete Zertifikate werden derzeit nicht von internen HTTP(S)-Load-Balancern unterstützt.
- Klicken Sie auf Front-End-Konfiguration.
- Klicken Sie auf Front-End-IP und Port hinzufügen.
- Geben Sie im Feld Name
l7-ilb-gke-forwarding-rule
ein. - Wählen Sie im Feld Protokoll die Option
HTTPS (includes HTTP/2)
aus. - Legen Sie als Subnetz backend-subnet fest.
- Wählen Sie unter Interne IP-Adresse die Option Statische interne IP-Adresse reservieren aus.
- Geben Sie im angezeigten Feld die folgenden Informationen ein:
- Name: l7-ilb-gke-ip
- Wählen Sie im Abschnitt Statische IP-Adresse die Option Selbst auswählen aus.
- Geben Sie im Abschnitt Benutzerdefinierte IP-Adresse
10.1.2.199
ein. - Klicken Sie auf Reservieren.
- Achten Sie darauf, dass der Port auf
443
festgelegt ist, um HTTPS-Traffic zuzulassen. - Klicken Sie auf die Drop-down-Liste Zertifikat.
- Wenn Sie bereits eine selbstverwaltete SSL-Zertifikatressource haben, die Sie als primäres SSL-Zertifikat verwenden möchten, wählen Sie es aus dem Drop-down-Menü aus.
- Wählen Sie andernfalls Neues Zertifikat erstellen aus.
- Geben Sie
l7-ilb-cert
als Name ein. - Laden Sie in den entsprechenden Feldern Ihre PEM-formatierten Dateien hoch:
- Public-Key-Zertifikat
- Zertifikatskette
- Privater Schlüssel
- Klicken Sie auf Erstellen.
- Geben Sie
- So fügen Sie zusätzlich zur primären SSL-Zertifikatsressource weitere Zertifikatsressourcen hinzu:
- Klicken Sie auf Zertifikat hinzufügen.
- Wählen Sie ein Zertifikat in der Liste Zertifikate aus oder klicken Sie auf Neues Zertifikat erstellen und befolgen Sie die obige Anleitung.
- Klicken Sie auf Fertig.
Konfiguration abschließen
- Klicken Sie auf Erstellen.
gcloud
Definieren Sie die HTTP-Systemdiagnose mit dem Befehl gcloud compute health-checks create http.
gcloud compute health-checks create http l7-ilb-gke-basic-check \ --region=us-west1 \ --use-serving-port
Definieren Sie den Back-End-Dienst mit dem Befehl gcloud compute backend-services create.
gcloud compute backend-services create l7-ilb-gke-backend-service \ --load-balancing-scheme=INTERNAL_MANAGED \ --protocol=HTTP \ --health-checks=l7-ilb-gke-basic-check \ --health-checks-region=us-west1 \ --region=us-west1
Legen Sie die Variable
DEPLOYMENT_NAME
fest.export DEPLOYMENT_NAME=neg-name
Dabei ist neg-name der Name der NEG.
Fügen Sie dem Back-End-Dienst NEG-Back-Ends mit dem Befehl gcloud compute backend-services add-backend hinzu.
gcloud compute backend-services add-backend l7-ilb-gke-backend-service \ --network-endpoint-group=$DEPLOYMENT_NAME \ --network-endpoint-group-zone=us-west1-b \ --region=us-west1 \ --balancing-mode=RATE \ --max-rate-per-endpoint=5
Erstellen Sie die URL-Zuordnung mit dem Befehl gcloud compute url-maps create.
gcloud compute url-maps create l7-ilb-gke-map \ --default-service=l7-ilb-gke-backend-service \ --region=us-west1
Erstellen Sie den Zielproxy.
Bei HTTP:
Verwenden Sie den Befehl gcloud compute target-http-proxies create.
gcloud compute target-http-proxies create l7-ilb-gke-proxy \ --url-map=l7-ilb-gke-map \ --url-map-region=us-west1 \ --region=us-west1
Bei HTTPS:
Informationen zum Erstellen von SSL-Zertifikatressourcen finden Sie unter SSL-Zertifikate. Von Google verwaltete Zertifikate werden derzeit nicht von internen HTTP(S)-Load-Balancern unterstützt.
Weisen Sie Ihre Dateipfade den entsprechenden Variablennamen zu.
export LB_CERT=path to PEM-formatted file
export LB_PRIVATE_KEY=path to PEM-formatted file
Erstellen Sie mit dem Befehl gcloud compute ssl-certificates create ein regionales SSL-Zertifikat.
gcloud compute ssl-certificates create
gcloud compute ssl-certificates create l7-ilb-cert \ --certificate=$LB_CERT \ --private-key=$LB_PRIVATE_KEY \ --region=us-west1
Verwenden Sie das regionale SSL-Zertifikat, um einen Zielproxy mit dem Befehl gcloud compute target-https-proxies create zu erstellen.
gcloud compute target-https-proxies create l7-ilb-gke-proxy \ --url-map=l7-ilb-gke-map \ --region=us-west1 \ --ssl-certificates=l7-ilb-cert
Erstellen Sie die Weiterleitungsregel.
Bei benutzerdefinierten Netzwerken müssen Sie in der Weiterleitungsregel auf das Subnetz verweisen. Achten Sie darauf, dass dies das VM-Subnetz und nicht das Proxy-Subnetz ist.
Bei HTTP:
Verwenden Sie den Befehl gcloud compute forwarding-rules create mit den richtigen Flags.
gcloud compute forwarding-rules create l7-ilb-gke-forwarding-rule \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=backend-subnet \ --address=10.1.2.199 \ --ports=80 \ --region=us-west1 \ --target-http-proxy=l7-ilb-gke-proxy \ --target-http-proxy-region=us-west1
Bei HTTPS:
Verwenden Sie den Befehl gcloud compute forwarding-rules create mit den richtigen Flags.
gcloud compute forwarding-rules create l7-ilb-gke-forwarding-rule \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=backend-subnet \ --address=10.1.2.199 \ --ports=443 \ --region=us-west1 \ --target-https-proxy=l7-ilb-gke-proxy \ --target-https-proxy-region=us-west1
API
Erstellen Sie die Systemdiagnose durch Stellen einer POST
-Anfrage an die Methode regionHealthChecks.insert
. Ersetzen Sie dabei project-id durch Ihre Projekt-ID.
POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/us-west1/healthChecks
{
"name": "l7-ilb-gke-basic-check",
"type": "HTTP",
"httpHealthCheck": {
"portSpecification": "USE_SERVING_PORT"
}
}
Erstellen Sie den regionalen Back-End-Service durch Stellen einer POST
-Anfrage an die Methode regionBackendServices.insert
. Ersetzen Sie dabei project-id durch Ihre Projekt-ID und neg-name durch den Namen der von Ihnen erstellten NEG.
POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/us-west1/backendServices
{
"name": "l7-ilb-gke-backend-service",
"backends": [
{
"group": "https://www.googleapis.com/compute/v1/projects/project-id/zones/us-west1-b/networkEndpointGroups/neg-name",
"balancingMode": "RATE",
"maxRatePerEndpoint": 5
}
],
"healthChecks": [
"projects/project-id/regions/us-west1/healthChecks/l7-ilb-gke-basic-check"
],
"loadBalancingScheme": "INTERNAL_MANAGED"
}
Erstellen Sie die URL-Zuordnung durch Stellen einer POST
-Anfrage an die Methode regionUrlMaps.insert
. Ersetzen Sie dabei project-id durch Ihre Projekt-ID.
POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/us-west1/urlMaps
{
"name": "l7-ilb-gke-map",
"defaultService": "projects/project-id/regions/us-west1/backendServices/l7-ilb-gke-backend-service"
}
Erstellen Sie den Ziel-HTTP-Proxy durch Stellen einer POST
-Anfrage an die Methode regionTargetHttpProxies.insert
. Ersetzen Sie dabei project-id durch Ihre Projekt-ID.
POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/us-west1/targetHttpProxy
{
"name": "l7-ilb-gke-proxy",
"urlMap": "projects/project-id/global/urlMaps/l7-ilb-gke-map",
"region": "us-west1"
}
Erstellen Sie die Firewallregel POST
, indem Sie eine -Anfrage an die Methode forwardingRules.insert
project-id senden und dabei durch Ihre Projekt-ID ersetzen.
POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/us-west1/forwardingRules
{
"name": "l7-ilb-gke-forwarding-rule",
"IPAddress": "10.1.2.199",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/project-id/regions/us-west1/targetHttpProxies/l7-ilb-gke-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/project-id/regions/us-west1/subnetworks/backend-subnet",
"network": "projects/project-id/global/networks/lb-network",
"networkTier": "PREMIUM",
}
Test
VM-Instanz in der Zone zum Testen der Konnektivität erstellen
gcloud compute instances create l7-ilb-client-us-west1-b \ --image-family=debian-9 \ --image-project=debian-cloud \ --zone=us-west1-b \ --network=lb-network \ --subnet=backend-subnet \ --tags=l7-ilb-client,allow-ssh
Melden Sie sich bei der Clientinstanz an, damit HTTP(S)-Services auf den Back-Ends über die IP-Adresse der Weiterleitungsregel des internen HTTP(S)-Load-Balancers erreichbar sind und der Traffic ausgeglichen auf die Endpunkte in der NEG verteilt wird.
Stellen Sie über SSH eine Verbindung zu jeder Clientinstanz her.
gcloud compute ssh l7-ilb-client-us-west1-b \ --zone=us-west1-b
Prüfen Sie, ob die IP-Adresse ihren Hostnamen bereitstellt.
curl 10.1.2.199
Ersetzen Sie für HTTPS-Tests curl
durch:
curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.199:443
Das Flag -k
bewirkt, dass curl die Zertifikatsvalidierung überspringt.
Führen Sie 100 Anfragen aus und prüfen Sie, ob ein Load-Balancing stattfindet.
Bei HTTP:
{ RESULTS= for i in {1..100} do RESULTS="$RESULTS:$(curl --silent 10.1.2.199)" done echo "***" echo "*** Results of load-balancing to 10.1.2.199: " echo "***" echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c echo }
Bei HTTPS:
{ RESULTS= for i in {1..100} do RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.199:443 )" done echo "***" echo "*** Results of load-balancing to 10.1.2.199: " echo "***" echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c echo }
Heterogene Services (VMs und Container) implementieren
Load-Balancer können Front-Ends für gemischte Kubernetes-Arbeitslasten und Nicht-Kubernetes-Arbeitslasten sein. Es könnte sich um einen Teil einer Migration von VMs zu Containern oder einer permanenten Architektur handeln, die von einem freigegebenen Load-Balancer profitiert. Dies kann durch Erstellen von Load-Balancern erreicht werden, die auf verschiedene Arten von Back-Ends abzielen, einschließlich eigenständiger NEGs.
VMs und Container im selben Back-End-Service
In diesem Beispiel wird gezeigt, wie Sie eine NEG erstellen, die auf eine vorhandene VM verweist, die eine Arbeitslast ausführt, und wie Sie diese NEG als weiteres Back-End eines vorhandenen backendService
hinzufügen.
Auf diese Weise wird durch einen einzigen Load-Balancer ein Lastenausgleich zwischen VMs und GKE-Containern durchgeführt.
Dieses Beispiel erweitert das obige Beispiel, das einen externen HTTP-Load-Balancer verwendet.
Da alle Endpunkte durch denselben backendService gruppiert werden, werden die VM- und die Containerendpunkte als derselbe Service betrachtet. Dies bedeutet, dass der Host/Pfad-Abgleich alle Back-Ends anhand der URL-Zuordnungsregeln identisch behandelt.
Wenn Sie in einem Back-End-Service eine NEG als Back-End verwenden, müssen auch alle anderen Back-Ends in diesem Service NEGs sein. Sie können in einem Back-End-Service nicht sowohl Instanzgruppen als auch NEGs als Back-Ends verwenden. Außerdem können Container und VMs nicht als Endpunkte in derselben NEG vorhanden sein, sodass sie immer mit separaten NEGs konfiguriert werden müssen.
Stellen Sie eine VM mit dem folgenden Befehl in Compute Engine bereit:
gcloud compute instances create vm1 --zone zone --network=network \ --subnet=subnet --image-project=cos-cloud \ --image-family=cos-stable --tags=vm-neg-tag
Stellen Sie eine Anwendung auf der VM bereit:
gcloud compute ssh vm1 --zone=${ZONE} --command="docker run -d --rm --network=host \ k8s.gcr.io/serve_hostname:v1.4 && sudo iptables -P INPUT ACCEPT"
Mit diesem Befehl wird auf der VM dieselbe Beispielanwendung wie im vorherigen Beispiel bereitgestellt. Der Einfachheit halber wird die Anwendung als Docker-Container ausgeführt. Dies ist jedoch nicht unbedingt erforderlich. Der Befehl
iptables
ist erforderlich, um Firewallzugriff auf den ausgeführten Container zuzulassen.Prüfen Sie, ob die Anwendung auf Port 9376 Traffic bereitstellt und meldet, dass sie auf vm1 ausgeführt wird:
gcloud compute ssh vm1 --zone=zone --command="curl -s localhost:9376"
Der Server sollte mit
vm1
antworten.Erstellen Sie eine NEG zum Verwenden mit dem VM-Endpunkt. Container und VMs können zwar beide NEG-Endpunkte sein, aber eine einzelne NEG kann nicht sowohl VM- als auch Container-Endpunkte haben.
gcloud compute network-endpoint-groups create vm-neg \ --subnet=subnet --zone=zone
Hängen Sie den VM-Endpunkt an die NEG an:
gcloud compute network-endpoint-groups update vm-neg --zone=zone \ --add-endpoint="instance=vm1,ip=vm-primary-ip,port=9376"
Bestätigen Sie, dass die NEG den VM-Endpunkt hat:
gcloud compute network-endpoint-groups list-network-endpoints vm-neg --zone zone
Hängen Sie die NEG mit dem gleichen Befehl, den Sie zum Hinzufügen eines Container-Back-Ends verwendet haben, an den Back-End-Service an:
gcloud compute backend-services add-backend my-bes --global \ --network-endpoint-group vm-neg \ --network-endpoint-group-zone zone \ --balancing-mode RATE --max-rate-per-endpoint 10
Öffnen Sie die Firewall, um die Systemdiagnose der VM zuzulassen:
gcloud compute firewall-rules create fw-allow-health-check-to-vm1 \ --network=network \ --action=allow \ --direction=ingress \ --target-tags=vm-neg-tag \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --rules=tcp:9376
Prüfen Sie, ob der Load-Balancer Traffic an das neue vm1-Back-End und das vorhandene Container-Back-End weiterleitet, indem Sie Test-Traffic senden:
for i in `seq 1 100`; do curl ${VIP};echo; done
Sie sollten Antworten von den Container- (
neg-demo-app
) und VM-Endpunkten (vm1
) sehen.
VMs und Container für verschiedene Back-End-Services
In diesem Beispiel wird gezeigt, wie Sie eine NEG erstellen, die auf eine vorhandene VM verweist, die eine Arbeitslast ausführt, und wie Sie diese NEG einem neuen backendService
als Back-End hinzufügen. Dies ist nützlich, wenn die Container und VMs unterschiedliche Services sind, aber denselben L7-Load-Balancer verwenden müssen, z. B. wenn die Services dieselbe IP-Adresse oder denselben Domainnamen haben.
Dieses Beispiel erweitert das vorherige Beispiel, bei dem ein VM-Back-End im selben Back-End-Service wie das Container-Back-End verwendet wurde. In diesem Beispiel wird jene VM wiederverwendet.
Da die Container- und VM-Endpunkte in separaten backendServices gruppiert sind, werden sie als unterschiedliche Services betrachtet. Dies bedeutet, dass die URL-Zuordnung Back-Ends abgleicht und den Traffic basierend auf dem Hostnamen an die VM oder den Container weiterleitet.
Das folgende Diagramm zeigt, wie eine einzelne virtuelle IP-Adresse zwei Hostnamen entspricht, die wiederum einem container- und einem VM-basierten Back-End-Service entsprechen.
Das folgende Diagramm zeigt die oben beschriebene Architektur:
Erstellen Sie für die VM einen neuen Back-End-Service:
gcloud compute backend-services create my-vm-bes \ --protocol HTTP \ --health-checks http-basic-check \ --global
Hängen Sie die NEG für die VM (
vm-neg
) an den Back-End-Service an:gcloud compute backend-services add-backend my-vm-bes --global \ --network-endpoint-group vm-neg \ --network-endpoint-group-zone zone \ --balancing-mode RATE --max-rate-per-endpoint 10
Fügen Sie der URL-Zuordnung eine Hostregel hinzu, um Anfragen für den Host
container.example.com
an den Container-Back-End-Service weiterzuleiten:gcloud compute url-maps add-path-matcher web-map \ --path-matcher-name=container-path --default-service=my-bes \ --new-hosts=container.example.com --global
Fügen Sie der URL-Zuordnung eine weitere Hostregel hinzu, um Anfragen für den Host
vm.example.com
an den VM-Back-End-Service weiterzuleiten:gcloud compute url-maps add-path-matcher web-map \ --path-matcher-name=vm-path --default-service=my-vm-bes \ --new-hosts=vm.example.com --global
Prüfen Sie, ob der Load-Balancer Traffic basierend auf dem angeforderten Pfad an das VM-Back-End sendet:
curl -H "HOST:vm.example.com" virtual-ip
Einschränkungen von eigenständigen NEGs
- Fehler bei der Anmerkungsprüfung werden dem Nutzer über Kubernetes-Ereignisse angezeigt.
- Die Einschränkungen von NEGs gelten auch für eigenständige NEGs.
- Eigenständige NEGs funktionieren nicht mit Legacy-Netzwerken.
- Eigenständige NEGs können nur mit kompatiblen Netzwerkservices wie Traffic Director und den kompatiblen Load-Balancer-Typen verwendet werden.
Preise
Weitere Informationen zu den Preisen des Load-Balancers finden Sie auf der Preisseite im Abschnitt zum Load-Balancing. Für NEGs fallen keine zusätzlichen Gebühren an.
Fehlerbehebung
Keine eigenständige NEG konfiguriert
Problem: Es wird keine NEG erstellt.
Mögliche Lösung:
- Prüfen Sie die mit dem Service verknüpften Ereignisse und suchen Sie nach Fehlermeldungen.
- Prüfen Sie, ob die eigenständige NEG-Anmerkung im korrekten JSON-Format vorliegt und die freigegebenen Ports mit den vorhandenen Ports in der Servicespezifikation übereinstimmen.
- Sehen Sie sich die NEG-Statusanmerkung an und prüfen Sie, ob die erwarteten Serviceports entsprechende NEGs haben.
- Prüfen Sie mit dem Befehl
gcloud compute network-endpoint-groups list
, ob die NEGs in den erwarteten Zonen erstellt wurden. - Wenn Sie die GKE-Version 1.18 oder höher verwenden, prüfen Sie, ob die
SvcNeg
-Ressource für den Dienst vorhanden ist. Falls ja, prüfen Sie die BedingungInitialiazed
auf Fehlerinformationen. - Wenn Sie benutzerdefinierte NEG-Namen verwenden, müssen alle NEG-Namen in ihrer Region eindeutig sein.
Traffic erreicht die Endpunkte nicht
Problem: 502-Fehler oder abgelehnte Verbindungen
Mögliche Lösung:
- Nach der Konfiguration des Services sind neue Endpunkte in der Regel erreichbar, sobald sie der NEG zugeordnet wurden, vorausgesetzt, sie reagieren auf Systemdiagnosen.
- Wenn der Traffic die Endpunkte nach Ablauf dieser Zeit immer noch nicht erreicht, was zu einem Fehlercode 502 für HTTP(S)-Load-Balancing führt oder dazu, dass Verbindungen für TCP/SSL-Load-Balancer abgelehnt werden, prüfen Sie Folgendes:
- Prüfen Sie, ob die Firewallregeln eingehenden TCP-Traffic an Ihre Endpunkte in den Bereichen
130.211.0.0/22
und35.191.0.0/16
zulassen. - Prüfen Sie, ob die Endpunkte fehlerfrei sind, indem Sie gcloud verwenden oder die API
getHealth
für BackendService oder die listEndpoints API für die NEG aufrufen und dabei den Parameter "showHealth" auf SHOW setzen.
- Prüfen Sie, ob die Firewallregeln eingehenden TCP-Traffic an Ihre Endpunkte in den Bereichen
Einführung wurde angehalten
Problem: Das Einführen eines aktualisierten Deployments wird angehalten und die Anzahl der Replikate, die auf dem neuesten Stand sind, stimmt nicht mit der gewünschten Anzahl von Replikaten überein.
Mögliche Lösung:
Die Systemdiagnosen des Deployments können nicht ausgeführt werden. Möglicherweise ist das Container-Image fehlerhaft oder die Systemdiagnose falsch konfiguriert. Mit dem rollierenden Ersetzen der Pods wird gewartet, bis das Pod-Readiness-Gate des neu gestarteten Pods den Status "True" aufweist. Dies geschieht nur, wenn der Pod auf Load-Balancer-Systemdiagnosen reagiert. Wenn der Pod nicht reagiert oder die Systemdiagnose falsch konfiguriert ist, können die Bedingungen des Readiness-Gates nicht erfüllt werden und das Rollout kann nicht fortgesetzt werden.
Wenn Sie kubectl ab Version 1.13 verwenden, können Sie den Status der Readiness-Gates eines Pods mit dem folgenden Befehl prüfen:
kubectl get my-Pod -o wide
Prüfen Sie die Spalte READINESS GATES.
Diese Spalte ist in kubectl 1.12 und niedrigeren Versionen nicht vorhanden. Ein Pod, für den der Status READY angegeben wird, weist möglicherweise ein fehlgeschlagenes Readiness-Gate auf. Verwenden Sie den folgenden Befehl, um dies zu prüfen:
kubectl get my-pod -o yaml
Die Readiness-Gates und der Status der einzelnen Gates werden in der Ausgabe aufgeführt.
Prüfen Sie, ob das in der Pod-Spezifikation Ihres Deployments genannte Container-Image richtig funktioniert und auf Systemdiagnosen reagieren kann.
Prüfen Sie, ob die Systemdiagnosen korrekt konfiguriert sind.
NEG wird nicht automatisch bereinigt.
Symptom: Eine NEG, die gelöscht werden sollte, ist weiterhin vorhanden.
Mögliche Lösung:
- Die NEG wird nicht automatisch bereinigt, wenn ein Back-End-Dienst auf die NEG verweist. Weitere Informationen finden Sie unter Gehackte NEGs verhindern.
- Wenn Sie Version 1.18 oder höher verwenden, können Sie mit dieser Anleitung nach Ereignissen in der
ServiceNetworkEndpointGroup
-Ressource suchen. - Prüfen Sie, ob die NEG noch von einem Dienst benötigt wird. Prüfen Sie die
svcneg
-Ressource auf den Dienst, der der NEG entspricht, und prüfen Sie, ob eine Dienstannotation vorhanden ist.
NEG wird nicht mit Dienst synchronisiert
Symptom: Die erwarteten Endpunkte sind nicht vorhanden oder die NEG scheint nicht synchronisiert zu sein
Mögliche Lösung:
Wenn Sie Version 1.18 oder höher verwenden, prüfen Sie die svcneg
-Ressource auf Informationen:
- Prüfen Sie den Wert
status.lastSyncTime
, um festzustellen, ob die NEG kürzlich synchronisiert wurde. - Prüfen Sie die
Synced
-Bedingung auf Fehler, die in der letzten Synchronisierung aufgetreten sind.
Nächste Schritte
- HTTP(S)-Load-Balancing-Konzepte
- Übersicht über zonale Netzwerk-Endpunktgruppen
- Back-End-Services
- Systemdiagnosen erstellen
- Zielproxys verwenden
- Weiterleitungsregeln verwenden