Préparer la configuration avec l'API Gateway GKE
La configuration décrite dans ce document est compatible avec les clients Preview, mais nous ne la recommandons pas aux nouveaux utilisateurs de Cloud Service Mesh. Pour en savoir plus, consultez la présentation de Cloud Service Mesh.
Ce guide explique comment préparer l'environnement pour l'utilisation de l'API Gateway Google Kubernetes Engine avec Cloud Service Mesh. En règle générale, vous devez effectuer les tâches suivantes :
- Activer les services Google Cloud requis
- Déployer un cluster GKE
- Configurer les autorisations IAM
- Installer les définitions de ressources personnalisées (CRD, Custom Resource Definitions)
- Enregistrer le cluster dans un parc
- [Facultatif] Activez les services multicluster (détection de services multicluster).
- Activer le maillage de services
Si vous n'utilisez pas GKE, utilisez les API de routage de services et créez une ressource Mesh
.
Avant de commencer
Assurez-vous que les composants de votre déploiement répondent aux exigences suivantes :
- La version de GKE doit être 1.20 ou ultérieure
- Seuls les plans de données utilisant l'API xDS version 3 ou ultérieure sont compatibles.
- Version Envoy minimale de 1.20.0
- Version minimale du générateur d'amorçage gRPC v0.14.0
- Les clusters GKE doivent être en mode VPC natif (adresses IP d'alias).
- Les clusters Kubernetes autogérés sur Compute Engine, et non sur GKE, ne sont pas compatibles.
- Toutes les restrictions supplémentaires répertoriées pour la fonctionnalité Gateway sur GKE s'appliquent à l'intégration de Cloud Service Mesh à l'API Gateway GKE.
- Le compte de service de vos nœuds et pods GKE doit être autorisé à accéder à l'API Traffic Director. Pour plus d'informations sur les autorisations requises, consultez la section Activer le compte de service pour accéder à l'API Traffic Director.
- Les limites de quota d'utilisation des ressources et de services de backend par projet s'appliquent.
Activez les services requis de l'API Google Cloud :
Exécutez la commande suivante pour activer les API requises, si elles ne sont pas déjà activées dans votre projet :
gcloud services enable --project=PROJECT_ID \ container.googleapis.com \ gkehub.googleapis.com \ multiclusteringress.googleapis.com \ trafficdirector.googleapis.com \ networkservices.googleapis.com
Si vous prévoyez d'inclure plusieurs clusters dans votre parc, activez l'API
multiclusterservicediscovery
:gcloud services enable --project=PROJECT_ID \ multiclusterservicediscovery.googleapis.com
Déployer un cluster GKE
Suivez ces instructions pour déployer un cluster GKE.
Créez un cluster GKE appelé
gke-1
dans la zoneus-west1-a
:gcloud container clusters create gke-1 \ --zone=us-west1-a \ --enable-ip-alias \ --workload-pool=PROJECT_ID.svc.id.goog \ --scopes=https://www.googleapis.com/auth/cloud-platform \ --enable-mesh-certificates \ --release-channel=regular \ --project=PROJECT_ID
--enable-ip-alias
: cette option crée un cluster de VPC natif et rend les adresses IP des pods routables sur le réseau VPC.--workload-pool
: cette option permet à votre cluster de participer au pool Workload Identity du projet.--scopes
: cette option spécifie les champs d'application OAuth attribués aux nœuds du cluster.--release-channel
: cette option désigne le canalregular
.--enable-mesh-certificates
: cette option active la fonctionnalité d'authentification mTLS automatique de Cloud Service Mesh si elle devient disponible par la suite.
Obtenez les identifiants du cluster :
gcloud container clusters get-credentials gke-1 --zone=us-west1-a
Renommez le contexte du cluster :
kubectl config rename-context gke_PROJECT_ID_us-west1-a_gke-1 gke-1
Configurer les autorisations IAM pour le plan de données
Pour ce déploiement de démonstration, vous attribuez le rôle de client Cloud Service Mesh roles/trafficdirector.client
à tous les utilisateurs authentifiés, y compris tous les comptes de service, du cluster GKE. Ce rôle IAM est requis pour autoriser les clients Cloud Service Mesh du plan de données, tels que les Envoy, à recevoir la configuration de Cloud Service Mesh.
Si vous ne souhaitez pas attribuer le rôle client à tous les utilisateurs authentifiés et préférez le limiter aux comptes de service, consultez le guide d'utilisation de Workload Identity sur GKE pour configurer un compte de service Kubernetes spécialisé avec le rôle roles/trafficdirector.client
pour vos services.
Attribuez le rôle
client
aux comptes de service :gcloud projects add-iam-policy-binding PROJECT_ID \ --member "group:PROJECT_ID.svc.id.goog:/allAuthenticatedUsers/" \ --role "roles/trafficdirector.client"
Installer les définitions de ressources personnalisées requises
Installez les définitions de ressources personnalisées (CRD) requises pour utiliser l'API Gateway avec Cloud Service Mesh:
kubectl apply -k "github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref=v0.6.0"
kubectl kustomize "https://github.com/GoogleCloudPlatform/gke-networking-recipes.git/gateway-api/config/mesh/crd" \ | kubectl apply -f -
Vérifiez que les CRD requises sont installées automatiquement dans le cluster en exécutant la commande suivante :
kubectl get crds
Le résultat répertorie les CRD suivantes et d'autres éléments qui ne sont pas liés à l'API Gateway, avec des dates de création différentes :
NAME CREATED AT gatewayclasses.gateway.networking.k8s.io 2023-08-08T05:29:03Z gateways.gateway.networking.k8s.io 2023-08-08T05:29:03Z grpcroutes.gateway.networking.k8s.io 2023-08-08T05:29:03Z httproutes.gateway.networking.k8s.io 2023-08-08T05:29:03Z referencegrants.gateway.networking.k8s.io 2023-08-08T05:29:04Z tcproutes.gateway.networking.k8s.io 2023-08-08T05:29:04Z tdgrpcroutes.net.gke.io 2023-08-08T05:29:23Z tdmeshes.net.gke.io 2023-08-08T05:29:23Z tlsroutes.gateway.networking.k8s.io 2023-08-08T05:29:05Z udproutes.gateway.networking.k8s.io 2023-08-08T05:29:05Z
Les ressources personnalisées tdmeshes.net.gke.io
et tdgrpcroutes.net.gke.io
sont installées à l'étape précédente.
Les CRD faisant partie du groupe d'API net.gke.io
sont spécifiques à GKE. Ces ressources ne font pas partie de la mise en œuvre de l'API Gateway Open Source, qui se trouve dans le groupe d'API networking.k8s.io
.
Enregistrer le cluster dans un parc
Une fois le cluster créé, vous devez l'enregistrer dans un parc. L'enregistrement de votre cluster dans un parc vous permet d'activer de manière sélective des fonctionnalités sur le cluster enregistré.
Enregistrez le cluster dans le parc :
gcloud container hub memberships register gke-1 \ --gke-cluster us-west1-a/gke-1 \ --location global \ --project=PROJECT_ID
Vérifiez que le cluster est enregistré auprès du parc :
gcloud container hub memberships list --project=PROJECT_ID
Le résultat ressemble à ce qui suit :
NAME EXTERNAL_ID gke-1 657e835d-3b6b-4bc5-9283-99d2da8c2e1b
(Facultatif) Activer la détection de services multiclusters
La fonctionnalité de détection de services multiclusters vous permet d'exporter des services locaux de clusters vers tous les clusters enregistrés dans le parc. Cette étape est facultative si vous ne prévoyez pas d'inclure plusieurs clusters dans votre parc.
Activez la détection de services multiclusters:
gcloud container hub multi-cluster-services enable \ --project PROJECT_ID
Attribuez le rôle IAM (Identity and Access Management) requis pour la détection de services multiclusters:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:PROJECT_ID.svc.id.goog[gke-mcs/gke-mcs-importer]" \ --role "roles/compute.networkViewer"
Vérifiez que la détection de services multiclusters est activée pour le cluster enregistré. L'affichage de tous les clusters peut prendre plusieurs minutes :
gcloud container hub multi-cluster-services describe --project=PROJECT_ID
Les abonnements pour
gke-1
, semblables aux suivants, doivent s'afficher :createTime: '2021-04-02T19:34:57.832055223Z' membershipStates projects/PROJECT_NUM/locations/global/memberships/gke-1: state: code: OK description: Firewall successfully updated updateTime: '2021-05-27T11:03:07.770208064Z' name: projects/PROJECT_NUM/locations/global/features/multiclusterservicediscovery resourceState: state: ACTIVE spec: {} updateTime: '2021-04-02T19:34:58.983512446Z'
Activer le maillage de services Cloud Service Mesh sur GKE
Dans cette section, vous allez activer le maillage de services.
Activez le maillage de services GKE Cloud Service Mesh sur le cluster que vous avez enregistré auprès de votre parc:
gcloud container hub ingress enable \ --config-membership=projects/PROJECT_ID/locations/global/memberships/gke-1 \ --project=PROJECT_ID
Vérifiez que la fonctionnalité est activée :
gcloud container hub ingress describe --project=PROJECT_ID
La sortie obtenue doit ressembler à ceci :
createTime: '2021-05-26T13:27:37.460383111Z' membershipStates: projects/PROJECT_NUM/locations/global/memberships/gke-1: state: code: OK updateTime: '2021-05-27T15:08:19.397896080Z' resourceState: state: ACTIVE spec: multiclusteringress: configMembership: projects/PROJECT_ID/locations/global/memberships/gke-1 state: state: code: OK description: Ready to use updateTime: '2021-05-26T13:27:37.899549111Z' updateTime: '2021-05-27T15:08:19.397895711Z'
Attribuez les rôles IAM (Identity and Access Management) suivants, requis par le contrôleur de l'API Gateway :
- roles/container.developer : ce rôle permet au contrôleur de gérer les ressources Kubernetes au sein du cluster.
- roles/compute.networkAdmin : ce rôle permet au contrôleur de gérer les configurations de maillage de services Cloud Service Mesh.
export PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format="value (projectNumber)") gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:service-${PROJECT_NUMBER}@gcp-sa-multiclusteringress.iam.gserviceaccount.com" \ --role "roles/container.developer"
gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:service-${PROJECT_NUMBER}@gcp-sa-multiclusteringress.iam.gserviceaccount.com" \ --role "roles/compute.networkAdmin"
Étape suivante
Pour configurer un exemple de déploiement, consultez les guides suivants :
- Configurer un maillage de services side-car Envoy
- Configurer un maillage de services gRPC sans proxy
- Configurer un maillage de services multiclusters