Provisionner un plan de contrôle Cloud Service Mesh géré sur GKE

Remarque :Ce guide n'est compatible qu'avec Cloud Service Mesh avec les API Istio ne sont pas compatibles avec les API Google Cloud. Pour en savoir plus, consultez Présentation de Cloud Service Mesh

Cloud Service Mesh est un maillage de services géré par Google que vous activez simplement. Google gère la fiabilité, les mises à niveau, le scaling et la sécurité à votre place.

Cette page vous explique comment utiliser le l'API fleet pour configurer des Maillage de services Cloud à l'aide des API Istio

Prérequis

Pour commencer, ce guide suppose que vous avez :

• Un projet Cloud
• Un compte Cloud Billing
• obtenu les autorisations requises ; pour provisionner Cloud Service Mesh
• Activé Workload Identity sur vos clusters.

Conditions requises

• Un ou plusieurs clusters avec une version compatible de GKE, dans l'une des régions compatibles.
• Assurez-vous que votre cluster dispose d'une capacité suffisante pour les composants requis qui les installations gérées Cloud Service Mesh dans le cluster.
  • Le déploiement mdp-controller dans l'espace de noms kube-system demande un processeur: 50 m, mémoire: 128 Mi.
  • Le daemonset istio-cni-node dans l'espace de noms kube-system demande le CPU: 100 m, mémoire: 100 Mi sur chaque nœud.
• Assurez-vous que la machine cliente à partir de laquelle vous provisionnez Cloud Service Mesh géré la connectivité réseau au serveur d'API.
• Les clusters doivent être enregistrés sur un parc. Cette opération est incluse dans les instructions ou peut être effectuée séparément et le provisionnement.
• La fonctionnalité de parc de maillages de services doit être activée pour votre projet. C'est incluses dans les instructions ou peuvent être effectuées séparément.

• GKE Autopilot n'est compatible qu'avec la version de GKE 1.21.3+.

• Cloud Service Mesh peut utiliser plusieurs clusters GKE dans un environnement à réseau unique à un seul projet ou réseau à un seul réseau multiprojet environnement.

  • Si vous joignez des clusters qui ne font pas partie du même projet, ils doivent être enregistrés dans le même projet hôte du parc et doivent tous se trouver dans la configuration d'un VPC partagé sur le même réseau.
  • Pour un environnement multicluster à projet unique, le projet de parc peut être identique au projet de cluster. Pour en savoir plus sur les parcs, consultez Présentation des parcs
  • Pour un environnement multiprojet, nous vous recommandons d'héberger le parc dans un environnement un projet distinct des projets de cluster. Si votre organisation et la configuration existante le permettent, nous vous recommandons d'utiliser le projet VPC partagé en tant que projet hôte du parc. Pour en savoir plus, consultez la page Configurer des clusters avec un VPC partagé.

Rôles requis pour installer Cloud Service Mesh

Le tableau suivant décrit les rôles requis pour installer l'infrastructure gérée Cloud Service Mesh.

Nom de rôle	ID de rôle	Emplacement d'attribution	Description
Administrateur de GKE Hub	roles/gkehub.admin	Projet de parc	Accès complet à GKE Hub et aux ressources associées.
Administrateur Service Usage	roles/serviceusage.serviceUsageAdmin	Projet de parc	Permet d'activer, de désactiver et d'inspecter les états de service, d'inspecter les opérations, et de consommer les quotas et la facturation pour un projet destiné à un consommateur. ^(Remarque 1)
Administrateur du service CA ^Bêta	roles/privateca.admin	Projet de parc	Accès complet à toutes les ressources du service CA. ^(Remarque 2)

Limites

Attention :Notez les limites suivantes propres au parc: - Tous les clusters d'un maillage de services Cloud Service spécifique doivent être enregistrés même parc. Les clusters ne peuvent pas être enregistrés dans différents parcs. - Tous les clusters d'un projet incluant un cluster Cloud Service Mesh doivent doivent être enregistrés dans le même parc.

Nous vous recommandons de consulter la liste Fonctionnalités et limites prises en charge par Cloud Service Mesh Observez en particulier les points suivants :

• L'API IstioOperator n'est pas compatible, car son objectif principal est de contrôler les composants au sein du cluster.

  Remarque :Vous pouvez toujours activer des fonctionnalités facultatives sans utiliser l'API IstioOperator, consultez la page Activer les fonctionnalités facultatives sur le service géré Cloud Service Mesh. Vous pouvez également utiliser l'outil de migration inclus dans asmcli pour convertir d'autres fonctionnalités facultatives de IstioOperator pour qu'elles soient compatibles avec plan de contrôle géré. Pour en savoir plus, consultez la page Migrer depuis IstioOperator.

