NGF

Démarrage avec NGINX Gateway Fabric (NGF) sur cegedim.cloud — déploiement d'HTTPRoutes et référence de migration Ingress

NGINX Gateway Fabric (NGF) est l'implémentation de la Gateway API qui remplace le contrôleur NGINX Ingress legacy sur cegedim.cloud. Il utilise NGINX comme plan de données, offrant un modèle opérationnel familier aux équipes utilisant déjà ingress-nginx.

F5 NGINX Gateway Fabric | NGINX Documentationnginx

Conformité Gateway API pour NGF :

Type de route	Canal	Version	Support NGF
HTTPRoute	Standard	v1 (graduated)	Oui
GRPCRoute	Standard	v1 (graduated)	Oui
TLSRoute	Expérimental	v1alpha2	Non
TCPRoute	Expérimental	v1alpha2	Non

TLSRoute (passthrough TLS brut vers le backend) n'est pas pertinent pour cegedim.cloud — la terminaison HTTPS au niveau de la gateway est suffisante pour tous les cas F5 L4.

Ce que la plateforme fournit

Vous n'avez pas besoin d'installer ou de configurer NGF. Les composants suivants sont déployés et gérés par l'équipe plateforme :

Composant	Namespace	Rôle
Contrôleur NGF	nginx-gateway	Surveille les ressources HTTPRoute/Gateway
internal-gateway	nginx-gateway	Point d'entrée pour le trafic interne (hostPort 80/443)
external-gateway	nginx-gateway	Point d'entrée pour le trafic externe (hostPort 8081/8443)
ReferenceGrant	nginx-gateway	Autorise les références HTTPRoute → Gateway cross-namespace

Le VIP F5 BigIP transfère le trafic vers les hostPorts de la gateway. Le TLS est terminé au niveau du F5 — NGF reçoit du HTTP simple, mais utilisez toujours https:// dans vos commandes curl/navigateur. Remplacez {{ cluster-name }} par le nom réel de votre cluster (ex. prod-paris, staging-lyon) dans tous les exemples ci-dessous.

Déployer votre application

Prérequis

• NGF est installé sur votre cluster (disponible auprès de l'équipe plateforme via ITCare)

• La ressource Gateway internal-gateway (ou external-gateway) existe dans le namespace nginx-gateway

Étape 1 — Déployer votre workload

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-web
  template:
    metadata:
      labels:
        app: nginx-web
    spec:
      containers:
      - name: nginx
        image: nginx:stable
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-web
spec:
  selector:
    app: nginx-web
  ports:
  - port: 80
    targetPort: 80

Étape 2 — Créer l'HTTPRoute

L'HTTPRoute est créée dans votre namespace applicatif. Elle référence l'internal-gateway dans le namespace nginx-gateway — cette référence cross-namespace est autorisée par le ReferenceGrant géré par l'équipe plateforme.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: nginx-web
spec:
  parentRefs:
  - name: internal-gateway
    namespace: nginx-gateway
  hostnames:
  - "nginx-web.{{ cluster-name }}.ccs.cegedim.cloud"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: nginx-web
      port: 80

Étape 3 — Vérifier

# Vérifier le statut de l'HTTPRoute
kubectl get httproute nginx-web

# La route est prête quand le statut affiche Accepted et ResolvedRefs = True
kubectl describe httproute nginx-web

# Tester le point d'accès
curl https://nginx-web.{{ cluster-name }}.ccs.cegedim.cloud/

Exemple avancé : Routage par chemin avec en-têtes de réponse

Cet exemple route le trafic /api vers un service API backend et / vers le serveur web NGINX, tout en ajoutant des en-têtes de réponse de sécurité :

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: nginx-web-advanced
spec:
  parentRefs:
  - name: internal-gateway
    namespace: nginx-gateway
  hostnames:
  - "myapp.{{ cluster-name }}.ccs.cegedim.cloud"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplacePrefixMatch
          replacePrefixMatch: /
    backendRefs:
    - name: my-api-service
      port: 8080
  - matches:
    - path:
        type: PathPrefix
        value: /
    filters:
    - type: ResponseHeaderModifier
      responseHeaderModifier:
        set:
        - name: X-Content-Type-Options
          value: nosniff
        - name: X-Frame-Options
          value: DENY
    backendRefs:
    - name: nginx-web
      port: 80

Les ressources HTTPRoute dans votre namespace applicatif prennent automatiquement la priorité de routage sur les routes catch-all de la plateforme, grâce à la spécificité du hostname — aucune coordination avec l'équipe plateforme n'est nécessaire lors de l'ajout ou de la suppression de routes.

Comparaison : Ingress vs HTTPRoute

Fonctionnalité	NGINX Ingress (legacy)	NGF HTTPRoute
Modèle de routage	Namespace unique, annotations	Multi-namespace, basé sur les rôles
Réécriture de chemin	annotation rewrite-target	filtre URLRewrite (standard)
En-têtes de réponse	configuration-snippet	filtre ResponseHeaderModifier
Liste blanche IP	whitelist-source-range	SnippetsFilter (alpha)
Authentification basique	auth-type: basic	AuthenticationFilter (alpha)
Portabilité	Spécifique au contrôleur	Fonctionne avec NGF, Traefik, Istio

Pour une référence complète annotation par annotation avec 15 cas d'usage, consultez le Migration vers la Gateway API (NGF).

Nettoyage

kubectl delete httproute nginx-web
kubectl delete service nginx-web
kubectl delete deployment nginx-web

Pour aller plus loin

gateway apiGateway API

Gateway API compatibility | NGINX Documentationnginx