Entrée multicluster

Un objet d'entrée multicluster est un contrôleur d'entrée multicluster hébergé dans le cloud pour les clusters GKE. Il s'agit d'un service hébergé par Google qui permet de déployer des ressources d'équilibrage de charge partagées entre les clusters et entre les régions. Pour déployer un objet Ingress multicluster sur plusieurs clusters, suivez les instructions de la section Configurer un objet Ingress multicluster, puis consultez la section Déployer une entrée sur plusieurs clusters.

Mise en réseau multicluster

De nombreux facteurs influencent les topologies multiclusters, notamment la proximité des utilisateurs pour les applications, la haute disponibilité des clusters et des régions, la séparation organisationnelle et de sécurité, la migration des clusters et la localité des données. Ces cas d'utilisation sont rarement isolés. À mesure que les raisons de la multiplication des clusters augmentent, il devient de plus en plus urgent de créer une plate-forme multicluster formelle et industrialisée.

Un objet objetIngress multicluster est conçu pour répondre aux besoins d'équilibrage de charge des environnements multicluster et multirégionaux. Il s'agit d'une commande permettant à l'équilibreur de charge HTTP(S) externe de fournir une entrée pour le trafic provenant d'Internet sur un ou plusieurs clusters.

La compatibilité multicluster de l'objet Ingress multicluster est assurée par de nombreux cas d'utilisation, parmi lesquels :

  • Une adresse IP virtuelle (IPV) unique et cohérente pour une application, indépendamment de l'endroit où celle-ci est déployée dans le monde entier.
  • La disponibilité multirégionale et multicluster via la vérification d'état et le basculement du trafic.
  • Le routage basé sur la proximité via les IPV publiques Anycast pour une faible latence du client.
  • La migration transparente des clusters pour les mises à niveau ou les reconstructions de clusters.

Tarifs et essais

Pour en savoir plus sur la tarification des entrées multicluster, consultez la page Tarifs des entrées multicluster.

Fonctionnement d'un objet Ingress multicluster

Un objet Ingress multicluster s'appuie sur l'architecture de l'équilibrage de charge HTTP(S) externe. L'équilibrage de charge HTTP(S) est un équilibreur de charge réparti dans le monde entier avec des proxys déployés dans plus de 100 points de présence Google (POP) dans le monde. Ces proxys appelés Google Front End (GFE) se trouvent à la périphérie du réseau de Google, à proximité des clients. Un objet Ingress multiclusters crée des équilibreurs de charge HTTP(S) externes de niveau Premium. Ces équilibreurs de charge utilisent des adresses IP externes globales annoncées par anycast. Les requêtes sont traitées par les GFE et par le cluster le plus proche du client. Le trafic Internet est dirigé vers le POP Google le plus proche et utilise le réseau Google pour atteindre un cluster GKE. Cette configuration d'équilibrage de charge entraîne une latence plus faible du client au serveur GFE. Vous pouvez également réduire la latence entre la diffusion des clusters GKE et des GFE en exécutant vos clusters GKE dans les régions les plus proches de vos clients.

L'interruption de connexions HTTP et HTTPS en périphérie permet à l'équilibreur de charge Google de choisir où acheminer le trafic en déterminant la disponibilité du backend avant que le trafic entre dans un centre de données ou une région. Le trafic suit ainsi le chemin le plus efficace entre le client et le backend, tout en tenant compte de l'état et de la capacité des backends.

Un objet Ingress multicluster est un contrôleur d'entrée qui programme l'équilibreur de charge HTTP(S) externe à l'aide de groupes de points de terminaison du réseau (NEG). Lorsque vous créez une ressource MultiClusterIngress, GKE déploie les ressources de l'équilibreur de charge Compute Engine et configure les pods appropriés sur les clusters en tant que backends. Les NEG sont utilisés pour effectuer le suivi dynamique des points de terminaison des pods de sorte que l'équilibreur de charge Google dispose de backends opérationnels.

Flux de trafic de l'objet Ingress multicluster

Lorsque vous déployez des applications sur plusieurs clusters dans GKE, l'objet Ingress multicluster s'assure que l'équilibreur de charge est synchronisé avec les événements qui se produisent dans le cluster :

  • Un déploiement est créé avec les libellés appropriés correspondants.
  • Le processus d'un pod disparaît et échoue à sa vérification d'état.
  • Un cluster est supprimé du pool de backends.