• L'utilisation de Certificate Authority Service (CA Service) nécessite de configurer Cloud Service Mesh par cluster, et n'est pas compatible avec la configuration par défaut du parc dans GKE Enterprise.

• Pour les clusters GKE Autopilot, la configuration multiprojet n'est compatibles avec GKE 1.23 ou version ultérieure.

• Pour les clusters GKE Autopilot, afin de vous adapter Limite de ressources GKE Autopilot. les demandes et limites de ressources de proxy par défaut sont définies sur 500 millicœurs de processeur et 512 Mo mémoire. Vous pouvez remplacer les valeurs par défaut injection personnalisée.

• Au cours du processus de provisionnement d'un plan de contrôle géré, les CRD Istio sont provisionnées dans le cluster spécifié. S'il existe des CRD Istio dans le fichier dans le cluster, elles seront écrasées

• CNI Istio et Cloud Service Mesh ne sont pas compatibles avec GKE Sandbox. Par conséquent, le service géré Cloud Service Mesh avec l'implémentation TRAFFIC_DIRECTOR ne permet pas n'est pas compatible avec les clusters sur lesquels GKE Sandbox est activé.

Avant de commencer

1. Connectez-vous à votre compte Google Cloud. Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.

2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Go to project selector

3. Vérifiez que la facturation est activée pour votre projet Google Cloud.

4. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Go to project selector

5. Vérifiez que la facturation est activée pour votre projet Google Cloud.

6. Configurez gcloud (même si vous utilisez Cloud Shell).
1. Authentifiez-vous à l'aide de la Google Cloud CLI, où FLEET_PROJECT_ID. correspond à l'ID de votre projet hôte de parc. En général, FLEET_PROJECT_ID est créé par défaut et porte le même nom que le projet.

          gcloud auth login --project FLEET_PROJECT_ID
   

2. Mettez à jour les composants :

          gcloud components update
   

7. Activez les API requises sur le projet hôte de votre parc.

     gcloud services enable mesh.googleapis.com \
         --project=FLEET_PROJECT_ID
   

L'activation de mesh.googleapis.com active les API suivantes :

Remarque : Certaines API requises ont des dépendances transitives par rapport aux autres.

API	Objectif	Peut-être désactivé
meshconfig.googleapis.com	Cloud Service Mesh utilise l'API Mesh Configuration pour relayer les données de configuration de votre réseau maillé vers Google Cloud. En outre, l'activation de l'API Mesh Configuration vous permet d'accéder aux pages Cloud Service Mesh dans la console Google Cloud et d'utiliser l'autorité de certification Cloud Service Mesh (Mesh CA).	Non
meshca.googleapis.com	Lié à l'autorité de certification Cloud Service Mesh utilisée par Cloud Service Mesh géré.	Non
container.googleapis.com	Obligatoire pour créer des clusters Google Kubernetes Engine (GKE).	Non
gkehub.googleapis.com	Obligatoire pour gérer le réseau maillé en tant que parc.	Non
monitoring.googleapis.com	Obligatoire pour capturer la télémétrie pour les charges de travail du réseau maillé.	Non
stackdriver.googleapis.com	Obligatoire pour utiliser l'interface utilisateur des services.	Non
opsconfigmonitoring.googleapis.com	Obligatoire pour utiliser l'interface utilisateur des services pour les clusters hors Google Cloud.	Non
connectgateway.googleapis.com	Obligatoire pour que le plan de contrôle Cloud Service Mesh géré puisse accéder aux charges de travail du réseau maillé.	Oui*
trafficdirector.googleapis.com	Active un plan de contrôle géré hautement disponible et évolutif.	Oui*
networkservices.googleapis.com	Active un plan de contrôle géré hautement disponible et évolutif.	Oui*
networksecurity.googleapis.com	Active un plan de contrôle géré hautement disponible et évolutif.	Oui*

Avertissement : Désactiver connectgateway.googleapis.com, trafficdirector.googleapis.com, networkservices.googleapis.com et/ou networksecurity.googleapis.com entraîne le dysfonctionnement du plan de contrôle Cloud Service Mesh géré. Si le parc n'utilise Cloud Service Mesh géré sur aucun cluster, ces API peuvent être désactivées.

Configurer le maillage de services Cloud Service géré

Les étapes requises pour provisionner le maillage de services Cloud Service géré à l'aide de l'API de parc dépendent si vous préférez activer par défaut pour les nouveaux clusters de parc ou l'activer par cluster.

Configurer pour votre parc

