Ingress für internes HTTP(S)-Load-Balancing konfigurieren

Auf dieser Seite erfahren Sie, wie Sie Ingress für das interne HTTP(S)-Load-Balancing in Google Kubernetes Engine (GKE) einrichten und verwenden. Ingress für internes HTTP(S)-Load-Balancing bietet integrierte Unterstützung für internes Load-Balancing über den GKE-Ingress-Controller.

Weitere Informationen darüber, welche Features für Ingress für das interne HTTP(S)-Load-Balancing unterstützt werden, finden Sie unter Ingress-Features. Weitere Informationen zur Funktionsweise von Ingress für internes HTTP(S)-Load-Balancing finden Sie hier.

Hinweis

Bevor Sie Load-Balancer-Ressourcen über die Kubernetes Ingress API bereitstellen können, müssen Sie Ihre Netzwerkumgebung vorbereiten, damit die Proxys des Load-Balancers in einer bestimmten Region bereitgestellt werden können. Informationen zum Bereitstellen des Nur-Proxy-Subnetzes finden Sie unter Netzwerk und Subnetze konfigurieren.

Sie müssen diesen Schritt ausführen, bevor Sie Ingress für das interne HTTP(S)-Load-Balancing bereitstellen.

Weitere Informationen darüber, warum Sie für das interne HTTP(S)-Load-Balancing ein Nur-Proxy-Subnetz verwenden müssen, finden Sie unter Erforderliche Netzwerkumgebung.

Voraussetzungen

Ingress für internes HTTP(S)-Load-Balancing hat die folgenden Anforderungen:

  • Der Cluster muss eine GKE-Version nach 1.16.5-gke.10 verwenden.
  • Der Cluster muss im VPC-nativen Modus (Alias-IP) ausgeführt werden. Weitere Informationen finden Sie unter VPC-native Cluster.
  • In Ihrem Cluster muss das HTTP-Load-Balancing aktiviert sein. Bei Clustern ist das HTTP-Load-Balancing standardmäßig aktiviert. Deaktivieren Sie das Add-on nicht.
  • Sie müssen Netzwerk-Endpunktgruppen (NEGs) als Back-Ends für Ihren Dienst verwenden.

Ingress für internes HTTP(S)-Load-Balancing bereitstellen

In den folgenden Übungen erfahren Sie, wie Sie Ingress für das interne HTTP(S)-Load-Balancing bereitstellen:

  1. Cluster erstellen
  2. Anwendung bereitstellen
  3. Service bereitstellen
  4. Ingress bereitstellen
  5. Bereitstellung validieren
  6. Ingress-Ressourcen löschen

Cluster erstellen

In diesem Abschnitt erstellen Sie einen Cluster, den Sie mit Ingress für das interne HTTP(S)-Load-Balancing verwenden können. Sie können diesen Cluster mit dem gcloud-Befehlszeilentool oder der Google Cloud Console erstellen.

gcloud

Erstellen Sie einen Cluster mit den folgenden Feldern:

gcloud container clusters create CLUSTER_NAME \
    --cluster-version=VERSION_NUMBER \
    --enable-ip-alias \
    --zone=ZONE \
    --network=NETWORK

Dabei gilt:

  • CLUSTER_NAME: Fügen Sie einen Namen für den Cluster hinzu.
  • VERSION_NUMBER: Fügen Sie eine Version ab 1.16.5-gke.10 hinzu. Sie können auch das Flag --release-channel verwenden, um eine Release-Version mit einer Standardversion ab 1.16.5-gke.10 auszuwählen.
  • --enable-ip-alias aktiviert die Alias-IP. Cluster, die Ingress für das interne HTTP(S)-Load-Balancing verwenden, müssen im VPC-nativen Modus (Alias-IP) ausgeführt werden. Weitere Informationen finden Sie unter VPC-nativen Cluster erstellen.
  • ZONE: Fügen Sie eine Zone hinzu, in der der Cluster erstellt werden soll. Sie müssen eine Zone in derselben Region wie das Proxy-Subnetz auswählen, das Sie für Ihren internen HTTP(S)-Load-Balancer beim Konfigurieren des Netzwerks und der Subnetze erstellt haben.
  • NETWORK: Fügen Sie den Namen des Netzwerks hinzu, in dem der Cluster erstellt werden soll. Dieses Netzwerk muss sich im selben VPC-Netzwerk wie das Proxy-Subnetz befinden.

