Résoudre les problèmes liés à Anthos Service Mesh géré

Ce document explique les problèmes couramment rencontrés dans Anthos Service Mesh et indique comment les résoudre ; par exemple, lorsqu'un pod est injecté avec istio.istio-system, l'outil d'installation génère des erreurs telles que des codes d'état HTTP 400 et les erreurs d'appartenance au cluster.

Si vous avez besoin d'aide supplémentaire pour résoudre des problèmes liés à Anthos Service Mesh, consultez la page Obtenir de l'aide.

Le pod est injecté avec istiod.istio-system

Cela peut se produire si vous n'avez pas remplacé le libellé istio-injection: enabled.

Vous pouvez également vérifier la configuration des webhooks en mutation à l'aide de la commande suivante :

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

Le script d'installation génère des erreurs HTTP 400.

L'outil d'installation peut générer des erreurs HTTP 400 comme suit :

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.

Cela peut se produire si vous n'avez pas activé Workload Identity sur votre cluster Kubernetes, ce que vous pouvez effectuer à l'aide de la commande suivante :

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

État du plan de données géré

La commande suivante affiche l'état du plan de données géré :

kubectl -n istio-system get dataplanecontrol -o custom-columns=REVISION:.spec.revision,STATE:status.state

Les éléments suivants devraient s'afficher environ dix minutes après le déploiement du plan de données géré :

REVISION            STATE
Regular             Ready

État vide

Si vous ne voyez aucun résultat, à l'exception des en-têtes de colonne REVISION et STATE, cela signifie que le contrôleur de plan de données n'a pas été déployé sur le cluster. Pour résoudre ce problème, exécutez la commande suivante pour vérifier si le cluster est enregistré dans le parc :

gcloud container hub memberships list --project=PROJECT_ID

  • Si le résultat de la commande gcloud est vide ou le nom de votre cluster n'apparaît pas dans la sortie, cela signifie que le cluster n'est pas enregistré dans le parc. Pour résoudre ce problème, réexécutez l'outil d'installation et assurez-vous d'inclure --enable-registration sur la ligne de commande. (Notez que vous devez également inclure --option cni-managed lors de l'exécution ultérieure de l'outil.)

  • Si le résultat comprend le nom de votre cluster, exécutez la commande suivante pour activer Anthos Service Mesh dans le parc :

    gcloud alpha container hub mesh enable --project=PROJECT_ID

État <nil>

Cela indique un problème avec le DaemonSet CNI. Exécutez la commande suivante pour vérifier si le DaemonSet CNI est opérationnel et en cours d'exécution :

kubectl get pods -n kube-system -l k8s-app=istio-cni-node

Si le DaemonSet CNI est opérationnel et en cours d'exécution, le résultat ressemble à ce qui suit :

NAME                   READY   STATUS    RESTARTS   AGE
istio-cni-node-8w88v   3/3     Running   0          12h
istio-cni-node-c69mn   3/3     Running   0          12h
istio-cni-node-n9pnr   3/3     Running   0          12h

  • Si le pod CNI ne figure pas dans la sortie, exécutez à nouveau l'outil d'installation et assurez-vous d'inclure --option cni-managed. (Vous devez également inclure --enable-registration pour vous assurer que le cluster est enregistré dans le parc lorsque vous exécutez à nouveau l'outil.)

  • Si le pod CNI n'est pas opérationnel, récupérez informations sur le pod. Dans la commande suivante, remplacez CNI_POD par le nom du pod non opérationnel :

    kubectl -n kube-system describe pod CNI_POD

    Contactez l'assistance Google Cloud en précisant les détails du pod non opérationnel.

Erreur d'appartenance au cluster (aucun fournisseur d'identité spécifié)

L'outil d'installation peut échouer avec des erreurs d'appartenance au cluster telles que les suivantes :

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.

L'erreur peut se produire si Workload Identity pour GKE n'est pas activé avant d'enregistrer le cluster. Vous pouvez réenregistrer le cluster depuis la ligne de commande en utilisant la commande suivante : gcloud container hub memberships register --enable-workload-identity