Ce guide explique comment installer Anthos Service Mesh pour un réseau maillé contenant plusieurs clusters Google Kubernetes Engine (GKE) situés dans différents projets Google Cloud.
Vous pouvez utiliser ce guide pour les cas d'utilisation suivants :
Nouvelles installations d'Anthos Service Mesh 1.10.6
Mise à niveau de 1.9 or a 1.10 patch release vers Anthos Service Mesh 1.10.6. Les mises à niveau à partir de versions antérieures ne sont pas acceptées.
Migration du logiciel Open Source Istio vers Anthos Service Mesh 1.10.6. Si vous disposez d'une version antérieure d'Istio, vous devez d'abord la mettre à niveau avant de migrer vers Anthos Service Mesh. Si vous devez effectuer une mise à niveau, accédez à la page Mettre à niveau Istio dans la version d'Istio applicable. Notez que la mise à niveau d'Istio vers plusieurs versions mineures (par exemple, 1.6.x vers 1.8.x) en une seule étape n'est pas officiellement testée ni recommandée. Pour planifier votre migration, veillez à consulter la page Préparer la migration depuis Istio.
Certaines fonctionnalités ne sont pas disponibles pour un maillage de services comportant des clusters hébergés dans différents projets. En particulier, les tableaux de bord Anthos Service Mesh de la console Google Cloud ne sont actuellement pas disponibles. Toutefois, vous pouvez toujours consulter les journaux dans Cloud Logging et les métriques dans Cloud Monitoring pour chaque projet.
Avant de commencer
Ce guide suppose que vous disposez des éléments suivants :
- Un projet Google Cloud.
- Un compte Cloud Billing
- Un cluster GKE répondant aux exigences.
Si vous effectuez une migration depuis Istio, veillez à consulter la page Préparer la migration depuis Istio.
Différences entre Anthos et Anthos Service Mesh
Anthos Service Mesh est disponible avec GKE Enterprise ou en tant que service autonome. Les API Google permettent de déterminer votre mode de facturation. Pour utiliser Anthos Service Mesh en tant que service autonome, n'activez pas l'API GKE Enterprise dans votre projet. Pour en savoir plus sur la tarification d'Anthos Service Mesh, consultez la page Tarifs.
Si vous êtes abonné à GKE Enterprise, veillez à activer l'API GKE Enterprise.
Si vous n'êtes pas abonné à GKE Enterprise, vous pouvez toujours installer Anthos Service Mesh, mais certains éléments d'interface utilisateur et fonctionnalités de la console Google Cloud ne sont disponibles que pour les abonnés GKE Enterprise. Pour en savoir plus sur ce qui est disponible pour les abonnés et les non-abonnés, consultez la section Différences entre les interfaces utilisateur de GKE Enterprise et d'Anthos Service Mesh.
Si vous avez activé l'API GKE Enterprise, mais que vous souhaitez utiliser Anthos Service Mesh en tant que service autonome, désactivez l'API GKE Enterprise.
Conditions requises
Étant donné que vos clusters se trouvent dans des projets différents, ils doivent se trouver dans un cloud privé virtuel (VPC) partagé. Pour en savoir plus sur la configuration des clusters, consultez la page Configurer des clusters avec un VPC partagé.
Votre cluster GKE doit répondre aux exigences suivantes :
Le cluster GKE doit être standard, car les clusters Autopilot ont des limites de webhooks qui n'autorisent pas
MutatingWebhookConfiguration
pour leistio-sidecar-injector
.Type de machine comportant au moins quatre processeurs virtuels, par exemple
e2-standard-4
. Si le type de machine de votre cluster ne comporte pas au moins quatre processeurs virtuels, modifiez le type de machine comme décrit dans la section Migrer des charges de travail vers différents types de machines.Le nombre minimal de nœuds dépend du type de machine. Anthos Service Mesh nécessite au moins huit processeurs virtuels. Si le type de machine comporte quatre processeurs virtuels, votre cluster doit comporter au moins deux nœuds. Si le type de machine comporte huit processeurs virtuels, le cluster n'a besoin que d'un nœud. Si vous devez ajouter des nœuds, consultez la page Redimensionner un cluster.
Pour préparer votre cluster avant d'installer Anthos Service Mesh, activez Workload Identity. Workload Identity est la méthode recommandée pour appeler les API Google. L'activation de Workload Identity modifie la manière dont les appels de vos charges de travail vers les API Google sont sécurisés, comme décrit dans la section Limites de Workload Identity.
Nous vous recommandons d'inscrire le cluster dans une version disponible, mais cela n'est pas obligatoire. Nous vous recommandons de vous inscrire à la version disponible standard, car d'autres versions peuvent être basées sur une version de GKE non compatible avec Anthos Service Mesh 1.10.6. Pour plus d'informations, consultez la section Environnements compatibles. Suivez les instructions de la page Enregistrer un cluster existant dans une version disponible si vous disposez d'une version GKE statique.
Pour être inclus dans le maillage de services, les ports de service doivent être nommés et le nom de protocole du port doit respecter la syntaxe suivante :
name: protocol[-suffix]
, où les crochets indiquent un suffixe facultatif qui doit commencer par un tiret. Pour plus d'informations, consultez la section Nommer les ports de service.Si vous installez Anthos Service Mesh sur un cluster privé, vous devez ouvrir le port 15017 dans le pare-feu pour que le webhook utilisé avec l'injection side-car automatique fonctionne correctement. Pour en savoir plus, consultez la page Ouvrir un port sur un cluster privé.
Si vous avez créé un périmètre de service dans votre organisation, vous devrez peut-être ajouter le service Mesh CA au périmètre. Pour en savoir plus, consultez la section Ajouter l'autorité de certification Mesh CA à un périmètre de service.
Un projet Google Cloud ne peut être associé qu'à un seul réseau maillé.
Si vous souhaitez réduire les limites de ressources par défaut pour le conteneur side-car
istio-proxy
, de nouvelles limites devraient autoriser une quantité de mémoire suffisante pour éviter les événements de mémoire saturée (OOM, Out Of Memory).
Choisir une autorité de certification
Pour les nouvelles installations et les migrations à partir d'Istio, vous pouvez utiliser l'autorité de certification Anthos Service Mesh (Mesh CA) ou Citadel d'Istio en tant qu'autorité de certification (CA) pour émettre des certificats TLS mutuels (mTLS).
À moins que vous n'ayez besoin d'une autorité de certification personnalisée, telle que HashiCorp Vault, nous vous recommandons d'utiliser Mesh CA pour les raisons suivantes :
- Mesh CA est un service hautement fiable et évolutif, optimisé pour les charges de travail à scaling dynamique sur Google Cloud.
- Avec Mesh CA, Google gère la sécurité et la disponibilité du backend CA.
- Mesh CA vous permet de dépendre d'une seule racine de confiance dans les clusters.
Si vous effectuez une migration depuis Istio, vous pouvez choisir de migrer vers Mesh CA ou de continuer à utiliser Citadel CA d'Istio. Si vous choisissez Citadel, il n'y a presque pas d'interruption car le trafic mTLS n'est pas interrompu pendant la migration. Si vous choisissez Mesh CA, vous devez planifier un temps d'arrêt pour la migration, car la racine de confiance passe de Citadel à Mesh CA. Pour migrer vers la racine de confiance de Mesh CA, vous devez redémarrer l'ensemble des pods dans tous les espaces de noms. Pendant ce processus, les anciens pods ne peuvent pas établir de connexions mTLS avec les nouveaux pods.
Les certificats émis par l'autorité de certification d'Anthos Service Mesh (Mesh CA) incluent les données suivantes sur les services de votre application :
- L'ID de projet Google Cloud
- L'espace de noms GKE
- Le nom du compte de service GKE
Enregistrer votre cluster
Bien que cela soit facultatif, nous vous recommandons d'enregistrer votre cluster dans leparc de votre projet (anciennement connu sous le nom d'Environ). Un parc vous permet d'organiser les clusters pour faciliter la gestion multicluster. En enregistrant vos clusters dans un parc, vous pouvez regrouper des services et d'autres infrastructures selon vos besoins pour appliquer des stratégies cohérentes. Si vos clusters se trouvent dans différents projets, vous devez les enregistrer auprès du projet hôte du parc, plutôt que du projet dans lequel ils ont été créés. Pour plus de détails sur l'enregistrement de votre cluster, consultez la section Enregistrer des clusters dans le parc.
Le concept de projet hôte du parc est important lorsque vous configurez votre cluster pour activer les options requises par Anthos Service Mesh. Le maillage de services de votre cluster est identifié par une valeur basée sur un numéro de projet. Lorsque vous configurez des clusters de différents projets, vous devez utiliser le numéro du projet hôte du parc.