Fehlerbehebung und Vorgänge für Ingress for Anthos

Der Anthos Ingress-Controller verwaltet Compute Engine-Ressourcen. Die Ressourcen MultiClusterIngress (MCI) und MultiClusterService (MCS) sind verschiedenen Compute Engine-Ressourcen zugeordnet. Wenn Sie die Beziehung zwischen diesen Ressourcen kennen, können Sie eventuelle Fehler beheben. Untersuchen Sie beispielsweise die folgende MCI-Ressource:

apiVersion: extensions/v1beta1
kind: MultiClusterIngress
metadata:
  name: foo-ingress
spec:
  rules:
  - host: store.foo.com
    http:
      paths:
      - backend:
          serviceName: store-foo
          servicePort: 80
  - host: search.foo.com
    http:
      paths:
      - backend:
          serviceName: search-foo
          servicePort: 80

Compute Engine zu Ingress for Anthos-Ressourcenzuordnungen

Die folgende Tabelle stellt die Zuordnung von Environ-Ressourcen zu Ressourcen dar, die in den Kubernetes-Clustern und Google Cloud erstellt wurden:

Kubernetes-Ressource	Google Cloud-Ressource	Beschreibung
MultiClusterIngress	Weiterleitungsregel	HTTP(S)-Load-Balancer-VIP.
	Zielproxy	Einstellungen für die HTTP/S-Beendigung, die aus Annotationen und aus dem TLS-Block übernommen werden.
	URL-Zuordnung	Pfadzuordnung für den virtuellen Host aus dem Abschnitt "Regeln".
MultiClusterService	Kubernetes-Dienst	Aus der Vorlage abgeleitete Ressource.
	Back-End-Dienst	Für jedes Paar (Service, ServicePort) wird ein Back-End-Dienst erstellt.
	Netzwerk-Endpunktgruppen	Satz von Back-End-Pods, die zum Dienst gehören.

Das folgende Diagramm veranschaulicht die Beziehung zwischen MCI/MCS und den Compute Engine-Load-Balancer-Ressourcen in zwei Mitgliedsclustern:

Diagramm: MCI-/MCS-Load-Balancer-Beziehung

Ressourcen des Compute Engine-Load-Balancers prüfen

Nach dem Erstellen eines Load-Balancers enthält der Ingress-Status die Namen aller Compute Engine-Ressourcen, die zum Erstellen des Load-Balancers erstellt wurden. Beispiel:

Name:         shopping-service
Namespace:    prod
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1beta1
Kind:         MultiClusterIngress
Metadata:
  Creation Timestamp:  2019-07-16T17:23:14Z
  Finalizers:
    mci.finalizer.networking.gke.io
Spec:
  Template:
    Spec:
      Backend:
        Service Name:  shopping-service
        Service Port:  80
Status:
  VIP:  34.102.212.68
  CloudResources:
    Firewalls: "mci-l7"
    ForwardingRules: "mci-abcdef-myforwardingrule"
    TargetProxies: "mci-abcdef-mytargetproxy"
    UrlMap: "mci-abcdef-myurlmap"
    HealthChecks: "mci-abcdef-80-myhealthcheck"
    BackendServices: "mci-abcdef-80-mybackendservice"
    NetworkEndpointGroups: "k8s1-neg1", "k8s1-neg2", "k8s1-neg3"

VIP nicht erstellt

Wenn keine VIP angezeigt wird, ist möglicherweise während der Erstellung ein Fehler aufgetreten. Führen Sie den folgenden Befehl aus, um festzustellen, ob ein Fehler aufgetreten ist:

kubectl describe mci shopping-service

Die Ausgabe sieht in etwa so aus:

Name:         shopping-service
Namespace:    prod
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1beta1
Kind:         MultiClusterIngress
Metadata:
  Creation Timestamp:  2019-07-16T17:23:14Z
  Finalizers:
    mci.finalizer.networking.gke.io
Spec:
  Template:
    Spec:
      Backend:
        Service Name:  shopping-service
        Service Port:  80
Status:
  VIP:  34.102.212.68
