Probleme mit dem verwalteten Anthos Service Mesh beheben

In diesem Dokument werden häufig auftretende Anthos Service Mesh-Probleme und deren Behebung erläutert. Beispiel: Ein Pod wird mit istio.istio-system eingefügt und das Installationstool generiert Fehler wie HTTP-400-Statuscodes und Fehler bei der Clustermitgliedschaft.

Weitere Informationen zur Fehlerbehebung bei Anthos Service Mesh finden Sie unter Support.

Überarbeitungen werden als fehlerhafter Fehler gemeldet

Möglicherweise wird ein allgemeiner Revision(s) reporting unhealthy-Fehler angezeigt, wenn ein verwalteter Anthos Service Mesh nicht das erforderliche von Google verwaltete Dienstkonto mit Anthos Service Mesh Service Agent Identity- und IAM-Rollenbindungen (Identity and Access Management) hat. Typischerweise tritt dies auf, wenn die Berechtigung für die Anthos Service Mesh-Dienst-Agent-Rolle über eine Terraform-, Puppet- oder CI/CD-Neukonfiguration widerrufen wurde.

Die Schritte zur Fehlerbehebung bei diesem Fehler hängen davon ab, ob Sie die Google Cloud Console oder die Google Cloud CLI verwenden.

Google Cloud Console

  1. Rufen Sie in der Google Cloud Console IAM und Verwaltung > IAM auf.

  2. Wählen Sie Von Google bereitgestellte Rollenzuweisungen einschließen aus.

  3. Prüfen Sie die Hauptkontoliste.

    Wird das verwaltete Dienstkonto mit der erforderlichen IAM-Rolle in der Liste angezeigt, so ist es korrekt konfiguriert.

    Wird das erforderliche verwaltete Dienstkonto nicht mit der erforderlichen IAM-Rolle in der Liste angezeigt, ist die erforderliche IAM-Rollenbindung für Anthos Service Mesh-Dienst-Agents im verwalteten Dienstkonto nicht vorhanden.

  4. Weisen Sie dem von Anthos Service Mesh verwalteten Dienstkonto in der Google Cloud Console IAM-Rollenbindungen für den Anthos Service Mesh-Dienst-Agent (roles/anthosservicemesh.serviceAgent) zu.

Google Cloud CLI

  1. Führen Sie in der Google Cloud CLI folgenden Befehl aus, um zu prüfen, ob die erforderliche IAM-Rolle konfiguriert ist:

    gcloud projects get-iam-policy PROJECT_ID  \
    --flatten="bindings[].members" \
    --filter="bindings.members:serviceAccount:service-PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com AND bindings.role:roles/anthosservicemesh.serviceAgent" \
    --format='table(bindings.role)'
    
  2. Sehen Sie sich die ROLE-Liste an.

    Wenn Sie Rollen in der Liste sehen, ist sie richtig konfiguriert.

    Werden in der Liste keine Rollen angezeigt, wurden alle Rollen des verwalteten Dienstkontos widerrufen.

  3. Führen Sie folgenden Befehl aus, um dem verwalteten Anthos Service Mesh-Dienstkonto die erforderlichen IAM-Rollenbindungen zuzuweisen:

     gcloud projects add-iam-policy-binding PROJECT_ID \
     --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
     --role="roles/anthosservicemesh.serviceAgent"
    

Pod wird mit istiod.istio-system eingefügt

Dies kann auftreten, wenn Sie das Label istio-injection: enabled nicht ersetzt haben.

Überprüfen Sie außerdem die mutierende Webhook-Konfiguration mit folgendem Befehl:

kubectl get mutatingwebhookconfiguration

...
istiod-asm-managed
…
# may include istio-sidecar-injector

kubectl get mutatingwebhookconfiguration   istio-sidecar-injector -o yaml

# Run debug commands
export T=$(echo '{"kind":"TokenRequest","apiVersion":"authentication.k8s.io/v1","spec":{"audiences":["istio-ca"], "expirationSeconds":2592000}}' | kubectl create --raw /api/v1/namespaces/default/serviceaccounts/default/token -f - | jq -j '.status.token')

