Anthos Service Mesh 1.10 ist abgelaufen und wird nicht mehr unterstützt. Siehe Upgraden von früheren Versionen.

Lesen Sie die aktuelle Dokumentation oder wählen Sie eine andere verfügbare Version aus:

Verfügbare Versionen

1.20 (neueste Version)
1.19
1.18
1.17
1.16
1.15
1.14
1.13
1.12
1.11
1.10
1.9
1.8
1.7
1.6
1.5
1.4

Probleme mit der VM-Unterstützung in Anthos Service Mesh beheben

Die folgenden Schritte und Logs sind hilfreich, um Probleme mit der VM-Unterstützung in Anthos Service Mesh zu beheben.

VM debuggen

Wenn Sie feststellen, dass VM-Instanzen ausgeführt werden, aber nicht vom Mesh-Netzwerk aus erreichbar sind, führen Sie auf der VM-Instanz die folgenden Schritte aus.

Agent prüfen

Prüfen Sie den Status des Envoy-Proxys:
```
curl localhost:15000/ready -v
```
Envoy-Fehlerlog prüfen
```
less /var/log/envoy/envoy.err.log
```
Prüfen Sie, ob service-proxy-agent-Fehler vorliegen:
```
journalctl -u service-proxy-agent
```
Prüfen Sie die syslog entweder in den Google Cloud-Beobachtbarkeitslogs für die Instanz oder auf der VM unter /var/log/syslog für Debian und /var/log/messages für Centos.

Proxystatus prüfen

Führen Sie den folgenden Befehl auf der VM aus, um die Konfiguration des Proxys zu debuggen:
```
curl localhost:15000/config_dump > config.out
```

Kopieren Sie jene Datei und führen Sie den folgenden Befehl aus:

istioctl proxy-config [cluster|route|listener] --file config.out

Ungültiges Token – Fehler

Möglicherweise sehen Sie im Envoy-Fehlerlog einen Fehler wie diesen:

E0217 17:59:17.206995798    2411 oauth2_credentials.cc:152]  Call to http server ended with error 500 [{
  "error": "invalid_target",
  "error_description": "federated token response does not have access token. {\"error\":\"invalid_grant\",\"error_description\":\"JWT expired.\"}",
  "error_uri": ""
}].

Prüfen Sie in diesem Fall, ob das Token in /var/run/secrets/tokens/istio-token auf der VM abgelaufen ist und vergewissern Sie sich, dass der Wert für exp (Epochensekunden) nicht abgelaufen ist:

cat /var/run/secrets/tokens/istio-token | cut -d '.' -f2 | base64 -d | python -m json.tool
{
    ...
    "azp": "...",
    "email": "example-service-account@developer.gserviceaccount.com",
    "email_verified": true,
    "exp": 1613995395,
    "google": {
        "compute_engine": {
            "instance_creation_timestamp": 1613775765,
            "instance_id": "5678",
            "instance_name": "vm-instance-03-0mqh",
            "project_id": "...",
            "project_number": 1234,
            "zone": "us-central1-c"
        }
    },
    "iat": ...,
    "iss": "https://accounts.google.com",
    "sub": "..."
}

Warnungs-Information zu nicht unterstützter Betriebssystem-Distribution

Überprüfen Sie den Agent, wenn im Dienstkonto „service-proxy-agent“ eine Warnmeldung wie die folgende angezeigt wird:

E0217 17:59:17.206995798    2021-04-09T21:21:29.6091Z service-proxy-agent Warn
Detected image is unsupported: [Ubuntu|Fedora|Suse]. Envoy may not work correctly.

Das bedeutet, dass Ihre Linux-Distribution möglicherweise nicht unterstützt wird, was zu einem unerwarteten Verhalten Ihres Proxys führen kann.

Clusterfehler beheben

Führen Sie die folgenden Schritte aus, um Probleme mit Ihrem Cluster zu beheben.

Prüfen, ob die automatische Registrierung funktioniert

