Anthos Service Mesh géré est un maillage de services géré par Google qu'il vous suffit d'activer. Google gère pour vous la fiabilité, les mises à niveau, le scaling et la sécurité de manière rétrocompatible.
Cette page vous explique comment utiliser l'API des fonctionnalités du parc pour configurer Anthos Service Mesh géré.
Lorsque vous activez Anthos Service Mesh géré à l'aide de l'API du parc:
- Google applique la configuration de plan de contrôle recommandée
- Google active la gestion automatique des plans de données
- Votre cluster est enregistré dans une version disponible d'Anthos Service Mesh en fonction de la version disponible de votre cluster Google Kubernetes Engine (GKE), et votre plan de contrôle et votre plan de données sont mis à jour à chaque nouvelle version.
- Google permet la découverte des points de terminaison et l'équilibrage de charge entre clusters sur l'ensemble de votre maillage de services avec les paramètres par défaut, mais vous devez créer des règles de pare-feu.
Utilisez ce parcours d'intégration si vous souhaitez:
- utiliser
gcloud
pour configurer Anthos Service Mesh géré à l'aide des API Google Cloud et d'IAM ; - configurer Anthos Service Mesh à l'aide des mêmes API que les autres fonctionnalités de parc ;
- obtenir automatiquement la configuration recommandée d'Anthos Service Mesh pour chacun de vos clusters.
Prérequis
Pour commencer, ce guide suppose que vous avez :
- Un projet Cloud
- Un compte Cloud Billing
- Obtention des autorisations requises pour provisionner le service Anthos Service Mesh géré
- 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 gérés par Anthos Service Mesh dans le cluster.
- Le déploiement
mdp-controller
dans l'espace de nomskube-system
demande un processeur de 50 m et une mémoire de 128 Mi. - Le daemonset
istio-cni-node
dans l'espace de nomskube-system
demande un processeur de 100 m et de mémoire : 100 Mi sur chaque nœud.
- Le déploiement
- Assurez-vous que la machine cliente à partir de laquelle vous provisionnez Anthos 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 du maillage de services doit être activée dans 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.
L'interface CNI Istio est requise et installée par défaut lors du provisionnement d'Anthos Service Mesh géré.
Le service Anthos Service Mesh géré peut utiliser plusieurs clusters GKE dans un environnement à réseau unique ou utiliser plusieurs réseaux à projet unique.
- 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 à un seul projet, le projet de parc peut être le même que le projet de cluster. Pour en savoir plus sur les parcs, consultez la page Présentation des parcs.
- Dans le cas d'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 de VPC partagé en tant que projet hôte du parc. Pour en savoir plus, consultez la page Configurer des clusters avec un VPC partagé.
- Si votre organisation utilise VPC Service Controls et que vous provisionnez des clusters Anthos Service Mesh gérés sur GKE, vous devez également suivre la procédure décrite dans VPC Service Controls pour Anthos Service Mesh.
Limites
Nous vous recommandons de consulter la liste des fonctionnalités compatibles et limitations d'Anthos Service Mesh géré. 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'activation de Anthos Service Mesh géré avec l'API de parc utilisera Mesh CA. Si le déploiement de votre maillage de services implique des charges de travail réglementées ou nécessite Certificate Authority Service (CA Service), suivez les instructions de la section Provisionner un service Anthos Service Mesh géré à l'aide de
asmcli
.Les migrations d'Anthos Service Mesh géré avec
asmcli
vers Anthos Service Mesh avec l'API Fleet ne sont pas possibles. De même, il n'est pas possible de configurer Anthos Service Mesh géré avec l'API de parc--management manual
vers--management automatic
.Pour les clusters GKE Autopilot, la configuration multiprojet n'est possible qu'avec GKE 1.23 ou version ultérieure.
Pour les clusters GKE Autopilot, afin de s'adapter à la limite de ressources GKE Autopilot, les demandes et limites de ressources de proxy par défaut sont définies sur 500 mCPU et 512 Mo de mémoire. Vous pouvez remplacer les valeurs par défaut à l'aide de l'injection personnalisée.
Les fonctionnalités réellement disponibles pour Anthos Service Mesh géré dépendent de la version disponible. Pour en savoir plus, consultez la liste complète des fonctionnalités compatibles et limitations d'Anthos Service Mesh.
Au cours du processus de provisionnement d'un plan de contrôle géré, les CRD Istio correspondant au canal sélectionné sont provisionnées dans le cluster spécifié. Si des CRD d'Istio sont présentes dans le cluster, elles seront écrasées.
L'interface CNI Istio n'est pas compatible avec GKE Sandbox. Par conséquent, le maillage de services Anthos Service Mesh géré sur Autopilot ne fonctionne pas avec GKE Sandbox, car une CNI Istio gérée est requise.
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, le projet 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
L'activation de mesh.googleapis.com active les API suivantes :
API | Objectif | Peut être désactivé |
---|---|---|
meshconfig.googleapis.com |
Anthos Service Mesh utilise l'API de configuration du maillage pour relayer les données de configuration de votre maillage vers Google Cloud. De plus, l'activation de l'API Mesh Configuration vous permet d'accéder aux pages Anthos Service Mesh dans la console Google Cloud et d'utiliser l'autorité de certification Anthos Service Mesh (Mesh CA). | Non |
meshca.googleapis.com |
Associé à l'autorité de certification Anthos Service Mesh utilisée par Anthos Service Mesh géré. | Non |
container.googleapis.com |
Requis pour créer des clusters Google Kubernetes Engine (GKE). | Non |
gkehub.googleapis.com |
Requis pour gérer le maillage en tant que parc. | Non |
monitoring.googleapis.com |
Requis pour capturer la télémétrie pour les charges de travail de maillage. | Non |
stackdriver.googleapis.com |
Obligatoire pour utiliser l'interface utilisateur des services. | Non |
opsconfigmonitoring.googleapis.com |
Requis 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 Anthos 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é disponibilité élevée et évolutif. | Oui* |
networkservices.googleapis.com |
Active un plan de contrôle géré disponibilité élevée et évolutif. | Oui* |
networksecurity.googleapis.com |
Active un plan de contrôle géré disponibilité élevée et évolutif. | Oui* |
Configurer Anthos Service Mesh géré
Les étapes requises pour provisionner Anthos Service Mesh géré à l'aide de l'API du parc varient 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 Anthos Service Mesh géré en tant que configuration par défaut pour votre parc. Cela signifie qu'Anthos Service Mesh géré est activé sur 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 la page Gérer les fonctionnalités au niveau du parc.
Pour activer les valeurs par défaut au niveau du parc pour Anthos Service Mesh géré, procédez comme suit:
Console
Dans la console Google Cloud, accédez à la page Gestionnaire de fonctionnalités.
Dans le volet Service Mesh, cliquez sur Configure (Configurer).
Vérifiez les paramètres hérités par tous les nouveaux clusters que vous créez dans la console Google Cloud, puis 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 des clusters sur lesquels Anthos 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.
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:
Paramètres au niveau du parc
Créez un fichier
mesh.yaml
ne contenant que la seule lignemanagement: automatic
:echo "management: automatic" > mesh.yaml
Activez Anthos Service Mesh pour votre parc:
gcloud container fleet mesh enable --project FLEET_PROJECT_ID \ --fleet-default-member-config mesh.yaml
Si vous voyez l'erreur suivante, 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 cluster
Lorsque vous êtes prêt à créer des clusters à utiliser avec Anthos Service Mesh, créez-les et enregistrez-les en une seule étape avec la Google Cloud CLI afin d'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 (par exemple,us-central1-a
ouus-central1
) du cluster.Si le projet de votre cluster diffère du projet hôte de votre parc, vous devez autoriser les comptes de service Anthos Service Mesh du projet de parc à accéder au projet de cluster, et activer les API requises sur le projet de cluster. Cette opération n'est à effectuer 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.
Passez à la section Vérifier que le plan de contrôle a été provisionné.
Configurer par cluster
Suivez les étapes ci-dessous pour configurer Anthos Service Mesh géré individuellement pour chaque cluster de votre maillage.
Activer la fonctionnalité de parc Anthos Service Mesh
Activez Anthos Service Mesh sur le projet de parc. Notez que si vous envisagez d'enregistrer plusieurs clusters, l'activation d'Anthos 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
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 exemple,us-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 le MEMBERSHIP_NAME, car vous en aurez besoin lorsque vous activerez la gestion automatique.
Si le projet de votre cluster diffère du projet hôte de votre parc, vous devez autoriser les comptes de service Anthos 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.
Si vous avez déjà utilisé
asmcli
pour configurer Anthos 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
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ù :
- MEMBERSHIP_NAME est le nom d'appartenance indiqué lorsque vous avez vérifié que votre cluster était enregistré dans le parc.
MEMBERSHIP_LOCATION est le lieu de votre adhésion (une région ou
global
).Si vous avez récemment créé l'appartenance à l'aide de la commande décrite dans 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
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é la zone géographiqueglobal
lors de l'abonnement. Vous pouvez vérifier le pays de votre abonnement auprès degcloud 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
dataPlaneManagement:
details:
- code: OK
details: Service is running.
state: ACTIVE
state:
code: OK
description: 'Revision(s) ready for use: asm-managed.'
...
Notez le libellé de révision dans le champ details
, par exemple asm-managed
dans le résultat fourni. Si vous utilisez des libellés de révision, vous devez les définir avant de déployer des applications. Si vous utilisez des étiquettes d'injection par défaut, vous n'avez pas besoin de définir ce libellé.
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 section Activer les fonctionnalités facultatives sur le service Anthos Service Mesh géré.
Plan de données géré
Si vous utilisez Anthos Service Mesh géré, Google gère entièrement les mises à niveau de vos proxys, sauf si vous les désactivez au niveau de l'espace de noms, de la charge de travail ou de la révision.
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 pour réinjecter les nouvelles versions du proxy. Cela se termine généralement 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 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 expulsant les pods qui exécutent des versions antérieures du proxy. Les évictions sont effectuées progressivement, en respectant le budget d'interruption de pods et en contrôlant le taux de modification.
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 Anthos 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é reste désactivé pour les clusters existants sur lesquels il a été 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 des proxys side-car vous-même, modifiez l'annotation:
kubectl annotate --overwrite controlplanerevision -n istio-system \
REVISION_LABEL \
mesh.cloud.google.com/proxy='{"managed":"false"}'
Pour désactiver le plan de données géré pour un espace de noms, procédez comme suit:
kubectl annotate --overwrite namespace NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"false"}'
Pour désactiver le plan de données géré d'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é de la 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 avant de pouvoir recevoir des notifications. Lorsque cette option est activée, les notifications sont envoyées au moins deux jours avant l'opération de mise à niveau.
Pour activer les notifications de maintenance du plan de données géré:
Accédez à la page Communication.
Dans la ligne Mise à niveau d'Anthos Service Mesh, sous la colonne Adresse e-mail, cochez la case d'option pour activer les notifications de maintenance.
Chaque utilisateur souhaitant recevoir des notifications doit activer lui-même l'option. Si vous souhaitez définir un filtre de messagerie pour ces notifications, la ligne d'objet est la suivante :
Upcoming upgrade for your Anthos Service Mesh cluster "CLUSTER_LOCATION/CLUSTER_NAME"
.
L'exemple suivant montre une notification de maintenance d'un plan de données géré classique:
Objet: Mise à niveau à venir pour votre cluster ASM "
<location/cluster-name>
"Bonjour,
La mise à niveau des composants Anthos Service Mesh de votre cluster ${instance_id} (https://console.cloud.google.com/kubernetes/clusters/details/${instance_id}/details?project=${project_id}) est planifiée pour le ${schedule_date_human_ présentés} à ${schedule_time_human_ présentés}.
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 maintenance, nous vous préviendrons par e-mail.
Cordialement,
L'équipe Anthos Service Mesh
(c) 2022 Google LLC, 1600 Amphitheatre Parkway, Mountain View, CA 94043, États-Unis Nous vous avons envoyé cette annonce pour vous informer de changements importants apportés à Google Cloud Platform ou à votre compte. Vous pouvez désactiver les notifications d'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)
Avant de continuer, vous devez avoir déjà configuré Anthos Service Mesh géré sur chaque cluster, comme décrit dans les étapes précédentes. Il n'est pas nécessaire d'indiquer qu'un cluster est un cluster principal, car il s'agit du comportement par défaut.
De plus, assurez-vous d'avoir téléchargé asmcli
(uniquement si vous souhaitez vérifier votre configuration avec l'exemple d'application) et défini les variables du projet et du cluster.
Clusters publics
Configurer la découverte des points de terminaison entre les clusters publics
L'activation d'Anthos Service Mesh géré avec l'API du parc activera la découverte des points de terminaison pour ce cluster. Vous devez toutefois ouvrir les ports de pare-feu. Pour désactiver la découverte de points de terminaison pour un ou plusieurs clusters, consultez les instructions correspondantes dans la section Découverte de points de terminaison entre clusters publics avec API déclarative.
Clusters privés
Configurer la recherche de points de terminaison entre les clusters privés
L'activation d'Anthos Service Mesh géré avec l'API du parc activera la découverte des points de terminaison pour ce cluster. Vous devez toutefois ouvrir les ports de pare-feu. Pour désactiver la découverte de points de terminaison pour un ou plusieurs clusters, consultez les instructions correspondantes dans la section Découverte de points de terminaison entre clusters privés avec 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 utilisent le service Anthos Service Mesh géré de votre parc, assurez-vous que les ports de détection des points de terminaison ou de pare-feu sont configurés comme prévu avant de poursuivre et de déployer des applications.Pour déployer des applications, utilisez le libellé correspondant au canal que vous avez configuré lors de l'installation, ou bien istio-injection=enabled
si vous utilisez des libellés d'injection par défaut.
Libellé d'injection par défaut
kubectl label namespace NAMESPACE istio-injection=enabled istio.io/rev- --overwrite
Libellé de révision
Avant de déployer des applications, supprimez les anciens libellés istio-injection
de leurs espaces de noms et définissez à la place le libellé istio.io/rev=REVISION_LABEL
.
Il s'agit du libellé de révision que vous avez identifié lors de la validation du plan de contrôle.
Pour lui attribuer un libellé de révision spécifique, cliquez sur REVISION_LABEL
et remplacez-le par le libellé applicable: asm-managed-rapid
pour "Rapide", asm-managed
pour "Standard" ou asm-managed-stable
pour "Stable".
Le libellé de révision correspond à une version disponible :
Libellé de révision | Canal |
---|---|
asm-managed |
Standard |
asm-managed-rapid |
Version précoce |
asm-managed-stable |
Stable |
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=REVISION_LABEL --overwrite
À ce stade, vous avez correctement configuré Anthos Service Mesh géré. Si vous avez des charges de travail existantes dans des espaces de noms étiquetés, redémarrez-les pour qu'elles reçoivent des proxys injectés.
Vous êtes maintenant prêt à déployer vos applications. Vous pouvez également déployer l'exemple d'application Bookinfo.
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)
La configuration par pod permet de 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 du modèle d'injection par défaut.
Par exemple, la configuration suivante personnalise divers paramètres, y compris la réduction des requêtes de processeur, l'ajout d'une installation de volume et l'ajout d'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"
limites:
cpu: "200m"
memory: "256Mi"
volumeMounts:
- mountPath: /etc/certs
name: certs
lifecycle:
preStop:
exec:
command: ["sleep", "10"]
volumes:
- name: certs
secret:
secretName: istio-certs
En règle générale, n'importe quel champ d'une série d'annonces peut être défini. Toutefois, vous devez faire attention à 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 de définirimage
surauto
. L'injecteur de side-car sélectionnera alors automatiquement l'image à utiliser. - Certains champs de
containers
dépendent de paramètres associés. Par exemple, le nombre de requêtes de processeur doit être inférieur à la limite de processeur. Si ces deux champs ne sont pas correctement configurés, le pod risque de ne pas démarrer. - Kubernetes vous permet de définir à la fois
requests
etlimits
pour les ressources de votrePodSpec
. GKE Autopilot ne prend en compte querequests
. Pour en savoir plus, consultez la section Définir des limites de ressources dans Autopilot.
En outre, 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. Des précautions supplémentaires doivent être prises concernant certaines annotations:
- 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 comme 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 comme illimitée. - Pour GKE Autopilot, la configuration des ressources
requests
etlimits
à l'aide d'annotations peut entraîner un surprovisionnement des ressources. Pour éviter cela, utilisez l'approche des modèles d'images. Consultez Exemples de modification de ressources dans Autopilot.
Par exemple, consultez la configuration d'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"
Vérifier les métriques du plan de contrôle
Vous pouvez afficher la version du plan de contrôle et du plan de données dans l'Explorateur de métriques.
Pour vérifier que la configuration fonctionne correctement, procédez comme suit :
Dans la console Google Cloud, affichez les métriques du plan de contrôle :
Choisissez votre espace de travail et ajoutez une requête personnalisée à l'aide des paramètres suivants :
- Type de ressource : conteneur Kubernetes
- Métrique : Clients proxy
- Filtre :
container_name="cr-REVISION_LABEL"
- Grouper par: libellés
revision
etproxy_version
- Aggregator (Agrégateur) : sum
- Période : 1 minute
Lorsque vous exécutez Anthos Service Mesh avec à la fois un plan de contrôle géré par Google et un plan de contrôle au sein du cluster, vous pouvez distinguer les métriques en fonction de leur nom de conteneur. Par exemple, les métriques gérées comportent
container_name="cr-asm-managed"
, tandis que les métriques non gérées comportentcontainer_name="discovery"
. Pour afficher les métriques gérées et non gérées, supprimez le filtre surcontainer_name="cr-asm-managed"
.Vérifiez la version du plan de contrôle et la version du proxy en inspectant les champs suivants dans l'explorateur de métriques :
- Le champ revision indique la version du plan de contrôle.
- Le champ proxy_version indique la valeur
proxy_version
. - Le champ value indique le nombre de proxys connectés.
Pour le mappage entre le canal actuel et la version d'Anthos Service Mesh, consultez la section Versions d'Anthos Service Mesh par canal.
Migrer des applications vers Anthos Service Mesh géré
Pour migrer des applications d'Anthos Service Mesh dans un cluster vers Anthos Service Mesh géré, procédez comme suit:
Remplacez le libellé de l'espace de noms actuel. Les étapes requises varient selon que vous souhaitez utiliser des libellés d'injection par défaut (par exemple,
istio-injection enabled
) ou le libellé de révision.Libellé d'injection par défaut
Exécutez la commande suivante pour déplacer le tag par défaut vers la révision gérée :
istioctl tag set default --revision REVISION_LABEL
Si ce n'est pas déjà fait, exécutez la commande suivante pour ajouter un libellé à l'espace de noms à l'aide de
istio-injection=enabled
:kubectl label namespace NAMESPACE istio-injection=enabled istio.io/rev- \ --overwrite
Libellé de révision
Si vous avez utilisé le libellé
istio.io/rev=REVISION_LABEL
, exécutez la commande suivante :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.
Vérifiez que les métriques s'affichent comme prévu en suivant les étapes décrites dans la section Vérifier les métriques du plan de contrôle.
Si vous êtes sûr que votre application fonctionne comme prévu, vous pouvez supprimer le istiod
du cluster après avoir basculé tous les espaces de noms sur le plan de contrôle géré, ou les conserver en tant que sauvegarde. istiod
s'adapte automatiquement pour utiliser moins de ressources. Pour le 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 :
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
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, exécutez à nouveau la commande d'installation d'Anthos Service Mesh, qui redéploiera la passerelle en pointant vers votre plan de contrôle au sein du cluster :
kubectl -n istio-system rollout undo deploy istio-ingressgateway
Attendez-vous à ce résultat :
deployment.apps/istio-ingressgateway rolled back
Désinstaller Anthos Service Mesh
Le plan de contrôle géré effectue un autoscaling à zéro lorsqu'aucun espace de noms ne l'utilise. Pour obtenir la procédure détaillée, consultez la section Désinstaller Anthos Service Mesh.
Dépannage
Pour identifier et résoudre les problèmes lors de l'utilisation du plan de contrôle géré, consultez la section Résoudre les problèmes liés au plan de contrôle géré.
Étapes suivantes
- Découvrez comment activer les fonctionnalités facultatives gérées d'Anthos Service Mesh, telles que :
- Configurez la sécurité du transport pour sécuriser votre maillage.