export INJECT_URL=$(kubectl get mutatingwebhookconfiguration istiod-asmca -o json | jq -r .webhooks[0].clientConfig.url)
export ISTIOD_ADDR=$(echo $INJECT_URL | 'sed s/\/inject.*//')

curl -v -H"Authorization: Bearer $T" $ISTIOD_ADDR/debug/configz

Das Installationstool generiert HTTP-400-Fehler

Das Installationstool generiert möglicherweise HTTP-400-Fehler wie diese:

HealthCheckContainerError, message: Cloud Run error: Container failed to start.
Failed to start and then listen on the port defined by the PORT environment
variable. Logs for this revision might contain more information.

Dieser Fehler kann auftreten, wenn Sie Workload Identity nicht in Ihrem Kubernetes-Cluster aktiviert haben. Zum Aktivieren können Sie den folgenden Befehl verwenden:

export CLUSTER_NAME=...
export PROJECT_ID=...
export LOCATION=...
gcloud container clusters update $CLUSTER_NAME --zone $LOCATION \
    --workload-pool=$PROJECT_ID.svc.id.goog

Status der verwalteten Datenebene

Der folgende Befehl zeigt den Status der verwalteten Datenebene an:

gcloud container fleet mesh describe --project PROJECT_ID

In der folgenden Tabelle sind alle möglichen Status der verwalteten Datenebene aufgeführt:

Status Code Beschreibung
ACTIVE OK Die verwaltete Datenebene wird normal ausgeführt.
DISABLED DISABLED Die verwaltete Datenebene hat diesen Status, wenn kein Namespace oder keine Überarbeitung für deren Verwendung konfiguriert ist. Folgen Sie der Anleitung unter Verwaltetes Anthos Service Mesh über die Fleet API aktivieren, oder Verwaltete Datenebene nach der Bereitstellung des verwalteten Anthos Service Mesh mitasmcli aktivieren. Beachten Sie, dass die Statusberichte zu verwalteten Datenebenen nur verfügbar sind, wenn Sie die verwaltete Datenebene durch Annotierung eines Namespace oder einer Überarbeitung aktiviert haben. Das Annotieren einzelner Pods führt dazu, dass diese Pods verwaltet werden, aber mit dem Featurestatus DISABLED, wenn keine Namespaces oder Überarbeitungen annotiert sind.
FAILED_PRECONDITION MANAGED_CONTROL_PLANE_REQUIRED Die verwaltete Datenebene erfordert eine aktive verwaltete Steuerungsebene von Anthos Service Mesh.
PROVISIONING PROVISIONING Die verwaltete Datenebene wird bereitgestellt. Wenn der Status länger als zehn Minuten andauert, ist wahrscheinlich ein Fehler aufgetreten und Sie sollten den Support kontaktieren.
STALLED INTERNAL_ERROR Die verwaltete Datenebene ist aufgrund eines internen Fehlerzustands für den Betrieb blockiert. Sollte das Problem weiterhin auftreten, wenden Sie sich bitte an den Support.
NEEDS_ATTENTION UPGRADE_FAILURES Die verwaltete Datenebene erfordert manuelle Eingriffe, um den Dienst wieder in den normalen Status zu versetzen. Weitere Informationen und Hinweise zur Behebung dieses Problems finden Sie unter dem NEEDS_ATTENTION-Status.

NEEDS_ATTENTION-Status

Wenn der Befehl gcloud container fleet mesh describe anzeigt, dass der Status der verwalteten Datenebene den Status NEEDS_ATTENTION und der Code UPGRADE_FAILURES hat, konnte die verwaltete Datenebene bestimmte Arbeitslasten nicht aktualisieren. finden Sie weitere Informationen. Diese Arbeitslasten werden vom weiteren Dienst der verwalteten Datenebene zur weiteren Analyse mit dataplane-upgrade: failed gekennzeichnet. Die Proxys müssen manuell neu gestartet werden, um ein Upgrade durchzuführen. Führen Sie den folgenden Befehl aus, um die Liste der Pods abzurufen, die Ihre Aufmerksamkeit erfordern:

kubectl get pods --all-namespaces -l dataplane-upgrade=failed

Fehler bei der Clustermitgliedschaft (kein Identitätsanbieter angegeben)

Das Installationstool kann mit folgenden Fehlern bei der Clustermitgliedschaft fehlschlagen:

asmcli: [ERROR]: Cluster has memberships.hub.gke.io CRD but no identity
provider specified. Please ensure that an identity provider is available for the
registered cluster.

Der Fehler kann auftreten, wenn Sie vor der Registrierung des Clusters GKE-Workload Identity nicht aktiviert haben. Sie können den Cluster mit dem Befehl gcloud container fleet memberships register --enable-workload-identity noch einmal über die Befehlszeile registrieren.

Status der verwalteten Steuerungsebene prüfen

Führen Sie gcloud container fleet mesh describe --project FLEET_PROJECT_ID aus, um den Status der verwalteten Steuerungsebene zu prüfen.

In der Antwort kann das Feld membershipStates[].servicemesh.controlPlaneManagement.details den spezifischen Fehler erklären.

Wenn Sie weitere Details benötigen, prüfen Sie die benutzerdefinierte Ressource ControlPlaneRevision im Cluster, die aktualisiert wird, wenn die verwaltete Steuerungsebene bereitgestellt wird oder die Bereitstellung fehlschlägt.

Zum Prüfen des Status der Ressource ersetzen Sie NAME durch den Wert für den jeweiligen Kanal: asm-managed, asm-managed-stable oder asm-managed-rapid.

kubectl describe controlplanerevision NAME -n istio-system

Die Ausgabe sieht etwa so aus:

    Name:         asm-managed

    …

    Status:
      Conditions:
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               The provisioning process has completed successfully
        Reason:                Provisioned
        Status:                True
        Type:                  Reconciled
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               Provisioning has finished
        Reason:                ProvisioningFinished
        Status:                True
        Type:                  ProvisioningFinished
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               Provisioning has not stalled
        Reason:                NotStalled
        Status:                False
        Type:                  Stalled

Die Bedingung Reconciled bestimmt, ob die verwaltete Steuerungsebene ordnungsgemäß ausgeführt wird. Bei true wird die Steuerungsebene erfolgreich ausgeführt. Stalled gibt an, ob beim Bereitstellungsprozess der verwalteten Steuerungsebene ein Fehler aufgetreten ist. Bei Stalled enthält das Feld Message weitere Informationen zu dem jeweiligen Fehler. Weitere Informationen zu möglichen Fehlern finden Sie unter Verzögerte Codes.

Stalled-Codes von ControlPlaneRevision

Es gibt mehrere Gründe, warum die Bedingung Stalled im Status ControlPlaneRevisions erfüllt sein kann.

Grund Meldung Beschreibung
PreconditionFailed Es werden nur GKE-Mitgliedschaften unterstützt, wobei ${CLUSTER_NAME} kein GKE-Cluster ist. Der aktuelle Cluster scheint kein GKE-Cluster zu sein. Eine verwaltete Steuerungsebene funktioniert nur in GKE-Clustern.
Nicht unterstützter ControlPlaneRevision-Name: ${NAME}. Der Name von ControlPlaneRevision muss einer der folgenden sein:
  • asm-managed
  • asm-managed-rapid
  • asm-managed-stable
Nicht unterstützter ControlPlaneRevision-Namespace: ${NAMESPACE}. Der Namespace von ControlPlaneRevision muss istio-system sein.
Nicht unterstützter Kanal ${CHANNEL} für ControlPlaneRevision mit dem Namen ${NAME}. Erwartet wird ${OTHER_CHANNEL}. Der Name von ControlPlaneRevision muss mit dem Kanal von ControlPlaneRevision übereinstimmen:
  • asm-managed -> Regulär
  • asm-managed-rapid -> Schnell
  • asm-managed-stable -> Stabil
