Auf dieser Seite erfahren Sie, wie Sie einen externen Application Load Balancer durch Erstellen eines Kubernetes Ingress-Objekts konfigurieren.
Machen Sie sich vor dem Lesen dieser Seite mit den GKE-Netzwerkkonzepten vertraut.
Hinweise
Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:
- Aktivieren Sie die Google Kubernetes Engine API. Google Kubernetes Engine API aktivieren
- Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit
gcloud components update
ab.
HttpLoadBalancing
-Add-on aktivieren
Für den Cluster muss das Add-on HttpLoadBalancing
aktiviert sein. Dieses Add-on ist standardmäßig aktiviert. In Autopilot-Clustern können Sie dieses Add-on nicht deaktivieren.
Sie können das Add-on HttpLoadBalancing
über die Google Cloud Console oder das Google Cloud CLI aktivieren.
Console
Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.
Klicken Sie auf den Namen des Clusters, den Sie ändern möchten.
Klicken Sie unter Netzwerk im Feld HTTP-Load-Balancing auf edit HTTP-Load-Balancing bearbeiten.
Klicken Sie das Kästchen HTTP-Load-Balancing aktivieren an.
Klicken Sie auf Änderungen speichern.
gcloud
gcloud container clusters update CLUSTER_NAME --update-addons=HttpLoadBalancing=ENABLED
Ersetzen Sie CLUSTER_NAME
durch den Namen Ihres Clusters.
Statische IP-Adresse erstellen
Ein externer Application Load Balancer stellt eine stabile IP-Adresse bereit, mit der Sie Anfragen an einen oder mehrere Services weiterleiten können. Wenn Sie eine permanente IP-Adresse benötigen, müssen Sie eine globale statische externe IP-Adresse reservieren, bevor Sie eine Ingress-Ressource erstellen.
Wenn Sie eine vorhandene Ingress-Ressource so ändern, dass eine statische IP-Adresse anstelle einer sitzungsspezifischen IP-Adresse verwendet wird, ändert GKE möglicherweise die IP-Adresse des Load-Balancers, wenn GKE die Weiterleitungsregel des Load-Balancers neu erstellt.
Externen Application Load Balancer erstellen
In dieser Übung konfigurieren Sie einen externen Application Load Balancer, um Anfragen je nach URL-Pfad an verschiedene Services weiterzuleiten.
Klicken Sie auf Anleitung, um eine detaillierte Anleitung für diese Aufgabe direkt in der Google Cloud Console aufzurufen.
Deployments und Services erstellen
Erstellen Sie zwei Deployments mit Services namens hello-world-1
und hello-world-2
:
Speichern Sie das folgende Manifest als
hello-world-deployment-1.yaml
:apiVersion: apps/v1 kind: Deployment metadata: name: hello-world-deployment-1 spec: selector: matchLabels: greeting: hello version: one replicas: 3 template: metadata: labels: greeting: hello version: one spec: containers: - name: hello-app-1 image: "us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0" env: - name: "PORT" value: "50000"
Dieses Manifest beschreibt ein Beispiel-Deployment mit drei Replikaten.
Wenden Sie das Manifest auf den Cluster an:
kubectl apply -f hello-world-deployment-1.yaml
Speichern Sie das folgende Manifest als
hello-world-service-1.yaml
:apiVersion: v1 kind: Service metadata: name: hello-world-1 spec: type: NodePort selector: greeting: hello version: one ports: - protocol: TCP port: 60000 targetPort: 50000
Dieses Manifest beschreibt einen Service mit folgenden Attributen:
- Jeder Pod mit dem Label
greeting: hello
und dem Labelversion: one
ist ein Mitglied des Services. - GKE leitet Anfragen, die an TCP-Port 60000 gesendet werden, an einen der Mitglieds-Pods an TCP-Port 50000 weiter.
- Der Servicetyp enthält
NodePort
, was erforderlich ist, sofern Sie nicht containernatives Load-Balancing verwenden. Bei Verwendung von containernativem Load-Balancing gibt es keine Einschränkungen für den Servicetyp. Es wird empfohlen,type: ClusterIP
zu verwenden.
- Jeder Pod mit dem Label
Wenden Sie das Manifest auf den Cluster an:
kubectl apply -f hello-world-service-1.yaml
Speichern Sie das folgende Manifest als
hello-world-deployment-2.yaml
:apiVersion: apps/v1 kind: Deployment metadata: name: hello-world-deployment-2 spec: selector: matchLabels: greeting: hello version: two replicas: 3 template: metadata: labels: greeting: hello version: two spec: containers: - name: hello-app-2 image: "us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0" env: - name: "PORT" value: "8080"
Dieses Manifest beschreibt ein Beispiel-Deployment mit drei Replikaten.
Wenden Sie das Manifest auf den Cluster an:
kubectl apply -f hello-world-deployment-2.yaml
Speichern Sie das folgende Manifest als
hello-world-service-2.yaml
:apiVersion: v1 kind: Service metadata: name: hello-world-2 spec: type: NodePort selector: greeting: hello version: two ports: - protocol: TCP port: 80 targetPort: 8080
Dieses Manifest beschreibt einen Service mit folgenden Attributen:
- Jeder Pod mit dem Label
greeting: hello
und dem Labelversion: two
ist ein Mitglied des Services. - GKE leitet Anfragen, die an TCP-Port 80 gesendet werden, an einen der Mitglieds-Pods an TCP-Port 8080 weiter.
- Jeder Pod mit dem Label
Wenden Sie das Manifest auf den Cluster an:
kubectl apply -f hello-world-service-2.yaml
Ingress-Objekt erstellen
Erstellen Sie ein Ingress, das Regeln für das Routing von Anfragen abhängig vom URL-Pfad in der Anfrage angibt. Wenn Sie das Ingress-Objekt erstellen, erstellt und konfiguriert der GKE-Ingress-Controller einen externen Application Load Balancer.
Speichern Sie das folgende Manifest als
my-ingress.yaml
:apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress annotations: # If the class annotation is not specified it defaults to "gce". kubernetes.io/ingress.class: "gce" spec: rules: - http: paths: - path: /* pathType: ImplementationSpecific backend: service: name: hello-world-1 port: number: 60000 - path: /v2 pathType: ImplementationSpecific backend: service: name: hello-world-2 port: number: 80
Dieses Manifest beschreibt ein Ingress mit den folgenden Attributen:
Es gibt zwei GKE-Ingress-Klassen. Wenn Sie eine Ingress-Klasse angeben möchten, müssen Sie die Annotation
kubernetes.io/ingress.class
verwenden. Sie können einen GKE-Ingress nicht mitspec.ingressClassName
angeben.Die Klasse
gce
stellt einen externen Application Load Balancer bereit.Die Klasse
gce-internal
stellt einen internen Application Load Balancer bereit.Wenn Sie eine Ingress-Ressource ohne die Annotationen
spec.ingressClassName
undkubernetes.io/ingress.class
bereitstellen, erstellt GKE einen externen Application Load Balancer. Dies ist das gleiche Verhalten, wenn Sie die Annotationkubernetes.io/ingress.class: gce
angeben. Weitere Informationen finden Sie unter Verhalten des GKE-Ingress-Controllers.GKE erstellt für jeden
backend.service
einen Google Cloud-Backend-Service.Wenn ein Client eine Anfrage mit dem URL-Pfad
/
an den Load-Balancer sendet, leitet GKE die Anfrage an den Servicehello-world-1
auf Port 60000 weiter. Wenn ein Client eine Anfrage mit dem URL-Pfad/v2
an den Load-Balancer sendet, leitet GKE die Anfrage an den Servicehello-world-2
auf Port 80 weiter. Weitere Informationen zu den Attributenpath
undpathType
finden Sie unter URL-Pfade.
Wenden Sie das Manifest auf den Cluster an:
kubectl apply -f my-ingress.yaml
Externen Application Load Balancer testen
Warten Sie etwa fünf Minuten, bis der Load Balancer konfiguriert wurde, und testen Sie dann den externen Application Load Balancer:
Sehen Sie sich das Ingress-Objekt an:
kubectl get ingress my-ingress --output yaml
Die Ausgabe zeigt die IP-Adresse des externen Application Load Balancers:
status: loadBalancer: ingress: - ip: 203.0.113.1
Testen Sie den Pfad
/
:curl LOAD_BALANCER_IP_ADDRESS/
Ersetzen Sie
LOAD_BALANCER_IP_ADDRESS
durch die externe IP-Adresse des Load-Balancers.Die Ausgabe sieht in etwa so aus:
Hello, world! Version: 1.0.0 Hostname: ...
Wenn die Ausgabe einen 404-Fehler enthält, warten Sie einige Minuten.
Testen Sie den Pfad
/v2
:curl load-balancer-ip/v2
Die Ausgabe sieht in etwa so aus:
Hello, world! Version: 2.0.0 Hostname: ...
Funktionsweise von Ingress für externes Load-Balancing
Ein externer Application Load Balancer fungiert als Proxy zwischen Ihren Clients und Ihrer Anwendung. Wenn HTTPS-Anfragen von den Clients angenommen werden sollen, benötigt der Load-Balancer ein Zertifikat, damit er seine Identität gegenüber den Clients nachweisen kann. Der Load-Balancer benötigt außerdem einen privaten Schlüssel, um den HTTPS-Handshake abzuschließen. Weitere Informationen
- HTTPS (TLS) zwischen Client und Load-Balancer einrichten
- Mehrere SSL-Zertifikate beim HTTP(S)-Load-Balancing mit Ingress verwenden
URL-Pfade
Das einzige unterstützte Platzhalterzeichen für das Feld path
eines Ingress ist das Zeichen *
. Das Zeichen *
muss auf einen Schrägstrich (/
) folgen und das letzte Zeichen des Musters sein. Beispielsweise sind /*
, /foo/*
und /foo/bar/*
gültige Muster, *
, /foo/bar*
und /foo/*/bar
jedoch nicht.
Ein spezifischeres Muster hat Vorrang vor einem weniger spezifischen Muster. Wenn sowohl /foo/*
als auch /foo/bar/*
vorhanden sind, wird /foo/bar/bat
für den Abgleich mit /foo/bar/*
herangezogen. Weitere Informationen zu Pfadeinschränkungen und zum Musterabgleich finden Sie in der Dokumentation zu URL-Zuordnungen.
Bei GKE-Clustern, auf denen eine frühere Version als 1.21.3-gke.1600 ausgeführt wird, ist ImplementationSpecific
der einzige unterstützte Wert für das Feld pathType
.
Bei Clustern mit Version 1.21.3-gke.1600 oder höher werden auch die Werte Prefix
und Exact
für pathType
unterstützt.
HTTP deaktivieren
Wenn der gesamte Traffic zwischen dem Client und dem Load-Balancer HTTPS verwenden soll, können Sie HTTP deaktivieren.
HTTPS zwischen Load-Balancer und Anwendung
Wenn Ihre in einem GKE-Pod ausgeführte Anwendung HTTPS-Anfragen empfangen kann, können Sie den Load-Balancer so konfigurieren, dass er bei der Weiterleitung von Anfragen an die Anwendung HTTPS verwendet. Weitere Informationen finden Sie unter HTTPS (TLS) zwischen dem Load-Balancer und Ihrer Anwendung.
HTTP/2 zwischen Client und Load-Balancer
Clients können HTTP/2 verwenden, um Anfragen an den Load-Balancer zu senden. Es ist keine Konfiguration erforderlich.
HTTP/2 zwischen Load-Balancer und Anwendung
Wenn Ihre in einem GKE-Pod ausgeführte Anwendung HTTP/2-Anfragen empfangen kann, können Sie den Load-Balancer so konfigurieren, dass bei der Weiterleitung von Anfragen an die Anwendung HTTP/2 verwendet wird. Weitere Informationen finden Sie unter HTTP/2 für Load-Balancing mit Ingress.
Netzwerk-Endpunktgruppen
Wenn Ihr Cluster Containernatives Load-Balancing unterstützt, empfehlen wir die Verwendung von Netzwerk-Endpunktgruppen (NEGs). Für GKE-Cluster 1.17 und höher und unter bestimmten Bedingungen ist containernatives Load-Balancing standardmäßig nicht erforderlich. Daher ist keine explizite cloud.google.com/neg: '{"ingress": true}'
-Dienstannotation erforderlich.
Freigegebene VPC
Wenn sich der GKE-Cluster, in dem Sie die Ingress-Ressourcen bereitstellen, in einem Dienstprojekt befindet und Sie möchten, dass die GKE-Steuerungsebene die Firewallressourcen in Ihrem Hostprojekt verwaltet, muss das GKE-Dienstkonto des Dienstprojekts die entsprechenden IAM-Berechtigungen im Hostprojekt gemäß der Anleitung Firewallressourcen für Cluster mit freigegebener VPC verwalten erhalten. Dadurch kann der Ingress-Controller Firewallregeln erstellen, um sowohl eingehenden Traffic als auch Traffic für Google Cloud-Systemdiagnosen zuzulassen.
Das folgende Beispiel zeigt ein Ereignis, das in den Ingress-Ressourcenlogs vorhanden sein kann. Dieser Fehler tritt auf, wenn der Ingress-Controller keine Firewallregel erstellen kann, die eingehenden Traffic für Google Cloud-Systemdiagnosen zulässt, wenn die Berechtigungen nicht richtig konfiguriert sind.
Firewall change required by security admin: `gcloud compute firewall-rules update <RULE_NAME> --description "GCE L7 firewall rule" --allow tcp:<PORT> --source-ranges 130.211.0.0/22,35.191.0.0/16 --target-tags <TARGET_TAG> --project <HOST_PROJECT>
Wenn Sie die Firewallregeln manuell aus dem Hostprojekt bereitstellen möchten, können Sie firewallXPNError
-Ereignisse stummschalten. Dazu fügen Sie der Ingress-Ressource die Annotation networking.gke.io/suppress-firewall-xpn-error: "true"
hinzu.
Zusammenfassung der externen Ingress-Annotationen
Ingress-Annotationen
Annotation | Beschreibung |
---|---|
kubernetes.io/ingress.allow-http | Gibt an, ob HTTP-Traffic zwischen dem Client und dem HTTP(S)-Load-Balancer zugelassen wird. Mögliche Werte sind "true" und "false". Der Standardwert ist "true". Weitere Informationen finden Sie unter HTTP deaktivieren. |
ingress.gcp.kubernetes.io/pre-shared-cert | Mit dieser Annotation können Sie Zertifikatsressourcen an GKE-Ingress-Ressourcen anhängen. Weitere Informationen finden Sie unter Mehrere SSL-Zertifikate mit externen Application Load Balancern verwenden. |
kubernetes.io/ingress.global-static-ip-name | Mit dieser Annotation können Sie festlegen, dass der Load-Balancer eine statische externe IP-Adresse verwenden soll, die Sie zuvor erstellt haben. Weitere Informationen finden Sie unter Statische IP-Adressen für HTTP(S)-Load-Balancer. |
networking.gke.io/v1beta1.FrontendConfig | Mit dieser Annotation können Sie die clientseitige Konfiguration des Load-Balancers anpassen. Weitere Informationen finden Sie unter Ingress-Konfiguration. |
networking.gke.io/suppress-firewall-xpn-error | Wenn Kubernetes bei Ingress-Load-Balancern die Firewallregeln aufgrund unzureichender Berechtigungen nicht ändern kann, wird alle paar Minuten ein firewallXPNError -Ereignis erstellt. Ab GLBC 1.4 können Sie das Ereignis firewallXPNError stummschalten. Dazu müssen Sie der Ressource für eingehenden Traffic die Annotation networking.gke.io/suppress-firewall-xpn-error: "true" hinzufügen. Sie können diese Annotation jederzeit entfernen, um die Stummschaltung aufzuheben. Mögliche Werte sind true und false .
Der Standardwert ist false .
|
Ingress-Dienstannotationen
Annotation | Beschreibung |
---|---|
cloud.google.com/app-protocols | Mit dieser Annotation können Sie das Protokoll für die Kommunikation zwischen dem Load-Balancer und der Anwendung festlegen. Die Protokolle HTTP, HTTPS und HTTP2 stehen zur Auswahl. Weitere Informationen finden Sie unter HTTPS zwischen Load-Balancer und Ihrer Anwendung und HTTP/2 für Load-Balancing mit Ingress. |
cloud.google.com/backend-config | Mit dieser Annotation können Sie einen Backend-Dienst konfigurieren, der einem Service zugeordnet ist. Weitere Informationen finden Sie unter Ingress-Konfiguration. |
cloud.google.com/neg | Mit dieser Annotation legen Sie fest, dass der Load-Balancer Netzwerk-Endpunktgruppen verwenden soll. Weitere Informationen finden Sie unter Containernatives Load-Balancing verwenden. |
Nächste Schritte
- Führen Sie die Anleitung unter Externen Application Load Balancer mit Ingress einrichten aus.
Konzeptübersicht über Services in GKE lesen
Implementieren Sie ein grundlegendes externes Ingress.