L'objet Ingress multicluster met à jour l'équilibreur de charge, en maintenant la cohérence avec l'environnement et l'état souhaité des ressources Kubernetes.

Architecture de l'objet Ingress multicluster

L'objet Ingress multicluster utilise un serveur d'API Kubernetes centralisé pour déployer l'objet Ingress sur plusieurs clusters. Ce serveur d'API centralisé est appelé "cluster de configuration". Tout cluster GKE peut faire office de cluster de configuration. Celui-ci utilise deux types de ressources personnalisés : MultiClusterIngress et MultiClusterService. En déployant ces ressources sur le cluster de configuration, le contrôleur d'entrée multicluster déploie des équilibreurs de charge sur plusieurs clusters.

Les concepts et composants suivants constituent un objet Ingress multicluster :

  • Contrôleur d'entrée multicluster : il s'agit d'un plan de contrôle distribué à l'échelle mondiale qui s'exécute en tant que service en dehors de vos clusters. Ainsi, le cycle de vie et les opérations du contrôleur peuvent être indépendants des clusters GKE.

  • Cluster de configuration : cluster GKE choisi s'exécutant sur Google Cloud, et où les ressources MultiClusterIngress et MultiClusterService sont déployées. Il s'agit d'un point de contrôle centralisé pour ces ressources multiclusters. Celles-ci existent dans une seule API logique et sont accessibles depuis celle-ci pour conserver la cohérence entre tous les clusters. Le contrôleur d'Ingress surveille le cluster de configuration et procède au rapprochement de l'infrastructure d'équilibrage de charge.

  • Fleet (anciennement Environ) : une Fleet est un domaine qui regroupe les clusters et l'infrastructure, gère les ressources et assure une stratégie cohérente pour l'ensemble des clusters. L'objet Ingress multicluster utilise le concept des parcs pour gérer l'application d'Ingress à différents clusters. Les clusters que vous enregistrez dans un parc deviennent visibles par Ingress multicluster et peuvent donc être utilisés comme backends pour Ingress.

  • Cluster membre : les clusters enregistrés dans une Fleet sont appelés clusters membres. Les clusters membres dans le parc comprennent l'ensemble des backends dont Ingress multicluster a connaissance. La vue Gestion des clusters Google Kubernetes Engine fournit une console sécurisée permettant d'afficher l'état de tous vos clusters enregistrés.

Architecture de l'objet Ingress multicluster

Workflow de déploiement

La procédure suivante illustre un workflow de haut niveau pour l'utilisation de l'objet Ingress multicluster sur plusieurs clusters.

  1. Enregistrez des clusters GKE en tant que clusters membres.

  2. Configurez un cluster GKE en tant que cluster de configuration central. Ce cluster peut être un plan de contrôle dédié ou exécuter d'autres charges de travail.

  3. Déployez des applications sur les clusters GKE où elles doivent être exécutées.

  4. Déployez une ou plusieurs ressources MultiClusterService dans le cluster de configuration avec des correspondances libellés et de clusters, afin de sélectionner des clusters, des espaces de noms et des pods considérés comme des backends pour un service donné. Cela crée des NEG dans Compute Engine, qui commence à enregistrer et à gérer les points de terminaison de service.

  5. Déployez une ressource MultiClusterIngress dans le cluster de configuration qui référence une ou plusieurs ressources MultiClusterService en tant que backends pour l'équilibreur de charge. Celle-ci déploie les ressources de l'équilibreur de charge externe Compute Engine et expose les points de terminaison entre les clusters via une seule IPV d'équilibreur de charge.

Concepts d'Ingress

L'objet Ingress multicluster utilise un serveur d'API Kubernetes centralisé pour déployer l'objet Ingress sur plusieurs clusters. Les sections suivantes décrivent le modèle de ressource de l'objet Ingress multicluster, comment déployer l'objet Ingress et les concepts importants pour gérer ce plan de contrôle de réseau à disponibilité élevée.

Ressources MultiClusterService

Un objet MultiClusterService (MCS) est une ressource personnalisée utilisée par un objet Ingress multicluster qui constitue une représentation logique d'un service sur plusieurs clusters. Un MCS s'apparente au type de service principal, mais en est sensiblement différent. Un MCS n'existe que dans le cluster de configuration et génère des services dérivés dans les clusters cibles. Un MCS n'achemine pas de trafic comme le fait un service ClusterIP, LoadBalancer ou NodePort. Il permet simplement au contrôleur d'entrée multicluster (MCI, Multicluster Ingress) de faire référence à une ressource distribuée particulière. Voici un MCS simple pour l'application foo :

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: foo
  namespace: blue
