Lab de migration Ingress-NGINX vers Kubernetes Gateway API (Course #gateway-api-migration)
For opérateurs Kubernetes, ingénieurs plateforme, SRE, ingénieurs sécurité.
À la fin, vous saurez
À l'issue de cette formation, vous saurez migrer un parc Ingress-NGINX vers Gateway API sur preuves — inventaire d'annotations classé en trois catégories, suite de parité automatisée et retour arrière répété — afin que le trafic ne bouge qu'après mesure du changement de comportement, et non sur hypothèse.
Cas fil rouge
Halvorsen Media sert 6 propriétés de streaming et de publicité sur 3 clusters derrière Ingress-NGINX, avec 190 objets Ingress portant 47 annotations distinctes, dont 11 à base de snippets. Depuis l'arrêt des mises à jour de sécurité du contrôleur en mars 2026, l'équipe sécurité laisse 2 trimestres à l'équipe plateforme pour en sortir sans interruption visible des partenaires. Le pic atteint 12 000 req/s pendant les directs, et le chemin de diffusion publicitaire ne tolère aucun changement de comportement sur la taille des requêtes.
Programme chaque ligne est quelque chose que vous faites
4 modules · 12 sujets · dans l'ordre du cours
-
Module 1
Inventorier avant de convertir
Objectif. Produire l'inventaire des annotations et des routes qui détermine quelle part du parc un convertisseur peut réellement reprendre.
- Extraire chaque objet Ingress et chaque annotation des 3 clusters et les classer par trafic servi, non par nombre
- Signaler d'abord le sous-ensemble sensible pour la sécurité : les annotations de snippet injectent de la configuration arbitraire et sont citées comme motif du retrait
- Consigner ce que le retrait signifie réellement : les installations existantes continuent de servir, mais ne reçoivent plus ni version, ni correctif, ni mise à jour de sécurité
-
Module 2
Ce que le convertisseur ne reprendra pas
Objectif. Classer chaque annotation inventoriée en traduite, spécifique à l'implémentation, ou sans équivalent sur la cible.
- Lancer la conversion et traiter les avertissements comme le livrable : plus de 30 annotations courantes se traduisent, les annotations propres à un fournisseur pas nécessairement
- Traiter explicitement les cas sans équivalent : proxy-body-size n'a pas d'équivalent Gateway API et n'est pas traduit
- Trancher au cas par cas entre extension propre à un emitter et changement de conception, et consigner le motif pour les 47 annotations
-
Module 3
La parité est une suite de tests
Objectif. Construire la suite de parité automatisée qui doit passer avant tout déplacement de trafic de production.
- Vérifier précédence de matching, réécriture, traitement des en-têtes et réponses d'erreur sur 100 % des routes portant du trafic partenaire
- Tester explicitement le chemin de taille de requête, un changement de plafond silencieux restant invisible jusqu'au premier envoi réel qui échoue
- Exécuter la suite simultanément sur les deux stacks et exiger zéro différence inexpliquée avant de planifier la bascule
-
Module 4
Un retour arrière déjà répété
Objectif. Concevoir puis éprouver le chemin de retour arrière, et séquencer les vagues de bascule en fonction de lui.
- Répéter le retour arrière de bout en bout dans une fenêtre de reprise de 15 minutes avant la première vague, et non après
- Séquencer les vagues par rayon d'impact, en démarrant sous 5 % du trafic de pic et en maintenant chaque vague un cycle d'événement complet
- Définir à l'avance les signaux d'abandon — taux d'erreur, latence p99, incidents remontés par les partenaires — et qui a autorité pour les déclencher
Références & documentation officielle chaque affirmation ci-dessus a une source
Module 1
- IngressDoc MuleSoft
- Ingress NGINX Retirement: What You Need to KnowDoc MuleSoft
Module 2
- Additional annotations support for ingress-nginxcommunity
- Announcing Ingress2Gateway 1.0Doc MuleSoft
Module 3
- Gateway API getting startedDoc MuleSoft
- Gateway API implementationsDoc MuleSoft
Module 4
- HTTPRouteDoc MuleSoft