Si vous avez activé Google Kubernetes Engine (GKE) Enterprise, vous pouvez activer le service géré Cloud Service Mesh comme configuration par défaut pour votre parc. Ce signifie que chaque nouveau cluster GKE sur Google Cloud enregistré pendant la mise en cluster création le service géré Cloud Service Mesh est activé sur le cluster. Vous pouvez en savoir plus sur la configuration par défaut du parc dans Gérer caractéristiques.

Activer le service géré Cloud Service Mesh comme configuration par défaut pour votre parc et enregistrer du cluster au parc lors de la création du cluster n'accepte CA maillé : Si vous souhaitez utiliser Certificate Authority Service, nous vous recommandons de l'activer pour chaque cluster.

Pour activer les paramètres par défaut au niveau du parc pour le maillage de services Cloud Service géré géré, exécutez la procédez comme suit:

Console

1. Dans la console Google Cloud, accédez à la page Gestionnaire de fonctionnalités.

   Accéder au gestionnaire de fonctionnalités

2. Dans le volet Service Mesh, cliquez sur Configurer.

3. Vérifiez les paramètres hérités par tous les nouveaux clusters que vous créez-les dans la console Google Cloud et enregistrez-les dans le parc.

   Remarque :Ces paramètres sont des paramètres GKE qui sont des prérequis. pour utiliser Cloud Service Mesh.

4. Pour appliquer ces paramètres, cliquez sur Configurer.

5. Dans la boîte de dialogue de confirmation, cliquez sur Confirmer.

6. Facultatif : Synchronisez les clusters existants avec les paramètres par défaut :

   1. Dans la liste Clusters du parc, sélectionnez les clusters que vous souhaitez synchroniser. Vous ne pouvez sélectionner que les clusters sur lesquels Cloud Service Mesh est installé.
   2. Cliquez sur Synchroniser avec les paramètres du parc, puis sur Confirmer dans la boîte de dialogue de confirmation qui s'affiche. Cette opération peut durer quelques minutes.

gcloud

Pour configurer les valeurs par défaut au niveau du parc à l'aide de la Google Cloud CLI, vous devez définissez les paramètres suivants:

• Paramètres au niveau du parc

  • Créer un fichier mesh.yaml ne contenant qu'une seule ligne management: automatic:

    echo "management: automatic" > mesh.yaml
    

  • Activez Cloud Service Mesh pour votre parc:

    gcloud container fleet mesh enable --project FLEET_PROJECT_ID \
        --fleet-default-member-config mesh.yaml
    

    Si l'erreur suivante s'affiche, vous devez Activez GKE Enterprise.

    ERROR: (gcloud.container.fleet.mesh.enable) FAILED_PRECONDITION: The
    [anthos.googleapis.com] service is required for this operation and is not
    enabled for the project [PROJECT_NUMBER]. Please use the Google Developers
    Console to enable it.: failed precondition
    

• Paramètres au niveau du réseau

  • Si le projet de votre réseau diffère du projet hôte de votre parc (par exemple, vous utilisez un VPC partagé), vous devez autoriser les comptes de service Cloud Service Mesh dans le projet de parc pour accéder de réseau VPC Google Cloud. Vous n'avez besoin d'effectuer cette opération qu'une seule fois pour le projet réseau.

    Accordez aux comptes de service du projet de parc l'autorisation d'accéder au projet réseau:

    gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID"  \
        --member "serviceAccount:[e-mail]" \
        --role roles/anthosservicemesh.serviceAgent
    

• Paramètres au niveau du cluster

  • Lorsque vous êtes prêt à créer des clusters à utiliser avec Cloud Service Mesh, créez et et les enregistrer en une seule étape avec la Google Cloud CLI pour utiliser configuration. Exemple :

    gcloud container clusters create-auto CLUSTER_NAME \
        --fleet-project FLEET_PROJECT_ID \
        --location=LOCATION
    

    Vous pouvez obtenir le numéro de votre projet de parc en exécutant la commande la commande suivante:

    gcloud projects list --filter="FLEET_PROJECT_ID" --format="value(PROJECT_ID)"
    

    L'option --location correspond à la zone ou à la région de calcul (par exemple, us-central1-a ou us-central1) pour le cluster.

  • Si le projet de votre cluster diffère du projet hôte de votre parc, vous devez autoriser les comptes de service Cloud Service Mesh du projet de parc à accéder un projet de cluster et activer les API requises sur celui-ci. Vous uniquement une fois pour chaque projet de cluster.

    Accordez aux comptes de service du projet de parc l'autorisation d'accéder au projet de cluster:

    gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID"  \
        --member "serviceAccount:[e-mail]" \
        --role roles/anthosservicemesh.serviceAgent
    

    Activez l'API Mesh sur le projet du cluster:

    gcloud services enable mesh.googleapis.com \
      --project=CLUSTER_PROJECT_ID
    

    Remplacez CLUSTER_PROJECT_ID par l'identifiant unique de votre projet de cluster. Si vous avez créé votre cluster dans le même projet que votre parc, le CLUSTER_PROJECT_ID est le même que la FLEET_PROJECT_ID.

