Version 1.20

Versions disponibles

1.20 (dernière version)
1.19
1.18
1.17
1.16
1.15
1.14
1.13
1.12

Résoudre les problèmes d'assistance des VM dans Anthos Service Mesh

Les étapes et journaux suivants sont utiles pour résoudre les problèmes liés à la compatibilité des VM Anthos Service Mesh.

Déboguer la VM

Si vous constatez que des instances de VM sont en cours d'exécution, mais ne sont pas accessibles depuis le maillage, procédez comme suit sur l'instance de VM.

Vérifier l'agent

Vérifiez l'état du proxy Envoy:
```
curl localhost:15000/ready -v
```
Consulter le journal d'erreurs d'envoy
```
less /var/log/envoy/envoy.err.log
```
Vérifiez si des erreurs service-proxy-agent se produisent :
```
journalctl -u service-proxy-agent
```
Vérifiez l'instance syslog dans les journaux de la suite Google Cloud Operations pour l'instance ou sur la VM située sous /var/log/syslog pour Debian, et /var/log/messages pour Centos.

Vérifier l'état du proxy

Pour déboguer la configuration du proxy, exécutez la commande suivante sur la VM:
```
curl localhost:15000/config_dump > config.out
```

Copiez ce fichier et exécutez la commande suivante:

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

Erreurs de jeton non valides

Une erreur semblable à la suivante peut s'afficher dans le journal des erreurs d'envoy:

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

Dans ce cas, vérifiez si le jeton dans /var/run/secrets/tokens/istio-token sur la VM est arrivé à expiration et vérifiez que la valeur exp (secondes epoch) n'a pas expiré:

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

Informations sur l'avertissement de distribution de l'OS non compatible

Dans Vérifier l'agent, si le journal de service-proxy-agent affiche un message d'avertissement semblable à celui-ci :

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.

Cela signifie que votre distribution Linux peut ne pas être compatible, ce qui peut entraîner un comportement inattendu du proxy.

Déboguer le cluster

Procédez comme suit pour résoudre les problèmes de votre cluster.

Vérifier le bon fonctionnement de l'enregistrement automatique

Vérifiez l'élément WorkloadEntry que istiod génère automatiquement:
```
kubectl get workloadentry -n WORKLOAD_NAMESPACE
```
En outre, vous pouvez vérifier l'existence du navigateur d'objets Kubernetes.

Si ce n'est pas le cas, recherchez les erreurs dans les journaux istiod, qui devraient être disponibles dans la suite d'opérations de Google Cloud. Vous pouvez également les récupérer directement:

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

Le résultat attendu est semblable à ceci :

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

Définissez la variable d'environnement de pod et utilisez-la pour exporter les journaux:

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

Vérifier les proxys connectés

Vous pouvez utiliser la commande proxy-status pour répertorier tous les proxys connectés, y compris ceux des VM:

istioctl proxy-status

Le résultat doit afficher des proxys connectés semblables à:

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

Pour en savoir plus sur les options de la commande, consultez la page istioctl proxy-config.

Vérifier la configuration de l'identité de charge de travail

Vérifiez l'état mesh pour détecter les erreurs potentielles dans votre cluster. Notez que vous devez disposer de la dernière version de gcloud. Pour en savoir plus, consultez les informations de mise à jour vers la dernière version.

gcloud alpha container hub mesh describe --project=PROJECT_ID

Une configuration valide présente le code d'état OK pour le cluster membre:

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'

Si la VM n'est pas configurée correctement, le code d'état sera WARNING avec des détails supplémentaires dans la description :

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

Vérifier que le fournisseur d'identité est correctement configuré

Consultez les champs de la ressource IdentityProvider :

 kubectl describe identityprovider

Assurez-vous que les champs répondent aux exigences suivantes :

Le champ serviceAccount est défini sur request.auth.claims["email"].
Le champ issuerURI est défini sur https://accounts.google.com (nous n'acceptons actuellement que google en tant que issuerURI).

Le champ name du fournisseur sous les métadonnées doit être défini sur google, qui est le seul fournisseur actuellement accepté.

Exemple de ressource personnalisée IdentityProvider valide :

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

Vérifier que `WorkloadGroup` est correctement configuré

Accédez au WorkloadGroup :

 kubectl get workloadgroup -n WORKLOAD_NAMESPACE

Assurez-vous que les résultats répondent aux exigences suivantes :

Le champ serviceAccount est correctement défini, par exemple 373206437219-compute@developer.gserviceaccount.com, où le compte est identique au compte de service utilisé par l'instance de VM.
Le champ security.cloud.google.com/IdentityProvider situé sous le champ d'annotation est défini (par exemple, security.cloud.google.com/IdentityProvider: google).
Le groupe de charges de travail fait référence à un fournisseur IdentityProvider valide, que vous pouvez vérifier en consultant le fournisseur d'identité existant :
```
kubectl describe identityprovider
```
Le résultat doit correspondre à une liste de fournisseurs existants, comme suit :
```
 NAME     AGE
 google   39m
```
Vérifiez dans le champ security.cloud.google.com/IdentityProvider de WorkloadGroup si le fournisseur figure dans la liste des fournisseurs existants.

Exemple de ressource personnalisée WorkloadGroup valide :
```
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
```

Erreur interne trouvée

Si vous recevez le message Internal Error Found, consultez la page Assistance.

Guide de dépannage de la VM Istio

Pour accéder à la procédure de dépannage supplémentaire, consultez la page Déboguer des machines virtuelles.