Events:
  Type     Reason  Age   From                              Message
  ----     ------  ----  ----                              -------
  Warning  SYNC    29s   multi-cluster-ingress-controller  error translating MCI prod/shopping-service: exceeded 4 retries with final error: error translating MCI prod/shopping-service: multiclusterservice prod/shopping-service does not exist

In diesem Beispiel besteht der Fehler darin, dass der Nutzer die MultiClusterService-Ressource, auf die von MultiClusterIngress verwiesen wird, nicht erstellt hat.

In den meisten Fällen gibt die Fehlermeldung das zugrunde liegende Problem an. Sollte dies nicht der Fall sein, wenden Sie sich an gke-mci-feedback@google.com.

502-Antwort

Wenn Ihr Load-Balancer eine VIP erhalten hat, aber immer eine 502-Antwort ausgibt, schlagen möglicherweise die Systemdiagnosen des Load-Balancers fehl. Systemdiagnosen können aus zwei Gründen fehlschlagen:

Anwendungs-Pods sind nicht fehlerfrei (siehe z. B. das Cloud Console-Debugging).
Eine falsch konfigurierte Firewall verhindert, dass Google-Systemdiagnosen ausgeführt werden.

Sorgen Sie bei Fall 1 dafür, dass Ihre Anwendung tatsächlich eine 200-Antwort im Pfad "/" bereitstellt.

Stellen Sie bei Fall 2 sicher, dass in Ihrer VPC eine Firewall namens "mci-default-l7" vorhanden ist. Der Ingress-Controller erstellt die Firewall in Ihrer VPC, damit Google-Systemdiagnosen Ihre Back-Ends erreichen können. Wenn die Firewall nicht vorhanden ist, müssen Sie dafür sorgen, dass diese Firewall nach dem Erstellen nicht durch eine externe Automatisierung gelöscht wird.

Traffic, der dem Cluster nicht hinzugefügt oder daraus entfernt wurde

Beim Hinzufügen einer neuen Mitgliedschaft sollte der Traffic gegebenenfalls die Back-Ends im zugrunde liegenden Cluster erreichen. Wenn eine Mitgliedschaft entfernt wird, sollte entsprechend kein Traffic die Back-Ends im zugrunde liegenden Cluster erreichen. Wenn dieses Verhalten nicht auftritt, prüfen Sie die Ressourcen MultiClusterIngress und MultiClusterService auf eventuelle Fehler.

Ein solcher Fehler kommt vor, wenn Sie einem GKE-Cluster, der sich nicht im VPC-nativen Modus befindet, eine neue Mitgliedschaft hinzufügen oder eine neue Mitgliedschaft hinzufügen, aber keine Anwendung im GKE-Cluster bereitstellen.

Beschreiben Sie MultiClusterService:
```
kubectl describe mcs zone-svc
```
Beschreiben Sie MultiClusterIngress:
```
kubectl describe mci zone-mci
```

Wenn sich der Fehler durch die obigen Befehle nicht ergründen lässt, wenden Sie sich an gke-mci-feedback@google.com.

Migration des Konfigurationsclusters

Weitere Informationen zu den Anwendungsfällen für die Migration finden Sie unter Clusterdesign konfigurieren.

Wenn die Migration von Konfigurationsclustern nicht korrekt ausgeführt wird, kann diese zu einer Unterbrechung führen. Um dies zu vermeiden, müssen Sie bei einer Migration des Konfigurationsclusters die folgenden Richtlinien beachten:

Achten Sie darauf, dass für Ihre MCI-Ressourcen die static-ip-Annotation verwendet wird. Andernfalls wird der Traffic während der Migration unterbrochen. Sitzungsspezifische IP-Adressen werden bei der Migration von Konfigurationsclustern neu erstellt.
Die Ressourcen MultiClusterIngress und MultiClusterService müssen für den vorhandenen und den neuen Konfigurationscluster identisch bereitgestellt werden. Eventuelle Unterschiede führen zu einem Abgleich der MCS- und MCI-Ressourcen, die sich im neuen Konfigurationscluster unterscheiden.
Es kann immer nur ein einziger Konfigurationscluster aktiv sein. Bis zur Änderung des Konfigurationsclusters haben die MCI- und MCS-Ressourcen im neuen Konfigurationscluster keine Auswirkungen auf die lokalen Load-Balancing-Ressourcen.

