Gateway API : quelles nouveautés pour Kubernetes ?
Gateway API : quelles nouveautés pour Kubernetes ?

Gateway API : quelles nouveautés pour Kubernetes ?

Kubernetes continue d'évoluer pour offrir des fonctionnalités avancées de gestion du réseau aux développeurs et aux administrateurs. Parmi les nouvelles ressources intéressantes, la Gateway API se démarque en offrant une approche déclarative pour la gestion des points d'entrée des applications et la configuration du trafic réseau dans Kubernetes.

Dans cet article, nous allons explorer les nouveautés de la Gateway API et les comparer avec la ressource Ingress, une autre ressource populaire pour la gestion du trafic http entrant dans Kubernetes.

Une ressource Ingress sous amphétamines ?

Bien que la ressource Gateway soit présentée comme une nouvelle ressource et qu'il a bien été précisé que l'Ingress ne sera à priori pas déprécié, il y a des similitudes évidentes dans les deux approches :

  • Tout d'abord, tout comme l'Ingress, la Gateway a été prévue pour être un modèle de spécification interopérable que chaque Ingress Controller implémente selon la spécification avec des divergences plus ou moins importantes. Ainsi, tout comme l'Ingress, la Gateway définie dans Kube peut être interprétée différemment selon que l'ingress controller soit Traefik, Nginx ou autre. À l'heure actuelle, il existe une vingtaine d'implémentations de l'API Gateway.
  • Tout comme l'ingress avait une propriété IngressClass, la gateway dispose de GatewayClass

Cependant quelques différences et améliorations sont à noter :

  • Là où l'Ingress utilise des annotations pour se configurer et modifier son comportement (ce qui pouvait se révéler assez difficile à maintenir car chaque ingress controller a ses propres annotations), la Gateway utilise des objets dédiés comme l'HTTP Route.
  • Cette division en deux ressources séparées permet une séparation des responsabilités entre les équipes d'administration du cluster (qui se chargent de créer la Gateway) et les équipes applicatives (qui se chargent de créer les HTTPRoute)
  • Un autre changement notable est la possibilité à une ressource Gateway de référencer des services ne se situant pas dans le namespace. Ce changement n'est pas anodin, car il permet alors une mutualisation des ressources exposées par le cluster sur un seul Load Balancer du Cloud provider, ce qui réduit à la fois la complexité opérationnelle et les coûts.
  • Il permet de gérer d’autres trafics réseaux autres que HTTP grâce à TLSRoute, TCPRoute, UDPRoute et GRPCRoute.
  • Il offre une meilleure intégration avec les solutions de services Mesh (exemples : linkerd, istio)

Comparaison entre différentes implémentations

Ingress Controller
Nginx
Traefik
GKE
AKS
Status
beta
alpha
stable
alpha
Prérequis
K8S >=1.21, Nginx >=1.21
K8S >=1.24, >=1.26 pour Autopilot
VPC CNI >=1.8.0
Ressources supportées
HTTPRoute
HTTPRoute, TCPRoute, TLSRoute
HTTPRoute
HTTPRoute
Limitations
pas de Cloud CDN, pas d'IAP

Comme le montre le tableau ci-dessus, à l'heure actuelle même les leaders du domaine de l'ingress controller ne supportent que très partiellement la spécification et les implémentations sont encore en développement actif.

Aperçu de quelques nouvelles features

image

Le schéma ci-dessus illustre les possibilités offertes par la ressource Gateway :

  • Un namespace commun dans lequel on déploie la Gateway,
  • Du routage sur d'autres namespace qui contiennent les applicatifs,
  • Du routage selon le path HTTP ou les headers,
  • De la distribution de trafic canary entre plusieurs versions d'un même service,
  • Une gestion de contraintes d'attachements qui permet de limiter quelle route a le droit de s'attacher à quel Gateway.

Voici le YAML de la ressource HTTPRoute qui effectue de la distribution de trafic :

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: login
  namespace: site-ns
spec:
  parentRefs:
  - name: shared-gateway
    namespace: infra-ns
  rules:
  - matches:
    - path:
        value: /login
    backendRefs:
    - name: login-v1
      port: 8080
      weight: 90
    - name: login-v2
      port: 8080
      weight: 10

Migration de Ingress vers Gateway

Pour simplifier la migration des ressources existantes, il existe un utilitaire qui permet de générer une ressource Gateway valide à partir d'une ressource Ingress.

Références

https://gateway-api.sigs.k8s.io

Article issu de notre participation aux KubeCon + CloudNativeCon Europe 2023

Merci pour votre lecture. Cet article vous a plu, partager sur vos réseaux 😉

Thibault Ayanides - Juin, 2023

image