spec:
  template:
    spec:
      selector:
        app: foo
      ports:
      - name: web
        protocol: TCP
        port: 80
        targetPort: 80

Comme un service, un MCS est un sélecteur pour les pods, mais il peut également sélectionner des libellés et des clusters. Les clusters qu'il sélectionne en pool sont appelés "clusters membres". Il s'agit de tous les clusters enregistrés dans la Fleet. Ce MCS déploie un service dérivé dans tous les clusters membres à l'aide du sélecteur app: foo. Si des pods app: foo existent dans ce cluster, les adresses IP de ces pods sont ajoutées en tant que backends pour le MCI.

Le service mci-zone1-svc-j726y6p1lilewtu7 suivant est un service dérivé généré par le MCS dans l'un des clusters cibles. Ce service crée un NEG qui effectue le suivi des points de terminaison des pods pour tous les pods correspondant au sélecteur de libellés spécifié dans ce cluster. Il existe un service dérivé et un NEG dans chaque cluster cible, pour chaque MCS (sauf si vous utilisez des sélecteurs de cluster). Si aucun pod correspondant n'existe dans un cluster cible, le service et le NEG seront vides. Les services dérivés sont entièrement gérés par le MCS, et non directement par les utilisateurs.

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports":{"8080":{}}}'
    cloud.google.com/neg-status: '{"network_endpoint_groups":{"8080":"k8s1-a6b112b6-default-mci-zone1-svc-j726y6p1lilewt-808-e86163b5"},"zones":["us-central1-a"]}'
    networking.gke.io/multiclusterservice-parent: '{"Namespace":"default","Name":"zone1"}'
  name: mci-zone1-svc-j726y6p1lilewtu7
  namespace: blue
spec:
  selector:
    app: foo
  ports:
  - name: web
    protocol: TCP
    port: 80
    targetPort: 80

Remarques sur le service dérivé :

  • Sa fonction est un regroupement logique de points de terminaison en tant que backends pour l'objet Ingress multicluster.
  • Il gère le cycle de vie du NEG pour un cluster et une application donnés.
  • Il est créé en tant que service sans adresse IP de cluster. Notez que seuls les champs Selector et Ports sont transférés de la spécification MCS vers la spécification de service dérivé.
  • Le contrôleur d'entrée gère son cycle de vie.

Ressource MultiClusterIngress

Une ressource MultiClusterIngress (MCI) se comporte de manière identique à la ressource Ingress principale. Elles ont toutes deux la même spécification pour la définition des hôtes, des chemins, de la terminaison de protocole et des backends. Il s'agit d'un exemple simple de ressource MCI qui achemine le trafic vers les backends foo et bar en fonction des en-têtes d'hôte HTTP.

apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  name: foobar-ingress
  namespace: blue
spec:
  template:
    spec:
      backend:
        serviceName: default-backend
        servicePort: 80
      rules:
      - host: foo.example.com
        backend:
          serviceName: foo
          servicePort: 80
      - host: bar.example.com
        backend:
          serviceName: bar
          servicePort: 80

Notez que ce MCI correspond au trafic vers l'IPV sur foo.example.com et bar.example.com en envoyant ce trafic aux ressources MCS (MultiClusterService) appelées "foo" et "bar". Ce MCI dispose d'un backend par défaut qui établit une correspondance avec tout le reste du trafic et l'envoie au MCS du backend par défaut.

Correspondance d'en-tête "Host"

Ressources Ingress sur plusieurs clusters

Le cluster de configuration est le seul à pouvoir disposer de ressources MultiClusterIngress et MultiClusterService. Un service dérivé correspondant est également planifié sur chaque cluster cible dont les pods correspondent aux sélecteurs de libellés MCS. Si un cluster n'est pas explicitement sélectionné par un MCS, aucun service dérivé correspondant n'est créé dans ce cluster.

Schéma d'un modèle de ressources Ingress

Identité de l'espace de noms

Les clusters GKE enregistrés deviennent membres d'une Fleet.

