Prérequis pour Cloud Service Mesh intégré au cluster

Cette page décrit les conditions préalables et la configuration requise pour installer Cloud Service Mesh dans un cluster pour les charges de travail Kubernetes hors Google Cloud, telles que les conditions requises pour les clusters, les exigences relatives au parc et les exigences générales.

Projet Cloud

Avant de commencer :

Conditions générales requises

  • 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 souhaitez modifier les limites de ressources par défaut pour le conteneur side-car istio-proxy, les nouvelles valeurs doivent être supérieures aux valeurs par défaut afin d'éviter -Événements de mémoire (OOM).

  • Un projet Google Cloud ne peut être associé qu'à un seul maillage.

Configuration requise pour les clusters

  • Assurez-vous que le cluster d'utilisateur sur lequel vous installez Cloud Service Mesh dispose au moins de quatre processeurs virtuels, de 15 Go de mémoire et de quatre nœuds.

  • Vérifiez que la version de votre cluster est répertoriée dans la section Plates-formes compatibles.

  • Assurez-vous que la machine cliente à partir de laquelle vous installez Cloud Service Mesh dispose d'une connectivité réseau au serveur d'API.

  • Si vous déployez des side-cars dans les pods d'application où la connectivité directe aux services CA (par exemple, meshca.googleapis.com etprivateca.googleapis.com) n'est pas disponible, vous devez configurer un proxy HTTPS CONNECT explicite.

  • Pour les clusters publics dont les règles de pare-feu de sortie sont définies et bloquent les règles implicites, assurez-vous d'avoir configuré les règles HTTP/HTTPS et DNS pour accéder aux API Google publiques.

Exigences concernant le parc

Tous les clusters doivent être enregistrés dans un parc et Workload Identity du parc doit être activé. Vous pouvez configurer les clusters vous-même ou laisser asmcli enregistrer les clusters tant qu'ils répondent aux exigences suivantes :

  • Clusters GKE en dehors de Google Cloud : (s'applique à Cloud Service Mesh en cluster) Google Distributed Cloud (logiciel uniquement) pour VMware, Google Distributed Cloud (logiciel uniquement) pour Bare Metal, GKE sur AWS (obsolète) et GKE sur Azure (obsolète) sont automatiquement enregistrés dans votre parc de projets au moment de la création du cluster. Depuis GKE Enterprise 1.8, tous ces types de clusters activent automatiquement Workload Identity du parc lorsqu'ils sont enregistrés. Les clusters enregistrés existants sont mis à jour pour utiliser Workload Identity de parc lorsqu'ils sont mis à niveau vers GKE Enterprise 1.8.
  • Clusters Amazon EKS (obsolète) : (s'applique à Cloud Service Mesh dans le cluster) Le cluster doit disposer d'un fournisseur d'identité IAM OIDC public. Suivez les instructions de la page Créer un fournisseur IAM OIDC pour le cluster pour vérifier si un fournisseur existe et en créer un si nécessaire.

Lorsque vous exécutez asmcli install, vous spécifiez l'ID du projet hôte du parc. asmcli enregistre le cluster si ce n'est pas déjà fait.

À partir de la version 1.25 de asmcli, toutes les installations et mises à niveau de Cloud Service Mesh dans le cluster provisionnent le contrôleur de service canonique géré. Pour cela, la fonctionnalité Cloud Service Mesh doit être activée sur votre projet de parc. Pour permettre à asmcli d'activer automatiquement cette fonctionnalité lors de l'installation ou de la mise à niveau, vous devez exécuter la commande asmcli avec l'option --enable_gcp_components.

Étape suivante