Configurer Ingress multicluster

Cette page explique comment acheminer le trafic entre plusieurs clusters Google Kubernetes Engine (GKE) dans différentes régions à l'aide de Multi Cluster Ingress, avec un exemple utilisant deux clusters.

Pour consulter une comparaison détaillée entre le service Multi Cluster Ingress (MCI), la passerelle multicluster (MCG) et un équilibreur de charge avec des groupes de points de terminaison du réseau autonomes (LB avec NEG autonomes), consultez la page Choisir votre API d'équilibrage de charge multicluster pour GKE.

Pour en savoir plus sur le déploiement de Multi Cluster Ingress, consultez la sectionDéployer Ingress dans les clusters.

Ces étapes nécessitent des privilèges élevés et doivent être effectuées par un administrateur GKE.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
    • Activer l'API Google Kubernetes Engine
  • Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.

Conditions requises et limites

Multi Cluster Ingress présente les exigences suivantes :

  • Google Cloud CLI version 290.0.0 et ultérieure.

Si vous utilisez des clusters en mode standard, assurez-vous de remplir les conditions suivantes. Les clusters Autopilot répondent déjà à ces exigences.

Multi Cluster Ingress présente les limites suivantes :

  • La compatibilité n'est assurée qu'avec un équilibreur de charge d'application externe.
  • Ne créez pas d'équilibreurs de charge Compute Engine qui ne sont pas gérés par Multi Cluster Ingress, en les définissant dans le même projet et avec le préfixe mci-, car ils seront supprimés. Google Cloud utilise le préfixe mci-[6 char hash] pour gérer les ressources Compute Engine déployées par Multi Cluster Ingress.
  • La configuration du protocole HTTPS nécessite une adresse IP statique pré-allouée. HTTPS n'est pas compatible avec les adresses IP éphémères.

Présentation

Dans cet exercice, vous allez effectuer les tâches suivantes :

  1. Sélectionner la tarification que vous souhaitez utiliser.
  2. Déployer des clusters.
  3. Configurer les identifiants du cluster.
  4. Enregistrez les clusters dans un parc.
  5. Spécifier un cluster de configuration. Ce cluster peut être un plan de contrôle dédié ou exécuter d'autres charges de travail.

Le diagramme suivant montre à quoi ressemblera votre environnement une fois l'exercice terminé :

Topologie de cluster montrant les relations entre les régions, le parc et le projet

Dans le schéma, il existe deux clusters GKE nommés gke-us et gke-eu dans les régions europe-west1 et us-central1. Les clusters sont enregistrés dans un parc de manière à ce que Multi Cluster Ingress puisse les reconnaître. Un parc vous permet de regrouper et de normaliser logiquement des clusters GKE, ce qui facilite l'administration de l'infrastructure et permet d'utiliser des fonctionnalités multicluster telles que Multi Cluster Ingress. Pour en savoir plus sur les avantages des parcs et leur création, consultez la documentation sur la gestion des parcs.

Sélectionner des tarifs

Si Multi Cluster Ingress est la seule fonctionnalité GKE Enterprise que vous utilisez, nous vous recommandons d'utiliser une tarification autonome. Si votre projet utilise d'autres composants ou fonctionnalités GKE Enterprise sur Google Cloud, vous devez activer l'intégralité de la plate-forme GKE Enterprise. Cela vous permet d'utiliser toutes les fonctionnalités de GKE Enterprise à un tarif unique par processeur virtuel.

Les API que vous devez activer dépendent de la tarification Multi Cluster Ingress que vous utilisez.

  • Si l'API GKE Enterprise (anthos.googleapis.com) est activée, votre projet est facturé en fonction du nombre de processeurs virtuels du cluster et des tarifs de GKE Enterprise.
  • Si l'API GKE Enterprise est désactivée, votre projet est facturé en fonction du nombre de pods Multi Cluster Ingress de backend dans votre projet.

Vous pouvez modifier le modèle de facturation de Multi Cluster Ingress pour passer de la facturation autonome à l'utilisation de GKE Enterprise ou inversement, à tout moment et sans que cela n'affecte les ressources ou le trafic de Multi Cluster Ingress.

Tarification autonome

Pour activer la tarification autonome, procédez comme suit :

  1. Vérifiez que l'API GKE Enterprise est désactivée dans votre projet:

    gcloud services list --project=PROJECT_ID | grep anthos.googleapis.com

    Remplacez PROJECT_ID par l'ID de projet dans lequel les clusters GKE sont exécutés.

    Si le résultat est une réponse vide, l'API GKE Enterprise est désactivée dans votre projet et toutes les ressources d'entrée multicluster sont facturées selon une tarification autonome.

  2. Activez les API requises dans votre projet :

    gcloud services enable \
    multiclusteringress.googleapis.com \
    gkehub.googleapis.com \
    container.googleapis.com \
    multiclusterservicediscovery.googleapis.com \
    --project=PROJECT_ID

