Ingress für interne Application Load Balancer konfigurieren

Auf dieser Seite erfahren Sie, wie Sie Ingress für interne Application Load Balancer in Google Kubernetes Engine (GKE) einrichten und verwenden. Ingress unterstützt das interne Load-Balancing über den GKE-Ingress-Controller.

Weitere Informationen dazu, welche Features für Ingress für interne Application Load Balancer unterstützt werden, finden Sie unter Ingress-Features. Weitere Informationen zur Funktionsweise von Ingress für interne Application Load Balancer finden Sie unter Ingress für interne Application Load Balancer.

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.

Voraussetzungen

Ingress für interne Application Load Balancer hat die folgenden Anforderungen:

  • Der Cluster muss eine GKE-Version nach 1.16.5-gke.10 verwenden.
  • Der Cluster muss VPC-nativ sein.
  • Für den Cluster muss das Add-on HttpLoadBalancing aktiviert sein. Dieses Add-on ist standardmäßig aktiviert. Sie dürfen es nicht deaktivieren.
  • Sie müssen Netzwerk-Endpunktgruppen (NEGs) als Back-Ends für Ihren Dienst verwenden.

Ingress für interne Application Load Balancer bereitstellen

In den folgenden Übungen erfahren Sie, wie Sie Ingress für interne Application Load Balancer bereitstellen:

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

Umgebung vorbereiten

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.

Nur-Proxy-Subnetz erstellen:

gcloud compute networks subnets create proxy-only-subnet \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=COMPUTE_REGION \
    --network=NETWORK_NAME \
    --range=10.129.0.0/23

Ersetzen Sie Folgendes:

Weitere Informationen finden Sie unter Nur-Proxy-Subnetz konfigurieren.

Firewallregel erstellen

Der Ingress-Controller erstellt keine Firewallregel, um Verbindungen von den Load-Balancer-Proxys im Proxy-Subnetz zuzulassen. Sie müssen diese Firewallregel manuell erstellen. Der Ingress-Controller erstellt jedoch Firewallregeln, um eingehenden Traffic für Google Cloud-Systemdiagnosen zuzulassen.

Erstellen Sie eine Firewallregel, um Verbindungen von den Load-Balancer-Proxys im Nur-Proxy-Subnetz zum Überwachungsport des Pods zuzulassen:

gcloud compute firewall-rules create allow-proxy-connection \
    --allow=TCP:CONTAINER_PORT \
    --source-ranges=10.129.0.0/23 \
    --network=NETWORK_NAME

Ersetzen Sie CONTAINER_PORT durch den Wert des Ports, den der Pod überwacht, z. B. 9376.

Cluster erstellen

In diesem Abschnitt erstellen Sie einen VPC-nativen Cluster, den Sie mit Ingress für interne Application Load Balancer verwenden können. Sie können diesen Cluster mithilfe der Google Cloud CLI oder der Google Cloud Console erstellen.

gcloud

Erstellen Sie einen Cluster im selben Netzwerk wie das Nur-Proxy-Subnetz:

gcloud container clusters create-auto CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --network=NETWORK_NAME

Ersetzen Sie Folgendes:

  • CLUSTER_NAME: ein Name für Ihren Cluster.
  • COMPUTE_LOCATION: der Compute Engine-Standort für den Cluster. Sie müssen denselben Standort verwenden wie das Proxy-Subnetz, das Sie im vorherigen Abschnitt erstellt haben.

Console

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

    Zur Seite „Google Kubernetes Engine“

  2. Klicken Sie auf Erstellen.

  3. Klicken Sie im Bereich „Autopilot“ auf Konfigurieren.

  4. Geben Sie im Bereich Clustergrundlagen Folgendes ein:

    1. Geben Sie den Namen für den Cluster ein.
    2. Wählen Sie als Standorttyp eine Compute Engine-Region für Ihren Cluster aus. Sie müssen dieselbe Region verwenden wie das Proxy-Subnetz, das Sie im vorherigen Abschnitt erstellt haben.

  5. Klicken Sie im Navigationsbereich auf Netzwerk.

  6. Wählen Sie in der 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.

  7. Wählen Sie in der Liste Knotensubnetz das von Ihnen erstellte Proxy-Subnetz aus.

  8. Klicken Sie auf Erstellen.

Webanwendung bereitstellen

In diesem Abschnitt erstellen Sie ein Deployment.