Passer à Vérifiez que le plan de contrôle a été provisionné.

Configurer par cluster

Procédez comme suit pour configurer Cloud Service Mesh géré pour chaque cluster dans votre réseau maillé individuellement.

Activer la fonctionnalité de parc Cloud Service Mesh

Activez Cloud Service Mesh sur le projet de parc. Notez que si vous prévoyez de vous inscrire plusieurs clusters, l'activation de Cloud Service Mesh s'effectue au niveau du parc. Ainsi, exécuter cette commande une seule fois.

gcloud container fleet mesh enable --project FLEET_PROJECT_ID

Enregistrer des clusters dans un parc

1. Enregistrer un cluster GKE à l'aide de Workload Identity du parc. L'option --location correspond à la zone de calcul. (us-central1-a ou us-central1, par exemple) du cluster.

   gcloud container clusters update CLUSTER_NAME \
     --location CLUSTER_LOCATION \
     --fleet-project FLEET_PROJECT_ID
   

2. Vérifiez que votre cluster est enregistré :

   gcloud container fleet memberships list --project FLEET_PROJECT_ID
   

   Exemple de résultat :

   NAME                 EXTERNAL_ID                           LOCATION
   cluster-1            1d8e255d-2b55-4df9-8793-0435461a2cbc  us-central1
   

   Prenez note du MEMBERSHIP_NAME, car vous en aurez besoin pour activer la gestion automatique.

3. Si le projet du réseau de votre cluster diffère du projet hôte de votre parc (par exemple, si vous utilisez un VPC partagé), vous devez autoriser les comptes de service Cloud Service Mesh dans le projet de parc pour accéder de réseau VPC Google Cloud. Vous n'avez besoin d'effectuer cette opération qu'une seule fois pour le projet réseau.

   Accordez aux comptes de service du projet de parc l'autorisation d'accéder au projet réseau:

    gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID"  \
         --member "serviceAccount:[e-mail]" \
         --role roles/anthosservicemesh.serviceAgent
   

4. Si le projet de votre cluster diffère du projet hôte de votre parc, vous devez autoriser Comptes de service Cloud Service Mesh dans le projet de parc pour accéder au cluster et activer les API requises sur le projet de cluster.

   Vous n'avez besoin d'effectuer cette opération qu'une seule fois pour chaque projet de cluster. Si vous aviez déjà configuré Cloud Service Mesh géré pour cette combinaison de parc, ces modifications ont déjà été appliquées et vous n'avez pas besoin exécuter les commandes suivantes.

   Accorder aux comptes de service du projet de parc l'autorisation d'accéder au cluster projet:

    gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID" \
        --member "serviceAccount:[e-mail]" \
        --role roles/anthosservicemesh.serviceAgent
   

   Activez l'API Mesh sur le projet du cluster:

    gcloud services enable mesh.googleapis.com \
        --project=CLUSTER_PROJECT_ID
   

Configurer Certificate Authority Service (facultatif)

Si le déploiement de votre maillage de services nécessite Certificate Authority Service (CA Service), Suivez ensuite la procédure Configurer Certificate Authority Service pour Cloud Service Mesh géré. pour l'activer pour votre parc. Assurez-vous d'avoir effectué toutes les étapes avant de continuer à la section suivante.

Activer la gestion automatique

Exécutez la commande suivante pour activer la gestion automatique:

Remarque :Vous pouvez appliquer cette modification à plusieurs clusters à la fois en transmettant une liste de noms de membres séparés par une virgule en tant que paramètre --memberships.

  gcloud container fleet mesh update \
     --management automatic \
     --memberships MEMBERSHIP_NAME \
     --project FLEET_PROJECT_ID \
     --location MEMBERSHIP_LOCATION

où :

• MEMBERSHIP_NAME est le nom de membre indiqué lors de la validation que votre cluster a été enregistré dans le parc.

• MEMBERSHIP_LOCATION est l'emplacement de votre abonnement (un "région" ou "global").

  Si vous avez récemment créé l'abonnement à l'aide de la commande de ce guide, doit correspondre à la région de votre cluster. Si vous disposez d'un cluster zonal, utilisez la correspondant à la zone du cluster. Par exemple, si vous disposez d'une couche cluster dans us-central1-c, puis utilisez la valeur us-central1.

  Cette valeur peut être global si vous vous êtes inscrit avant mai 2023 ou si vous spécifié l'emplacement global lors de l'enregistrement de l'abonnement. Vous pouvez vérifiez l'emplacement de votre abonnement avec gcloud container fleet memberships list --project FLEET_PROJECT_ID