Console

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

    Zur Seite "Google Kubernetes Engine"

  2. Klicken Sie auf Erstellen.

  3. Geben Sie im Bereich Clustergrundlagen Folgendes ein:

    1. Geben Sie den Namen für den Cluster ein.
    2. Wählen Sie unter Standorttyp eine Zone für den Cluster aus. Sie müssen eine Zone in derselben Region wie das Proxy-Subnetz auswählen, das Sie für den internen HTTP(S)-Load-Balancer erstellt haben, und zwar unter Netzwerk und Subnetze konfigurieren.
    3. Wählen Sie unter Version der Steuerungsebene eine statische Version ab Version 1.16.5-gke.10 oder eine Release-Version mit einer Standardversion über 1.16.5-gke.10 aus.
  4. Klicken Sie im Navigationsbereich unter Cluster auf Netzwerk.

    1. Wählen Sie in der Drop-down-Liste Netzwerk das Netzwerk aus, in dem der Cluster erstellt werden soll. Dieses Netzwerk muss sich im selben VPC-Netzwerk wie das Proxy-Subnetz befinden.
    2. Unter Erweiterte Netzwerkoptionen müssen die Optionen VPC-natives Traffic-Routing aktivieren (verwendet Alias-IP) und HTTP-Load-Balancing aktivieren ausgewählt sein.
  5. Klicken Sie auf Erstellen.

Webanwendung bereitstellen

In diesem Abschnitt erstellen Sie ein Deployment.

So erstellen Sie ein Deployment:

  1. Kopieren Sie die folgende Deployment-Ressource und speichern Sie sie in einer Datei mit dem Namen web-deployment.yaml:

    # web-deployment.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        app: hostname
      name: hostname-server
    spec:
      selector:
        matchLabels:
          app: hostname
      minReadySeconds: 60
      replicas: 3
      template:
        metadata:
          labels:
            app: hostname
        spec:
          containers:
          - image: k8s.gcr.io/serve_hostname:v1.4
            name: hostname-server
            ports:
            - containerPort: 9376
              protocol: TCP
          terminationGracePeriodSeconds: 90
    

    Diese Deployment-Datei verwendet ein Container-Image, das einen HTTPS-Server an Port 9376 beobachtet. Dieses Deployment verwaltet auch Pods für Ihre Anwendung. Jeder Pod führt einen Anwendungscontainer mit einem HTTPS-Server aus, der den Hostnamen des Anwendungsservers als Antwort zurückgibt. Der Standardhostname eines Pods ist der Name des Pods. Der Container übernimmt auch die ordnungsgemäße Beendigung.

  2. Nachdem Sie das Deployment erstellt haben, wenden Sie die Ressource auf den Cluster an:

    kubectl apply -f web-deployment.yaml
    

Service als Netzwerk-Endpunktgruppe (NEG) bereitstellen

In diesem Abschnitt erstellen Sie eine Dienstressource. Der Dienst wählt die Back-End-Container anhand ihrer Labels aus, damit der Ingress-Controller sie als Back-End-Endpunkte programmieren kann. Wenn Sie Ingress für das interne HTTP(S)-Load-Balancing nutzen möchten, müssen Sie NEGs als Back-Ends verwenden. Das Feature unterstützt keine Instanzgruppen als Back-Ends. Da NEG-Back-Ends erforderlich sind, ist die folgende NEG-Annotation erforderlich, wenn Sie Dienste bereitstellen, die über Ingress verfügbar gemacht werden:

annotations:
  cloud.google.com/neg: '{"ingress": true}'

Ihr Dienst wird automatisch mit cloud.google.com/neg: '{"ingress": true}' annotiert, wenn alle folgenden Bedingungen erfüllt sind:

  • Sie haben den Dienst in GKE-Clustern 1.17.6-gke.7 und höher erstellt.
  • Sie verwenden VPC-native Cluster.
  • Sie verwenden keine freigegebene VPC.
  • Sie verwenden keine GKE-Netzwerkrichtlinie.

