Cette page a été traduite par l'API Cloud Translation.

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.

Erreur de révision(s) signalée(s) comme étant non opérationnelle(s)

Une erreur Revision(s) reporting unhealthy générique peut s'afficher si Anthos Service Mesh géré ne dispose pas du compte de service géré par Google requis avec les liaisons de rôles IAM (Identity and Access Management) de l'agent de service Anthos Service Mesh. Cette erreur se produit généralement lorsque l'autorisation pour le rôle d'agent de service Anthos Service Mesh est révoquée via Terraform, Puppet ou une reconfiguration CI/CD.

Les étapes requises pour résoudre cette erreur varient selon que vous utilisez la console Google Cloud ou Google Cloud CLI.

Console Google Cloud

Dans la console Google Cloud, accédez à IAM et Admin > IAM.
Sélectionnez Inclure les attributions de rôles fournies par Google.
Examinez la liste Compte principal.

Si le compte de service géré s'affiche avec le rôle IAM requis dans la liste, il est correctement configuré.

Remarque : Le format du nom du compte de service géré est service-${PROJECT_NUMBER}@gcp-sa-servicemesh.iam.gserviceaccount.com, et le nom du rôle IAM requis pour Anthos Service Mesh est Anthos Service Mesh Service Agent(roles/anthosservicemesh.serviceAgent).

Si le compte de service géré requis n'apparait pas avec le rôle IAM requis dans la liste, alors la liaison de rôle IAM requise pour l'agent de service Anthos Service Mesh n'existe pas dans le compte de service géré.
Attribuez des liaisons de rôle IAM de l'agent de service Anthos Service Mesh (roles/anthosservicemesh.serviceAgent) au compte de service géré Anthos Service Mesh dans la console Google Cloud.

Remarque : Assurez-vous que vous n'avez pas d'outils automatisés qui annuleront cette modification. Si l'erreur se répète, mettez à jour les configurations ou les listes d'autorisation pertinentes.

Google Cloud CLI

Dans Google Cloud CLI, exécutez la commande suivante pour vérifier si le rôle IAM requis est configuré :

gcloud projects get-iam-policy PROJECT_ID  \
--flatten="bindings[].members" \
--filter="bindings.members:serviceAccount:service-PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com AND bindings.role:roles/anthosservicemesh.serviceAgent" \
--format='table(bindings.role)'

Examinez la liste ROLE.

Si des rôles apparaissent dans la liste, cela signifie qu'ils sont correctement configurés.

Si vous ne voyez aucun rôle dans la liste, cela signifie que tous les rôles du compte de service géré ont été révoqués.
Exécutez la commande suivante pour attribuer les liaisons de rôle IAM appropriées au compte de service géré Anthos Service Mesh :
```
 gcloud projects add-iam-policy-binding PROJECT_ID \
 --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
 --role="roles/anthosservicemesh.serviceAgent"
```
Remarque : Assurez-vous que vous n'avez pas d'outils automatisés qui annuleront cette modification. Si l'erreur se répète, mettez à jour les configurations ou les listes d'autorisation pertinentes.

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é :

gcloud container fleet mesh describe --project PROJECT_ID

Le tableau suivant répertorie tous les états de plan de données gérés possibles :

État	Coder	Description
`ACTIVE`	`OK`	Le plan de données géré s'exécute normalement.
`DISABLED`	`DISABLED`	Le plan de données géré aura cet état si aucun espace de noms ni révision n'est configuré pour l'utiliser. Suivez les instructions pour Activer Anthos Service Mesh géré via l'API Fleet, ou Activer le plan de données géré après avoir provisionné Anthos Service Mesh géré avec `asmcli`. Notez que les rapports sur l'état du plan de données géré ne sont disponibles que si vous avez activé le plan de données géré en annotant un espace de noms ou une révision. L'annotation de pods individuels entraîne leur gestion, mais avec l'état de fonctionnalité `DISABLED` si aucun espace de noms ou aucune révision n'est annoté.
`FAILED_PRECONDITION`	`MANAGED_CONTROL_PLANE_REQUIRED`	Le plan de données géré nécessite un plan de contrôle Anthos Service Mesh géré actif.
`PROVISIONING`	`PROVISIONING`	Le plan de données géré est en cours de provisionnement. Si cet état persiste pendant plus de 10 minutes, une erreur s'est probablement produite et vous devez contacter l'assistance.
`STALLED`	`INTERNAL_ERROR`	Le plan de données géré ne fonctionne pas en raison d'une condition d'erreur interne. Si ce problème persiste, contactez l'assistance.
`NEEDS_ATTENTION`	`UPGRADE_FAILURES`	Le plan de données géré nécessite une intervention manuelle pour rétablir le service normal. Pour plus d'informations et pour savoir comment résoudre ce problème, consultez la section état `NEEDS_ATTENTION`.

