Conditions préalables à l'utilisation de Cloud Service Mesh dans le cluster
{version_1.0.1 dCette page décrit les conditions préalables et les exigences liées à l'installation de Cloud Service Mesh dans le cluster pour les charges de travail Kubernetes hors de Google Cloud, telles que les licences GKE Enterprise, les exigences pour les clusters, les exigences concernant le parc et les exigences générales.
Cloud Identity,
Avant de commencer :
Vérifiez que la facturation est activée pour votre projet.
Licences GKE Enterprise
Pour installer Cloud Service Mesh sur site, sur GKE sur AWS, sur Amazon EKS, sur GKE sur Azure ou sur Microsoft AKS, vous devez être un client GKE Enterprise. Cloud Service Mesh est déjà inclus dans les tarifs de GKE Enterprise et ne sont pas facturés séparément pour les clients GKE Enterprise. Pour en savoir plus, consultez le guide des tarifs de GKE Enterprise.
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 avez créé un périmètre de service dans votre organisation, vous devrez peut-être y ajouter le service de l'autorité de certification Cloud Service Mesh. Pour en savoir plus, consultez la section Ajouter l'autorité de certification Cloud Service Mesh à un périmètre 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 réseau maillé.
Configuration requise pour les clusters
Assurez-vous que le cluster d'utilisateur sur lequel vous installez Cloud Service Mesh dispose d'au moins quatre processeurs virtuels, 15 Go de mémoire et 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.cometprivateca.googleapis.com) n'est pas disponible, vous devez configurer un proxy HTTPSCONNECTexplicite.Pour les clusters publics sur lesquels des règles de pare-feu de sortie bloquent les règles implicites, assurez-vous d'avoir configuré des 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 l'identité des charges de travail du parc doit être activée. 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 au maillage de services Cloud Service intégré au cluster) : GKE sur VMware, GKE sur Bare Metal, GKE sur AWS et GKE sur Azure 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 lors de leur enregistrement. Les clusters enregistrés existants sont mis à jour pour utiliser la fonctionnalité Workload Identity du parc lorsqu'ils sont mis à niveau vers GKE Enterprise 1.8.
- Clusters Amazon EKS : (s'applique au maillage Cloud Service Mesh intégré au cluster) : le cluster doit disposer d'un fournisseur d'identité IAM OIDC public. Suivez les instructions de la section Créer un fournisseur OIDC IAM pour votre 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.