Les Fleet possèdent une caractéristique connue sous le nom d'uniformité de l'espace de noms, qui suppose que les ressources ayant les mêmes noms et le même espace de noms sur les clusters sont considérées comme des instances de la même ressource. En effet, cela signifie que les pods de l'espace de noms ns1 portant les libellés app: foo dans différents clusters sont tous considérés comme faisant partie du même pool de backends d'applications, du point de vue de l'objet Ingress multicluster.

Cela a des conséquences sur le mode opératoire des différentes équipes de développement au sein d'un groupe de clusters. Des équipes différentes peuvent toujours exploiter le même parc de clusters en utilisant les espaces de noms pour segmenter les charges de travail, même au-delà des limites des clusters. Cependant, il est important que chaque équipe réserve explicitement ou implicitement son ou ses propres espaces de noms sur tous les clusters de sa Fleet.

Dans l'exemple suivant, une équipe bleue a accès au déploiement dans tous les espaces de noms "blue" sur les clusters du parc. "blue" est considéré comme un espace de noms identique dans chaque cluster. L'espace de noms bleu existe également dans le cluster de configuration de l'objet multicluster. Les ressources MultiClusterService déployées par l'équipe bleue ne peuvent sélectionner que les pods qui existent également dans l'espace de noms "blue" dans les différents clusters. Les ressources MCI et MCS n'ont ni visibilité, ni accès aux espaces de noms dans les différents clusters. Par conséquent, la signification et "l'uniformité" des ressources sont assurées pour l'ensemble des clusters.

Schéma illustrant l'uniformité de l'espace de noms

L'uniformité de l'espace de noms a certaines conséquences en termes de conception. Les principes suivants aideront les utilisateurs :

  • Les espaces de noms ayant des objectifs différents ne doivent pas avoir le même nom sur l'ensemble des clusters.
  • Les espaces de noms doivent être réservés explicitement en allouant un espace de noms, ou implicitement, via des règles hors bande, aux équipes et aux clusters au sein d'une Fleet.
  • Les espaces de noms ayant le même objectif sur l'ensemble des clusters doivent partager le même nom.
  • L'autorisation utilisateur sur les espaces de noms pour l'ensemble des clusters doit être étroitement contrôlée pour empêcher tout accès non autorisé.
  • L'espace de noms par défaut ou les espaces de noms génériques tels que "prod" ou "dev" ne doivent pas être utilisés pour le déploiement normal d'une application. En effet, les utilisateurs pourraient déployer accidentellement des ressources dans l'espace de noms par défaut et enfreindre les principes de segmentation des espaces de noms.
  • Le même espace de noms doit être créé dans les clusters, dès lors qu'une équipe ou un groupe d'utilisateurs donné doit déployer des ressources.

Conception du cluster de configuration

Le cluster de configuration de l'objet Ingress multicluster est un cluster GKE unique qui héberge les ressources MCI et MCS, et sert de point de contrôle unique pour l'objet Ingress sur l'ensemble des clusters GKE cibles. Vous choisissez le cluster de configuration lorsque vous activez l'objet Ingress multicluster. Vous pouvez choisir n'importe quel cluster GKE comme cluster de configuration et le modifier à tout moment.

Disponibilité du cluster de configuration

Comme le cluster de configuration est un point de contrôle unique, les ressources de l'objet Ingress multicluster ne peuvent pas être créées ni mises à jour si l'API du cluster de configuration n'est pas disponible. Les équilibreurs de charge et le trafic desservi ne sont pas affectés par une panne du cluster de configuration. Toutefois, les modifications apportées aux MCI et aux MCS ne sont pas rapprochées par le contrôleur tant que celui-ci n'est pas disponible.

Voici quelques principes de conception qui vous aideront à utiliser et à gérer le cluster de configuration :

  • Le cluster de configuration doit être choisi de sorte qu'il soit hautement disponible. Les clusters régionaux sont préférables aux clusters zonaux.
  • Le cluster de configuration ne doit pas nécessairement être un cluster dédié à l'objet Ingress multicluster. Le cluster de configuration peut héberger des charges de travail d'administration, voire d'application. Veillez cependant à ce que les applications hébergées n'affectent pas la disponibilité du serveur d'API du cluster de configuration. Le cluster de configuration peut être un cluster cible qui héberge des backends pour les MCI. Toutefois, si des précautions supplémentaires sont nécessaires, il peut également être exclu en tant que backend MCI via la sélection de clusters.
  • Les clusters de configuration doivent détenir tous les espaces de noms utilisés par les backends de cluster cible. Un MCS ne peut référencer des pods que dans le même espace de noms sur plusieurs clusters ; cet espace de noms doit donc être présent dans le cluster de configuration.
  • Les utilisateurs qui déploient Ingress sur plusieurs clusters doivent avoir accès au cluster de configuration pour déployer des ressources MCI et MCS. Toutefois, les utilisateurs ne doivent avoir accès qu'aux espaces de noms qu'ils sont autorisés à utiliser.

