Vous consultez la documentation de Service Mesh 1.21.

Versions disponibles

Cloud Service Mesh
Archive 1.22
Archive 1.21
Archive 1.20
Archive 1.19
Archive 1.18

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

Résoudre les problèmes gérés de Cloud Service Mesh

Ce document décrit les problèmes courants liés à Cloud Service Mesh et explique comment les résoudre. comme lorsqu'un pod est injecté avec istio.istio-system, l'installation l'outil génère des erreurs telles que les codes d'état HTTP 400 et l'appartenance à un cluster. les erreurs.

Si vous avez besoin d'une aide supplémentaire pour résoudre les problèmes liés à Cloud Service Mesh, consultez 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 l'agent de service de Cloud Service Mesh géré ne dispose pas du rôle IAM (Identity and Access Management) requis. Cela se produit généralement lorsque le rôle est révoqué par Terraform, Puppet ou les reconfigurations 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 l'agent de service s'affiche avec le rôle IAM requis dans la liste, cela signifie qu'il est correctement configuré.

Remarque :Le format de l'identifiant de l'agent de service est service-PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com, et le rôle IAM requis est "Service Anthos Service Mesh" Agent (roles/anthosservicemesh.serviceAgent).

Si l'agent de service et le rôle requis ne figurent pas dans la liste, passez à l'étape suivante.
Attribuez le rôle d'agent de service Anthos Service Mesh (roles/anthosservicemesh.serviceAgent) à l'agent de service Cloud Service Mesh du projet. Pour obtenir des instructions, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.

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 a été accordé :

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 le rôle requis était révoquée.
Pour attribuer le rôle requis à l'agent de service, exécutez la commande suivante :
```
 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 de ne pas disposer d'outils automatisés qui rétabliront ce changement. Si l'erreur se répète, mettez à jour les configurations ou les listes d'autorisation pertinentes.

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	Code	Description
`ACTIVE`	`OK`	Le plan de données géré s'exécute normalement.
`DISABLED`	`DISABLED`	Le plan de données géré sera dans cet état si aucun espace de noms ni révision est configuré pour l'utiliser. Suivez les instructions pour activer Cloud Service Mesh géré via l'API Fleet ou activer le plan de données géré après avoir provisionné Cloud 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 contrôle Cloud Service Mesh géré actif dans le plan de contrôle.
`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 à l'aide de la commande à l'aide de la commande Commande gcloud container fleet memberships register --enable-workload-identity

Vérifier l'état du plan de contrôle géré

Pour vérifier l'état du plan de contrôle géré, exécutez la commande suivante : gcloud container fleet mesh describe --project FLEET_PROJECT_ID

Dans la réponse, le champ membershipStates[].servicemesh.controlPlaneManagement.details peut expliquer l'erreur spécifique.

Pour en savoir plus, consultez la ressource personnalisée ControlPlaneRevision dans le cluster, qui est mise à jour lorsque le plan de contrôle géré est provisionné ou que le provisionnement échoue.

Pour inspecter l'état de la ressource, remplacez NAME par la valeur correspondant à chaque canal: asm-managed, asm-managed-stable ou asm-managed-rapid

kubectl describe controlplanerevision NAME -n istio-system

Le résultat est semblable à :

    Name:         asm-managed

    …

    Status:
      Conditions:
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               The provisioning process has completed successfully
        Reason:                Provisioned
        Status:                True
        Type:                  Reconciled
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               Provisioning has finished
        Reason:                ProvisioningFinished
        Status:                True
        Type:                  ProvisioningFinished
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               Provisioning has not stalled
        Reason:                NotStalled
        Status:                False
        Type:                  Stalled