Prüfen Sie den WorkloadEntry, den istiod automatisch generiert:
```
kubectl get workloadentry -n WORKLOAD_NAMESPACE
```
Darüber hinaus können Sie prüfen, ob der Kubernetes-Objektbrowser vorhanden ist.

Wenn sie nicht vorhanden ist, suchen Sie in den istiod-Logs nach Fehlern, die Ihnen in Google Cloud-Beobachtbarkeit zur Verfügung stehen sollten. Alternativ können Sie sie auch direkt abrufen:

kubectl -n istio-system get pods -l app=istiod

Die erwartete Ausgabe sieht in etwa so aus:

NAME                                       READY   STATUS    RESTARTS   AGE
istiod-asm-190-1-7f6699cfb-5mzxw           1/1     Running   0          5d13h
istiod-asm-190-1-7f6699cfb-pgvpf           1/1     Running   0          5d13h

Legen Sie die Pod-Umgebungsvariable fest und verwenden Sie sie, um die Logs zu exportieren:

export ISTIO_POD=istiod-asm-190-1-7f6699cfb-5mzxw
kubectl logs -n istio-system ${ISTIO_POD} | grep -i 'auto-register\|WorkloadEntry'

Verbundene Proxys prüfen

Mit dem Befehl proxy-status können Sie alle verbundenen Proxys auflisten, einschließlich derjenigen für VMs:

istioctl proxy-status

Die Ausgabe sollte verbundene Proxys anzeigen, die etwa so aussehen:

NAME                                                    CDS        LDS        EDS        RDS          ISTIOD                               VERSION
details-v1-5f449bdbb9-bhl8d.default                     SYNCED     SYNCED     SYNCED     SYNCED       istiod-asm-190-1-7f6699cfb-5mzxw     1.9.0-asm.1
httpbin-779c54bf49-647vd.default                        SYNCED     SYNCED     SYNCED     SYNCED       istiod-asm-190-1-7f6699cfb-pgvpf     1.9.0-asm.1
istio-eastwestgateway-5b6d4ddd9d-5rzx2.istio-system     SYNCED     SYNCED     SYNCED     NOT SENT     istiod-asm-190-1-7f6699cfb-pgvpf     1.9.0-asm.1
istio-ingressgateway-66b6ddd7cb-ctb6b.istio-system      SYNCED     SYNCED     SYNCED     SYNCED       istiod-asm-190-1-7f6699cfb-pgvpf     1.9.0-asm.1
istio-ingressgateway-66b6ddd7cb-vk4bb.istio-system      SYNCED     SYNCED     SYNCED     SYNCED       istiod-asm-190-1-7f6699cfb-5mzxw     1.9.0-asm.1
vm-instance-03-39b3.496270428946                        SYNCED     SYNCED     SYNCED     SYNCED       istiod-asm-190-1-7f6699cfb-pgvpf     1.9.0
vm-instance-03-nh5k.496270428946                        SYNCED     SYNCED     SYNCED     SYNCED       istiod-asm-190-1-7f6699cfb-pgvpf     1.9.0
vm-instance-03-s4nl.496270428946                        SYNCED     SYNCED     SYNCED     SYNCED       istiod-asm-190-1-7f6699cfb-5mzxw     1.9.0

Weitere Informationen zu den Befehlsoptionen finden Sie unter istioctl proxy-config.

Workload Identity-Konfiguration prüfen

Prüfen Sie den Status mesh auf potenzielle Fehler in Ihrem Cluster. Beachten Sie, dass die neueste gcloud-Version erforderlich ist. Weitere Informationen finden Sie unter Update auf die neueste Version ausführen.

gcloud alpha container hub mesh describe --project=PROJECT_ID

Eine gültige Konfiguration hat den Statuscode OK für den Mitgliedscluster:

createTime: '2021-06-15T21:56:10.221032150Z'
featureState:
  detailsByMembership:
    projects/<your project number>/locations/global/memberships/<your cluster name>:
      code: OK
      description: Revision(s) ready for use: istiod-asm-195-2.
      updateTime: 2021-06-15T21:56:10.221032402Z
  lifecycleState: ENABLED
