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.
Vorbereitung
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:
- Umgebung vorbereiten
- Cluster erstellen
- Anwendung bereitstellen
- Service bereitstellen
- Ingress bereitstellen
- Bereitstellung validieren
- 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 dabei Folgendes:
COMPUTE_REGION
: Eine Compute Engine-Region.NETWORK_NAME
: Name des Netzwerks für das Subnetz.
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 dabei 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
Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.
Klicken Sie auf add_box Erstellen.
Klicken Sie im Bereich „Autopilot“ auf Konfigurieren.
Geben Sie im Bereich Clustergrundlagen Folgendes ein:
- Geben Sie den Namen für den Cluster ein.
- 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.
Klicken Sie im Navigationsbereich auf Netzwerk.
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.
Wählen Sie in der Liste Knotensubnetz das von Ihnen erstellte Proxy-Subnetz aus.
Klicken Sie auf Erstellen.
Webanwendung bereitstellen
In diesem Abschnitt erstellen Sie ein Deployment.
So erstellen Sie ein Deployment:
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.
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:
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
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:
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
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:
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 dabei 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.
Um von der VM aus auf die interne VIP zuzugreifen, verwenden Sie
curl
:Stellen Sie eine SSH-Verbindung zur VM her, die Sie im vorherigen Schritt erstellt haben:
gcloud compute ssh l7-ilb-client \ --zone=COMPUTE_ZONE
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:
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.
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 sowohl für HTTPS- als auch für HTTP-Traffic senden.
Erstellen Sie das regionale Zertifikat:
gcloud compute ssl-certificates create CERT_NAME \ --certificate CERT_FILE_PATH \ --private-key KEY_FILE_PATH \ --region COMPUTE_REGION
Ersetzen Sie dabei Folgendes:
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.
Reservieren und wenden Sie eine statische IP-Adresse gemäß Statische IP-Adresse an.
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
Ersetzen Sie dabei Folgendes:
DOMAIN
: Ihre DomainCERT_NAME
: der Name des Zertifikats, das Sie im vorherigen Abschnitt erstellt haben.SERVICE_NAME
: der Name Ihres Dienstes.
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
Fügen Sie der Ingress-Ressource die Annotation |
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. |
Ingress-Dienstannotationen
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 Backend-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
Implementieren Sie eine grundlegende interne Ingress-Ressource.