So erstellen Sie ein Deployment:

  1. Speichern Sie das folgende Beispielmanifest als 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: registry.k8s.io/serve_hostname:v1.4
        name: hostname-server
        ports:
        - containerPort: 9376
          protocol: TCP
      terminationGracePeriodSeconds: 90

    Dieses Manifest beschreibt ein Deployment, das einen HTTPS-Server auf 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. Wenden Sie das Manifest 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 Backend-Container anhand ihrer Labels aus, damit der Ingress-Controller sie als Backend-Endpunkte programmieren kann. Wenn Sie Ingress für interne Application Load Balancer 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 verwenden VPC-native Cluster.
  • Sie verwenden keine freigegebene VPC.
  • Sie verwenden keine GKE-Netzwerkrichtlinie.

Die Annotation wird automatisch mithilfe einer MutatingWebhookConfiguration mit dem Namen neg-annotation.config.common-webhooks.networking.gke.io hinzugefügt. Mit dem folgenden Befehl können Sie prüfen, ob die MutatingWebhookConfiguration vorhanden ist:

kubectl get mutatingwebhookconfigurations

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 Application 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. Speichern Sie das folgende Beispielmanifest als 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: ClusterIP

  2. Wenden Sie das Manifest 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-Balancers über den Ingress-Controller auslöst. Ingress für interne Application Load Balancer erfordert die folgende Annotation:

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

Sie können das Feld ingressClassName nicht verwenden, um eine GKE-Ingress-Ressource anzugeben. Sie müssen die Annotation kubernetes.io/ingress.class verwenden. Weitere Informationen finden Sie unter Verhalten des GKE-Ingress-Controllers.

So erstellen Sie ein Ingress:

  1. Speichern Sie das folgende Beispielmanifest als 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. Wenden Sie das Manifest 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 entsprechende Ausgabe sieht etwa so aus:

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

    gcloud compute instances create l7-ilb-client \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --network=NETWORK_NAME \
    --subnet=SUBNET_NAME \
    --zone=COMPUTE_ZONE \
    --tags=allow-ssh

    Ersetzen Sie Folgendes:

    • SUBNET_NAME: Der Name eines Subnetzes im Netzwerk.
    • COMPUTE_ZONE: Eine Compute Engine-Zone in der Region.

    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 \
    --zone=COMPUTE_ZONE

    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.

Informationen zum Bereitstellen einer Anwendung in GKE und zum Freigeben der Anwendung mit einer privaten IP-Adresse mit Load-Balancing finden Sie unter Grundlegender interner Ingress.

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 die statische IP-Adresse, bevor Sie die Ingress-Ressource bereitstellen. 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. 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.
  • Die statische IP-Adresse wird im Dienstprojekt reserviert für ein Ingress, das im Dienstprojekt einer freigegebenen VPC bereitgestellt wird.
  • 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. Die gleichzeitige Verwendung von HTTPS und HTTP wird für GKE 1.25 und höher unterstützt. Um dieses Feature zu aktivieren, müssen Sie eine statische IP-Adresse mit PURPOSE=Shared_LOADBALANCER_VIP erstellen und für eingehenden Traffic konfigurieren. Wenn keine statische IP-Adresse angegeben ist, ist nur HTTPS-Traffic zulässig. Folgen Sie der Dokumentation zum Deaktivieren von HTTP.

In den folgenden Schritten wird beschrieben, wie Sie ein Zertifikat in Google Cloud erstellen und es dann über Ingress an interne Clients für HTTPS- und HTTP-Traffic senden:

  1. Erstellen Sie das regionale Zertifikat:

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

    Dabei gilt:

    • CERT_NAME: ein Name für das von Ihnen ausgewählte Zertifikat.
    • CERT_FILE_PATH: der Pfad zu Ihrer lokalen Zertifikatsdatei, um ein selbstverwaltetes Zertifikat zu erstellen. Das Zertifikat muss im PEM-Format sein.
    • KEY_FILE_PATH: der Pfad zu einer lokalen privaten Schlüsseldatei Der private Schlüssel muss das Format PEM haben und muss die RSA- oder ECDSA-Verschlüsselung verwenden.
    • COMPUTE_REGION: eine Compute Engine-Region für Ihr Zertifikat.

  2. Reservieren Sie eine statische IP-Adresse und wenden Sie sie gemäß der statischen IP-Adressierung an.

  3. Speichern Sie das folgende Beispielmanifest als 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.regional-static-ip-name: STATIC_IP_NAME
    kubernetes.io/ingress.class: "gce-internal"
