: Remarque : Ce guide n'est compatible qu'avec les API Cloud Service Mesh avec Istio et n'est pas compatible avec les API Google Cloud. Pour en savoir plus, consultez la page Présentation de Cloud Service Mesh . Cette page explique comment installer Cloud Service Mesh dans le cluster non géré pour les charges de travail Kubernetes en dehors de Google Cloud:
Exécutez asmcli pour effectuer une nouvelle installation de Cloud Service Mesh .
Vous pouvez éventuellement déployer une passerelle d'entrée.
Déployez ou redéployez vos charges de travail pour injecter des proxys side-car.
Si vous devez installer un maillage de services Cloud dans le cluster non géré avec un plan de contrôle istiod sur GKE, consultez la section Installer Cloud Service Mesh dans le cluster sur Google Cloud . Notez que pour les charges de travail Kubernetes sur Google Cloud, nous vous recommandons de provisionner un plan de contrôle géré .
Pour savoir comment préparer une installation hors connexion de Cloud Service Mesh, consultez la section Préparer une installation hors connexion de Cloud Service Mesh . Vous devez spécifier les options --offline et --output_dir lorsque vous exécutez asmcli install.
Limites
Prenez note des restrictions suivantes :
Pour que vous puissiez utiliser Cloud Service Mesh, tous les clusters Cloud Service Mesh d'un seul maillage doivent être enregistrés à tout moment dans le même parc. Les autres clusters du projet d'un cluster Cloud Service Mesh ne doivent pas être enregistrés dans un autre parc.
L'outil asmcli doit avoir accès au point de terminaison Google Kubernetes Engine (GKE). Vous pouvez configurer l'accès via un serveur "jump" , tel qu'une VM Compute Engine dans le cloud privé virtuel (VPC), en accordant un accès spécifique.
Avant de commencer
Avant de commencer, veillez à suivre les étapes ci-dessous :
Avertissement :Pour que Cloud Service Mesh fonctionne correctement, déployez istiod et canonical-service-controller-manager sur votre cluster. Ces outils intègrent des autorisations de contrôle des accès basé sur les rôles (RBAC) , telles que la possibilité de modifier tous les déploiements et tous les secrets du cluster.
Ces autorisations sont requises pour les fonctions de Cloud Service Mesh, telles que l'injection de side-cars, la découverte de services, la sécurisation du trafic, la gestion des passerelles d'entrée et la présentation des tableaux de bord des services. Rôles requis pour installer Cloud Service Mesh dans le cluster
Le tableau suivant décrit les rôles requis pour installer Cloud Service Mesh dans le cluster.
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 de Kubernetes Engine
roles/container.admin
Projet de cluster. Notez que ce rôle doit être attribué dans les projets de parc et de cluster pour les liaisons entre projets.
Permet la gestion complète des clusters de conteneurs et de leurs objets API Kubernetes.
Administrateur de configuration du maillage
roles/meshconfig.admin
Projet de parc et de cluster
Fournit les autorisations requises pour initialiser les composants gérés de Cloud Service Mesh, telles que l'autorisation de plan de contrôle géré et de backend qui permet aux charges de travail de communiquer avec Stackdriver sans être autorisées individuellement (pour les plans de contrôle gérés et in-cluster).
Administrateur de projet IAM
roles/resourcemanager.projectIamAdmin
Projet de cluster
Fournit des autorisations permettant d'administrer les stratégies IAM appliquées aux projets.
Administrateur de compte de service
roles/iam.serviceAccountAdmin
Projet de parc
Authentifier en tant que compte de service.
Administrateur de gestion des services
roles/servicemanagement.admin
Projet de parc
Contrôle complet des ressources Google Service Management.
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)
Remarques :
Administrateur Service Usage : ce rôle est nécessaire au préalable pour activer l'API mesh.googleapis.com lors du provisionnement initial du service Cloud Service Mesh géré.
Administrateur du service CA : ce rôle n'est requis que si vous effectuez une intégration au service CA.
Installer Cloud Service Mesh
Avertissement :Les outils GitOps (y compris Config Sync, Argo CD, Terraform et Jenkins) peuvent interférer avec vos processus d'installation, de migration ou de mise à niveau de Cloud Service Mesh. Pour de meilleurs résultats, désactivez vos outils GitOps avant d'installer, de migrer ou de mettre à niveau Cloud Service Mesh. Voici comment installer Cloud Service Mesh:
Exécutez asmcli install pour installer le plan de contrôle intégré sur un cluster unique. Consultez les sections suivantes pour obtenir des exemples de ligne de commande. Les exemples contiennent à la fois des arguments obligatoires et des arguments facultatifs qui peuvent vous être utiles. Nous vous recommandons de toujours spécifier l'argument output_dir afin de pouvoir localiser des exemples de passerelles et d'outils tels que istioctl. Consultez la barre de navigation à droite pour consulter la liste des exemples.
Vous pouvez également installer une passerelle d'entrée . Par défaut, asmcli n'installe pas la passerelle istio-ingressgateway. Nous vous recommandons de déployer et de gérer le plan de contrôle et les passerelles séparément. Si vous avez besoin d'installer l'option istio-ingressgateway par défaut avec le plan de contrôle au sein du cluster, incluez l'argument --option legacy-default-ingressgateway.
Pour terminer la configuration de Cloud Service Mesh, vous devez activer l'injection automatique de side-car et déployer ou redéployer des charges de travail .
Si vous installez Cloud Service Mesh sur plusieurs clusters, exécutez asmcli install sur chaque cluster. Lorsque vous exécutez asmcli install, veillez à utiliser le même FLEET_PROJECT_ID hors de Google Cloud .
Si vos clusters se trouvent sur des réseaux différents (en mode île ), vous devez transmettre un nom de réseau unique à asmcli à l'aide de l'option --network_id.
Installer les fonctionnalités par défaut et Mesh CA
Cette section explique comment exécuter asmcli pour installer Cloud Service Mesh avec les fonctionnalités compatibles par défaut pour votre plate-forme et activer l'autorité de certification Cloud Service Mesh en tant qu'autorité de certification.
Sur site Exécutez les commandes suivantes sur GKE sur VMware ou Google Distributed Cloud Virtual pour Bare Metal pour installer le plan de contrôle avec les fonctionnalités par défaut et l'autorité de certification Cloud Service Mesh. Saisissez vos valeurs dans les espaces réservés fournis.
Définissez le contexte actuel sur votre cluster d'utilisateur :
kubectl config use-context CLUSTER_NAME
Exécutez asmcli install :
./asmcli install \
--fleet_id FLEET_PROJECT_ID \
--kubeconfig KUBECONFIG_FILE \
--output_dir DIR_PATH \
--platform multicloud \
--enable_all \
--ca mesh_ca
--fleet_id : ID du projet du projet hôte du parc .--kubeconfig : chemin d'accès complet au fichier kubeconfig .
La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
--output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp.
Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.--platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
--enable_all
Accorder les autorisations IAM requises.
Activer les API Google requises.
Définir un libellé sur le cluster qui identifie le réseau maillé.
Enregistrer le cluster dans le parc si ce n'est déjà fait.
--ca mesh_ca Utilisez l'autorité de certification Cloud Service Mesh comme autorité de certification. asmcliElle configure l'autorité de certification Cloud Service Mesh pour utiliser l'identité de charge de travail du parc .
Pour afficher les SLO et les métriques d'infrastructure dans l'interface utilisateur de Cloud Service Mesh, vous devez également effectuer les trois premières étapes de la section Activer la journalisation et la surveillance des applications .
Si la journalisation et la surveillance ne sont pas activées et ne reçoivent pas de journaux ni de métriques personnalisés, le tableau de bord Cloud Service Mesh n'affiche pas les SLO, les journaux d'erreurs ni les métriques de processeur et de mémoire.
AWS Exécutez les commandes suivantes sur GKE sur AWS pour installer le plan de contrôle avec les fonctionnalités par défaut et l'autorité de certification Cloud Service Mesh. Saisissez vos valeurs dans les espaces réservés fournis.
Définissez le contexte actuel sur votre cluster d'utilisateur :
kubectl config use-context CLUSTER_NAME
Exécutez asmcli install :
./asmcli install \
--fleet_id FLEET_PROJECT_ID \
--kubeconfig KUBECONFIG_FILE \
--output_dir DIR_PATH \
--platform multicloud \
--enable_all \
--ca mesh_ca
--fleet_id : ID du projet du projet hôte du parc .--kubeconfig : chemin d'accès complet au fichier kubeconfig .
La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
--output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp.
Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.--platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
--enable_all
Accorder les autorisations IAM requises.
Activer les API Google requises.
Définir un libellé sur le cluster qui identifie le réseau maillé.
Enregistrer le cluster dans le parc si ce n'est déjà fait.
--ca mesh_ca Utilisez l'autorité de certification Cloud Service Mesh comme autorité de certification. asmcli configure l'autorité de certification Cloud Service Mesh pour utiliser l'identité de charge de travail du parc .
Pour afficher les SLO et les métriques d'infrastructure dans l'interface utilisateur de Cloud Service Mesh, vous devez également effectuer les trois premières étapes de la section Activer la journalisation et la surveillance des applications .
Si la journalisation et la surveillance ne sont pas activées et ne reçoivent pas de journaux ni de métriques personnalisés, le tableau de bord Cloud Service Mesh n'affiche pas les SLO, les journaux d'erreurs ni les métriques de processeur et de mémoire.
Azure Exécutez les commandes suivantes sur GKE sur Azure pour installer le plan de contrôle avec les fonctionnalités par défaut et l'autorité de certification Cloud Service Mesh.
Saisissez vos valeurs dans les espaces réservés fournis.
Définissez le contexte actuel sur votre cluster d'utilisateur :
kubectl config use-context CLUSTER_NAME
Exécutez asmcli install :
./asmcli install \
--fleet_id FLEET_PROJECT_ID \
--kubeconfig KUBECONFIG_FILE \
--output_dir DIR_PATH \
--platform multicloud \
--enable_all \
--ca mesh_ca
--fleet_id : ID du projet du projet hôte du parc .--kubeconfig : chemin d'accès complet au fichier kubeconfig .
La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
--output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp.
Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.--platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
--enable_all
Accorder les autorisations IAM requises.
Activer les API Google requises.
Définir un libellé sur le cluster qui identifie le réseau maillé.
Enregistrer le cluster dans le parc si ce n'est déjà fait.
--ca mesh_ca Utilisez l'autorité de certification Cloud Service Mesh comme autorité de certification. asmcli configure l'autorité de certification Cloud Service Mesh pour utiliser l'identité de charge de travail du parc .
Pour afficher les SLO et les métriques d'infrastructure dans l'interface utilisateur de Cloud Service Mesh, vous devez également effectuer les trois premières étapes de la section Activer la journalisation et la surveillance des applications .
Si la journalisation et la surveillance ne sont pas activées et ne reçoivent pas de journaux ni de métriques personnalisés, le tableau de bord Cloud Service Mesh n'affiche pas les SLO, les journaux d'erreurs ni les métriques de processeur et de mémoire.
Amazon EKS Exécutez les commandes suivantes sur Amazon EKS pour installer le plan de contrôle avec les fonctionnalités par défaut et l'autorité de certification Cloud Service Mesh. Saisissez vos valeurs dans les espaces réservés fournis.
Définissez le contexte actuel sur votre cluster d'utilisateur :
kubectl config use-context CLUSTER_NAME
Exécutez asmcli install :
./asmcli install \
--fleet_id FLEET_PROJECT_ID \
--kubeconfig KUBECONFIG_FILE \
--output_dir DIR_PATH \
--platform multicloud \
--enable_all \
--option attached-cluster \
--network_id default \
--ca mesh_ca
--fleet_id : ID du projet du projet hôte du parc .--kubeconfig : chemin d'accès complet au fichier kubeconfig .
La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
--output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp.
Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.--platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
--enable_all
Accorder les autorisations IAM requises.
Activer les API Google requises.
Définir un libellé sur le cluster qui identifie le réseau maillé.
Enregistrer le cluster dans le parc si ce n'est déjà fait.
--option attached-cluster Modifie l'utilitaire de signature par défaut pour qu'il soit compatible avec Istio.--network_id : si vous configurez un maillage multiréseau, définissez --network_id sur une valeur unique pour chaque cluster du maillage.--ca mesh_ca Utilisez l'autorité de certification Cloud Service Mesh comme autorité de certification. asmcli configure l'autorité de certification Cloud Service Mesh pour utiliser l'identité de charge de travail du parc .
Pour afficher les SLO et les métriques d'infrastructure dans l'interface utilisateur de Cloud Service Mesh, vous devez également effectuer les trois premières étapes de la section Activer la journalisation et la surveillance des applications .
Si la journalisation et la surveillance ne sont pas activées et ne reçoivent pas de journaux ni de métriques personnalisés, le tableau de bord Cloud Service Mesh n'affiche pas les SLO, les journaux d'erreurs ni les métriques de processeur et de mémoire.
Microsoft AKS Exécutez les commandes suivantes sur Microsoft AKS pour installer le plan de contrôle avec les fonctionnalités par défaut et l'autorité de certification Cloud Service Mesh. Saisissez vos valeurs dans les espaces réservés fournis.
Définissez le contexte actuel sur votre cluster d'utilisateur :
kubectl config use-context CLUSTER_NAME
Exécutez asmcli install :
HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer ./asmcli install \
--fleet_id FLEET_PROJECT_ID \
--kubeconfig KUBECONFIG_FILE \
--output_dir DIR_PATH \
--platform multicloud \
--enable_all \
--option attached-cluster \
--network_id default \
--ca mesh_ca
HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer autorise l'enregistrement avec GKE Hub.
Remarque : Pour autoriser l'enregistrement avec GKE Hub, vous devez utiliser cette option, car les clusters AKS ne disposent pas de point de terminaison de découverte OIDC routable publiquement pour le jeton de compte de service Kubernetes.
--fleet_id : ID du projet du projet hôte du parc .--kubeconfig : chemin d'accès complet au fichier kubeconfig .
La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
--output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp.
Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.--platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
--enable_all
Accorder les autorisations IAM requises.
Activer les API Google requises.
Définir un libellé sur le cluster qui identifie le réseau maillé.
Enregistrer le cluster dans le parc si ce n'est déjà fait.
--option attached-cluster Modifie l'utilitaire de signature par défaut pour qu'il soit compatible avec Istio.--network_id : si vous configurez un maillage multiréseau, définissez --network_id sur une valeur unique pour chaque cluster du maillage.--ca mesh_ca Utilisez l'autorité de certification Cloud Service Mesh comme autorité de certification. asmcli configure l'autorité de certification Cloud Service Mesh pour utiliser l'identité de charge de travail du parc .
Pour afficher les SLO et les métriques d'infrastructure dans l'interface utilisateur de Cloud Service Mesh, vous devez également effectuer les trois premières étapes de la section Activer la journalisation et la surveillance des applications .
Si la journalisation et la surveillance ne sont pas activées et ne reçoivent pas de journaux ni de métriques personnalisés, le tableau de bord Cloud Service Mesh n'affiche pas les SLO, les journaux d'erreurs ni les métriques de processeur et de mémoire.
Installer les fonctionnalités par défaut et le service Certificate Authority (CA)
Cette section explique comment exécuter asmcli pour installer Cloud Service Mesh avec les fonctionnalités compatibles par défaut pour votre plate-forme et activer CA Service en tant qu'autorité de certification.
Remarque concernant la plate-forme :CA Service n'est compatible qu'avec les plates-formes suivantes: clusters GKE sur Google Cloud, GKE sur VMware et GDCV pour Bare Metal. Si vous exécutez asmcli install et spécifiez --ca gcp_cas sur d'autres plates-formes, l'installation semble fonctionner, mais vos charges de travail ne pourront pas démarrer
En plus de l'autorité de certification Cloud Service Mesh , vous pouvez configurer Cloud Service Mesh pour qu'il utilise Certificate Authority Service . Ce guide vous offre l'occasion d'intégrer le service CA, qui est recommandé pour les cas d'utilisation suivants :
Vous avez besoin de plusieurs autorités de certification différentes pour signer des certificats de charge de travail sur différents clusters.
Vous devez sauvegarder vos clés de signature dans un HSM géré .
Vous travaillez dans un secteur hautement réglementé et vous êtes soumis à des exigences de conformité.
Si vous souhaitez associer votre autorité de certification Cloud Service Mesh à un certificat racine d'entreprise personnalisé pour signer les certificats de charge de travail.
Le coût de l'autorité de certification Cloud Service Mesh est inclus dans les tarifs de Cloud Service Mesh . Le service CA n'est pas inclus dans le tarif de base de Cloud Service Mesh et est facturé séparément . De plus, le service CA est fourni avec un contrat de niveau de service explicite , ce qui n'est pas le cas de l'autorité de certification Cloud Service Mesh.
Créez le pool d'autorités de certification au niveau DevOps et dans la même région que le cluster qu'il dessert, afin d'éviter des problèmes de latence excessive ou des pannes interrégionales potentielles. Pour en savoir plus, consultez la page Niveaux optimisés pour les charges de travail .
Créez l'autorité de certification afin de disposer d'au moins une autorité de certification active dans le pool d'autorités de certification du même projet que le cluster GKE. Utilisez des autorités de certification subordonnées pour signer les certificats de charge de travail Cloud Service Mesh. Notez le pool d'autorités de certification correspondant à l'autorité de certification subordonnée.S'il est destiné à ne fournir que des certificats pour les charges de travail Cloud Service Mesh, configurez la stratégie d'émission suivante pour le pool d'autorités de certification:
policy.yaml
baselineValues:
keyUsage:
baseKeyUsage:
digitalSignature: true
keyEncipherment: true
extendedKeyUsage:
serverAuth: true
clientAuth: true
caOptions:
isCa: false
identityConstraints:
allowSubjectPassthrough: false
allowSubjectAltNamesPassthrough: true
celExpression:
expression: subject_alt_names.all(san, san.type == URI && san.value.startsWith("spiffe://PROJECT_ID .svc.id.goog/ns/") )
Remarque : Il est recommandé de définir un pool d'autorités de certification subordonné par région de cluster unique pour les réseaux maillés multiclusters. Tous les pools d'autorités de certification subordonnés doivent être reliés au même pool d'autorités de certification racine.Pour mettre à jour la stratégie d'émission du pool d'autorités de certification, exécutez la commande suivante :
gcloud privateca pools update CA_POOL --location ca_region --issuance-policy policy.yaml
Pour en savoir plus sur la définition d'une stratégie sur un pool, consultez la section Utiliser une stratégie d'émission de certificat .
Si vous utilisez un modèle de certificat , configurez-le maintenant. Pour plus d'informations, suivez le guide du service CA pour les certificats d'identité de charge de travail.
Vérifiez que le modèle de certificat est créé dans la même région que le pool d'autorités de certification. S'il existe plusieurs régions pour les pools d'autorités de certification, créez un modèle de certificat par région.
Exécutez les commandes suivantes sur GKE sur VMware ou Google Distributed Cloud Virtual pour Bare Metal pour installer le plan de contrôle avec les fonctionnalités par défaut et Certificate Authority Service. Saisissez vos valeurs dans les espaces réservés fournis.
Définissez le contexte actuel sur votre cluster d'utilisateur :
kubectl config use-context CLUSTER_NAME
Exécutez asmcli install :
./asmcli install \
--kubeconfig KUBECONFIG_FILE \
--fleet_id FLEET_PROJECT_ID \
--output_dir DIR_PATH \
--enable_all \
--ca gcp_cas \
--platform multicloud \
--ca_pool projects/CA_POOL_PROJECT_ID /locations/ca_region /caPools/CA_POOL
Pour afficher les SLO et les métriques d'infrastructure dans l'interface utilisateur de Cloud Service Mesh, vous devez également effectuer les trois premières étapes de la section Activer la journalisation et la surveillance des applications .
Si la journalisation et la surveillance ne sont pas activées et ne reçoivent pas de journaux ni de métriques personnalisés, le tableau de bord Cloud Service Mesh n'affiche pas les SLO, les journaux d'erreurs ni les métriques de processeur et de mémoire.
Installer les fonctionnalités par défaut avec Istio CA
Cette section explique comment effectuer les opérations suivantes :
Générez des certificats et des clés pour l'autorité de certification Istio utilisée par Cloud Service Mesh afin de signer vos charges de travail.
Exécutez asmcli pour installer Cloud Service Mesh avec les fonctionnalités par défaut et activer l'autorité de certification Istio.
Par défaut, les environnements qui installent Cloud Service Mesh avec des métriques d'autorité de certification d'Istio envoient des métriques à Prometheus. Si vous souhaitez utiliser les tableaux de bord Cloud Service Mesh, vous devez activer Stackdriver. Pour en savoir plus, consultez la section Installer avec des fonctionnalités facultatives .
Pour une sécurité optimale, nous vous recommandons vivement de conserver une autorité de certification racine hors connexion et d'utiliser les autorités de certification subordonnées pour émettre des autorités de certification pour chaque cluster. Pour en savoir plus, consultez la section Utiliser des certificats CA .
Dans cette configuration, toutes les charges de travail du maillage de services utilisent la même autorité de certification racine (CA). Chaque autorité de certification Cloud Service Mesh utilise une clé de signature d'autorité de certification et un certificat intermédiaire, signés par l'autorité de certification racine. Lorsque plusieurs autorités de certification existent dans un maillage, cela établit une hiérarchie de confiance entre les autorités de certification. Vous pouvez répéter ces étapes pour provisionner les certificats et les clés d'un nombre illimité d'autorités de certification.
Important : Ces étapes permettent de créer des certificats et des clés à l'aide d'une commande make que nous ne fournissons qu'à titre indicatif. Pour une sécurité optimale, utilisez un ordinateur et des outils de production sécurisés hors connexion. Par exemple, utilisez HashiCorp Vault pour générer la clé de signature CA en toute sécurité et la protéger. Le fichier Makefile pour générer les certificats se trouve dans le sous-répertoire --output_dir que vous avez spécifié dans la commande asmcli validate. Si vous n'avez pas exécuté asmcli validate ou si vous ne disposez pas du répertoire téléchargé localement, vous pouvez obtenir le fichier Makefile en téléchargeant le fichier d'installation de Cloud Service Mesh et en extrayant son contenu.
Accédez au répertoire
Créez un répertoire pour les certificats et les clés :
mkdir -p certs && \
pushd certs Générez un certificat et une clé racine :
make -f ../tools/certs/Makefile.selfsigned.mk root-ca
Les fichiers suivants sont alors générés :
root-cert.pem : certificat racineroot-key.pem : clé racineroot-ca.conf : configuration nécessaire pour qu'openssl génère le certificat racineroot-cert.csr : demande CSR du certificat racine Générez un certificat et une clé intermédiaires :
make -f ../tools/certs/Makefile.selfsigned.mk cluster1-cacerts
Cette opération génère les fichiers suivants dans un répertoire nommé cluster1 :
ca-cert.pem : certificats intermédiairesca-key.pem : clé intermédiairecert-chain.pem : chaîne de certificats utilisée par istiodroot-cert.pem : certificat racine Remarque : Vous pouvez remplacer cluster1 par un autre nom. Par exemple, make
mycluster-cacerts crée un répertoire nommé mycluster. Si vous effectuez ces étapes en utilisant un ordinateur hors connexion, copiez le répertoire généré sur un ordinateur qui a accès aux clusters.
Revenez au répertoire précédent :
popd Exécutez asmcli pour installer un réseau maillé à l'aide de l'autorité de certification Istio :
Sur site Exécutez les commandes suivantes sur GKE sur VMware ou Google Distributed Cloud Virtual pour Bare Metal pour installer le plan de contrôle avec les fonctionnalités par défaut et Istio CA. Saisissez vos valeurs dans les espaces réservés fournis.
Définissez le contexte actuel sur votre cluster d'utilisateur :
kubectl config use-context CLUSTER_NAME
Exécutez asmcli install :
./asmcli install \
--fleet_id FLEET_PROJECT_ID \
--kubeconfig KUBECONFIG_FILE \
--output_dir DIR_PATH \
--platform multicloud \
--enable_all \
--ca citadel \
--ca_cert CA_CERT_FILE_PATH \
--ca_key CA_KEY_FILE_PATH \
--root_cert ROOT_CERT_FILE_PATH \
--cert_chain CERT_CHAIN_FILE_PATH
--fleet_id : ID du projet du projet hôte du parc .--kubeconfig : chemin d'accès complet au fichier kubeconfig .
La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
--output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp.
Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.--platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
--enable_all
Accorder les autorisations IAM requises.
Activer les API Google requises.
Définir un libellé sur le cluster qui identifie le réseau maillé.
Enregistrer le cluster dans le parc si ce n'est déjà fait.
-ca citadel : utiliser l'autorité de certification Istio comme autorité de certification.--ca_cert : le certificat intermédiaire--ca_key : la clé du certificat intermédiaire--root_cert : le certificat racine--cert_chain : la chaîne de certificats AWS Exécutez les commandes suivantes sur GKE sur AWS pour installer le plan de contrôle avec les fonctionnalités par défaut et Istio CA. Saisissez vos valeurs dans les espaces réservés fournis. Vous pouvez choisir d'activer l'entrée du sous-réseau public ou du sous-réseau privé.
Public
Définissez le contexte actuel sur votre cluster d'utilisateur :
kubectl config use-context CLUSTER_NAME
Exécutez asmcli install :
./asmcli install \
--fleet_id FLEET_PROJECT_ID \
--kubeconfig KUBECONFIG_FILE \
--output_dir DIR_PATH \
--platform multicloud \
--enable_all \
--ca citadel \
--ca_cert CA_CERT_FILE_PATH \
--ca_key CA_KEY_FILE_PATH \
--root_cert ROOT_CERT_FILE_PATH \
--cert_chain CERT_CHAIN_FILE_PATH
--fleet_id : ID du projet du projet hôte du parc .--kubeconfig : chemin d'accès complet au fichier kubeconfig .
La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
--output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp.
Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.--platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
--enable_all
Accorder les autorisations IAM requises.
Activer les API Google requises.
Définir un libellé sur le cluster qui identifie le réseau maillé.
Enregistrer le cluster dans le parc si ce n'est déjà fait.
-ca citadel : utiliser l'autorité de certification Istio comme autorité de certification.--ca_cert : le certificat intermédiaire--ca_key : la clé du certificat intermédiaire--root_cert : le certificat racine--cert_chain : la chaîne de certificats Privé
Définissez le contexte actuel sur votre cluster d'utilisateur :
kubectl config use-context CLUSTER_NAME
Enregistrez le fichier YAML suivant dans un fichier appelé istio-operator-internal-lb.yaml :
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
components:
ingressGateways:
- enabled: true
k8s:
serviceAnnotations:
service.beta.kubernetes.io/aws-load-balancer-internal: "true"
name: istio-ingressgateway
Exécutez asmcli install :
./asmcli install \
--fleet_id FLEET_PROJECT_ID \
--kubeconfig KUBECONFIG_FILE \
--output_dir DIR_PATH \
--platform multicloud \
--enable_all \
--ca citadel \
--ca_cert FILE_PATH \
--ca_key FILE_PATH \
--root_cert FILE_PATH \
--cert_chain FILE_PATH \
--custom_overlay istio-operator-internal-lb.yaml
--fleet_id : ID du projet du projet hôte du parc .--kubeconfig : chemin d'accès complet au fichier kubeconfig .
La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
--output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp.
Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.--platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
--enable_all
Accorder les autorisations IAM requises.
Activer les API Google requises.
Définir un libellé sur le cluster qui identifie le réseau maillé.
Enregistrer le cluster dans le parc si ce n'est déjà fait.
-ca citadel : utiliser l'autorité de certification Istio comme autorité de certification.--ca_cert : le certificat intermédiaire--ca_key : la clé du certificat intermédiaire--root_cert : le certificat racine--cert_chain : la chaîne de certificats--custom_overlay : nom du fichier de superposition créé. Pour en savoir plus sur les fichiers de superposition, consultez la page Activer des fonctionnalités facultatives sur le plan de contrôle au sein du cluster . Azure Exécutez les commandes suivantes sur GKE sur Azure pour installer le plan de contrôle avec les fonctionnalités par défaut et Istio CA. Saisissez vos valeurs dans les espaces réservés fournis. Vous pouvez choisir d'activer l'entrée du sous-réseau public ou du sous-réseau privé.
Public
Définissez le contexte actuel sur votre cluster d'utilisateur :
kubectl config use-context CLUSTER_NAME
Exécutez asmcli install :
./asmcli install \
--fleet_id FLEET_PROJECT_ID \
--kubeconfig KUBECONFIG_FILE \
--output_dir DIR_PATH \
--platform multicloud \
--enable_all \
--ca citadel \
--ca_cert CA_CERT_FILE_PATH \
--ca_key CA_KEY_FILE_PATH \
--root_cert ROOT_CERT_FILE_PATH \
--cert_chain CERT_CHAIN_FILE_PATH
--fleet_id : ID du projet du projet hôte du parc .--kubeconfig : chemin d'accès complet au fichier kubeconfig .
La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
--output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp.
Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.--platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
--enable_all
Accorder les autorisations IAM requises.
Activer les API Google requises.
Définir un libellé sur le cluster qui identifie le réseau maillé.
Enregistrer le cluster dans le parc si ce n'est déjà fait.
-ca citadel : utiliser l'autorité de certification Istio comme autorité de certification.--ca_cert : le certificat intermédiaire--ca_key : la clé du certificat intermédiaire--root_cert : le certificat racine--cert_chain : la chaîne de certificats Privé
Définissez le contexte actuel sur votre cluster d'utilisateur :
kubectl config use-context CLUSTER_NAME
Enregistrez le fichier YAML suivant dans un fichier appelé istio-operator-internal-lb.yaml :
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
components:
ingressGateways:
- enabled: true
k8s:
serviceAnnotations:
service.beta.kubernetes.io/aws-load-balancer-internal: "true"
name: istio-ingressgateway
Exécutez asmcli install :
./asmcli install \
--fleet_id FLEET_PROJECT_ID \
--kubeconfig KUBECONFIG_FILE \
--output_dir DIR_PATH \
--platform multicloud \
--enable_all \
--ca citadel \
--ca_cert FILE_PATH \
--ca_key FILE_PATH \
--root_cert FILE_PATH \
--cert_chain FILE_PATH \
--custom_overlay istio-operator-internal-lb.yaml
--fleet_id : ID du projet du projet hôte du parc .--kubeconfig : chemin d'accès complet au fichier kubeconfig .
La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
--output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp.
Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.--platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
--enable_all
Accorder les autorisations IAM requises.
Activer les API Google requises.
Définir un libellé sur le cluster qui identifie le réseau maillé.
Enregistrer le cluster dans le parc si ce n'est déjà fait.
-ca citadel : utiliser l'autorité de certification Istio comme autorité de certification.--ca_cert : le certificat intermédiaire--ca_key : la clé du certificat intermédiaire--root_cert : le certificat racine--cert_chain : la chaîne de certificats--custom_overlay : nom du fichier de superposition créé. Pour en savoir plus sur les fichiers de superposition, consultez la page Activer des fonctionnalités facultatives sur le plan de contrôle au sein du cluster . Amazon EKS Exécutez les commandes suivantes sur Amazon EKS pour installer le plan de contrôle avec les fonctionnalités par défaut et Istio CA. Saisissez vos valeurs dans les espaces réservés fournis.
Définissez le contexte actuel sur votre cluster d'utilisateur :
kubectl config use-context CLUSTER_NAME
Exécutez asmcli install :
./asmcli install \
--fleet_id FLEET_PROJECT_ID \
--kubeconfig KUBECONFIG_FILE \
--output_dir DIR_PATH \
--platform multicloud \
--enable_all \
--option attached-cluster \
--ca citadel \
--ca_cert CA_CERT_FILE_PATH \
--ca_key CA_KEY_FILE_PATH \
--root_cert ROOT_CERT_FILE_PATH \
--cert_chain CERT_CHAIN_FILE_PATH \
--network_id default
--fleet_id : ID du projet du projet hôte du parc .--kubeconfig : chemin d'accès complet au fichier kubeconfig .
La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
--output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp.
Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.--platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
--enable_all
Accorder les autorisations IAM requises.
Activer les API Google requises.
Définir un libellé sur le cluster qui identifie le réseau maillé.
Enregistrer le cluster dans le parc si ce n'est déjà fait.
--option attached-cluster Modifie l'utilitaire de signature par défaut pour qu'il soit compatible avec Istio.-ca citadel : utiliser l'autorité de certification Istio comme autorité de certification.--ca_cert : le certificat intermédiaire--ca_key : la clé du certificat intermédiaire--root_cert : le certificat racine--cert_chain : la chaîne de certificats--network_id : si vous configurez un maillage multiréseau, définissez --network_id sur une valeur unique pour chaque cluster du maillage. Microsoft AKS Exécutez les commandes suivantes sur Microsoft AKS pour installer le plan de contrôle avec les fonctionnalités par défaut et Istio CA. Saisissez vos valeurs dans les espaces réservés fournis.
Définissez le contexte actuel sur votre cluster d'utilisateur :
kubectl config use-context CLUSTER_NAME
Exécutez asmcli install :
HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer ./asmcli install \
--fleet_id FLEET_PROJECT_ID \
--kubeconfig KUBECONFIG_FILE \
--output_dir DIR_PATH \
--platform multicloud \
--enable_all \
--option attached-cluster \
--ca citadel \
--ca_cert CA_CERT_FILE_PATH \
--ca_key CA_KEY_FILE_PATH \
--root_cert ROOT_CERT_FILE_PATH \
--cert_chain CERT_CHAIN_FILE_PATH \
--network_id default
HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer autorise l'enregistrement avec GKE Hub.
Remarque : Pour autoriser l'enregistrement avec GKE Hub, vous devez utiliser cette option, car les clusters AKS ne disposent pas de point de terminaison de découverte OIDC routable publiquement pour le jeton de compte de service Kubernetes.
--fleet_id : ID du projet du projet hôte du parc .--kubeconfig : chemin d'accès complet au fichier kubeconfig .
La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
--output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp.
Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.--platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
--enable_all
Accorder les autorisations IAM requises.
Activer les API Google requises.
Définir un libellé sur le cluster qui identifie le réseau maillé.
Enregistrer le cluster dans le parc si ce n'est déjà fait.
--option attached-cluster Modifie l'utilitaire de signature par défaut pour qu'il soit compatible avec Istio.-ca citadel : utiliser l'autorité de certification Istio comme autorité de certification.--ca_cert : le certificat intermédiaire--ca_key : la clé du certificat intermédiaire--root_cert : le certificat racine--cert_chain : la chaîne de certificats--network_id : si vous configurez un maillage multiréseau, définissez --network_id sur une valeur unique pour chaque cluster du maillage.
Installer avec l'autorité de certification Istio avec l'observabilité Google Cloud activée
Si vous souhaitez utiliser les tableaux de bord Cloud Service Mesh, vous devez activer Stackdriver.
Sur site Exécutez les commandes suivantes sur GKE sur VMware ou Google Distributed Cloud Virtual pour Bare Metal pour installer le plan de contrôle avec Stackdriver, ainsi que d'autres fonctionnalités facultatives et Istio CA. Saisissez vos valeurs dans les espaces réservés fournis.
Définissez le contexte actuel sur votre cluster d'utilisateur :
kubectl config use-context CLUSTER_NAME
Exécutez asmcli install :
./asmcli install \
--fleet_id FLEET_PROJECT_ID \
--kubeconfig KUBECONFIG_FILE \
--output_dir DIR_PATH \
--platform multicloud \
--enable_all \
--ca citadel \
--ca_cert CA_CERT_FILE_PATH \
--ca_key CA_KEY_FILE_PATH \
--root_cert ROOT_CERT_FILE_PATH \
--cert_chain CERT_CHAIN_FILE_PATH
--fleet_id : ID du projet du projet hôte du parc .--kubeconfig : chemin d'accès complet au fichier kubeconfig .
La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
--output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp.
Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.--platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
--enable_all
Accorder les autorisations IAM requises.
Activer les API Google requises.
Définir un libellé sur le cluster qui identifie le réseau maillé.
Enregistrer le cluster dans le parc si ce n'est déjà fait.
-ca citadel : utiliser l'autorité de certification Istio comme autorité de certification.--ca_cert : le certificat intermédiaire--ca_key : la clé du certificat intermédiaire--root_cert : le certificat racine--cert_chain : la chaîne de certificats--option stackdriver active l'option Stackdriver. Notez que vous pouvez également activer Stackdriver et Prometheus en utilisant --option prometheus-and-stackdriver.
Pour afficher les SLO et les métriques d'infrastructure dans l'interface utilisateur de Cloud Service Mesh, vous devez également effectuer les trois premières étapes de la section Activer la journalisation et la surveillance des applications .
Si la journalisation et la surveillance ne sont pas activées et ne reçoivent pas de journaux ni de métriques personnalisés, le tableau de bord Cloud Service Mesh n'affiche pas les SLO, les journaux d'erreurs ni les métriques de processeur et de mémoire.
AWS Exécutez les commandes suivantes sur GKE sur AWS pour installer le plan de contrôle avec Stackdriver et d'autres fonctionnalités facultatives, ainsi qu'Istio CA. Saisissez vos valeurs dans les espaces réservés fournis. Vous pouvez choisir d'activer l'entrée du sous-réseau public ou du sous-réseau privé.
Public
Définissez le contexte actuel sur votre cluster d'utilisateur :
kubectl config use-context CLUSTER_NAME
Exécutez asmcli install :
./asmcli install \
--fleet_id FLEET_PROJECT_ID \
--kubeconfig KUBECONFIG_FILE \
--output_dir DIR_PATH \
--platform multicloud \
--enable_all \
--ca citadel \
--ca_cert CA_CERT_FILE_PATH \
--ca_key CA_KEY_FILE_PATH \
--root_cert ROOT_CERT_FILE_PATH \
--cert_chain CERT_CHAIN_FILE_PATH \
--option stackdriver
--fleet_id : ID du projet du projet hôte du parc .--kubeconfig : chemin d'accès complet au fichier kubeconfig .
La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
--output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp.
Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.--platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
--enable_all
Accorder les autorisations IAM requises.
Activer les API Google requises.
Définir un libellé sur le cluster qui identifie le réseau maillé.
Enregistrer le cluster dans le parc si ce n'est déjà fait.
-ca citadel : utiliser l'autorité de certification Istio comme autorité de certification.--ca_cert : le certificat intermédiaire--ca_key : la clé du certificat intermédiaire--root_cert : le certificat racine--cert_chain : la chaîne de certificats--option stackdriver active l'option Stackdriver. Notez que vous pouvez également activer Stackdriver et Prometheus en utilisant --option prometheus-and-stackdriver.
Privé
Définissez le contexte actuel sur votre cluster d'utilisateur :
kubectl config use-context CLUSTER_NAME
Enregistrez le fichier YAML suivant dans un fichier appelé istio-operator-internal-lb.yaml :
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
components:
ingressGateways:
- enabled: true
k8s:
serviceAnnotations:
service.beta.kubernetes.io/aws-load-balancer-internal: "true"
name: istio-ingressgateway
Exécutez asmcli install :
./asmcli install \
--fleet_id FLEET_PROJECT_ID \
--kubeconfig KUBECONFIG_FILE \
--output_dir DIR_PATH \
--platform multicloud \
--enable_all \
--ca citadel \
--ca_cert FILE_PATH \
--ca_key FILE_PATH \
--root_cert FILE_PATH \
--cert_chain FILE_PATH
--custom_overlay istio-operator-internal-lb.yaml \
--option stackdriver
--fleet_id : ID du projet du projet hôte du parc .--kubeconfig : chemin d'accès complet au fichier kubeconfig .
La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
--output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp.
Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.--platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
--enable_all
Accorder les autorisations IAM requises.
Activer les API Google requises.
Définir un libellé sur le cluster qui identifie le réseau maillé.
Enregistrer le cluster dans le parc si ce n'est déjà fait.
-ca citadel : utiliser l'autorité de certification Istio comme autorité de certification.--ca_cert : le certificat intermédiaire--ca_key : la clé du certificat intermédiaire--root_cert : le certificat racine--cert_chain : la chaîne de certificats--custom_overlay : nom du fichier de superposition créé. Pour en savoir plus sur les fichiers de superposition, consultez la page Activer des fonctionnalités facultatives sur le plan de contrôle au sein du cluster .--option stackdriver active l'option Stackdriver. Notez que vous pouvez également activer Stackdriver et Prometheus en utilisant --option prometheus-and-stackdriver. Vous pouvez également activer Stackdriver en utilisant --custom_overlay stackdriver.yaml. Vous devez télécharger le package anthos-service-mesh-package , ou créer stackdriver.yaml à partir du fichier manifeste fourni .
Azure Exécutez les commandes suivantes sur GKE sur Azure pour installer le plan de contrôle avec Stackdriver et d'autres fonctionnalités facultatives, ainsi qu'Istio CA. Saisissez vos valeurs dans les espaces réservés fournis. Vous pouvez choisir d'activer Ingress pour le sous-réseau public ou le sous-réseau privé.
Public
Définissez le contexte actuel sur votre cluster d'utilisateur :
kubectl config use-context CLUSTER_NAME
Exécutez asmcli install :
./asmcli install \
--fleet_id FLEET_PROJECT_ID \
--kubeconfig KUBECONFIG_FILE \
--output_dir DIR_PATH \
--platform multicloud \
--enable_all \
--ca citadel \
--ca_cert CA_CERT_FILE_PATH \
--ca_key CA_KEY_FILE_PATH \
--root_cert ROOT_CERT_FILE_PATH \
--cert_chain CERT_CHAIN_FILE_PATH \
--option stackdriver
--fleet_id : ID du projet du projet hôte du parc .--kubeconfig : chemin d'accès complet au fichier kubeconfig .
La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
--output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp.
Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.--platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
--enable_all
Accorder les autorisations IAM requises.
Activer les API Google requises.
Définir un libellé sur le cluster qui identifie le réseau maillé.
Enregistrer le cluster dans le parc si ce n'est déjà fait.
-ca citadel : utiliser l'autorité de certification Istio comme autorité de certification.--ca_cert : le certificat intermédiaire--ca_key : la clé du certificat intermédiaire--root_cert : le certificat racine--cert_chain : la chaîne de certificats--option stackdriver active l'option Stackdriver. Notez que vous pouvez également activer Stackdriver et Prometheus en utilisant --option prometheus-and-stackdriver.
Privé
Définissez le contexte actuel sur votre cluster d'utilisateur :
kubectl config use-context CLUSTER_NAME
Enregistrez le fichier YAML suivant dans un fichier appelé istio-operator-internal-lb.yaml :
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
components:
ingressGateways:
- enabled: true
k8s:
serviceAnnotations:
service.beta.kubernetes.io/aws-load-balancer-internal: "true"
name: istio-ingressgateway
Exécutez asmcli install :
./asmcli install \
--fleet_id FLEET_PROJECT_ID \
--kubeconfig KUBECONFIG_FILE \
--output_dir DIR_PATH \
--platform multicloud \
--enable_all \
--ca citadel \
--ca_cert FILE_PATH \
--ca_key FILE_PATH \
--root_cert FILE_PATH \
--cert_chain FILE_PATH
--custom_overlay istio-operator-internal-lb.yaml \
--option stackdriver
--fleet_id : ID du projet du projet hôte du parc .--kubeconfig : chemin d'accès complet au fichier kubeconfig .
La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
--output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp.
Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.--platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
--enable_all
Accorder les autorisations IAM requises.
Activer les API Google requises.
Définir un libellé sur le cluster qui identifie le réseau maillé.
Enregistrer le cluster dans le parc si ce n'est déjà fait.
-ca citadel : utiliser l'autorité de certification Istio comme autorité de certification.--ca_cert : le certificat intermédiaire--ca_key : la clé du certificat intermédiaire--root_cert : le certificat racine--cert_chain : la chaîne de certificats--custom_overlay : nom du fichier de superposition créé. Pour en savoir plus sur les fichiers de superposition, consultez la page Activer des fonctionnalités facultatives sur le plan de contrôle au sein du cluster .--option stackdriver active l'option Stackdriver. Notez que vous pouvez également activer Stackdriver et Prometheus en utilisant --option prometheus-and-stackdriver. Vous pouvez également activer Stackdriver en utilisant --custom_overlay stackdriver.yaml. Vous devez télécharger le package anthos-service-mesh-package , ou créer stackdriver.yaml à partir du fichier manifeste fourni .
Amazon EKS Exécutez les commandes suivantes sur Amazon EKS pour installer le plan de contrôle avec Stackdriver et d'autres fonctionnalités facultatives, ainsi que Istio CA. Saisissez vos valeurs dans les espaces réservés fournis.
Définissez le contexte actuel sur votre cluster d'utilisateur :
kubectl config use-context CLUSTER_NAME
Exécutez asmcli install :
./asmcli install \
--fleet_id FLEET_PROJECT_ID \
--kubeconfig KUBECONFIG_FILE \
--output_dir DIR_PATH \
--platform multicloud \
--enable_all \
--ca citadel \
--ca_cert CA_CERT_FILE_PATH \
--ca_key CA_KEY_FILE_PATH \
--root_cert ROOT_CERT_FILE_PATH \
--cert_chain CERT_CHAIN_FILE_PATH \
--option stackdriver \
--option attached-cluster
--fleet_id : ID du projet du projet hôte du parc .--kubeconfig : chemin d'accès complet au fichier kubeconfig .
La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
--output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp.
Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.--platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
--enable_all
Accorder les autorisations IAM requises.
Activer les API Google requises.
Définir un libellé sur le cluster qui identifie le réseau maillé.
Enregistrer le cluster dans le parc si ce n'est déjà fait.
-ca citadel : utiliser l'autorité de certification Istio comme autorité de certification.--ca_cert : le certificat intermédiaire--ca_key : la clé du certificat intermédiaire--root_cert : le certificat racine--cert_chain : la chaîne de certificats--option stackdriver active l'option Stackdriver. Notez que vous pouvez également activer Stackdriver et Prometheus en utilisant --option prometheus-and-stackdriver.--option stackdriver Redéfinit l'utilitaire de signature par défaut sur istiod. Microsoft AKS Exécutez les commandes suivantes sur Microsoft AKS pour installer le plan de contrôle avec les fonctionnalités par défaut et Istio CA. Saisissez vos valeurs dans les espaces réservés fournis.
Définissez le contexte actuel sur votre cluster d'utilisateur :
kubectl config use-context CLUSTER_NAME
Exécutez asmcli install :
HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer ./asmcli install \
--fleet_id FLEET_PROJECT_ID \
--kubeconfig KUBECONFIG_FILE \
--output_dir DIR_PATH \
--platform multicloud \
--enable_all \
--ca citadel \
--ca_cert CA_CERT_FILE_PATH \
--ca_key CA_KEY_FILE_PATH \
--root_cert ROOT_CERT_FILE_PATH \
--cert_chain CERT_CHAIN_FILE_PATH \
--option stackdriver \
--option attached-cluster
HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer autorise l'enregistrement avec GKE Hub.
Remarque : Pour autoriser l'enregistrement avec GKE Hub, vous devez utiliser cette option, car les clusters AKS ne disposent pas de point de terminaison de découverte OIDC routable publiquement pour le jeton de compte de service Kubernetes.
--fleet_id : ID du projet du projet hôte du parc .--kubeconfig : chemin d'accès complet au fichier kubeconfig .
La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
--output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp.
Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.--platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
--enable_all
Accorder les autorisations IAM requises.
Activer les API Google requises.
Définir un libellé sur le cluster qui identifie le réseau maillé.
Enregistrer le cluster dans le parc si ce n'est déjà fait.
-ca citadel : utiliser l'autorité de certification Istio comme autorité de certification.--ca_cert : le certificat intermédiaire--ca_key : la clé du certificat intermédiaire--root_cert : le certificat racine--cert_chain : la chaîne de certificats--option stackdriver active l'option Stackdriver. Notez que vous pouvez également activer Stackdriver et Prometheus en utilisant --option prometheus-and-stackdriver.--option stackdriver Redéfinit l'utilitaire de signature par défaut sur istiod.
Installer avec des fonctionnalités facultatives
Un fichier de superposition est un fichier YAML contenant une ressource personnalisée IstioOperator que vous transmettez à asmcli pour configurer le plan de contrôle. Vous pouvez ignorer la configuration par défaut du plan de contrôle et activer une fonctionnalité facultative en transmettant le fichier YAML à asmcli. Vous pouvez effectuer plusieurs couches de superpositions. Chaque fichier de superposition remplace la configuration dans les couches précédentes. Nous vous conseillons d'enregistrer les fichiers superposés dans votre système de contrôle des versions.
Il existe deux options pour activer les fonctionnalités facultatives : --option--custom_overlay
Utilisez --option si vous n'avez pas besoin de modifier le fichier de superposition. Avec cette méthode, asmcli extrait pour vous le fichier du dépôt GitHub .
Utilisez --custom_overlay lorsque vous devez personnaliser le fichier de superposition.
Pour en savoir plus, consultez la page Activer des fonctionnalités facultatives sur le plan de contrôle au sein du cluster .
Exécutez les commandes suivantes sur GKE sur VMware, Google Distributed Cloud Virtual pour Bare Metal, GKE sur AWS, GKE sur Azure, Amazon EKS ou Microsoft AKS. Saisissez vos valeurs dans les espaces réservés fournis.
Définissez le contexte actuel sur votre cluster d'utilisateur :
kubectl config use-context CLUSTER_NAME
Exécutez asmcli install pour installer le plan de contrôle avec une fonctionnalité facultative. Pour ajouter plusieurs fichiers, spécifiez --custom_overlay et le nom du fichier, par exemple : --custom_overlayoverlay_file1.yaml
--custom_overlay overlay_file2.yaml --custom_overlay overlay_file3.yaml
./asmcli install \
--fleet_id FLEET_PROJECT_ID \
--kubeconfig KUBECONFIG_FILE \
--output_dir DIR_PATH \
--platform multicloud \
--enable_all \
--ca mesh_ca \
--custom_overlay OVERLAY_FILE
--fleet_id : ID du projet du projet hôte du parc .--kubeconfig : chemin d'accès complet au fichier kubeconfig .
La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
--output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp.
Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.--platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
--enable_all
Accorder les autorisations IAM requises.
Activer les API Google requises.
Définir un libellé sur le cluster qui identifie le réseau maillé.
Enregistrer le cluster dans le parc si ce n'est déjà fait.
--ca mesh_ca Utilisez l'autorité de certification Cloud Service Mesh comme autorité de certification. Notez que asmcli configure l'autorité de certification Cloud Service Mesh pour utiliser l'identité de charge de travail du parc .--custom_overlay : spécifier le nom du fichier de superposition.
Installer les passerelles
Cloud Service Mesh vous permet de déployer et de gérer des passerelles dans le cadre de votre maillage de services. Une passerelle décrit un équilibreur de charge fonctionnant à la périphérie du réseau maillé recevant des connexions HTTP/TCP entrantes ou sortantes. Les passerelles sont des proxys Envoy qui vous permettent de contrôler avec précision le trafic entrant et sortant du réseau maillé.
Créez un espace de noms pour la passerelle d'entrée si vous n'en possédez pas déjà un.
Les passerelles sont des charges de travail d'utilisateur. Il est déconseillé de les déployer dans l'espace de noms du plan de contrôle. Remplacez GATEWAY_NAMESPACE
kubectl create namespace GATEWAY_NAMESPACE
Résultat attendu :
namespace/GATEWAY_NAMESPACE created
Activez l'injection automatique sur la passerelle. Les étapes requises varient selon que vous souhaitez utiliser les libellés d'injection par défaut (par exemple, istio-injection=enabled) ou le libellé de révision sur l'espace de noms de la passerelle. Le tag de révision et le libellé de révision par défaut sont utilisés par le webhook d'injecteur side-car pour associer les proxys injectés à une révision spécifique du plan de contrôle.
Libellés d'injection par défaut Remarque :Si vous avez utilisé une révision de tag par défaut pour activer l'injection automatique sur la passerelle, vérifiez que le tag par défaut existe dans le répertoire que vous avez spécifié dans --output_dir et pointe vers la révision récemment installée. Exécutez la commande istioctl tag list. Appliquez les libellés d'injection par défaut à l'espace de noms.
kubectl label namespace GATEWAY_NAMESPACE istio-injection=enabled istio.io/rev-
Libellé de révision
Exécutez la commande suivante pour localiser le libellé de révision sur istiod :
kubectl get deploy -n istio-system -l app=istiod -o \
"jsonpath={.items[*].metadata.labels['istio\.io/rev']}{'\n'}"
La commande génère le libellé de révision qui correspond à la version de Cloud Service Mesh, par exemple:
Appliquez l'étiquette de révision à l'espace de noms. Dans la commande suivante, REVISION istiod que vous avez notée à l'étape précédente.
kubectl label namespace GATEWAY_NAMESPACE \
istio.io/rev=REVISION --overwrite
Résultat attendu :
namespace/GATEWAY_NAMESPACE labeled
Vous pouvez ignorer le message "istio.io/rev" not found dans le résultat. Cela signifie que l'espace de noms ne portait pas auparavant le libellé istio.io/rev, ce qui est normal dans les nouvelles installations de Cloud Service Mesh ou les nouveaux déploiements. Étant donné que l'injection automatique échoue si un espace de noms comporte à la fois les étiquettes istio.io/rev et istio-injection, toutes les commandes kubectl label de la documentation de Cloud Service Mesh spécifient explicitement les deux libellés.
Si l'espace de noms de la passerelle ne comporte pas de libellé, les pods istio-ingressgateway échouent avec une erreur ImagePullBackOff lorsque la passerelle tente d'extraire l'image auto. Cette image doit être remplacée par le webhook.
Téléchargez l'exemple de fichier de configuration .yaml de la passerelle d'entrée à partir du dépôt anthos-service-mesh-packages .
Appliquez l'exemple de configuration .yaml de la passerelle d'entrée tel quel ou modifiez-le selon vos besoins.
kubectl apply -n GATEWAY_NAMESPACE \
-f CONFIG_PATH /istio-ingressgateway
Résultat attendu :
deployment.apps/istio-ingressgateway created
poddisruptionbudget.policy/istio-ingressgateway created
horizontalpodautoscaler.autoscaling/istio-ingressgateway created
role.rbac.authorization.k8s.io/istio-ingressgateway created
rolebinding.rbac.authorization.k8s.io/istio-ingressgateway created
service/istio-ingressgateway created
serviceaccount/istio-ingressgateway created
Découvrez les bonnes pratiques liées aux passerelles .
Déployer et redéployer des charges de travail
Avertissement : Si vous installez des side-cars dans les pods d'application où la connectivité CA via une connexion directe n'est pas disponible (par exemple, en raison de pare-feu ou d'autres fonctionnalités restrictives), vous devez configurer la connectivité de l'autorité de certification via un proxy après avoir installé le plan de contrôle du cluster et avant de redéployer les charges de travail.
Cloud Service Mesh utilise des proxys side-car pour améliorer la sécurité, la fiabilité et l'observabilité du réseau. Avec Cloud Service Mesh, ces fonctions sont extraites du conteneur principal de l'application et mises en œuvre dans un proxy commun hors processus fourni sous la forme d'un conteneur distinct dans le même pod.
Votre installation n'est pas terminée tant que vous n'avez pas activé l'injection automatique du proxy side-car (injection automatique) et redémarré les pods pour toutes les charges de travail en cours d'exécution sur votre cluster avant l'installation de Cloud Service Mesh.
Pour activer l'injection automatique, ajoutez à vos espaces de noms les libellés d'injection par défaut libellé de révision istiod lors de l'installation de Cloud Service Mesh. Le tag de révision et le libellé de révision par défaut sont utilisés par le webhook d'injecteur side-car pour associer les side-cars injectés à une révision istiod. Après avoir ajouté le libellé, tous les pods existants dans l'espace de noms doivent être redémarrés pour que les sidecars soient injectés.
Avant de déployer de nouvelles charges de travail dans un nouvel espace de noms, veillez à configurer l'injection automatique afin que Cloud Service Mesh puisse surveiller et sécuriser le trafic.
Les étapes requises pour activer l'injection automatique varient selon que vous souhaitez utiliser les libellés d'injection par défaut ou le libellé de révision :
Libellés d'injection par défaut Remarque :Si vous avez utilisé une révision de tag par défaut pour activer l'injection automatique sur la passerelle, vérifiez que le tag par défaut existe dans le répertoire que vous avez spécifié dans --output_dir et pointe vers la révision récemment installée. Exécutez la commande DIR_PATH /istioctl tag list Dans la commande suivante, NAMESPACE
kubectl label namespace NAMESPACE istio-injection=enabled istio.io/rev-
Étant donné que les libellés d'injection par défaut injectent la révision vers laquelle le tag par défaut pointe, il n'est pas nécessaire de modifier les libellés des espaces de noms.
Libellé de révision
Exécutez la commande suivante pour localiser le libellé de révision sur istiod :
kubectl -n istio-system get pods -l app=istiod --show-labels
La sortie ressemble à ceci :
NAME READY STATUS RESTARTS AGE LABELS
istiod--5788d57586-bljj4 1/1 Running 0 23h app=istiod,istio.io/rev=,istio=istiod,pod-template-hash=5788d57586
istiod--5788d57586-vsklm 1/1 Running 1 23h app=istiod,istio.io/rev=,istio=istiod,pod-template-hash=5788d57586
Dans le résultat, sous la colonne LABELS, notez la valeur du libellé de révision istiod, qui suit le préfixe istio.io/rev=. Dans cet exemple, la valeur est
Appliquez le libellé de révision et supprimez le libellé istio-injection s'il existe. Dans la commande suivante, NAMESPACE REVISION
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
Vous pouvez ignorer le message "istio-injection not found" dans le résultat. Cela signifie que l'espace de noms ne portait pas auparavant le libellé istio-injection, ce qui est normal dans les nouvelles installations de Cloud Service Mesh ou les nouveaux déploiements. Étant donné que le comportement d'injection automatique n'est pas défini lorsqu'un espace de noms comporte à la fois le libellé istio-injection et le libellé de révision, toutes les commandes kubectl label de la documentation de Cloud Service Mesh garantissent explicitement qu'une seule est définie.
Si des charges de travail étaient en cours d'exécution sur votre cluster avant l'installation de Cloud Service Mesh, redémarrez les pods pour déclencher la réinjection.
La méthode de redémarrage des pods dépend de votre application et de l'environnement dans lequel se trouve le cluster. Par exemple, dans votre environnement de préproduction, vous pouvez simplement supprimer tous les pods, ce qui entraîne leur redémarrage. Toutefois, dans votre environnement de production, vous pouvez avoir un processus qui met en œuvre un déploiement bleu-vert afin de pouvoir redémarrer les pods en toute sécurité pour éviter toute interruption de trafic.
Vous pouvez exécuter kubectl pour effectuer un redémarrage progressif :
kubectl rollout restart deployment -n NAMESPACE
Étape suivante
