Ingress für externe Application Load Balancer konfigurieren

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 Schritte durch, 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

  1. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

    Zur Seite "Google Kubernetes Engine"

  2. Klicken Sie auf den Namen des Clusters, den Sie ändern möchten.

  3. Klicken Sie unter Netzwerk im Feld HTTP-Load-Balancing auf HTTP-Load-Balancing bearbeiten.

  4. Klicken Sie das Kästchen HTTP-Load-Balancing aktivieren an.

  5. 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.

Anleitung

Deployments und Services erstellen

Erstellen Sie zwei Deployments mit Services namens hello-world-1 und hello-world-2:

  1. 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.

  2. Wenden Sie das Manifest auf den Cluster an:

    kubectl apply -f hello-world-deployment-1.yaml

  3. 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 Label version: 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.

  4. Wenden Sie das Manifest auf den Cluster an:

    kubectl apply -f hello-world-service-1.yaml

  5. 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.

  6. Wenden Sie das Manifest auf den Cluster an:

    kubectl apply -f hello-world-deployment-2.yaml

  7. 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 Label version: 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.

  8. 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.

  1. 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 mit spec.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 und kubernetes.io/ingress.class bereitstellen, erstellt GKE einen externen Application Load Balancer. Dies ist das gleiche Verhalten, wenn Sie die Annotation kubernetes.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. Jeder dieser Back-End-Dienste entspricht einem Kubernetes-Dienst und jeder Back-End-Dienst muss auf eine Google Cloud-Systemdiagnose verweisen. Diese Systemdiagnose unterscheidet sich von einer Kubernetes-Aktivitätsprüfung oder -Bereitschaftsprüfung, da die Systemdiagnose außerhalb des Clusters implementiert wird. Weitere Informationen finden Sie unter Systemdiagnosen.

    • Wenn ein Client eine Anfrage mit dem URL-Pfad / an den Load-Balancer sendet, leitet GKE die Anfrage an den Service hello-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 Service hello-world-2 auf Port 80 weiter. Weitere Informationen zu den Attributen path und pathType finden Sie unter URL-Pfade.

  2. 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:

  1. 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

  2. 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.

  3. 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

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 Zertifikatressourcen 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.
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