Der Kanal darf nicht weggelassen werden oder leer sein. Channel ist ein Pflichtfeld für ControlPlaneRevision. Es fehlt in der benutzerdefinierten Ressource oder ist leer.
Nicht unterstützter Überarbeitungstyp der Steuerungsebene: ${TYPE}. managed_service ist das einzige zulässige Feld für das Feld ControlPlaneRevisionType.
Nicht unterstützte Kubernetes-Version: ${VERSION}. Kubernetes-Versionen ab 1.15 werden unterstützt.
Workload Identity ist nicht aktiviert. Aktivieren Sie Workload Identity in Ihrem Cluster.
Nicht unterstützter Arbeitslastpool: ${POOL}. Der Arbeitslastpool muss das Format ${PROJECT_ID}.svc.id.goog haben.
Clusterprojekt und Environ-Projekt stimmen nicht überein. Cluster müssen zu dem Projekt gehören, in dem sie für den Gerätepool registriert sind.
ProvisioningFailed Beim Aktualisieren von Clusterressourcen ist ein Fehler aufgetreten. Google konnte Ihre clusterinternen Ressourcen wie CRDs und Webhooks nicht aktualisieren.
„istioistiod-asm-managed“ von MutatingWebhookConfiguration enthält einen Webhook mit der URL ${EXISTING_URL}. Es wird aber ${EXPECTED_URL} erwartet. Google überschreibt keine vorhandenen Webhooks, damit die Installation nicht geändert wird. Aktualisieren Sie diesen manuell, wenn es erforderlich ist.
ValidatingWebhookConfiguration ${NAME} enthält einen Webhook mit der URL ${EXISTING_URL}. Es wird aber ${EXPECTED_URL} erwartet. Google überschreibt keine vorhandenen Webhooks, damit die Installation nicht geändert wird. Aktualisieren Sie diesen manuell, wenn es erforderlich ist.

Verwaltetes Anthos Service Mesh kann keine Verbindung zum GKE-Cluster herstellen

Zwischen Juni 2022 und September 2022 hat Google Sicherheitsarbeiten in Bezug auf autorisierte Netzwerke, Cloud Run und Cloud Functions in der Google Kubernetes Engine (GKE) durchgeführt. Projekte, die zuvor verwaltetes Anthos Service Mesh verwendet, aber vor der Migration nicht mehr genutzt haben, verfügen nicht über die für die Kommunikation zwischen Cloud Run und GKE erforderliche API.

In diesem Szenario schlägt die verwaltete Anthos Service Mesh-Bereitstellung fehl und Cloud Logging zeigt die folgende Fehlermeldung an:

Connect Gateway API has not been used in project [*PROJECT_NUMBER*] before or it is disabled.
Enable it by visiting https://console.developers.google.com/apis/api/connectgateway.googleapis.com/overview?project=[*PROJECT_NUMBER*] then retry.
If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.

Filtern Sie diese Nachricht mit der folgenden Abfrage:

resource.type="istio_control_plane"
resource.labels.project_id=[*PROJECT_ID*]
resource.labels.location=[*REGION*]
severity=ERROR
jsonPayload.message=~"Connect Gateway API has not been used in project"

In der Zwischenzeit schlägt auch das Einfügen der Sidecar-Datei und das Bereitstellen benutzerdefinierter Kubernetes-Ressourcen im Zusammenhang mit Anthos Service Mesh fehl. Cloud Logging zeigt dann die folgende Warnmeldung an:

Error creating: Internal error occurred: failed calling webhook
"rev.namespace.sidecar-injector.istio.io": failed to call webhook: an error on
the server ("unknown") has prevented the request from succeeding.

Filtern Sie diese Nachricht mit der folgenden Abfrage:

resource.type="k8s_cluster"
resource.labels.project_id=[*PROJECT_ID*]
resource.labels.location=[*REGION*]
resource.labels.cluster_name=[*CLUSTER_NAME*]
severity=WARNING
jsonPayload.message=~"Internal error occurred: failed calling webhook"

So beheben Sie das Problem:

  1. Aktivieren Sie die erforderliche connectgateway API:

     gcloud services enable connectgateway.googleapis.com --project=[*PROJECT_ID*]
    
  2. Installieren Sie das verwaltete Anthos Service Mesh neu.

  3. Führen Sie einen rollierenden Neustart für die Arbeitslasten durch.