spec:
  rules:
  - host: DOMAIN
    http:
      paths:
      - pathType: ImplementationSpecific
        backend:
          service:
            name: SERVICE_NAME
            port:
              number: 80

    Dabei gilt:

    • DOMAIN: Ihre Domain
    • CERT_NAME: der Name des Zertifikats, das Sie im vorherigen Abschnitt erstellt haben.
    • SERVICE_NAME: der Name Ihres Dienstes.

  4. Wenden Sie das Manifest auf den Cluster an:

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

HTTPS zwischen Load-Balancer und Anwendung

Wenn Ihre Anwendung in einem GKE-Pod ausgeführt wird und HTTPS-Anfragen empfangen kann, können Sie den Load-Balancer so konfigurieren, dass er bei der Weiterleitung von Anfragen an Ihre Anwendung HTTPS verwendet. Weitere Informationen finden Sie unter HTTPS (TLS) zwischen dem Load-Balancer und Ihrer Anwendung.

Freigegebene VPC

NEG-Annotation manuell hinzufügen

Wenn sich die GKE, in der Sie die Ingress-Ressourcen bereitstellen, in einem Dienstprojekt mit freigegebener VPC befindet, werden die Dienste nicht automatisch mit cloud.google.com/neg: '{"ingress": true}' annotiert, da die MutatingWebhookConfiguration, die für das Einfügen der Annotation für die Dienste zuständig ist, nicht installiert ist.

Sie müssen die NEG-Annotation dem Manifest der Services hinzufügen, die über Ingress für interne Application Load Balancer verfügbar gemacht werden.

VPC-Firewallregeln

Wenn sich der GKE-Cluster, in dem Sie die Ingress-Ressourcen bereitstellen, in einem Dienstprojekt mit freigegebener VPC 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 eingehenden 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 internen Ingress-Annotationen

Die folgenden Tabellen zeigen die Annotationen, die Sie beim Erstellen von Ingress- und Dienstressourcen für Ingress für interne Application Load Balancer hinzufügen können.

Ingress-Annotationen

Annotation Beschreibung
kubernetes.io/ingress.class Sie können "gce-internal" für internes Ingress festlegen. Wenn die Klasse nicht angegeben ist, wird eine Ingress-Ressource standardmäßig als externe Ingress-Ressource interpretiert. Weitere Informationen finden Sie unter Verhalten des GKE-Ingress-Controllers.
kubernetes.io/ingress.allow-http Sie können HTTP-Traffic zwischen dem Client und dem HTTP(S)-Load-Balancer zulassen. Die möglichen Werte sind true und false. Der Standardwert ist true. 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 mit externen Application Load Balancern verwenden.
networking.gke.io/suppress-firewall-xpn-error

Ab GLBC 1.4 können Sie das Ereignis firewallXPNError stummschalten. Wenn Kubernetes bei Ingress-Load-Balancern die Firewallregeln aufgrund unzureichender Berechtigungen nicht ändern kann, wird alle paar Minuten ein firewallXPNError-Ereignis ausgegeben.

Fügen Sie der Ingress-Ressource die Annotation networking.gke.io/suppress-firewall-xpn-error: "true" hinzu. Der Standardwert ist false. Sie können diese Annotation jederzeit entfernen, um die Stummschaltung aufzuheben.

kubernetes.io/ingress.regional-static-ip-name Sie können eine statische IP-Adresse angeben, um Ihre interne Ingress-Ressource bereitzustellen. Weitere Informationen finden Sie unter Statische IP-Adressierung.
Annotation Beschreibung
cloud.google.com/backend-config Mit dieser Annotation können Sie den einem ServicePort zugeordneten Backend-Dienst konfigurieren. 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.

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 entsprechende Ausgabe sieht etwa so aus:

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

Die entsprechende Ausgabe sieht etwa so aus:

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

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

gcloud compute backend-services list

Die entsprechende Ausgabe sieht etwa so aus:

NAME                                         BACKENDS                                                                       PROTOCOL
k8s1-42084f6a-default-hostname-80-98cbc1c1   REGION_NAME/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 COMPUTE_REGION

Ersetzen Sie COMPUTE_REGION durch die Compute Engine-Region des Back-End-Dienstes.

Die entsprechende Ausgabe sieht etwa so aus:

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

Nächste Schritte