Fehlerbehebung und Vorgänge für Multi-Cluster-Ingress


Der GKE Enterprise Ingress-Controller verwaltet Compute Engine-Ressourcen. MultiClusterIngress- und MultiClusterService-Ressourcen 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 MultiClusterIngress-Ressource:

apiVersion: extensions/v1beta1
kind: MultiClusterIngress
metadata:
  name: foo-ingress
spec:
  template:
    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 Multi-Cluster-Ingress-Ressourcenzuordnungen

Die folgende Tabelle stellt die Zuordnung von Flotten-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.
Backend-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.

Ressourcen des Compute Engine-Load-Balancers prüfen

Nach dem Erstellen eines Load-Balancers enthält der Multi-Cluster-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.

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:

  1. Anwendungs-Pods sind nicht fehlerfrei (siehe z. B. das Cloud Console-Debugging).
  2. 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.

  1. Beschreiben Sie MultiClusterService:

    kubectl describe mcs zone-svc
    
  2. Beschreiben Sie MultiClusterIngress:

    kubectl describe mci zone-mci
    

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:

  1. Achten Sie darauf, dass für Ihre MultiClusterIngress-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.
  2. 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 MultiClusterService- und MultiClusterIngress-Ressourcen, die sich im neuen Konfigurationscluster unterscheiden.
  3. Es kann immer nur ein einziger Konfigurationscluster aktiv sein. Bis zur Änderung des Konfigurationsclusters haben die MultiClusterIngress- und MultiClusterService-Ressourcen im neuen Konfigurationscluster keine Auswirkungen auf die lokalen Load-Balancing-Ressourcen.

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

  gcloud container fleet 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 container fleet 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

Multi-Cluster-Ingress gibt Fehler- und Warnungscodes für MultiClusterIngress- und MultiClusterService-Ressourcen sowie das gcloud-Beschreibungsfeld multiclusteringress 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] not recognized

Dieser Fehler wird angezeigt, wenn für ein MultiClusterIngress- oder MultiClusterService-Manifest eine Annotation angegeben ist, die nicht erkannt wird. Es gibt mehrere Gründe, warum die Annotation möglicherweise nicht erkannt wird:

  1. Die Annotation wird in Multi-Cluster-Ingress nicht unterstützt. Dies kann auftreten, wenn Ressourcen annotiert werden, die nicht vom GKE Enterprise Ingress-Controller verwendet werden sollen.

  2. 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] not found.

Dieser Fehler wird angezeigt, wenn eine zusätzliche Ressource in einem MultiClusterIngress angegeben ist, aber nicht in der Konfigurationsmitgliedschaft gefunden wird. Dieser Fehler wird beispielsweise ausgegeben, wenn sich ein MultiClusterIngress auf einen MultiClusterService bezieht, der nicht gefunden wird, oder MultiClusterService auf eine BackendConfig bezieht, die nicht gefunden wird. Es gibt mehrere Gründe, warum eine Ressource nicht gefunden werden kann:

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

AVMBR103: [CLUSTER_SELECTOR] is invalid

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

  1. Der angegebene String enthält einen Tippfehler.
  2. Der angegebene String verweist auf eine Clustermitgliedschaft, die nicht mehr in der Flotte vorhanden ist.

AVMBR104: Cannot find NEGs for Service Port [SERVICE_PORT]

Dieser Fehler wird ausgegeben, wenn die Netzwerk-Endpunktgruppen (NEGs) für ein bestimmtes MultiClusterService- und Dienst/Port-Paar nicht ermittelt werden können. NEGs sind die Ressourcen, die in Ihren Back-End-Clustern jeweils die Pod-Endpunkte enthalten. Das liegt hauptsächlich daran, dass die NEGs möglicherweise nicht vorhanden sind, weil beim Erstellen oder Aktualisieren der abgeleiteten Dienste in Ihren Back-End-Clustern ein Fehler aufgetreten ist. Weitere Informationen finden Sie in den Ereignissen in der Ressource MultiClusterService.

AVMBR105: Missing GKE Enterprise license.

Dieser Fehler wird unter „Funktionsstatus“ angezeigt und bedeutet, dass die GKE Enterprise API (anthos.googleapis.com) nicht aktiviert ist.

AVMBR106: Derived service is invalid: [REASON].

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: whereami
spec:
  clusters:
  - link: "us-central1-a/gke-us"
  - link: "europe-west1-c/gke-eu"

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 fleet 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] not found.

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

AVMBR109: [NAME] is not a VPC-native GKE cluster.

Dieser Fehler wird unter Featurestatus angezeigt. Die Fehlermeldung wird ausgegeben, wenn der angegebene GKE-Cluster ein routenbasierter Cluster ist. Der Multi-Cluster-Ingress-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_PERMISSION] permission missing for GKE cluster [NAME].

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

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

AVMBR111: Failed to get Config Membership: [REASON].

Dieser Fehler wird unter Featurestatus angezeigt. Dieser Fehler tritt hauptsächlich auf, da die Konfigurationsmitgliedschaft gelöscht wurde, während das Feature 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: HTTPLoadBalancing Addon is disabled in GKE Cluster [NAME].

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: This resource is orphaned.

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.