Sélectionner et migrer le cluster de configuration

Vous choisissez le cluster de configuration lorsque vous activez l'objet Ingress multicluster. Tout cluster membre d'une Fleet peut être sélectionné en tant que cluster de configuration. Vous pouvez mettre à jour le cluster de configuration à tout moment, mais vous devez veiller à ce que cela n'entraîne pas de perturbations. Le contrôleur d'entrée rapproche toutes les ressources MCI et MCS présentes dans le cluster de configuration. Lors de la migration du cluster de configuration du cluster actuel vers le suivant, les ressources MCI et MCS doivent être identiques. Si les ressources ne sont pas identiques, les équilibreurs de charge Compute Engine risquent d'être mis à jour ou détruits après la mise à jour du cluster de configuration.

Dans le schéma suivant, un système CI/CD centralisé applique à tout moment des ressources MCI et MCS au serveur d'API GKE pour le cluster de configuration (gke-us) et un cluster de sauvegarde (gke-eu), afin que les ressources soient identiques sur les deux clusters. Si vous devez modifier le cluster de configuration, en cas d'urgence ou de temps d'arrêt planifié, le cluster de configuration peut être mis à jour sans aucun impact, car les ressources MCI et MCS sont identiques.

Système CI/CD centralisé appliquant des ressources MCI et MCS

Sélection des clusters

Les ressources MCS ont une capacité de sélection explicite sur l'ensemble des clusters. Par défaut, un MCS planifie les services dérivés sur chaque cluster cible. La sélection de clusters définit une liste explicite de clusters pour un MCS donné dans lequel les services dérivés doivent être planifiés. Tous les autres clusters cibles seront ignorés. Consultez la page Configurer l'objet Ingress multicluster pour configurer la sélection des clusters.

Il existe de nombreux cas d'utilisation dans lesquels vous pouvez appliquer des règles d'entrée à des clusters spécifiques :

  • Isoler le cluster de configuration pour empêcher les MCS de les sélectionner
  • Contrôler le trafic entre les clusters en mode bleu-vert pour la migration des applications
  • Définir un routage vers des backends d'application qui n'existent que dans un sous-ensemble de clusters
  • Utiliser une seule adresse IPV L7 pour le routage hôte/chemin vers les backends qui résident sur différents clusters

La sélection des clusters s'effectue via le champ clusters du MCS. Les clusters sont explicitement référencés sous la forme <region | zone>/<name>. Les clusters membres d'une même Fleet et d'une même région doivent avoir des noms uniques afin d'éviter tout conflit de nom.

Dans l'exemple suivant, le MCS foo comporte un champ clusters qui fait référence à europe-west1-c/gke-eu et asia-northeast1-a/gke-asia. Par conséquent, les pods avec les libellés correspondants dans les clusters gke-asia et gke-eu peuvent être inclus en tant que backends pour un MCI donné. Le cluster gke-us d'Ingress est donc exclu, même s'il comporte des pods avec le libellé app: foo. Cela peut être utile pour l'intégration ou la migration vers de nouveaux clusters et le contrôle du trafic, indépendamment du déploiement du pod.

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: foo
  namespace: blue
spec:
  template:
    spec:
      selector:
        app: foo
      ports:
      - name: web
        protocol: TCP
        port: 80
        targetPort: 80
  clusters:
  - link: "europe-west1-c/gke-eu"
  - link: "asia-northeast1-a/gke-asia-1"

Le schéma suivant montre trois clusters : gke-eu, gke-asia-1 et gke-asia-2. Le cluster gke-asia-2 est exclu en tant que backend, même si les pods avec des libellés correspondants y sont déjà placés. Cela permet d'exclure le cluster pour ne pas recevoir de trafic lors de la maintenance ou d'autres opérations. Notez que si le champ "clusters" est omis d'un MCS, il sélectionne implicitement tous les clusters membres.

Schéma illustrant un backend exclu

Étape suivante