La condition Reconciled détermine si le plan de contrôle géré fonctionne correctement. Si la valeur est true, le plan de contrôle fonctionne correctement. Stalled détermine si le processus de provisionnement du plan de contrôle géré a rencontré une erreur. Si la valeur est Stalled, le champ Message contient plus d'informations sur l'erreur spécifique. Voir Codes historiques pour en savoir plus sur les erreurs possibles.

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`.
	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é.

Le service géré Cloud Service Mesh ne parvient pas à se connecter au cluster GKE

Entre juin 2022 et septembre 2022, Google a terminé les travaux de sécurité liés aux réseaux autorisés, à Cloud Run et aux fonctions Cloud Run sur Google Kubernetes Engine (GKE). Les projets qui utilisaient auparavant Cloud Service Mesh géré, mais qui ont cessé de l'utiliser avant la migration, ne disposent pas de l'API requise pour la communication entre Cloud Run et GKE.

Dans ce scénario, le provisionnement de Cloud Service Mesh géré échouera et Cloud Logging affichera le message d'erreur suivant :

Connect Gateway API has not been used in project [*PROJECT_NUMBER*] before or it is disabled.
Enable it by visiting https://console.developers.google.com/apis/api/connectgateway.googleapis.com/overview?project=[*PROJECT_NUMBER*] then retry.
If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.

Filtrez ce message à l'aide de la requête suivante :

resource.type="istio_control_plane"
resource.labels.project_id=[*PROJECT_ID*]
resource.labels.location=[*REGION*]
severity=ERROR
jsonPayload.message=~"Connect Gateway API has not been used in project"

En attendant, l'injection de sidecar et le déploiement de toute ressource personnalisée Kubernetes associée à Cloud Service Mesh échoueront également, et Cloud Logging affichera le message d'avertissement suivant :

Error creating: Internal error occurred: failed calling webhook
"rev.namespace.sidecar-injector.istio.io": failed to call webhook: an error on
the server ("unknown") has prevented the request from succeeding.

Filtrez ce message en utilisant la requête suivante:

resource.type="k8s_cluster"
resource.labels.project_id=[*PROJECT_ID*]
resource.labels.location=[*REGION*]
resource.labels.cluster_name=[*CLUSTER_NAME*]
severity=WARNING
jsonPayload.message=~"Internal error occurred: failed calling webhook"

Pour résoudre le problème :

Activez l'API connectgateway requise :

 gcloud services enable connectgateway.googleapis.com --project=[*PROJECT_ID*]

Réinstallez le service géré Cloud Service Mesh.
Effectuez un redémarrage progressif sur les charges de travail.

Les API Google Cloud ne sont pas activées

Si votre parc Cloud Service Mesh géré utilise l'implémentation du plan de contrôle TRAFFIC_DIRECTOR, certaines API doivent être activées.

Activez toutes les API requises, y compris celles listées comme "Peut être désactivé" lorsque vous n'utilisez pas Cloud Service Mesh géré.

gcloud services enable --project=[*PROJECT_ID*] \
    trafficdirector.googleapis.com \
    networkservices.googleapis.com \
    networksecurity.googleapis.com

Assurez-vous qu'aucun outil automatisé ne vous permettra de rétablir ce paramètre. le changement. Si l'erreur se répète, mettez à jour les configurations ou les listes d'autorisation pertinentes.

La fédération d'identité de charge de travail de nœud de pool pour GKE est désactivée

La commande suivante affiche l'état de Cloud Service Mesh géré :

    gcloud container fleet mesh describe

Le code d'erreur NODEPOOL_WORKLOAD_IDENTITY_FEDERATION_REQUIRED peut s'afficher dans le champ Conditions de votre abonnement:

    membershipStates:
      projects/test-project/locations/us-central1/memberships/my-membership:
        servicemesh:
          conditions:
          - code: NODEPOOL_WORKLOAD_IDENTITY_FEDERATION_REQUIRED
            details: One or more node pools have workload identity federation disabled.
            documentationLink: https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity
            severity: ERROR
          controlPlaneManagement:
            details:
            - code: REVISION_FAILED_PRECONDITION
              details: Required in-cluster components are not ready. This will be retried
                within 15 minutes.
            implementation: TRAFFIC_DIRECTOR
            state: FAILED_PRECONDITION

Cette erreur s'affiche si la fédération d'identité de charge de travail n'est pas activée sur tous les pools de nœuds du cluster GKE, car il s'agit d'une condition préalable à l'installation de Cloud Service Mesh.

Pour résoudre ce message d'erreur, vous devez suivre les instructions pour Activer la fédération d'identité de charge de travail sur tous les pools de nœuds. Notez que l'activation peut varier en fonction de votre cas de cluster spécifique.

Après l'activation, le message d'erreur devrait être automatiquement supprimé et votre le cluster doit revenir à l'état ACTIVE. Si le problème persiste et que vous avez besoin une aide supplémentaire, consultez la page Obtenir de l'aide.