Durch die Verwendung von NEGs kann der Ingress-Controller ein containernatives Load-Balancing durchführen. Für den Traffic findet das Load-Balancing direkt vom Ingress-Proxy zur Pod-IP statt und durchläuft keine Knoten-IP- oder Kube-Proxy-Netzwerke. Darüber hinaus werden Pod-Readiness-Gates implementiert, um den Zustand von Pods aus Sicht des Load-Balancers zu ermitteln, und nicht nur die Bereitschafts- und Aktivitätsprüfungen von Kubernetes. Pod-Readiness-Gates sorgen dafür, dass Traffic während Lebenszyklus-Ereignissen wie Pod-Start, Pod-Verlust oder Knotenverlust nicht unterbrochen wird.

Wenn Sie keine NEG-Annotation einfügen, erhalten Sie eine Warnung für das Ingress-Objekt, die die Konfiguration des internen HTTP(S)-Load-Balancers verhindert. Wenn die NEG-Annotation nicht enthalten ist, wird auch ein Kubernetes-Ereignis für das Ingress-Ereignis generiert. Die folgende Nachricht ist ein Beispiel für die Ereignisnachricht:

Message
-------
error while evaluating the ingress spec: could not find port "8080" in service "default/no-neg-svc"

Eine NEG wird erst erstellt, wenn ein Ingress-Objekt auf den Dienst verweist. Die NEG wird erst in Compute Engine angezeigt, wenn sowohl das Ingress-Objekt als auch der zugehörige Dienst vorhanden sind. NEGs sind zonale Ressourcen und für multizonale Cluster wird eine pro Dienst und Zone erstellt.

So erstellen Sie einen Service:

  1. Kopieren Sie die folgende Dienstressource und speichern Sie sie in einer Datei mit dem Namen web-service.yaml:

    # web-service.yaml
    apiVersion: v1
    kind: Service
    metadata:
      name: hostname
      namespace: default
      annotations:
        cloud.google.com/neg: '{"ingress": true}'
    spec:
      ports:
      - name: host1
        port: 80
        protocol: TCP
        targetPort: 9376
      selector:
        app: hostname
      type: NodePort
    
  2. Nachdem Sie die Dienstdatei erstellt haben, wenden Sie die Ressource auf den Cluster an:

    kubectl apply -f  web-service.yaml
    

Ingress bereitstellen

In diesem Abschnitt erstellen Sie eine Ingress-Ressource, die die Bereitstellung des Compute Engine-Load-Balancings über den Ingress-Controller auslöst. Ein Ingress für das interne HTTP(S)-Load-Balancing erfordert die folgende Annotation:

annotations:
    kubernetes.io/ingress.class: "gce-internal"

So erstellen Sie ein Ingress:

  1. Kopieren Sie die folgende Ingress-Ressource und speichern Sie sie in einer Datei mit dem Namen internal-ingress.yaml:

    # internal-ingress.yaml
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: ilb-demo-ingress
      namespace: default
      annotations:
        kubernetes.io/ingress.class: "gce-internal"
    spec:
      defaultBackend:
        service:
          name: hostname
          port:
            number: 80
    
  2. Nachdem Sie die Ingress-Datei erstellt haben, wenden Sie die Ressource auf den Cluster an:

    kubectl apply -f internal-ingress.yaml
    

Erfolgreiche Ingress-Bereitstellung prüfen

In diesem Abschnitt überprüfen Sie, ob Ihre Bereitstellung erfolgreich war.

Es kann einige Minuten dauern, bis die Ingress-Ressource vollständig bereitgestellt ist. Während dieser Zeit erstellt der Ingress-Controller Elemente wie Weiterleitungsregeln, Back-End-Dienste, URL-Zuordnungen und NEGs.

Führen Sie den folgenden Befehl aus, um den Status der im vorherigen Abschnitt erstellten Ingress-Ressource abzurufen:

kubectl get ingress ilb-demo-ingress

Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

NAME               HOSTS    ADDRESS            PORTS     AGE
ilb-demo-ingress   *        10.128.0.58        80        59s

