Anthos Service Mesh 1.11 ha raggiunto la fine del ciclo di vita e non è più supportato. Vedi Upgrade da versioni precedenti.

Visualizza la documentazione più recente o seleziona un'altra versione disponibile:

Versioni disponibili

Risoluzione dei problemi di supporto delle VM in Anthos Service Mesh

I passaggi e i log seguenti sono utili per risolvere i problemi relativi al supporto delle VM mesh di servizi Anthos.

Esegui il debug della VM

Se noti che le istanze VM sono in esecuzione ma non raggiungibili dal mesh, esegui i passaggi seguenti sull'istanza VM.

Verifica l'agente

Controlla l'integrità del proxy di Envoy:
```
curl localhost:15000/ready -v
```
Controlla il log degli errori di Envoy
```
less /var/log/envoy/envoy.err.log
```
Controlla se sono presenti service-proxy-agent errori:
```
journalctl -u service-proxy-agent
```
Controlla syslog nei log di osservabilità di Google Cloud per l'istanza o sulla VM in /var/log/syslog per Debian e /var/log/messages per Centos.

Verifica l'integrità del proxy

Per eseguire il debug della configurazione del proxy, esegui questo comando sulla VM:
```
curl localhost:15000/config_dump > config.out
```

Copia il file ed esegui questo comando:

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

Errori relativi ai token non validi

Nel log degli errori di Envoy potrebbe essere visualizzato un errore simile al seguente:

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": ""
}].

In questo caso, controlla se il token in /var/run/secrets/tokens/istio-token sulla VM è scaduto e verifica che il valore exp (secondi epoch) non sia scaduto:

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": "..."
}

Informazioni di avviso relative alla distribuzione del sistema operativo non supportate

Nella sezione Verifica l'agente, se nel log service-proxy-agent viene visualizzato un messaggio di avviso simile al seguente:

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.

Ciò significa che la distribuzione Linux potrebbe non essere supportata e questo potrebbe causare un comportamento imprevisto del proxy.

Esegui il debug del cluster

Segui questi passaggi per risolvere i problemi del cluster.

Verificare il funzionamento della registrazione automatica

Controlla il WorkloadEntry che istiod genera automaticamente:
```
kubectl get workloadentry -n WORKLOAD_NAMESPACE
```
Inoltre, puoi verificare l'esistenza del browser degli oggetti Kubernetes.

Se non esiste, verifica la presenza di errori nei log istiod, che dovrebbero essere disponibili in Google Cloud Observability. In alternativa, puoi recuperarle direttamente:

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

L'output previsto è simile al seguente:

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

Imposta la variabile di ambiente del pod e utilizzala per esportare i log:

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

Controlla i proxy connessi

Puoi utilizzare il comando proxy-status per elencare tutti i proxy connessi, inclusi quelli per le VM:

istioctl proxy-status

L'output dovrebbe mostrare proxy connessi simili a questo:

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

Per ulteriori informazioni sulle opzioni del comando, consulta istioctl proxy-config.

Controlla la configurazione di Workload Identity

Controlla lo stato mesh per verificare la presenza di potenziali errori nel cluster. Tieni presente che è necessaria l'ultima versione di gcloud. Per ulteriori informazioni, consulta la pagina relativa all'aggiornamento alla versione più recente.

gcloud alpha container hub mesh describe --project=PROJECT_ID

Una configurazione valida avrà il codice di stato OK per il cluster membro:

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'

Se la VM non è configurata correttamente, il codice di stato sarà WARNING, con ulteriori dettagli nella descrizione:

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.11/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'

Verifica che il provider di identità sia configurato correttamente

Controlla i IdentityProvider campi delle risorse:

 kubectl describe identityprovider

Assicurati che i campi soddisfino i seguenti requisiti:

Il campo serviceAccount è impostato su request.auth.claims["email"]
Il campo issuerURI è impostato su https://accounts.google.com (al momento supportiamo solo google come emittenteURI)

Il campo name del provider nei metadati deve essere impostato su google, che è l'unico fornitore attualmente supportato.

Esempio di RP IdentityProvider valido:

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

Verifica che `WorkloadGroup` sia configurato correttamente

Controlla WorkloadGroup:

 kubectl get workloadgroup -n WORKLOAD_NAMESPACE

Assicurati che i risultati soddisfino i seguenti requisiti:

Il campo serviceAccount è impostato correttamente, ad esempio 373206437219-compute@developer.gserviceaccount.com, dove l'account è uguale all'account di servizio utilizzato dall'istanza VM
È impostato il valore security.cloud.google.com/IdentityProvider sotto il campo dell'annotazione, ad es. security.cloud.google.com/IdentityProvider: google

Il gruppo di carichi di lavoro fa riferimento a un IdentityProvider valido, che puoi verificare controllando il provider di identità esistente:

kubectl describe identityprovider

L'output dovrebbe essere un elenco di provider esistenti come questo:

 NAME     AGE
 google   39m

Controlla il campo security.cloud.google.com/IdentityProvider in WorkloadGroup se il provider esiste nell'elenco dei provider esistenti.

Esempio di RP WorkloadGroup valido:

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

Errore interno rilevato

Se ricevi il messaggio Internal Error Found, vedi Ricevere assistenza.

Guida alla risoluzione dei problemi delle VM Istio

Per ulteriori passaggi di risoluzione dei problemi, consulta Debug delle macchine virtuali.