Version 1.9 :

Installation de plusieurs projets sur GKE

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.9.5

  • Mise à niveau de 1.8 or a 1.9 patch release vers Anthos Service Mesh 1.9.5. Les mises à niveau à partir de versions antérieures ne sont pas acceptées.

  • Migration du logiciel Open Source Istio 1.8 or 1.9 vers Anthos Service Mesh 1.9.5. 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 couvrant 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 Cloud Console 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 :

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 Anthos 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 Anthos dans votre projet. Pour en savoir plus sur la tarification d'Anthos Service Mesh, consultez la page Tarifs.

  • Si vous êtes abonné à Anthos, assurez-vous d'activer l'API Anthos.

    Activer l'API

  • Si vous n'êtes pas abonné à Anthos, vous pouvez toujours installer Anthos Service Mesh, mais certains éléments d'UI et certaines fonctionnalités de Google Cloud Console ne sont disponibles que pour les abonnés Anthos. 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 Anthos et Anthos Service Mesh.

  • Si vous avez activé l'API Anthos, mais que vous souhaitez utiliser Anthos Service Mesh en tant que service autonome, désactivez l'API Anthos.

Exigences

  • É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 le istio-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.9.5. 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, vous pouvez utiliser l'autorité de certification Anthos Service Mesh (Mesh CA) ou Istio CA (anciennement Citadel) en tant qu'autorité de certification (CA) pour émettre des certificats TLS mutuels (mTLS).

Nous vous recommandons généralement 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.

Toutefois, vous pouvez envisager d'utiliser Istio CA dans les cas suivants :

  • Si vous disposez d'une autorité de certification personnalisée.
  • Si vous migrez depuis Istio.

    Si vous choisissez Istio CA, 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 d'Istio CA à 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.