Führen Sie zum Migrieren des Konfigurationsclusters den folgenden Befehl aus:

  gcloud alpha container hub ingress update \
    --config-membership=projects/project_id/locations/global/memberships/new_config_cluster

Prüfen Sie, ob der Befehl funktioniert hat und keine sichtbaren Fehler im Featurestatus vorliegen:

  gcloud alpha container hub ingress describe

In der Console debuggen

In den meisten Fällen ist es hilfreich, den genauen Status des Load-Balancers zu prüfen, wenn ein Problem behoben werden muss. Sie finden den Load-Balancer in der Google Cloud Console unter Load-Balancing.

Fehler-/Warncodes

Ingress for Anthos gibt Fehler- und Warncodes für MCI- und MCS-Ressourcen sowie das multiclusteringress-Beschreibungsfeld von gcloud für bekannte Probleme aus. In diesen Mitteilungen sind Fehler- und Warncodes dokumentiert, die eine Unterstützung für das Ermitteln der Ursache eines aufgetretenen Fehlers bieten. Jeder Code besteht aus einer Fehler-ID im Format AVMBR123, wobei 123 eine eindeutige Zahl ist, die einem Fehler oder einer Warnung sowie Lösungsvorschlägen entspricht.

AVMBR101: "Annotation [NAME] nicht erkannt"

Dieser Fehler wird angezeigt, wenn für eine MCI/MCS-Spezifikation eine Annotation angegeben ist, die nicht erkannt wird. Es gibt mehrere Gründe, warum die Annotation möglicherweise nicht erkannt wird:

Die Annotation wird in Ingress for Anthos nicht unterstützt. Dies kann auftreten, wenn Ressourcen annotiert werden, die nicht vom Anthos Ingress-Controller verwendet werden sollen.
Die Annotation wird unterstützt, ist jedoch falsch geschrieben und wird daher nicht erkannt.

In beiden Fällen finden Sie in der Dokumentation Informationen zu den unterstützten Annotationen und ihrer Definition.

AVMBR102: "[RESOURCE_NAME] nicht gefunden"

Dieser Fehler wird angezeigt, wenn eine zusätzliche Ressource in einem MCI angegeben, aber nicht in der Konfigurationsmitgliedschaft gefunden wird. Dieser Fehler wird beispielsweise ausgegeben, wenn sich eine MCI-Ressource auf eine nicht gefundene MCS-Ressource bezieht oder eine MCS-Ressource auf eine nicht gefundene BackendConfig verweist. Es gibt mehrere Gründe, warum eine Ressource nicht gefunden werden konnte:

Sie befindet sich nicht im korrekten Namespace. Achten Sie darauf, dass sich Ressourcen, die aufeinander verweisen, alle im selben Namespace befinden.
Der Ressourcenname ist falsch geschrieben.
Die Ressource ist nicht mit dem richtigen Namespace und Namen vorhanden. Erstellen Sie sie in diesem Fall.

AVMBR103: "[CLUSTER_SELECTOR] ist ungültig"

Dieser Fehler wird angezeigt, wenn die für eine MCS-Ressource angegebene Clusterauswahl ungültig ist. Die ungültige Auswahl kann verschiedene Gründe haben:

Der angegebene String enthält einen Tippfehler.
Der angegebene String verweist auf eine Mitgliedschaft, die nicht mehr in Environ ist.

AVMBR104: "NEGs für Dienstport [SERVICE_PORT] nicht gefunden"

Dieser Fehler wird ausgegeben, wenn die Netzwerk-Endpunktgruppen (NEGs) für ein bestimmtes MultiClusterService-Dienst/Port-Paar nicht ermittelt werden können. NEGs sind die Ressourcen, die in Ihren Back-End-Clustern jeweils die Pod-Endpunkte enthalten. Der Hauptgrund, warum die NEGs möglicherweise nicht vorhanden sind, liegt darin, dass bei der Erstellung oder Aktualisierung der abgeleiteten Dienste in Ihren Back-End-Clustern ein Fehler aufgetreten ist. Weitere Informationen finden Sie in den Ereignissen in der Ressource MultiClusterService.

AVMBR105: "Anthos-Lizenz fehlt."