Tarifs de GKE Enterprise

Pour activer la tarification GKE Enterprise, activez les API requises dans votre projet :

gcloud services enable \
    anthos.googleapis.com \
    multiclusteringress.googleapis.com \
    gkehub.googleapis.com \
    container.googleapis.com \
    multiclusterservicediscovery.googleapis.com \
    --project=PROJECT_ID

Une fois l'API anthos.googleapis.com activée dans votre projet, tous les clusters enregistrés dans Connect sont facturés conformément aux tarifs de GKE Enterprise.

Déployer des clusters

Créez deux clusters GKE nommés gke-us et gke-eu dans les régions europe-west1 et us-central1.

Autopilot

  1. Créez le cluster gke-us dans la région us-central1 :

    gcloud container clusters create-auto gke-us \
    --region=us-central1 \
    --release-channel=stable \
    --project=PROJECT_ID

    Remplacez PROJECT_ID par l'ID de votre projet Google Cloud.

  2. Créez le cluster gke-eu dans la région europe-west1 :

    gcloud container clusters create-auto gke-eu \
    --region=europe-west1 \
    --release-channel=stable \
    --project=PROJECT_ID

Standard

Créez les deux clusters avec la fédération d'identité de charge de travail pour GKE activée.

  1. Créez le cluster gke-us dans la région us-central1 :

    gcloud container clusters create gke-us \
    --region=us-central1 \
    --enable-ip-alias \
    --workload-pool=PROJECT_ID.svc.id.goog \
    --release-channel=stable \
    --project=PROJECT_ID

    Remplacez PROJECT_ID par l'ID de votre projet Google Cloud.

  2. Créez le cluster gke-eu dans la région europe-west1 :

    gcloud container clusters create gke-eu \
    --region=europe-west1 \
    --enable-ip-alias \
    --workload-pool=PROJECT_ID.svc.id.goog \
    --release-channel=stable \
    --project=PROJECT_ID

Configurer les identifiants du cluster

Configurez les identifiants de vos clusters et renommez les contextes de clusters afin de faciliter le basculement entre les clusters lors du déploiement des ressources.

  1. Récupérez les identifiants de vos clusters :

    gcloud container clusters get-credentials gke-us \
    --region=us-central1 \
    --project=PROJECT_ID

gcloud container clusters get-credentials gke-eu \
    --region=europe-west1 \
    --project=PROJECT_ID

    Les identifiants sont stockés localement pour que vous puissiez utiliser votre client kubectl afin d'accéder aux serveurs d'API du cluster. Par défaut, un nom généré automatiquement est créé pour les identifiants.

  2. Renommez les contextes de cluster :

    kubectl config rename-context gke_PROJECT_ID_us-central1_gke-us gke-us
kubectl config rename-context gke_PROJECT_ID_europe-west1_gke-eu gke-eu

Enregistrer des clusters dans un parc

Enregistrez vos clusters dans le parc de votre projet comme suit.

  1. Enregistrez vos clusters :

    gcloud container fleet memberships register gke-us \
    --gke-cluster us-central1/gke-us \
    --enable-workload-identity \
    --project=PROJECT_ID

gcloud container fleet memberships register gke-eu \
    --gke-cluster europe-west1/gke-eu \
    --enable-workload-identity \
    --project=PROJECT_ID

  2. Vérifiez que vos clusters ont bien été enregistrés dans le parc :

    gcloud container fleet memberships list --project=PROJECT_ID

    Le résultat ressemble à ce qui suit :

    NAME                                  EXTERNAL_ID
gke-us                                0375c958-38af-11ea-abe9-42010a800191
gke-eu                                d3278b78-38ad-11ea-a846-42010a840114

Une fois vos clusters enregistrés, GKE déploie le pod gke-mcs-importer sur votre cluster.

Pour en savoir plus sur l'enregistrement de clusters, consultez la section Enregistrer un cluster GKE dans votre parc.

Spécifier un cluster de configuration

Le cluster de configuration est un cluster GKE que vous choisissez comme point de contrôle central pour Ingress parmi les clusters membres. Ce cluster doit déjà être enregistré dans le parc. Pour en savoir plus, consultez la section Conception du cluster de configuration.

Activez Multi Cluster Ingress et sélectionnez gke-us comme cluster de configuration :

gcloud container fleet ingress enable \
    --config-membership=gke-us \
    --location=us-central1 \
    --project=PROJECT_ID

L'enregistrement du cluster de configuration peut prendre jusqu'à 15 minutes. Le résultat ressemble à ce qui suit :

Waiting for Feature to be created...done.
Waiting for controller to start...done.

