Cette page décrit l'implémentation 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 implémentations 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.
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 ressourceFrontendConfig
à 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 ressourceBackendConfig
à 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.
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 entre espaces de noms permet aux ressources Route d'associer des ressources Gateway à 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.
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.
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.
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.
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 |
|
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
- Découvrez comment configurer des ressources Gateway à l'aide de ressources Policy.
- Découvrez comment déployer des passerelles.
- Découvrez comment déployer des passerelles multiclusters.
- Pour obtenir des informations complètes sur l'utilisation de Traffic Director avec l'API Gateway, consultez la page Présentation du maillage de services GKE Traffic Director.