Passerelle

Cette page décrit la mise en œuvre de Google Kubernetes Engine (GKE) de l'API Kubernetes Gateway à l'aide du contrôleur de passerelle GKE.

L'API Gateway est une norme Open Source pour la mise en réseau de services. L'API Gateway fait évoluer la ressource Ingress et l'améliore des manières suivantes :

  • Basée sur les rôles : Gateway est composée de ressources d'API qui correspondent aux rôles organisationnels de l'opérateur de cluster, du développeur et du fournisseur d'infrastructures. Cela permet aux opérateurs de cluster de définir comment l'infrastructure partagée peut être utilisée par de nombreuses équipes de développeurs différentes et non coordonnées.

  • Portable : l'API Gateway est un standard Open Source avec de nombreuses mises en œuvre. Elle est conçue à l'aide du concept de conformité flexible, qui promeut une API principale hautement portable (comme Ingress) qui présente néanmoins la flexibilité et l'extensibilité nécessaires pour offrir des fonctionnalités natives de l'environnement et de la mise en œuvre. Cela permet de garantir la cohérence des concepts et des ressources principales entre les mises en œuvre et les environnements, ce qui réduit la complexité et améliore la connaissance des utilisateurs.

  • Expressive : les ressources de l'API Gateway fournissent des fonctionnalités intégrées pour la correspondance basée sur l'en-tête, la pondération du trafic et d'autres fonctionnalités qui ne sont possibles que dans Ingress via des annotations personnalisées.

Ressources de l'API Gateway

L'API Gateway est un modèle de ressource basé sur les rôles, conçu pour les personas qui interagissent avec la mise en réseau Kubernetes. Comme le montre le schéma suivant, ce modèle permet à différents propriétaires de services non coordonnés de partager la même infrastructure réseau sous-jacente en toute sécurité, de manière à centraliser les règles et les contrôles pour l'administrateur de la plate-forme.

GKE fournit des classes Gateway. Les opérateurs de cluster créent des ressources Gateway basées sur ces classes. Les développeurs d'applications créent des ressources HTTPRoute qui se lient à des ressources Gateway.
Figure : Présentation de l'API Gateway

L'API Gateway contient les types de ressources suivants :

  • GatewayClass : définit une ressource à l'échelle d'un cluster, qui est un modèle permettant de créer des équilibreurs de charge dans un cluster. GKE fournit des ressources GatewayClasses utilisables dans les clusters GKE.
  • Gateway : définit où et comment les équilibreurs de charge écoutent le trafic. Les opérateurs de cluster créent des ressources Gateway dans leurs clusters en fonction d'une ressource GatewayClass. GKE crée des équilibreurs de charge qui mettent en œuvre la configuration définie dans la ressource Gateway.
  • HTTPRoute : définit des règles spécifiques au protocole pour acheminer les requêtes d'une ressource Gateway vers les services Kubernetes. GKE est compatible avec les ressources HTTPRoute pour le routage du trafic basé sur HTTP(S). Les développeurs d'applications créent des ressources HTTPRoute pour exposer leurs applications HTTP à l'aide de ressources Gateway.
  • Policy : définit un ensemble de caractéristiques spécifiques à la mise en œuvre d'une ressource Gateway. Vous pouvez associer une règle à une passerelle, à une route ou à un service Kubernetes.

GatewayClass

GatewayClass est une ressource qui définit un modèle pour les équilibreurs de charge HTTP(S) (niveau 7) dans un cluster Kubernetes. GKE fournit des ressources GatewayClass comme ressources à l'échelle d'un cluster. Les opérateurs de cluster spécifient une ressource GatewayClass lors de la création de ressources Gateway dans leurs clusters.

Les différentes ressources GatewayClass correspondent à différents équilibreurs de charge Google Cloud. Lorsque vous créez une ressource Gateway basée sur une ressource GatewayClass, un équilibreur de charge correspondant est créé pour mettre en œuvre la configuration spécifiée.

Certaines ressources GatewayClass sont compatibles avec l'équilibrage de charge multicluster.

Le tableau suivant répertorie les ressources GatewayClass disponibles dans les clusters GKE et leur type d'équilibreur de charge sous-jacent. Pour en savoir plus sur les ressources GatewayClass, consultez la page Fonctionnalités et spécifications de la ressource GatewayClass.

