Lorsque vous installez Anthos Service Mesh, les fonctionnalités du plan de contrôle activé par défaut diffèrent en fonction de la plate-forme. Vous activez les fonctionnalités facultatives en incluant un fichier overlay lorsque vous installez (ou mettez à niveau) Anthos Service Mesh. Un fichier de superposition est un fichier YAML contenant une ressource personnalisée (RP) IstioOperator
que vous utilisez pour configurer le plan de contrôle. Vous pouvez remplacer la configuration par défaut et activer une fonctionnalité facultative dans un fichier de superposition. Vous pouvez effectuer plusieurs couches de superpositions. Chaque fichier de superposition remplace la configuration dans les couches précédentes.
À propos des fichiers de superposition
Les fichiers de superposition utilisés sur cette page se trouvent dans le package anthos-service-mesh
sur GitHub. Ces fichiers contiennent des personnalisations courantes de la configuration par défaut. Vous pouvez utiliser ces fichiers tels quels ou vous pouvez apporter des modifications supplémentaires si nécessaire.
Lorsque vous installez Anthos Service Mesh à l'aide de la commande
istioctl install
, vous pouvez spécifier un ou plusieurs fichiers de superposition à l'aide de l'option de ligne de commande-f
. Bien que vous puissiez modifier la configuration en spécifiant des paramètres de configuration dans la ligne de commande à l'aide de l'option--set
de valeuristioctl install
, nous vous recommandons d'utiliser un fichier de superposition afin de stocker le fichier dans votre système de contrôle des versions, ainsi que vos autres fichiers de ressources personnalisés. Vous devez conserver ces fichiers pour la mise à niveau d'Anthos Service Mesh afin que votre plan de contrôle ait la même configuration après la mise à niveau.Lorsque vous installez Anthos Service Mesh à l'aide du script
install_asm
fourni par Google, vous pouvez spécifier un ou plusieurs fichiers de superposition avec les options--option
ou--custom_overlay
. Si vous n'avez pas besoin de modifier les fichiers du dépôtanthos-service-mesh
, vous pouvez utiliser--option
. Le script récupère alors le fichier de GitHub à votre place. Sinon, vous pouvez apporter des modifications au fichier de superposition, puis utiliser l'option--custom_overlay
pour le transmettre au scriptinstall_asm
. Pour des exemples d'utilisation de ces deux options, consultez les exemplesinstall_asm
.
N'incluez pas plusieurs RP dans un même fichier YAML. | Créer des fichiers YAML distincts pour chaque RP |
---|---|
Télécharger le package anthos-service-mesh
Pour télécharger le package anthos-service-mesh
, procédez comme suit :
Les étapes suivantes utilisent kpt
pour télécharger le package asm
à partir du dépôt GitHub. Si vous préférez, vous pouvez utiliser à la place git clone
.
Si ce n'est pas déjà fait, installez
kpt
:gcloud components install kpt
Téléchargez le package contenant les fichiers :
kpt pkg get \ https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.8-asm asm
Les exemples suivants supposent que le package
asm
se trouve dans votre répertoire de travail actuel.
Examples
Pour activer une fonctionnalité lorsque vous installez Anthos Service Mesh, la commande exacte varie légèrement en fonction de votre plate-forme et selon que vous utilisez le script install_asm
ou la commande istioctl install
.
Toutes les commandes suivantes définissent un libellé de révision sur istiod
. Le nom du déploiement istiod
sera défini sur istiod-asm-186-8
. Un libellé de révision est au format istio.io/rev=asm-186-8
. Le libellé de révision est utilisé par le webhook d'injecteur side-car automatique pour associer les side-cars injectés à une révision istiod
particulière. Pour activer l'injection side-car automatique sur un espace de noms, vous devez lui attribuer un libellé associé à une révision correspondant au libellé de révision sur istiod
.
Activer une passerelle de sortie sur GKE On-Prem
Cet exemple part du principe que vous avez suivi les étapes décrites dans le guide Installer Anthos Service Mesh sur site pour accéder au point où vous installez Anthos Service Mesh
Le guide inclut les étapes permettant de définir la variable d'environnement CTX_CLUSTER1
et de configurer cluster.yaml
. L'un des paramètres que vous configurez dans cluster.yaml
est la révision. Le fichier egressgateways.yaml
contient la configuration permettant d'activer une passerelle de sortie facultative.
Installez Anthos Service Mesh sur GKE sur VMware:
istioctl install --context="${CTX_CLUSTER1}" \ -f cluster.yaml \ -f asm/istio/options/egressgateways.yaml
Veillez à revenir au guide d'installation de GKE sur VMware pour configurer le webhook de validation, qui est nécessaire pour les nouvelles installations.
L'ordre des fichiers sur la ligne de commande est important. Veillez à spécifier d'abord cluster.yaml
, qui a la configuration requise pour les fonctionnalités par défaut, puis les fichiers de superposition.
Activer une passerelle de sortie sur GKE sur Google Cloud
Nous vous recommandons d'utiliser le script install_asm
pour configurer un ou plusieurs clusters dans le même projet. Le script définit un libellé de révision sur istiod
.
Cet exemple part du principe que vous avez suivi le guide Installer Anthos Service Mesh sur GKE pour télécharger la version du script install_asm
sur la branche release-1.8-asm
qui installe Anthos Service Mesh 1.8.6.
Pour utiliser le script install_asm
afin d'installer une passerelle de sortie, procédez comme suit :
./install_asm \
--project_id PROJECT_ID \
--cluster_name CLUSTER_NAME \
--cluster_location CLUSTER_LOCATION \
--mode install \
--enable_all \
--option egressgateways
Cette commande exécute le script pour une nouvelle installation et active l'autorité de certification Mesh, qui est l'autorité de certification par défaut pour les installations. L'option --enable_all
permet au script d'activer les API Google requises, de définir les autorisations Identity and Access Management, et d'effectuer les mises à jour requises de votre cluster, ce qui inclut l'activation de la fonctionnalité Workload Identity de GKE.
Le script récupère le fichier egressgateways.yaml
à partir de GitHub, utilisé pour configurer le plan de contrôle.
Activer une passerelle de sortie sur des clusters GKE dans différents projets
Actuellement, le script install_asm
ne permet pas d'installer Anthos Service Mesh sur les clusters de différents projets.
La ligne de commande suivante suppose que vous avez suivi toutes les étapes de la section Installation et migration multi-projets jusqu'au point de l'installation d'Anthos Service Mesh.
Installez Anthos Service Mesh :
istioctl install \ -f asm/istio/istio-operator.yaml \ -f asm/istio/options/multiproject.yaml \ -f asm/istio/options/multicluster.yaml\ -f asm/istio/options/egressgateways.yaml \ --set revision=asm-186-8
Les fichiers suivants superposent les paramètres dans le fichier
istio-operator.yaml
:Le fichier
multiproject.yaml
permet de spécifier les fonctionnalités par défaut d'un maillage multi-projets. Vous devez le spécifier avant les autres fichiers de superposition.Le fichier
multicluster.yaml
configure les paramètres dont Anthos Service Mesh a besoin pour une configuration multicluster.Le fichier
egressgateways.yaml
configure la passerelle de sortie.
Veillez à revenir au guide d'installation sur plusieurs projets pour configurer le webhook de validation, nécessaire pour les nouvelles installations.
Format YAML pour les fonctionnalités facultatives
Les sections suivantes fournissent le code YAML permettant d'activer les fonctionnalités facultatives compatibles.
Mode mTLS STRICT
La configuration global.mtls.enabled
a été supprimée pour éviter les problèmes liés aux mises à niveau et fournir une installation plus flexible. Pour activer le mode TLS STRICT
, configurez une règle d'authentification des pairs à la place.
Diriger Envoy vers stdout
Pour en savoir plus, consultez la page Activer la journalisation des accès Envoy.
Cloud Trace
Pour les installations sur GKE, vous pouvez activer Cloud Trace. Pour en savoir plus sur la tarification, consultez la page des tarifs de Cloud Trace.
Le taux d'échantillonnage par défaut est de 1 %, mais vous pouvez remplacer la valeur par défaut en spécifiant une valeur tracing.sampling
. La valeur doit être comprise entre 0 et 100 avec une précision de 0,01. Par exemple, pour tracer cinq requêtes sur 10 000, spécifiez 0,05.
L'exemple suivant montre un taux d'échantillonnage de 100 % (ce qui n'est destiné qu'à des fins de démonstration ou de dépannage).
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
meshConfig:
enableTracing: true
defaultConfig:
tracing:
sampling: 100
values:
global:
proxy:
tracer: stackdriver
Notez qu'à l'heure actuelle, la configuration du traceur fait partie de la configuration d'amorçage du proxy. Par conséquent, le pod doit redémarrer et être réinjecté pour récupérer la mise à jour du traceur. Par exemple, vous pouvez utiliser la commande suivante pour redémarrer les pods faisant partie d'un déploiement :
kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME
Propagation du contexte de trace
Même si les proxys side-car peuvent envoyer automatiquement des délais de trace, ils ont besoin d'indications pour relier l'intégralité de la trace. Les applications doivent propager les en-têtes HTTP appropriés de sorte que, lorsque les proxys envoient des informations de délais, ceux-ci soient correctement corrélés en une seule trace.
Pour ce faire, une application doit collecter et propager les en-têtes suivants de la requête entrante vers les requêtes sortantes :
- x-request-id
- x-b3-traceid
- x-b3-spanid
- x-b3-parentspanid
- x-b3-sampled
- x-b3-flags
- x-ot-span-context
- x-cloud-trace-context
- traceparent
- grpc-trace-bin
Pour obtenir des exemples de propagation des en-têtes, consultez la page propagation du contexte de trace.
Créer une trace à partir d'un client avec un ID personnalisé
Pour créer une trace à partir d'un client avec un ID personnalisé, utilisez la commande curl
afin de créer une requête avec un client externe et forcez-la à afficher une trace. Exemple :
curl $URL --header "x-client-trace-id: 105445aa7843bc8bf206b12000100000"
Pour plus d'informations sur x-client-trace-id
, reportez-vous à la documentation d'Envoy.
Sortie via des passerelles de sortie
Pour plus d'informations, consultez la section Passerelles de sortie.
Container Network Interface d'Istio
La procédure d'activation de l'interface CNI (Container Network Interface) d'Istio dépend de l'environnement sur lequel Anthos Service Mesh est installé. Vous devez également activer une règle de réseau.
Activer CNI sur GKE
Activer CNI sur GKE sur VMware
Activer un équilibreur de charge interne
Pour les installations sur GKE, vous pouvez activer un équilibreur de charge interne pour la passerelle d'entrée Istio.
Gestion des certificats externes sur la passerelle d'entrée
Pour plus d'informations sur l'activation de la gestion des certificats externes sur la passerelle d'entrée à l'aide d'Envoy SDS, consultez la page Passerelles sécurisées.