Vérifier que le plan de contrôle a été provisionné

Après quelques minutes, vérifiez que l'état du plan de contrôle est ACTIVE :

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

Le résultat est semblable à :

...
membershipSpecs:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    mesh:
      management: MANAGEMENT_AUTOMATIC
membershipStates:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        state: ACTIVE
        implementation: ISTIOD | TRAFFIC_DIRECTOR
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed.'
...

Prenez note du plan de contrôle affiché dans le champ implementation : ISTIOD ou TRAFFIC_DIRECTOR. Voir Fonctionnalités compatibles avec Cloud Service Mesh pour connaître les différences du plan de contrôle et les configurations compatibles, et pour savoir comment l'implémentation du plan de contrôle est sélectionnée.

Configurer kubectl pour qu'il pointe vers le cluster

Les sections suivantes impliquent l'exécution de commandes kubectl sur chacun des vos clusters. Avant de passer aux sections suivantes, exécutez la la commande suivante pour chacun de vos clusters afin de configurer kubectl pour qu'il pointe vers le cluster.

gcloud container clusters get-credentials CLUSTER_NAME \
      --location CLUSTER_LOCATION \
      --project CLUSTER_PROJECT_ID

Notez qu'une passerelle d'entrée n'est pas déployée automatiquement avec le plan de contrôle. Dissocier le déploiement de la passerelle d'entrée et du plan de contrôle vous permet de gérer plus facilement vos passerelles dans un environnement de production. Si le cluster nécessite une passerelle d'entrée ou une passerelle de sortie, consultez la section Déployer des passerelles. Pour activer d'autres fonctionnalités facultatives, consultez Activez les fonctionnalités facultatives sur Cloud Service Mesh.

Plan de données géré

Si vous utilisez Cloud Service Mesh géré, Google gère entièrement les mises à niveau de vos proxys sauf si vous la désactivez.

Avec le plan de données géré, les proxys side-car et les passerelles injectées automatiquement mis à jour conjointement avec le plan de contrôle géré redémarrer des charges de travail pour réinjecter de nouvelles versions du proxy. Normalement, se termine une à deux semaines après la mise à niveau du plan de contrôle géré.

Si cette option est désactivée, la gestion du proxy est régie par le cycle de vie naturel des pods le cluster. L'utilisateur doit les déclencher manuellement pour contrôler la mise à jour taux de conversion.

Le plan de données géré met à niveau les proxys en évinçant les pods en cours d'exécution les versions antérieures du proxy. Les évictions sont effectuées progressivement, conformément à la un budget d'interruptions de pods et le contrôle du taux d'évolution.

Remarque :Si le cluster dispose d'un Intervalle de maintenance de GKE les évictions de pods débuteront au début de la prochaine l'intervalle de maintenance et se poursuivent sans interruption jusqu'à ce que tous les pods gérés mises à jour (12 heures en général). L'intervalle de maintenance n'est pas observé pour les failles CVE déploiements.

Le plan de données géré ne gère pas les éléments suivants:

• Pods non injectés
• Pods injectés manuellement
• Jobs
• StatefulSets
• DaemonSets

Désactiver le plan de données géré (facultatif)

Si vous provisionnez Cloud Service Mesh géré sur un nouveau cluster, vous pouvez désactiver complètement le plan de données géré, ou pour des espaces de noms ou des pods individuels. Le plan de données géré continuera d'être désactivé pour les clusters existants où il a été désactivé par défaut par défaut ou manuellement.

Pour désactiver le plan de données géré au niveau du cluster et revenir au gérez vous-même les proxys side-car, modifiez l'annotation:

kubectl annotate --overwrite controlplanerevision -n istio-system \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

Pour désactiver le plan de données géré pour un espace de noms:

kubectl annotate --overwrite namespace NAMESPACE \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

Pour désactiver le plan de données géré pour un pod, procédez comme suit:

kubectl annotate --overwrite pod POD_NAME \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

Activer les notifications de maintenance

Vous pouvez demander à être averti de la mise à jour à venir du plan de données géré à une semaine avant la planification de la maintenance. Les notifications de maintenance ne sont pas envoyées par défaut. Vous devez également Configurer un intervalle de maintenance GKE avant de pouvoir recevoir des notifications. Lorsque cette option est activée, les notifications sont envoyées à au moins deux jours avant la mise à niveau.

Pour activer les notifications de maintenance du plan de données géré:

1. Accédez à la page Communication.

   Accédez à la page Communication.