Nom GatewayClass Description
gke-l7-global-external-managed Équilibreurs de charge d'application externes globaux basés sur l'équilibreur de charge d'applications externe global
gke-l7-regional-external-managed Équilibreurs de charge d'application externes régionaux basés sur l'équilibreur de charge d'application externe régional
gke-l7-rilb Équilibreurs de charge d'application internes basés sur l'équilibreur de charge d'application interne
gke-l7-gxlb Équilibreurs de charge d'application externes globaux basés sur l'équilibreur de charge d'application classique
gke-l7-global-external-managed-mc Équilibreurs de charge d'application externes globaux multicluster basés sur l'équilibreur de charge d'application externe global
gke-l7-regional-external-managed-mc Équilibreurs de charge d'application externes régionaux multicluster basés sur l'équilibreur de charge d'application externe global
gke-l7-rilb-mc Équilibreurs de charge d'application internes multicluster basés sur l'équilibreur de charge d'application interne
gke-l7-gxlb-mc Équilibreurs de charge d'application externes multicluster globaux basés sur l'équilibreur de charge d'application classique
gke-td Maillage de services Traffic Director multicluster
asm-l7-gxlb Équilibreurs de charge d'application externes globaux basés sur Anthos Service Mesh

Chaque ressource GatewayClass est soumise aux limites de l'équilibreur de charge sous-jacent.

Passerelle