Wenn das Feld ADDRESS ausgefüllt ist, ist Ingress bereit. Wenn eine RFC-1918-Adresse in diesem Feld verwendet wird, wird dadurch eine interne IP-Adresse innerhalb der VPC angegeben.

Da der interne HTTP(S)-Load-Balancer ein regionaler Load-Balancer ist, ist der Zugriff auf die virtuelle IP-Adresse (VIP) nur über einen Client in derselben Region und VPC möglich. Nachdem Sie die VIP des Load-Balancers abgerufen haben, können Sie mit Tools (z. B. curl) HTTP GET-Aufrufe an die VIP innerhalb der VPC senden.

Führen Sie die folgenden Schritte aus, um einen HTTP GET-Aufruf auszuführen:

  1. Wenn Sie die Ingress-VIP über die VPC erreichen möchten, stellen Sie eine VM in derselben Region und demselben Netzwerk wie der Cluster bereit.

    Wenn Sie beispielsweise die vorherigen Schritte zum Erstellen Ihres Deployments, des Dienstes und des Ingress ausgeführt und Ihren Cluster im Standardnetzwerk erstellt haben und in der Zone us-central1-a, können Sie den folgenden Befehl verwenden:

    gcloud compute instances create l7-ilb-client-us-central1-a \
        --image-family=debian-9 \
        --image-project=debian-cloud \
        --network=default \
        --subnet=default \
        --zone=us-central1-a \
        --tags=allow-ssh
    

    Weitere Informationen zum Erstellen von Instanzen finden Sie unter VM-Instanzen erstellen und starten.

  2. Um von der VM aus auf die interne VIP zuzugreifen, verwenden Sie curl:

    1. Stellen Sie eine SSH-Verbindung zur VM her, die Sie im vorherigen Schritt erstellt haben:

      gcloud compute ssh l7-ilb-client-us-central1-a \
         --zone=us-central1-a
      
    2. Verwenden Sie curl, um auf die VIP der internen Anwendung zuzugreifen:

      curl 10.128.0.58
      hostname-server-6696cf5fc8-z4788
      

      Durch eine erfolgreiche HTTP-Antwort und den Hostnamen eines der Back-End-Container wird darauf hingewiesen, dass der vollständige Load-Balancing-Pfad ordnungsgemäß funktioniert.

Ingress-Ressourcen löschen

Wenn Sie Ingress- und Dienstressourcen löschen, werden auch die ihnen zugeordneten Ressourcen des Compute Engine-Load-Balancers entfernt. Entfernen Sie Ingress-Ressourcen, sobald Sie sie nicht mehr benötigen. Dadurch vermeiden Sie Ressourcenlecks. Ingress- und Dienstressourcen müssen gelöscht werden, bevor Cluster gelöscht werden. Andernfalls sind die Ressourcen für das Compute Engine-Load-Balancing verwaist.

So entfernen Sie Ingress-Ressourcen:

  1. Löschen Sie die Ingress-Ressource. Führen Sie beispielsweise den folgenden Befehl aus, um die auf dieser Seite erstellte Ingress-Ressource zu löschen:

    kubectl delete ingress ilb-demo-ingress
    

    Durch das Löschen der Ingress-Ressource werden die Weiterleitungsregeln, Back-End-Dienste und URL-Zuordnungen entfernt, die mit dieser Ingress-Ressource verknüpft sind.

  2. Löschen Sie den Dienst. Führen Sie beispielsweise den folgenden Befehl aus, um den Dienst zu löschen, den Sie auf dieser Seite erstellt haben:

    kubectl delete service hostname
    

    Durch das Löschen des Dienstes wird die dem Dienst zugeordnete NEG entfernt.

Statische IP-Adresse