name: projects/<your project name>/locations/global/features/servicemesh
servicemeshFeatureSpec: {}
updateTime: '2021-06-15T21:56:10.221032402Z'

Wenn die VM falsch konfiguriert ist, lautet der Statuscode WARNING mit zusätzlichen Details in der Beschreibung:

createTime: '2021-06-15T22:56:10.227167202Z'
featureState:
  detailsByMembership:
    projects/<your project number>/locations/global/memberships/<your cluster name>:
      code: WARNING
      description: |-
        Revision(s) ready for use: istiod-asm-195-2.
        WorkloadGroup <namespace>/<workloadgroup name> missing ServiceAccount field, please see https://cloud.google.com/service-mesh/v1.10/docs/troubleshooting/troubleshoot-vms#verify_the_workloadgroup_is_set_up_correctly.
      servicemeshFeatureState: {}
      updateTime: '2021-06-15T22:56:00.220164192Z'
  lifecycleState: ENABLED
name: projects/<your project name>/locations/global/features/servicemesh
servicemeshFeatureSpec: {}
updateTime: '2021-06-15T22:56:10.227167402Z'

Prüfen, ob der Identitätsanbieter richtig eingerichtet ist

Prüfen Sie die IdentityProvider-Ressourcenfelder:

 kubectl describe identityprovider

Achten Sie darauf, dass die Felder diese Anforderungen erfüllen:

Das Feld serviceAccount ist auf request.auth.claims["email"] gesetzt.
Das Feld issuerURI ist auf https://accounts.google.com gesetzt (derzeit unterstützen wir nur Google als Aussteller-URI).

Das Feld "Anbieter-name" unter "Metadaten" muss auf google gesetzt sein. Dies ist das einzige aktuell unterstützte Anbieter.

Ein gültiges Beispiel für IdentityProvider-Antwortvorlage:

apiVersion: security.cloud.google.com/v1alpha1
kind: IdentityProvider
metadata:
  name: google
spec:
  authentication:
    oidc:
      issuerUri: https://accounts.google.com
  serviceAccount: request.auth.claims["email"]

Prüfen Sie, ob `WorkloadGroup` korrekt eingerichtet ist.

Überprüfen Sie WorkloadGroup:

 kubectl get workloadgroup -n WORKLOAD_NAMESPACE

Achten Sie darauf, dass die Ergebnisse diesen Anforderungen entsprechen:

Das Feld serviceAccount ist korrekt festgelegt, z. B. 373206437219-compute@developer.gserviceaccount.com, wobei das Konto mit dem Dienstkonto übereinstimmt, das von der VM-Instanz verwendet wird.
Die security.cloud.google.com/IdentityProvider im Annotationsfeld ist festgelegt. z. B. security.cloud.google.com/IdentityProvider: google
Die Arbeitslastgruppe verweist auf einen gültigen IdentityProvider, den Sie durch Prüfen des vorhandenen Identitätsanbieters prüfen können:
```
kubectl describe identityprovider
```
Daraufhin sollte eine Liste vorhandener Anbieter wie die folgende ausgegeben werden:
```
 NAME     AGE
 google   39m
```
Überprüfen Sie im Feld security.cloud.google.com/IdentityProvider im WorkloadGroup, ob der Anbieter in der Liste der vorhandenen Anbieter vorhanden ist

Ein gültiges Beispiel für WorkloadGroup-Antwortvorlage:
```
apiVersion: networking.istio.io/v1alpha3
kind: WorkloadGroup
metadata:
name: wg-a
namespace: foo
spec:
metadata:
  annotations:
    security.cloud.google.com/IdentityProvider: google
  labels:
    app: wg-a
template:
  ports:
    grpc: 3550
    http: 8080
  serviceAccount: 373206437219-compute@developer.gserviceaccount.com
```

Interner Fehler gefunden

Wenn Sie die Nachricht Internal Error Found erhalten, finden Sie weitere Informationen unter Support erhalten.

Leitfaden zur Fehlerbehebung für Istio-VMs

Weitere Schritte zur Fehlerbehebung finden Sie unter Virtuelle Maschinen debuggen.