Les opérateurs de cluster créent des ressources Gateway pour définir où et comment les équilibreurs de charge écoutent le trafic. Les ressources Gateway tiennent leur comportement (c'est-à-dire leur mise en œuvre) de leur ressource GatewayClass associée.

La spécification de la ressource Gateway inclut la ressource GatewayClass de la ressource Gateway, les ports et les protocoles d'écoute, ainsi que les routes pouvant être associées à la ressource Gateway. Une ressource Gateway sélectionne des routes en fonction de leurs métadonnées, en particulier le genre, l'espace de noms et les libellés des ressources de route.

Pour obtenir un exemple de déploiement d'une ressource Gateway, consultez la section Déployer des ressources Gateway.

Pour obtenir un exemple de déploiement d'une ressource Gateway multicluster, consultez la section Déployer des ressources Gateway multiclusters.

HTTPRoute

Une ressource HTTPRoute définit la manière dont les requêtes HTTP et HTTPS reçues par une ressource Gateway sont dirigées vers les services. Les développeurs d'applications créent des ressources HTTPRoute pour exposer leurs applications via des ressources Gateway.

Une ressource HTTPRoute définit les ressources Gateway à partir desquelles elle peut acheminer le trafic, les services vers lesquels il doit être acheminé et les règles qui définissent le trafic correspondant à la ressource HTTPRoute. La liaison de passerelle et de route est bidirectionnelle, ce qui signifie que les deux ressources doivent se sélectionner pour qu'elles soient liées. Les ressources HTTPRoute peuvent correspondre à des requêtes en fonction des détails de l'en-tête de la requête.

Règle

Une ressource Policy définit les caractéristiques d'une ressource Gateway, généralement spécifique à la mise en œuvre, que les opérateurs de cluster peuvent rattacher à une passerelle, une route ou un service Kubernetes. Une ressource Policy définit le fonctionnement de l'infrastructure Google Cloud sous-jacente.

Une ressource Policy est généralement associée à un espace de noms et peut référencer une ressource dans le même espace de noms. L'accès est accordé à l'aide du contrôle des accès basé sur les rôles (RBAC). Le caractère hiérarchique de l'API Gateway vous permet d'associer une ressource Policy à une ressource supérieure (Gateway) dans un espace de noms, et de faire en sorte que toutes les ressources sous-jacentes, situées dans des espaces de noms différents, reçoivent les caractéristiques de cette règle.

GKE Gateway Controller est compatible avec les règles suivantes:

  • HealthCheckPolicy : définit les paramètres et le comportement de la vérification d'état utilisée pour vérifier l'état des pods de backend.
  • GCPGatewayPolicy : définit des paramètres spécifiques de l'interface de l'équilibreur de charge Google Cloud. Elle est semblable à l'association d'une ressource FrontendConfig à une ressource Ingress.
  • GCPBackendPolicy: définit la manière dont les services de backend de l'équilibreur de charge doivent distribuer le trafic vers les points de terminaison. Elle est semblable à l'association d'une ressource BackendConfig à une ressource Ingress.

Propriétaire et modèles d'utilisation de la passerelle

Les ressources Gateway et Route offrent une certaine flexibilité dans la façon dont elles sont détenues et déployées dans une organisation. Cela signifie qu'un équilibreur de charge peut être déployé et géré par une équipe chargée de l'infrastructure, alors que le routage sous un domaine ou un chemin particulier peut être délégué à une autre équipe dans un autre espace de noms Kubernetes. Le contrôleur GKE Gateway est compatible avec l'utilisation mutualisée d'un équilibreur de charge partagé entre plusieurs espaces de noms, clusters et régions. Les passerelles n'ont pas à être partagées si une propriété plus distribuée est requise. Voici quelques-uns des modèles d'utilisation les plus courants des passerelles dans GKE.

Passerelle autogérée

Un propriétaire unique peut déployer une passerelle et une route uniquement pour ses applications et les utiliser exclusivement. Les passerelles et les routes déployées de cette manière sont semblables à la ressource Ingress. Le schéma suivant présente deux propriétaires de services différents qui déploient et gèrent leurs propres passerelles. Comme pour la ressource Ingress, chaque passerelle correspond à sa propre adresse IP et à son propre équilibreur de charge. Le protocole TLS, le routage et d'autres règles sont entièrement contrôlés par le propriétaire du service.

Un seul propriétaire peut contrôler entièrement la passerelle et la route

Ce modèle d'utilisation est courant pour la ressource Ingress, mais s'avère difficile à faire évoluer pour de nombreuses équipes en raison du manque de ressources partagées. Le modèle de ressource de l'API Gateway permet d'utiliser les modèles d'utilisation ci-dessous, qui proposent toute une gamme d'options pour la propriété et le contrôle distribués.

Passerelle par espace de noms gérée par la plate-forme

La séparation entre les ressources Gateway et Route permet aux administrateurs de plate-forme de contrôler les passerelles pour le compte des propriétaires de services. Les administrateurs de plate-forme peuvent déployer une passerelle par espace de noms ou par équipe, ce qui donne à cet espace de noms un accès exclusif à l'utilisation de la passerelle. Cela donne au propriétaire de service un contrôle total sur les règles de routage sans risque de conflit avec les autres équipes. Cela permet à l'administrateur de la plate-forme de contrôler des aspects tels que l'allocation d'adresses IP, l'exposition des ports, les protocoles, les domaines et TLS. Les administrateurs de plate-forme peuvent également choisir les types de passerelles disponibles pour les équipes, par exemple les passerelles internes ou externes/publiques. Ce modèle d'utilisation crée une séparation claire des responsabilités entre les différents rôles.

Le routage multi-espace de noms permet aux routes d'associer des passerelles à d'autres espaces de noms. Les passerelles peuvent limiter les espaces de noms à partir desquels il est possible d'associer des routes. De même, les routes spécifient les passerelles auxquelles elles sont associées, mais elles ne peuvent être associées qu'à une passerelle qui a autorisé l'espace de noms de la route. Ce rattachement bidirectionnel fournit à chaque côté des contrôles flexibles qui rendent possible une grande variété de cas d'utilisation.

Dans le diagramme suivant, l'administrateur de plate-forme a déployé une passerelle pour fournir un accès exclusif à chaque espace de noms. Par exemple, la passerelle store est configurée de sorte à ce que seules les routes de l'espace de noms store puissent y être associées. Chaque passerelle représente une adresse IP unique avec équilibrage de charge et permet à chaque équipe de déployer un nombre illimité de routes sur la passerelle, pour tous les domaines et toutes les routes qu'elle choisit.

Une passerelle par espace de noms, qui fournit un accès exclusif à une passerelle vers cet espace de noms.

Passerelle partagée par cluster

Le partage des passerelles sur plusieurs espaces de noms offre une forme de propriété encore plus centralisée aux administrateurs de plate-forme. Cela permet à différents propriétaires de service opérant dans différents espaces de noms de partager la même adresse IP, le même domaine DNS, les mêmes certificats ou les mêmes chemins d'accès pour un routage précis entre les services. Les passerelles permettent aux administrateurs de plate-forme de choisir quels espaces de noms peuvent établir des routes vers un domaine spécifique. Cet exemple ressemble à l'exemple précédent, à la différence que les passerelles autorisent les rattachements de route à partir de plusieurs espaces de noms.

Dans le diagramme suivant, l'administrateur de plate-forme a déployé deux passerelles dans l'espace de noms infra. La passerelle external permet d'associer des routes des espaces de noms web et mobile à la passerelle. Les routes de l'espace de noms accounts ne peuvent pas utiliser la passerelle external, car l'espace de noms accounts est réservé aux services internes. La passerelle internal permet aux clients internes de communiquer en mode privé au sein du VPC en utilisant des adresses IP privées.

Une passerelle par cluster permet à différents espaces de noms d'un cluster de partager une même passerelle

Le domaine m.example.com est délégué à l'espace de noms mobile, ce qui permet aux propriétaires de service mobile de configurer toutes les règles de routage dont ils ont besoin sous le domaine m.example.com. Cela permet aux propriétaires de services de mieux contrôler l'introduction de nouveaux points de terminaison d'API et de contrôler le trafic sans demander de modification aux administrateurs.

Passerelle partagée par parc

À l'aide de passerelles multicluster, une passerelle peut être partagée sur plusieurs espaces de noms, clusters et régions. Les grandes organisations disposant d'applications distribuées géographiquement peuvent bénéficier de l'utilisation de passerelles multiclusters, car elles permettent de contrôler le trafic de manière précise et de déléguer le routage. De la même manière que pour les exemples précédents, un administrateur de plate-forme gère la passerelle et délègue le routage. Le principal intérêt de ce cas d'utilisation est que les routes font référence à des services multiclusters, qui sont déployés dans plusieurs clusters. Le trafic peut être acheminé de manière explicite : le trafic à destination de store.example.com/us est dirigé vers les pods gke-us et, de manière implicite, le trafic à destination de example.com/* est acheminé vers le cluster le plus proche du client. Cette flexibilité permet aux propriétaires de services de définir la stratégie de routage optimale pour leur application.

Une passerelle par parc qui fournit un équilibrage de charge multicluster et multirégional

Contrôleur GKE Gateway

Le contrôleur GKE Gateway est la mise en œuvre par Google de l'API Gateway pour Cloud Load Balancing. Tout comme le contrôleur GKE Ingress, le contrôleur Gateway surveille une API Kubernetes pour identifier les ressources de l'API Gateway et effectue un rapprochement des ressources Cloud Load Balancing pour mettre en œuvre le comportement de réseau spécifié par les ressources Gateway.

Il existe deux versions du contrôleur GKE Gateway :

  • Cluster unique : gère les passerelles à cluster unique pour un seul cluster GKE.
  • Multicluster : gère les passerelles multiclusters pour un ou plusieurs clusters GKE.

Les deux contrôleurs Gateway sont des contrôleurs hébergés par Google qui surveillent l'API Kubernetes pour identifier les clusters GKE. Contrairement au contrôleur GKE Ingress, les contrôleurs Gateway ne sont pas hébergés sur des plans de contrôle GKE ou dans le projet de l'utilisateur, ce qui leur permet d'être plus évolutifs et plus robustes. Les deux contrôleurs Gateway sont en disponibilité générale.

Les contrôleurs Gateway eux-mêmes ne constituent pas un plan de données de mise en réseau et ne traitent aucun trafic. Ils sont isolés du trafic et gèrent divers plans de données qui traitent le trafic. Le schéma suivant illustre l'architecture des contrôleurs GKE Gateway à cluster unique et multiclusters. Le contrôleur sous-jacent utilisé dépend de la GatewayClass de la passerelle déployée.

Les contrôleurs Gateway à cluster unique et multiclusters déploient et gèrent des équilibreurs de charge pour GKE, mais ne traitent pas le trafic réseau proprement dit

Contrôleur Contrôleur Gateway à cluster unique Contrôleur Gateway multiclusters
Géré par Google Cloud Google Cloud
Champ d'application : cluster Ressources Gateway à cluster unique Ressources Gateway multiclusters
Emplacement du déploiement Déploiement régional dans la même région que son cluster GKE. Déploiement global dans plusieurs régions Google Cloud.
Comment l'activer Activation par défaut dans GKE. Activation via l'API d'entrée multicluster et enregistrement dans une Fleet. Consultez la page Activer des ressources Gateway multiclusters.
Ressources GatewayClass compatibles
  • gke-l7-global-external-managed-mc GA
  • gke-l7-regional-external-managed-mc GA
  • gke-l7-rilb-mc GA
  • gke-l7-gxlb-mc GA
  • gke-td Preview

Vous pouvez utiliser simultanément plusieurs contrôleurs Gateway, y compris des contrôleurs non fournis par Google, dans un cluster GKE. Chaque ressource GatewayClass est compatible avec un seul contrôleur Gateway, ce qui permet d'utiliser simultanément l'équilibrage de charge unique et multicluster.

Ressources Ingress et Gateway

Comparaison entre les ressources Ingress et Gateway

Les ressources Gateway et Ingress sont toutes deux des standards Open Source permettant d'acheminer le trafic. La ressource Gateway a été conçue par la communauté Kubernetes, en s'appuyant sur les leçons tirées des écosystèmes d'Ingress et de maillage de services. La ressource Gateway est une évolution de la ressource Ingress qui offre la même fonction, fournie en tant que sur-ensemble des fonctionnalités Ingress. Les deux ressources peuvent être utilisés simultanément sans conflit. Toutefois, au fil du temps, les ressources Gateway et Route fourniront davantage de fonctionnalités non disponibles dans Ingress, incitant les utilisateurs à commencer à utiliser Gateway dans des situations où ils auraient pu utiliser Ingress auparavant.

Dans GKE, toutes les ressources Ingress sont directement convertibles en ressources Gateway et HTTPRoute. Une seule ressource Ingress correspond à la fois à une passerelle (pour la configuration de l'interface) et à une route HTTPRoute (pour la configuration de routage). L'exemple suivant montre à quoi ressemble la configuration de la passerelle et de l'objet HTTPRoute correspondant. Notez que la passerelle et l'objet HTTPRoute peuvent être créées séparément, et même par différents utilisateurs. Les passerelles peuvent avoir plusieurs routes, et une route peut également être associée à plusieurs passerelles. Les relations entre les passerelles et les routes sont décrites dans la section Modèles d'utilisation de la passerelle.

Entrée

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.class: "gce-internal"
spec:
  rules:
  - host: "example.com"
    http:
      paths:
      - pathType: Prefix
        path: /
        backend:
          service:
            name: site
            port:
              number: 80
      - pathType: Prefix
        path: /shop
        backend:
          service:
            name: store
            port:
              number: 80

Passerelle

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: my-gateway
spec:
  gatewayClassName: gke-l7-rilb
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      - kind: HTTPRoute

Routage

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: my-route
spec:
  parentRefs:
  - name: my-gateway
  hostnames:
  - "example.com"
  rules:
  - matches:
    - path:
        value: /
    backendRefs:
    - name: site
      port: 80
  - matches:
    - path:
        value: /shop
    backendRefs:
    - name: store
      port: 80

Intégrer l'API Gateway aux maillages de services

Vous pouvez configurer un maillage de services Traffic Director à l'aide de l'API Gateway. Cela permet les communications de service à service, la gestion du trafic, l'équilibrage de charge mondial et l'application des règles de sécurité pour les cas d'utilisation du maillage de services. Pour obtenir des informations complètes sur l'utilisation de Traffic Director avec l'API Gateway, y compris des guides de configuration de déploiement, consultez la présentation du maillage de services GKE Traffic Director.

Tarification

Toutes les ressources Compute Engine déployées via les contrôleurs Gateway sont facturées sur le projet dans lequel résident vos clusters GKE. Le contrôleur Gateway à cluster unique est offert sans frais supplémentaires dans le cadre des tarifs de GKE Standard et Autopilot. La tarification des ressources Gateway multiclusters est décrite sur la page Tarifs des ressources Ingress et Gateway multiclusters.

Étapes suivantes