Interne Ingress-Ressourcen unterstützen sowohl statische als auch sitzungsspezifische IP-Adressen. Wenn keine IP-Adresse angegeben ist, wird automatisch eine verfügbare IP-Adresse aus dem GKE-Knotensubnetz zugewiesen. Die Ingress-Ressource stellt jedoch keine IP-Adressen aus dem Nur-Proxy-Subnetz bereit, da dieses Subnetz nur für den internen Proxy-Verbrauch verwendet wird. Diese sitzungsspezifischen IP-Adressen werden dem Ingress nur für den Lebenszyklus der internen Ingress-Ressource zugewiesen. Wenn Sie Ihr Ingress löschen und ein neues Ingress aus derselben Manifestdatei erstellen, wird nicht garantiert, dass Sie dieselbe externe IP-Adresse erhalten.

Wenn Sie eine permanente IP-Adresse möchten, die vom Lebenszyklus der internen Ingress-Ressource unabhängig ist, müssen Sie eine regionale statische interne IP-Adresse reservieren. Sie können dann eine statische IP-Adresse angeben. Dazu verwenden Sie die Anmerkung kubernetes.io/ingress.regional-static-ip-name für Ihre Ingress-Ressource.

Das folgende Beispiel zeigt, wie diese Annotation hinzugefügt wird:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.regional-static-ip-name: STATIC_IP_NAME
    kubernetes.io/ingress.class: "gce-internal"

Ersetzen Sie STATIC_IP_NAME durch einen statischen IP-Namen, der die folgenden Kriterien erfüllt:

  • Erstellen Sie vor der Bereitstellung des Ingress die statische IP-Adresse. Ein Load-Balancer wird erst bereitgestellt, wenn die statische IP-Adresse vorhanden ist. Wenn Sie auf eine nicht vorhandene IP-Adressressource verweisen, wird keine statische IP-Adresse erstellt.
  • Verweisen Sie auf die Google Cloud-IP-Adressressource anhand ihres Namens, nicht anhand der IP-Adresse.
  • Die IP-Adresse muss aus einem Subnetz stammen, das sich in derselben Region wie der GKE-Cluster befindet. Sie können jedes verfügbare private Subnetz innerhalb der Region verwenden (mit Ausnahme des Nur-Proxy-Subnetzes). Verschiedene Ingress-Ressourcen können auch Adressen aus verschiedenen Subnetzen haben.

HTTPS zwischen Client und Load-Balancer

Ingress für das interne Load-Balancing unterstützt die Bereitstellung von TLS-Zertifikaten an Clients. Sie können TLS-Zertifikate über Kubernetes-Secrets oder vorinstallierte regionale SSL-Zertifikate in Google Cloud bereitstellen. Sie können auch mehrere Zertifikate pro Ingress-Ressource angeben.

In den folgenden Schritten wird beschrieben, wie Sie ein Zertifikat in Google Cloud erstellen und es dann über Ingress an interne Clients senden.

  1. Erstellen Sie das regionale Zertifikat:

    gcloud compute ssl-certificates create CERT_NAME \
        --certificate CERT_FILE_PATH \
        --private-key KEY_FILE_PATH \
        --region REGION
    

    Dabei gilt:

    • CERT_NAME: Geben Sie einen Namen für das Zertifikat ein.
    • CERT_FILE_PATH: Fügen Sie den Pfad zu Ihrer lokalen Zertifikatsdatei hinzu, um ein selbstverwaltetes Zertifikat zu erstellen. Das Zertifikat muss im PEM-Format sein.
    • KEY_FILE_PATH: Fügen Sie den Pfad zu einer lokalen privaten Schlüsseldatei hinzu. Der private Schlüssel muss das Format PEM haben und muss die RSA- oder ECDSA-Verschlüsselung verwenden.
    • REGION: Fügen Sie eine Region für Ihr Zertifikat hinzu.
  2. Erstellen Sie eine Ingress-Ressource. Die folgende YAML-Datei mit dem Namen ingress-pre-shared-cert.yaml ist ein Beispiel für die Ingress-Ressource, die Sie erstellen müssen:

    # ingress-pre-shared-cert.yaml
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: ilb-demo-ing
      namespace: default
      annotations:
        ingress.gcp.kubernetes.io/pre-shared-cert: "CERT_NAME"
        kubernetes.io/ingress.class: "gce-internal"
        kubernetes.io/ingress.allow-http: "false"
    spec:
      rules:
      - host: DOMAIN
        http:
          paths:
          - backend:
              service:
                name: SERVICE_NAME
                port:
                  number: 80
    

    Dabei gilt:

    • DOMAIN: Fügen Sie Ihre Domain hinzu.
    • CERT_NAME: Fügen Sie den Namen des Zertifikats hinzu, das Sie im vorherigen Abschnitt erstellt haben.
    • SERVICE_NAME: Fügen Sie den Namen Ihres Dienstes hinzu.
  3. Nachdem Sie die Ingress-Ressource erstellt haben, wenden Sie die Ressource auf den Cluster an:

    kubectl apply -f ingress-pre-shared-cert.yaml
    