2. Sur la ligne Mise à niveau Cloud Service Mesh, dans la colonne E-mail, sélectionnez pour activer les notifications de maintenance.

Chaque utilisateur souhaitant recevoir des notifications doit les activer séparément. Si vous voulez pour définir un filtre de messagerie pour ces notifications, l'objet est le suivant:

Upcoming upgrade for your Cloud Service Mesh cluster "CLUSTER_LOCATION/CLUSTER_NAME"

L'exemple suivant illustre une opération de maintenance classique pour un plan de données géré notification:

Objet: Mise à niveau à venir de votre cluster Cloud Service Mesh "<location/cluster-name>"

Bonjour,

La mise à niveau des composants Cloud Service Mesh de votre cluster ${instance_id} (https://console.cloud.google.com/kubernetes/clusters/details/${instance_id}/details?project=${project_id}) est programmée le ${schedule_date_human_enhanced} à ${schedule_time_human_connected}.

Vous pouvez consulter les notes de version (https://cloud.google.com/service-mesh/docs/release-notes) pour en savoir plus sur la nouvelle mise à jour.

En cas d'annulation de cette opération de maintenance, nous vous préviendrons par e-mail.

Cordialement,

L'équipe Cloud Service Mesh

(c) 2023 Google LLC 1600 Amphitheatre Parkway, Mountain View, CA 94043, États-Unis Cette annonce vous a été envoyée afin de vous informer de changements importants apportés à Google Cloud Platform ou à votre compte. Vous pouvez désactiver les notifications concernant les intervalles de maintenance en modifiant vos préférences utilisateur: https://console.cloud.google.com/user-preferences/communication?project=${project_id}.

Configurer la découverte des points de terminaison (uniquement pour les installations multiclusters)

Si votre réseau maillé ne comporte qu'un seul cluster, ignorez ces étapes concernant l'utilisation de plusieurs clusters et passez à Déployer des applications ou Migrer des applications.

Avant de continuer, assurez-vous que Cloud Service Mesh est configuré sur chaque cluster.

Remarque : Pour plus d'informations sur la détection des points de terminaison, reportez-vous à la section Détection de points de terminaison avec plusieurs plans de contrôle.

L'activation de Cloud Service Mesh avec l'API du parc activera la détection des points de terminaison pour ce cluster. Toutefois, vous devez ports de pare-feu ouverts. Pour désactiver la détection de points de terminaison pour un ou plusieurs clusters, consultez les instructions pour la désactiver dans Détection des points de terminaison entre les clusters avec une API déclarative

Pour obtenir un exemple d'application comportant deux clusters, consultez la page Exemple de service HelloWorld.

Remarque : L'exemple du service HelloWorld utilise Docker Hub. Dans un cluster privé, l'environnement d'exécution du conteneur peut extraire les images de conteneur d'Artifact Registry par défaut. L'environnement d'exécution du conteneur ne peut pas extraire des images d'un autre registre d'images de conteneurs sur Internet. Vous pouvez télécharger l'image et la transférer vers Artifact Registry ou utiliser Cloud NAT pour fournir un accès Internet sortant à certains nœuds privés. Pour en savoir plus, consultez les pages Migrer des conteneurs externes et Créer un cluster privé.

Déployer des applications

Si plusieurs clusters de votre parc utilisent le service géré Cloud Service Mesh, vous assurer que la détection des points de terminaison ou les ports de pare-feu sont configurés comme prévu et déployer des applications.

Activez l'espace de noms pour l'injection : Les étapes dépendent de la mise en œuvre du plan de contrôle.

Géré (TD)

1. Appliquez l'étiquette d'injection par défaut à l'espace de noms:

kubectl label namespace NAMESPACE
    istio.io/rev- istio-injection=enabled --overwrite

Géré (Istiod)

Recommandé:Exécutez la commande suivante pour appliquer l'injection par défaut. l'étiquette à l'espace de noms:

  kubectl label namespace NAMESPACE \
      istio.io/rev- istio-injection=enabled --overwrite

Si vous êtes un utilisateur existant disposant du plan de contrôle Istiod géré: Nous vous recommandons d'utiliser l'injection par défaut, mais celle basée sur les révisions compatibles. Pour ce faire, procédez comme suit:

1. Exécutez la commande suivante pour localiser les versions disponibles:

   kubectl -n istio-system get controlplanerevision
   

   Le résultat ressemble à ce qui suit :

   NAME                AGE
   asm-managed-rapid   6d7h
   

   REMARQUE: Si deux révisions du plan de contrôle figurent dans la liste ci-dessus, supprimez-en une. Il n'est pas possible d'avoir plusieurs canaux de plan de contrôle dans le cluster.

   Dans le résultat, la valeur figurant dans la colonne NAME correspond au libellé de révision qui correspond à la version disponible disponible pour la version de Cloud Service Mesh.

2. Appliquez le libellé de révision à l'espace de noms.

   kubectl label namespace NAMESPACE \
       istio-injection- istio.io/rev=REVISION_LABEL --overwrite
   

À ce stade, vous avez correctement configuré le service géré Cloud Service Mesh. Si vous des charges de travail existantes dans des espaces de noms étiquetés, puis redémarrez-les pour obtenir proxys injectés.

Si vous déployez une application dans une configuration multi-cluster, répliquez la configuration de Kubernetes et du plan de contrôle dans tous les clusters, sauf si vous envisagez de limiter cette configuration à un sous-ensemble de clusters. La configuration appliquée à un cluster particulier est la source de vérité de ce cluster.

Personnaliser l'injection (facultatif)

Vous pouvez remplacer les valeurs par défaut et personnaliser les paramètres d'injection, entraîner des erreurs de configuration imprévues et des problèmes qui en découlent avec le side-car containers. Avant de personnaliser l'injection, lisez les informations après le pour les notes sur des paramètres et recommandations spécifiques.

La configuration par pod est disponible pour remplacer ces options sur des pods individuels. Pour ce faire, ajoutez un conteneur istio-proxy à votre pod. Le side-car traitera toute configuration définie ici comme un remplacement modèle d'injection par défaut.

Par exemple, la configuration suivante personnalise divers paramètres, en réduisant le nombre de demandes de ressources de processeur, en ajoutant un montage de volume preStop : crochet :

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
  - name: hello
    image: alpine
  - name: istio-proxy
    image: auto
    resources:
      requests:
        cpu: "200m"
        memory: "256Mi"
      limits:
        cpu: "200m"
        memory: "256Mi"
    volumeMounts:
    - mountPath: /etc/certs
      name: certs
    lifecycle:
      preStop:
        exec:
          command: ["sleep", "10"]
  volumes:
  - name: certs
    secret:
      secretName: istio-certs

En général, n'importe quel champ d'un pod peut être défini. Toutefois, il convient de veiller certains champs:

• Kubernetes nécessite que le champ image soit défini avant l'exécution de l'injection. Bien que vous puissiez définir une image spécifique pour remplacer l'image par défaut, nous vous recommandons que vous définissez image sur auto, ce qui entraîne l'injecteur de side-car pour sélectionner automatiquement l'image à utiliser.
• Certains champs de containers dépendent de paramètres associés. Par exemple : doit être inférieure ou égale à la limite du processeur. Si les deux champs ne sont pas corrects configuré, le démarrage du pod peut échouer.
• Kubernetes vous permet de définir à la fois requests et limits pour les ressources de votre Pod spec. GKE Autopilot ne prend en compte que requests. Pour plus pour plus d'informations, consultez Définir des limites de ressources en mode Autopilot.

De plus, certains champs peuvent être configurés à l'aide d'annotations sur le pod. bien qu'il soit recommandé d'utiliser l'approche ci-dessus pour personnaliser les paramètres. Prenez garde aux annotations suivantes:

• Pour GKE Standard, si sidecar.istio.io/proxyCPU est défini, veillez à définir explicitement sidecar.istio.io/proxyCPULimit. Dans le cas contraire, La limite du processeur sera définie sur illimitée.
• Pour GKE Standard, si sidecar.istio.io/proxyMemory est défini, veillez à définir explicitement sidecar.istio.io/proxyMemoryLimit. Dans le cas contraire, la limite de mémoire du side-car sera définie comme illimitée.
• Pour GKE Autopilot, configurer les ressources requests et limits l'utilisation d'annotations peut surprovisionner des ressources. Utiliser l'approche basée sur les modèles d'images à éviter. Consultez Exemples de modification de ressources en Autopilot.

Par exemple, consultez l'annotation de ressources ci-dessous:

spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/proxyCPU: "200m"
        sidecar.istio.io/proxyCPULimit: "200m"
        sidecar.istio.io/proxyMemory: "256Mi"
        sidecar.istio.io/proxyMemoryLimit: "256Mi"

Migrer des applications vers le service géré Cloud Service Mesh

Avertissement :Pendant le processus de migration, les objets CRD Istio sont installés dans les cluster. Si le cluster comporte déjà des CRD Istio, écrasées.

Pour migrer des applications depuis le maillage de services Cloud Service intégré au cluster vers le service géré Cloud Service Mesh, procédez comme suit:

Remarque :Assurez-vous d'avoir provisionné le service géré Cloud Service Mesh en suivant toutes les dans les sections précédentes de ce guide.
1. Remplacez le libellé de l'espace de noms actuel. Les étapes dépendent de la mise en œuvre du plan de contrôle.

Géré (TD)

1. Appliquez l'étiquette d'injection par défaut à l'espace de noms:

kubectl label namespace NAMESPACE
    istio.io/rev- istio-injection=enabled --overwrite

Géré (Istiod)

Recommandé:Exécutez la commande suivante pour appliquer l'injection par défaut. l'étiquette à l'espace de noms:

  kubectl label namespace NAMESPACE \
      istio.io/rev- istio-injection=enabled --overwrite

Si vous êtes un utilisateur existant disposant du plan de contrôle Istiod géré: Nous vous recommandons d'utiliser l'injection par défaut, mais celle basée sur les révisions compatibles. Pour ce faire, procédez comme suit:

1. Exécutez la commande suivante pour localiser les versions disponibles:

   kubectl -n istio-system get controlplanerevision
   

   Le résultat ressemble à ce qui suit :

   NAME                AGE
   asm-managed-rapid   6d7h
   

   REMARQUE: Si deux révisions du plan de contrôle figurent dans la liste ci-dessus, supprimez-en une. Il n'est pas possible d'avoir plusieurs canaux de plan de contrôle dans le cluster.

   Dans le résultat, la valeur figurant dans la colonne NAME correspond au libellé de révision qui correspond à la version disponible disponible pour la version de Cloud Service Mesh.

2. Appliquez le libellé de révision à l'espace de noms.

   kubectl label namespace NAMESPACE \
       istio-injection- istio.io/rev=REVISION_LABEL --overwrite
   

1. Effectuez une mise à niveau progressive des déploiements dans l'espace de noms :

   kubectl rollout restart deployment -n NAMESPACE
   

2. Testez votre application pour vérifier que les charges de travail fonctionnent correctement.

3. Si vous avez des charges de travail dans d'autres espaces de noms, répétez les étapes précédentes pour chaque espace de noms.

4. Si vous avez déployé l'application dans une configuration multi.cluster, répliquez la configuration de Kubernetes et d'Istio dans tous les clusters, sauf si vous souhaitez limiter cette configuration à un sous-ensemble de clusters uniquement. La configuration appliquée à un cluster particulier est la source de vérité de ce cluster.

Si vous êtes satisfait du fonctionnement de votre application, vous pouvez supprimer le istiod du cluster après le passage de tous les espaces de noms au contrôle géré ou les conserver comme solution de secours : istiod effectue automatiquement un scaling à la baisse moins de ressources. Pour la supprimer, passez à Supprimez l'ancien plan de contrôle.

Si vous rencontrez des problèmes, vous pouvez les identifier et les résoudre en utilisant les informations figurant dans la section Résoudre les problèmes liés au plan de contrôle géré et, si nécessaire, effectuer un rollback vers la version précédente.

Supprimer l'ancien plan de contrôle

Après avoir installé et vérifié que tous les espaces de noms utilisent le plan de contrôle géré par Google, vous pouvez supprimer l'ancien plan de contrôle.

kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true

Si vous avez utilisé istioctl kube-inject au lieu de l'injection automatique ou si vous avez installé des passerelles supplémentaires, vérifiez les métriques du plan de contrôle et vérifiez que le nombre de points de terminaison connectés est de zéro.

Rollback

Pour effectuer un rollback vers la version précédente du plan de contrôle, procédez comme suit :

1. Mettez à jour les charges de travail à injecter avec la version précédente du plan de contrôle. Dans la commande suivante, la valeur de révision asm-191-1 n'est utilisée qu'à titre d'exemple. Remplacez l'exemple de valeur par le libellé de révision de votre précédent plan de contrôle.

   kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
   

2. Redémarrez les pods pour déclencher une réinjection afin que les proxys disposent de la version précédente :

   kubectl rollout restart deployment -n NAMESPACE
   

Le plan de contrôle géré effectue un scaling automatique à zéro instance et n'utilise aucune ressource lorsqu'il n'est pas utilisé. Les webhooks et le provisionnement en mutation restent inchangés et n'affectent pas le comportement du cluster.

La passerelle est maintenant définie sur la révision asm-managed. Pour effectuer un rollback, réexécutez la commande d'installation de Cloud Service Mesh, qui redéploie la passerelle en renvoyant au plan de contrôle du cluster:

kubectl -n istio-system rollout undo deploy istio-ingressgateway

Attendez-vous à ce résultat :

deployment.apps/istio-ingressgateway rolled back

Désinstaller Cloud Service Mesh

Le plan de contrôle géré effectue un scaling automatique à zéro instance lorsqu'aucun espace de noms ne l'utilise. Pour consultez la procédure détaillée Désinstaller Cloud Service Mesh.