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 explique comment utiliser l'API du parc pour configurer le maillage de services géré à l'aide des API Istio.
Prérequis
Pour commencer, ce guide suppose que vous avez :
- Un projet Cloud
- Un compte Cloud Billing
- Vous avez obtenu les autorisations requises pour provisionner Cloud Service Mesh.
- Activez 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 que le service Mesh géré installe dans le cluster.
- Le déploiement
mdp-controller
dans l'espace de nomskube-system
demande un processeur : 50 m, une mémoire: 128 Mi. - Le daemonset
istio-cni-node
dans l'espace de nomskube-system
demande un processeur de 100 m, une mémoire de 100 Mi sur chaque nœud.
- Le déploiement
- Assurez-vous que la machine cliente à partir de laquelle vous provisionnez Cloud Service Mesh géré dispose d'une 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 avant le provisionnement.
- La fonctionnalité de parc de maillages de services doit être activée pour votre projet. Cette opération est incluse dans les instructions ou peut être effectuée séparément.
GKE Autopilot n'est compatible qu'avec les versions 1.21.3 et ultérieures de GKE.
Cloud Service Mesh peut utiliser plusieurs clusters GKE dans un environnement réseau à un seul projet ou dans un environnement à réseau unique et multiprojet.
- 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 la page Présentation des parcs.
- Pour un environnement multiprojet, nous vous recommandons d'héberger le parc dans un projet distinct des projets de cluster. Si vos règles d'administration et votre configuration existante le permettent, nous vous recommandons d'utiliser le projet VPC partagé en tant que projet hôte de 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 Cloud Service Mesh géré.
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
Nous vous recommandons de consulter la liste des fonctionnalités et limites compatibles avec 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.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 possible qu'avec GKE 1.23 ou une version ultérieure.
Pour les clusters GKE Autopilot, afin de vous adapter à la limite de ressources de 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 de mémoire. Vous pouvez remplacer les valeurs par défaut à l'aide de l'injection personnalisée.
Au cours du processus de provisionnement d'un plan de contrôle géré, les objets CRD Istio sont provisionnés dans le cluster spécifié. S'il existe des CRD Istio dans le cluster, elles seront écrasées
L'interface CNI d'Istio et Cloud Service Mesh ne sont pas compatibles avec GKE Sandbox. Par conséquent, le service Cloud Service Mesh géré avec l'implémentation
TRAFFIC_DIRECTOR
n'est pas compatible avec les clusters pour lesquels GKE Sandbox est activé.
Avant de commencer
- 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.
-
Dans Google Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud.
-
Vérifiez que la facturation est activée pour votre projet Google Cloud.
-
Dans Google Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud.
-
Vérifiez que la facturation est activée pour votre projet Google Cloud.
- Configurez
gcloud
(même si vous utilisez Cloud Shell). -
Authentifiez-vous à l'aide de la Google Cloud CLI, où FLEET_PROJECT_ID est l'ID de votre projet hôte de parc. En règle générale, FLEET_PROJECT_ID est créé par défaut et porte le même nom que le projet.
gcloud auth login --project FLEET_PROJECT_ID
- Mettez à jour les composants :
gcloud components update
-
Activez les API requises sur le projet hôte de votre parc.
gcloud services enable mesh.googleapis.com \ --project=FLEET_PROJECT_ID
Dans la console Google Cloud, accédez à la page Gestionnaire de fonctionnalités.
Dans le volet Service Mesh, cliquez sur Configurer.
Examinez les paramètres hérités par tous les nouveaux clusters que vous créez dans la console Google Cloud et enregistrez-les dans le parc.
Pour appliquer ces paramètres, cliquez sur Configurer.
Dans la boîte de dialogue de confirmation, cliquez sur Confirmer.
Facultatif : Synchronisez les clusters existants avec les paramètres par défaut :
- 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é.
- 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.
Paramètres au niveau du parc
Créez un fichier
mesh.yaml
contenant uniquement la lignemanagement: 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 activer 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, si vous utilisez un VPC partagé), vous devez autoriser les comptes de service Cloud Service Mesh dans le projet de parc à accéder au projet réseau. 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:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \ --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-les et enregistrez-les en une seule étape avec la Google Cloud CLI pour utiliser la configuration par défaut. Exemple :
gcloud container clusters create-auto CLUSTER_NAME \ --fleet-project FLEET_PROJECT_ID \ --location=LOCATION
Pour obtenir le numéro de votre projet de parc, exécutez 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 (telle queus-central1-a
ouus-central1
) du cluster.Si le projet de 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 au projet de cluster et activer les API requises sur le projet de cluster. Vous ne devez effectuer cette opération qu'une seule 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:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \ --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, CLUSTER_PROJECT_ID est identique à FLEET_PROJECT_ID.
Enregistrez un cluster GKE à l'aide de l'identité de charge de travail du parc. L'option
--location
correspond à la zone ou à la région de calcul (par exempleus-central1-a
ouus-central1
) du cluster.gcloud container clusters update CLUSTER_NAME \ --location CLUSTER_LOCATION \ --fleet-project FLEET_PROJECT_ID
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
Notez la valeur de MEMBERSHIP_NAME, car vous en aurez besoin pour activer la gestion automatique.
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 du projet de parc à accéder au projet de réseau. 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:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \ --role roles/anthosservicemesh.serviceAgent
Si le projet de 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 au projet de 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 avez déjà configuré le service Cloud Service Mesh géré pour cette combinaison de projets de cluster et de parc, ces modifications ont déjà été appliquées et vous n'avez pas besoin d'exécuter les commandes suivantes.
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:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \ --role roles/anthosservicemesh.serviceAgent
Activez l'API Mesh sur le projet du cluster:
gcloud services enable mesh.googleapis.com \ --project=CLUSTER_PROJECT_ID
- MEMBERSHIP_NAME est le nom d'appartenance répertorié lorsque vous avez vérifié que votre cluster était enregistré dans le parc.
MEMBERSHIP_LOCATION est l'emplacement de votre appartenance (une région ou
global
).Si vous avez récemment créé l'appartenance à l'aide de la commande de ce guide, il doit s'agir de la région de votre cluster. Si vous disposez d'un cluster zonal, utilisez la région correspondant à la zone du cluster. Par exemple, si vous avez un cluster zonal dans la région
us-central1-c
, utilisez la valeurus-central1
.Cette valeur peut être
global
si vous vous êtes inscrit avant mai 2023 ou si vous avez spécifié le lieuglobal
lors de l'enregistrement de l'abonnement. Vous pouvez vérifier l'emplacement de votre abonnement avecgcloud container fleet memberships list --project FLEET_PROJECT_ID
.- Pods non injectés
- Pods injectés manuellement
- Jobs
- StatefulSets
- DaemonSets
Accédez à la page Communication.
Sur la ligne Mise à niveau de Cloud Service Mesh, sous la colonne E-mail, sélectionnez la case d'option pour activer les notifications de maintenance.
- Appliquez l'étiquette d'injection par défaut à l'espace de noms:
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.Appliquez le libellé de révision à l'espace de noms.
kubectl label namespace NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
- 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 de définirimage
surauto
, ce qui entraînera la sélection automatique de l'image à utiliser par l'injecteur de side-car. - Certains champs de
containers
dépendent de paramètres associés. Par exemple, la valeur doit être inférieure ou égale à la limite du processeur. Si les deux champs ne sont pas correctement configurés, le pod peut ne pas démarrer. - Kubernetes vous permet de définir à la fois
requests
etlimits
pour les ressources de votre podspec
. GKE Autopilot ne prend en compte querequests
. Pour en savoir plus, consultez la section Définir des limites de ressources en Autopilot. - Pour GKE Standard, si
sidecar.istio.io/proxyCPU
est défini, veillez à définir explicitementsidecar.istio.io/proxyCPULimit
. Sinon, la limite de processeur du side-car sera définie sur illimitée. - Pour GKE Standard, si
sidecar.istio.io/proxyMemory
est défini, veillez à définir explicitementsidecar.istio.io/proxyMemoryLimit
. Sinon, la limite de mémoire du side-car sera définie sur illimitée. - Pour GKE Autopilot, la configuration des ressources
requests
etlimits
à l'aide d'annotations peut entraîner un surprovisionnement des ressources. Utilisez l'approche de modèle d'image à éviter. Consultez Exemples de modification de ressources en Autopilot. - Remplacez le libellé de l'espace de noms actuel. Les étapes dépendent de la mise en œuvre du plan de contrôle.
- Appliquez l'étiquette d'injection par défaut à l'espace de noms:
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.Appliquez le libellé de révision à l'espace de noms.
kubectl label namespace NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
Effectuez une mise à niveau progressive des déploiements dans l'espace de noms :
kubectl rollout restart deployment -n NAMESPACE
Testez votre application pour vérifier que les charges de travail fonctionnent correctement.
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.
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.
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
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
L'activation de mesh.googleapis.com active les API suivantes :
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 maillage à Google Cloud. De plus, 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. | Non |
meshca.googleapis.com |
En lien avec l'autorité de certification Cloud Service Mesh utilisée par le service géré Cloud Service Mesh. | 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 maillage. | 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* |
Configurer le maillage de services Cloud Service géré
La procédure à suivre pour provisionner le service Cloud Service Mesh géré à l'aide de l'API du parc varie selon que vous préférez l'activer par défaut pour les nouveaux clusters de parc ou l'activer par cluster.
Configurer pour votre parc
Si vous avez activé l'édition Google Kubernetes Engine (GKE) Enterprise, vous pouvez activer le service géré Cloud Service Mesh comme configuration par défaut pour votre parc. Cela signifie que le service géré Cloud Service Mesh sera activé pour chaque nouveau cluster GKE sur Google Cloud enregistré lors de la création du cluster. Pour en savoir plus sur la configuration par défaut du parc, consultez Gérer les fonctionnalités au niveau du parc.
L'activation du service géré Cloud Service Mesh comme configuration par défaut pour votre parc et l'enregistrement de clusters dans le parc lors de la création du cluster n'acceptent que Mesh CA. 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 service Cloud Service Mesh géré, procédez comme suit:
Console
gcloud
Pour configurer les valeurs par défaut au niveau du parc à l'aide de la Google Cloud CLI, vous devez définir les paramètres suivants:
Passez à l'étape Vérifier que le plan de contrôle a été provisionné.
Configurer par cluster
Procédez comme suit pour configurer le service Cloud Service Mesh géré individuellement pour chaque cluster de votre réseau maillé.
Activer la fonctionnalité de parc Cloud Service Mesh
Activez Cloud Service Mesh sur le projet de parc. Notez que si vous envisagez d'enregistrer plusieurs clusters, l'activation de Cloud Service Mesh s'effectue au niveau du parc. Vous n'avez donc besoin d'exécuter cette commande qu'une seule fois.
gcloud container fleet mesh enable --project FLEET_PROJECT_ID
Enregistrer des clusters dans un parc
Configurer Certificate Authority Service (facultatif)
Si le déploiement de votre maillage de services nécessite Certificate Authority Service (CA Service), suivez les instructions de la page Configurer Certificate Authority Service pour le service géré Cloud Service Mesh pour l'activer pour votre parc. Assurez-vous d'avoir effectué toutes les étapes avant de passer à la section suivante.
Activer la gestion automatique
Exécutez la commande suivante pour activer la gestion automatique:
gcloud container fleet mesh update \
--management automatic \
--memberships MEMBERSHIP_NAME \
--project FLEET_PROJECT_ID \
--location MEMBERSHIP_LOCATION
où :
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
. Consultez la section Fonctionnalités compatibles avec Cloud Service Mesh pour connaître les différences et les configurations compatibles avec le plan de contrôle, et pour découvrir 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 de vos clusters. Avant de parcourir les sections suivantes, exécutez la commande suivante pour chacun de vos clusters afin de configurer kubectl
afin 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 la page Activer les fonctionnalités facultatives sur Cloud Service Mesh.
Plan de données géré
Si vous utilisez le service géré Cloud Service Mesh, Google gère entièrement les mises à niveau de vos proxys, sauf si vous les désactivez.
Avec le plan de données géré, les proxys side-car et les passerelles injectées sont automatiquement mis à jour conjointement avec le plan de contrôle géré en redémarrant les charges de travail afin d'injecter de nouvelles versions du proxy. Cette opération prend généralement fin une à deux semaines après la mise à niveau du plan de contrôle géré.
Si elle est désactivée, la gestion du proxy est régie par le cycle de vie naturel des pods du cluster et doit être déclenchée manuellement par l'utilisateur pour contrôler la fréquence de mise à jour.
Le plan de données géré met à niveau les proxys en évinçant les pods qui exécutent des versions antérieures du proxy. Les évictions sont effectuées progressivement, en respectant le budget d'interruptions de pods et en contrôlant le taux de changement.
Le plan de données géré ne gère pas les éléments suivants:
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 sur lesquels il était désactivé par défaut ou manuellement.
Pour désactiver le plan de données géré au niveau du cluster et revenir à la gestion vous-même des 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 informé des opérations de maintenance à venir du plan de données géré jusqu'à 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 pour 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é:
Chaque utilisateur souhaitant recevoir des notifications doit les activer séparément. Si vous souhaitez 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 montre une notification de maintenance classique pour un plan de données géré:
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 pour les multiclusters et passez à la section Déployer des applications ou Migrer des applications.
Avant de continuer, assurez-vous que Cloud Service Mesh est configuré sur chaque cluster.
L'activation de Cloud Service Mesh avec l'API du parc active la détection des points de terminaison pour ce cluster. Cependant, vous devez ouvrir les ports de pare-feu. Si vous souhaitez désactiver la détection de points de terminaison pour un ou plusieurs clusters, consultez les instructions de la section Détection de 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.
Déployer des applications
Si plusieurs clusters de votre parc utilisent le service géré Cloud Service Mesh, assurez-vous que les ports de découverte des points de terminaison ou de pare-feu sont configurés comme prévu avant de poursuivre et de 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)
kubectl label namespace NAMESPACE
istio.io/rev- istio-injection=enabled --overwrite
Géré (Istiod)
Recommandé:Exécutez la commande suivante pour appliquer le libellé d'injection par défaut à 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 l'injection basée sur les révisions est compatible. Pour ce faire, procédez comme suit:
À ce stade, vous avez correctement configuré le service géré Cloud Service Mesh. Si vous avez des charges de travail existantes dans des espaces de noms étiquetés, redémarrez-les pour qu'ils reçoivent des proxys.
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, mais cela peut entraîner des erreurs de configuration imprévues et des problèmes qui en découlent avec les conteneurs side-car. Avant de personnaliser l'injection, lisez les informations qui suivent l'exemple pour obtenir des notes sur des paramètres et des recommandations particuliers.
La configuration par pod est disponible pour remplacer ces options sur des pods individuels.
Pour ce faire, ajoutez un conteneur istio-proxy
à votre pod. L'injection side-car traite toute configuration définie ici comme un remplacement par rapport au modèle d'injection par défaut.
Par exemple, la configuration suivante personnalise divers paramètres, y compris en diminuant le nombre de demandes de ressources de processeur, en ajoutant un montage de volume et en ajoutant un hook preStop
:
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 faire attention à certains champs:
De plus, certains champs peuvent être configurés par des 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:
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
Pour migrer des applications depuis Cloud Service Mesh intégré au cluster vers le service géré Cloud Service Mesh, procédez comme suit:
Géré (TD)
kubectl label namespace NAMESPACE
istio.io/rev- istio-injection=enabled --overwrite
Géré (Istiod)
Recommandé:Exécutez la commande suivante pour appliquer le libellé d'injection par défaut à 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 l'injection basée sur les révisions est compatible. Pour ce faire, procédez comme suit:
Si vous êtes satisfait du fonctionnement de votre application, vous pouvez supprimer les istiod
du cluster après avoir basculé tous les espaces de noms sur le plan de contrôle géré, ou les conserver comme sauvegarde. istiod
effectue automatiquement un scaling à la baisse pour utiliser moins de ressources. Pour les supprimer, passez à la section Supprimer 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 :
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éployera la passerelle pointant vers votre plan de contrôle dans le 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 connaître la procédure détaillée, consultez la page Désinstaller Cloud Service Mesh.