Zusammenfassung der internen Ingress-Annotationen

Die folgenden Tabellen zeigen die Annotationen, die Sie beim Erstellen von Ingress- und Dienstressourcen für Ingress für das interne HTTP(S)-Load-Balancing hinzufügen können.

Ingress-Annotationen

Annotation Beschreibung
kubernetes.io/ingress.class Wird für das interne Ingress als "gce-internal" angegeben. Wenn die Klasse nicht angegeben ist, wird eine Ingress-Ressource standardmäßig als externe Ingress-Ressource interpretiert.
kubernetes.io/ingress.allow-http Gibt an, ob HTTP-Traffic zwischen dem Client und dem HTTP(S)-Load-Balancer zugelassen wird. Die möglichen Werte sind true und false. Der Standardwert ist true. Sie müssen diese Annotation jedoch auf false festlegen, wenn Sie HTTPS für das interne Load-Balancing verwenden. Weitere Informationen finden Sie unter HTTP deaktivieren.
ingress.gcp.kubernetes.io/pre-shared-cert Sie können Zertifikate und Schlüssel in Ihr Google Cloud-Projekt hochladen. Verwenden Sie diese Annotation, um die Zertifikate und Schlüssel zu referenzieren. Weitere Informationen finden Sie unter Mehrere SSL-Zertifikate beim HTTP(S)-Load-Balancing verwenden.
Annotation Beschreibung
cloud.google.com/backend-config Mit dieser Annotation können Sie den einem ServicePort zugeordneten Back-End-Dienst konfigurieren. Weitere Informationen finden Sie unter Ingress-Features.
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.

Fehlerbehebung

Wenn Sie den Ingress-Status verstehen und beobachten möchten, müssen Sie in der Regel die zugehörigen Ressourcen prüfen. Zu den auftretenden Problemen zählen häufig Load-Balancing-Ressourcen, die nicht ordnungsgemäß erstellt werden, Traffic, der die Back-Ends nicht erreicht, oder Back-Ends, die nicht als fehlerfrei angezeigt werden.

Im Folgenden sind einige gängige Schritte zur Fehlerbehebung aufgeführt:

  • Prüfen, ob der Client-Traffic aus derselben Region und VPC stammt wie der Load-Balancer
  • Prüfen, ob die Pods und Back-Ends fehlerfrei sind
  • Prüfen des Traffic-Pfads zur VIP und für Compute Engine-Systemdiagnosen, um sich zu vergewissern, dass er nicht durch Firewallregeln blockiert wird
  • Prüfen der Ingress-Ressourcenereignisse auf Fehler
  • Beschreiben der Ingress-Ressource, um sich die Zuordnung zu Compute Engine-Ressourcen anzusehen
  • Prüfen, ob die Compute Engine-Load-Balancing-Ressourcen vorhanden sind, die richtigen Konfigurationen haben und keine Fehler gemeldet werden

Nach Ingress-Ereignissen filtern

Die folgende Abfrage filtert nach Fehlern in allen Ingress-Ereignissen in Ihrem Cluster:

kubectl get events --all-namespaces --field-selector involvedObject.kind=Ingress

Sie können auch nach Objekten oder Objektnamen filtern:

kubectl get events --field-selector involvedObject.kind=Ingress,involvedObject.name=hostname-internal-ingress

Im folgenden Fehler sehen Sie, dass der von der Ingress-Ressource referenzierte Dienst nicht existiert:

LAST SEEN   TYPE      REASON      OBJECT                              MESSAGE
0s          Warning   Translate   ingress/hostname-internal-ingress   error while evaluating the ingress spec: could not find service "default/hostname-invalid"