Le résultat renvoyé en cas d'échec ressemble à ce qui suit :

Waiting for controller to start...failed.
ERROR: (gcloud.container.fleet.ingress.enable) Controller did not start in 2 minutes. Please use the `describe` command to check Feature state for debugging information.

Si une erreur s'est produite à l'étape précédente, vérifiez l'état de la fonctionnalité :

gcloud container fleet ingress describe \
    --project=PROJECT_ID

Le résultat renvoyé en cas de succès ressemble à ce qui suit :

createTime: '2021-02-04T14:10:25.102919191Z'
membershipStates:
 projects/PROJECT_ID/locations/global/memberships/CLUSTER_NAME:
 state:
   code: ERROR
   description: '...is not a VPC-native GKE Cluster.'
   updateTime: '2021-08-10T13:58:50.298191306Z'
 projects/PROJECT_ID/locations/global/memberships/CLUSTER_NAME:
 state:
   code: OK
   updateTime: '2021-08-10T13:58:08.499505813Z'

Pour en savoir plus sur la résolution des erreurs avec Multi Cluster Ingress, consultez la section Dépannage et opérations.

Impact sur les clusters opérationnels

Vous pouvez activer en toute sécurité Multi Cluster Ingress à l'aide de gcloud container fleet ingress enable sur un cluster opérationnel, car cela n'entraîne aucun temps d'arrêt ni aucun impact sur le trafic du cluster.

VPC partagé

Vous pouvez déployer une ressource MultiClusterIngress pour les clusters d'un réseau VPC partagé, mais tous les clusters GKE de backend participants doivent faire partie du même projet. Il n'est pas possible d'avoir des clusters GKE dans différents projets en utilisant la même adresse IP virtuelle pour Cloud Load Balancing.

Dans les réseaux VPC non partagés, le contrôleur Multi Cluster Ingress gère les règles de pare-feu pour permettre la transmission des vérifications d'état de l'équilibreur de charge aux charges de travail de conteneurs.

Dans un réseau VPC partagé, un administrateur de projet hôte doit créer manuellement les règles de pare-feu pour le trafic de l'équilibreur de charge pour le compte du contrôleur Multi Cluster Ingress.

La commande suivante indique la règle de pare-feu que vous devez créer si vos clusters résident dans un réseau VPC partagé. Les plages sources correspondent aux plages utilisées par l'équilibreur de charge pour envoyer du trafic aux backends. Cette règle doit exister pour la durée de vie opérationnelle d'une ressource MultiClusterIngress.

Si vos clusters résident dans un réseau VPC partagé, créez la règle de pare-feu :

gcloud compute firewall-rules create FIREWALL_RULE_NAME \
    --project=HOST_PROJECT \
    --network=SHARED_VPC \
    --direction=INGRESS \
    --allow=tcp:0-65535 \
    --source-ranges=130.211.0.0/22,35.191.0.0/16

Remplacez les éléments suivants :

  • FIREWALL_RULE_NAME : nom de la nouvelle règle de pare-feu que vous choisissez.
  • HOST_PROJECT : ID du projet hôte de VPC partagé.
  • SHARED_VPC : nom du réseau VPC partagé.

Problèmes connus

Cette section décrit les problèmes connus liés à Multi Cluster Ingress.

InvalidValueError pour le champ config_membership

Un problème connu empêche Google Cloud CLI d'interagir avec l'objet Ingress multicluster. Ce problème a été introduit dans la version 346.0.0 et résolu dans la version 348.0.0. Nous vous déconseillons d'utiliser les versions 346.0.0 et 347.0.0 de gcloud CLI avec Multi Cluster Ingress.

Valeur non valide pour le champ "resource"

Google Cloud Armor ne peut pas communiquer avec les clusters de configuration d'objets Ingress multiclusters exécutés sur les versions suivantes de GKE :

  • 1.18.19-gke.1400 et versions ultérieures
  • 1.19.10-gke.700 et versions ultérieures
  • 1.20.6-gke.700 et versions ultérieures

Lorsque vous configurez une stratégie de sécurité Google Cloud Armor, le message suivant s'affiche :

Invalid value for field 'resource': '{"securityPolicy": "global/securityPolicies/"}': The given policy does not exist

Pour éviter ce problème, mettez à niveau votre cluster de configuration vers la version 1.21 ou une version ultérieure, ou exécutez la commande suivante pour mettre à jour la ressource BackendConfig CustomResourceDefinition :

kubectl patch crd backendconfigs.cloud.google.com --type='json' -p='[{"op": "replace", "path": "/spec/versions/1/schema/openAPIV3Schema/properties/spec/properties/securityPolicy", "value":{"properties": {"name": {"type": "string"}}, "required": ["name" ],"type": "object"}}]'

Étape suivante