Dieser Fehler wird unter Funktionszustand angezeigt und gibt an, dass die Anthos API (anthos.googleapis.com) nicht aktiviert ist.

AVMBR106: "Der abgeleitete Dienst ist ungültig: [GRUND]."

Dieser Fehler wird unter den Ereignissen der Ressource MultiClusterService angezeigt. Ein häufiger Grund für diesen Fehler ist, dass die von MultiClusterService abgeleitete Dienstressource eine ungültige Spezifikation enthält.

Zum Beispiel ist für MultiClusterService in dieser Spezifikation kein ServicePort definiert.

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: zone-mcs
  namespace: zoneprinter
spec:
  clusters:
  - link: "us-central1-a/gke-us"
  - link: "europe-west1-c/gke-eu"

AVMBR107: "GKE-Clusterressourcenlink fehlt in Mitgliedschaft."

Dieser Fehler wird unter „Funktionsstatus“ angezeigt und tritt auf, weil kein GKE-Cluster die Ressource „Mitgliedschaft“ repräsentiert. Dies können Sie verifizieren, indem Sie die folgenden Befehl ausführen:

gcloud container hub memberships describe membership-name

Sorgen Sie außerdem dafür, dass unter dem Feld „Endpunkt“ kein GKE-Cluster-Ressourcenlink angegeben ist.

AVMBR108: "GKE-Cluster [NAME] nicht gefunden."

Dieser Fehler wird unter „Funktionsstatus“ angezeigt und ausgelöst, wenn der zugrunde liegende GKE-Cluster für die Mitgliedschaft nicht vorhanden ist.

AVMBR109: "[NAME] ist kein VPC-nativer GKE-Cluster."

Dieser Fehler wird unter Funktionsstatus angezeigt. Die Fehlermeldung wird ausgegeben, wenn der angegebene GKE-Cluster ein routenbasierter Cluster ist. Der Ingress for Anthos-Controller erstellt einen containernativen Load-Balancer mit NEGs. Cluster müssen VPC-nativ sein, um einen containernativen Load-Balancer verwenden zu können.

Weitere Informationen finden Sie unter VPC-nativen Cluster erstellen.

AVMBR110: "[IAM_BERECHTIGUNG] Berechtigung für GKE-Cluster [NAME] fehlt."

Dieser Fehler wird unter Funktionsstatus angezeigt. Dieser Fehler kann verschiedene Ursachen haben:

Der der Mitgliedschaft zugrunde liegende GKE-Cluster befindet sich in einem anderen Projekt als die Mitgliedschaft selbst.
Die angegebene IAM-Berechtigung wurde aus dem MultiClusterIngress-Dienst-Agent entfernt.

AVMBR111: "Config-Mitgliedschaft konnte nicht abgerufen werden: [GRUND]."

Dieser Fehler wird unter Funktionsstatus angezeigt. Dieser Fehler tritt hauptsächlich auf, da die Config-Mitgliedschaft gelöscht wurde, während die Funktion aktiviert war.

Sie sollten die Config-Mitgliedschaft nie löschen müssen. Wenn Sie dies ändern möchten, führen Sie die Schritte zur Migration von Config-Clustern aus.

AVMBR112: "Das HTTPLoadBalancing-Add-on ist im GKE-Cluster [NAME] deaktiviert."

Dieser Fehler wird unter Funktionsstatus angezeigt und tritt auf, wenn das Add-on HTTPLoadBalancing in einem GKE-Cluster deaktiviert ist. Sie können Ihren GKE-Cluster aktualisieren, um das HTTPLoadBalancing-Add-on zu aktivieren.

gcloud container clusters update name --update-addons=HttpLoadBalancing=ENABLED

AVMBR113: "Diese Ressource ist verwaist."

In einigen Fällen hängt der Nutzen einer Ressource davon ab, ob eine andere Ressource auf sie verweist. Diese Fehlermeldung wird ausgegeben, wenn eine Kubernetes-Ressource erstellt wird, auf die jedoch keine andere Ressource verweist. Dieser Fehler wird beispielsweise angezeigt, wenn Sie eine BackendConfig-Ressource erstellen, auf die kein MultiClusterService verweist.