Ressourcen des Compute Engine-Load-Balancers prüfen

Der folgende Befehl zeigt die vollständige Ausgabe für die Ingress-Ressource an, damit Sie die Zuordnungen zu den Compute Engine-Ressourcen sehen können, die vom Ingress-Controller erstellt wurden:

kubectl get ing INGRESS_FILENAME -o yaml

Ersetzen Sie INGRESS_FILENAME durch den Dateinamen Ihrer Ingress-Ressource.

Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

apiVersion: v1
items:
- apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    annotations:
      ingress.kubernetes.io/backends: '{"k8s1-241a2b5c-default-hostname-80-29269aa5":"HEALTHY"}'
      ingress.kubernetes.io/forwarding-rule: k8s-fw-default-ilb-demo-ingress--241a2b5c94b353ec
      ingress.kubernetes.io/target-proxy: k8s-tp-default-ilb-demo-ingress--241a2b5c94b353ec
      ingress.kubernetes.io/url-map: k8s-um-default-ilb-demo-ingress--241a2b5c94b353ec
      kubectl.kubernetes.io/last-applied-configuration: |
       {"apiVersion":"networking.k8s.io/v1","kind":"Ingress","metadata":{"annotations":{"kubernetes.io/ingress.class":"gce-internal"},"name":"ilb-demo-ingress","namespace":"default"},"spec":{"defaultBackend":{"service":{"name":"hostname"},"port":{"number":80}}}}
      kubernetes.io/ingress.class: gce-internal
    creationTimestamp: "2019-10-15T02:16:18Z"
    finalizers:
    - networking.gke.io/ingress-finalizer
    generation: 1
    name: ilb-demo-ingress
    namespace: default
    resourceVersion: "1538072"
    selfLink: /apis/networking.k8s.io/v1/namespaces/default/ingresses/ilb-demo-ingress
    uid: 0ef024fe-6aea-4ee0-85f6-c2578f554975
  spec:
    defaultBackend:
      service:
        name: hostname
        port:
          number: 80
  status:
    loadBalancer:
      ingress:
      - ip: 10.128.0.127
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

Die ingress.kubernetes.io/backends-Annotationen enthalten die Back-Ends und ihren Status. Achten Sie darauf, dass Ihre Back-Ends als HEALTHY aufgeführt sind.

Die von der Ingress-Ressource erstellten Compute Engine-Ressourcen können direkt abgefragt werden, um ihren Status und ihre Konfiguration zu ermitteln. Diese Abfragen können auch bei der Fehlerbehebung hilfreich sein.

So listen Sie alle Compute Engine-Weiterleitungsregeln auf:

gcloud compute forwarding-rules list

Beispielausgabe:

NAME                                                        REGION       IP_ADDRESS      IP_PROTOCOL  TARGET
k8s-fw-default-hostname-internal-ingress--42084f6a534c335b  us-central1  10.128.15.225   TCP          us-central1/targetHttpProxies/k8s-tp-default-hostname-internal-ingress--42084f6a534c335b

Zum Auflisten des Back-End-Dienstes listen Sie zuerst die Back-End-Dienste auf und erstellen Sie eine Kopie des Namens des Back-End-Dienstes, den Sie untersuchen möchten:

gcloud compute backend-services list

Beispielausgabe:

NAME                                         BACKENDS                                                                       PROTOCOL
k8s1-42084f6a-default-hostname-80-98cbc1c1   us-central1-a/networkEndpointGroups/k8s1-42084f6a-default-hostname-80-98cbc1c1 HTTP

Sie können nun den Namen des Back-End-Dienstes verwenden, um seinen Zustand abzufragen:

gcloud compute backend-services get-health k8s1-42084f6a-default-hostname-80-98cbc1c1 \
    --region us-central1

Beispielausgabe:

backend: https://www.googleapis.com/compute/v1/projects/user1-243723/zones/us-central1-a/networkEndpointGroups/k8s1-42084f6a-default-hostname-80-98cbc1c1
status:
  healthStatus:
  - healthState: HEALTHY

Nächste Schritte