État `NEEDS_ATTENTION`

Si la commande gcloud container fleet mesh describe indique que l'état du plan de données géré est NEEDS_ATTENTION et que le code est UPGRADE_FAILURES, le plan de données géré n'a pas pu mettre à niveau certaines charges de travail. Ces charges de travail seront signalées avec dataplane-upgrade: failed par le service de plan de données géré pour une analyse plus approfondie. Les proxys doivent être redémarrés manuellement pour être mis à niveau. Pour obtenir la liste des pods nécessitant votre attention, exécutez la commande suivante :

kubectl get pods --all-namespaces -l dataplane-upgrade=failed

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 gcloud container fleet memberships register --enable-workload-identity.

Codes bloqués pour ControlPlaneRevision

Il existe plusieurs raisons pour lesquelles la condition Stalled peut devenir vraie à l'état ControlPlaneRevisions.

Motif	Message	Description
PreconditionFailed	Seuls les membres GKE sont acceptés, mais ${CLUSTER_NAME} n'est pas un cluster GKE.	Le cluster actuel ne semble pas être un cluster GKE. Le plan de contrôle géré ne fonctionne que sur les clusters GKE.
	Nom de champ ControlPlaneRevision non compatible : ${NAME}	Le nom de ControlPlaneRevision doit être l'un des suivants : asm-managed asm-managed-rapid asm-managed-stable
	Espace de noms ControlPlaneRevision non compatible : ${NAMESPACE}	L'espace de noms ControlPlaneRevision doit être `istio-system`.
	Le canal ${CHANNEL} n'est pas compatible avec le nom de ControlPlaneRevision ${NAME}. ${OTHER_CHANNEL} attendu	Le nom de ControlPlaneRevision doit correspondre au canal ControlPlaneRevision comme ci-dessous : asm-managed -> standard asm-managed-rapid -> rapide asm-managed-stable -> stable
	Le canal ne peut pas être omis ou vide	`Channel` est un champ obligatoire de ControlPlaneRevision. Ce champ est manquant ou vide sur la ressource personnalisée.
	Type de révision du plan de contrôle non compatible : ${TYPE}	`managed_service` est le seul champ autorisé pour le champ ControlPlaneRevisionType.
	Version de Kubernetes non compatible : ${VERSION}	Les versions 1.15 et ultérieures de Kubernetes sont compatibles.
	Workload Identity n'est pas activé	Veuillez activer Workload Identity sur votre cluster.
	Pool de charges de travail non compatible : ${POOL}	Le pool de charges de travail doit être au format `${PROJECT_ID}.svc.id.goog`.
	Le projet du cluster et le projet de l'environnement ne correspondent pas	Les clusters doivent faire partie du même projet que celui dans lequel ils sont enregistrés dans le parc.
ProvisioningFailed	Une erreur s'est produite lors de la mise à jour des ressources du cluster	Google n'a pas pu mettre à jour vos ressources intégrées au cluster, telles que les CRD et les webhooks.
	MutatingWebhookConfiguration "istiod-asm-managed" contient un webhook avec l'URL ${EXISTING_URL}, alors qu'il est attendu ${EXPECTED_URL}	Google n'écrase pas les webhooks existants pour éviter de perturber votre installation. Mettez-les à jour manuellement s'il s'agit du comportement souhaité.
	ValidatingWebhookConfiguration ${NAME} contient un webhook avec l'URL ${EXISTING_URL}, alors qu'il est attendu ${EXPECTED_URL}	Google n'écrase pas les webhooks existants pour éviter de perturber votre installation. Mettez-les à jour manuellement s'il s'agit du comportement souhaité.