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