Praticien des gateways API cloud-native (Course #cloud-native-gateway)

Programme chaque ligne est quelque chose que vous faites

7 modules · 21 sujets · dans l'ordre du cours

1. Module 1

   Trois rôles, trois ressources

   Objectif. Concevoir la séparation des rôles présupposée par Gateway API et produire la répartition RBAC qui rend les équipes applicatives propriétaires de leurs routes.

   • Associer GatewayClass, Gateway et HTTPRoute aux 3 personas nommés par la spécification : fournisseur d'infrastructure, opérateur de cluster, développeur applicatif
   • Découper le RBAC pour qu'une équipe fusionne une route sans toucher aux listeners, ramenant les 9 jours de revue à une seule approbation d'équipe
   • Modéliser les règles de listener, de hostname et de rattachement de route, et prouver quel namespace peut se rattacher à quel listener
2. Module 2

   Des routes qui survivent au renommage

   Objectif. Construire un jeu de routes dont le matching, la réécriture et la répartition de trafic sont spécifiés plutôt qu'hérités d'un défaut de contrôleur.

   • Exprimer précisément le matching par chemin, en-tête et méthode, et résoudre la précédence entre 4 règles qui se recouvrent
   • Mettre en œuvre une répartition pondérée pour un canari à 5 % et prouver la répartition par des preuves au niveau requête
   • Sortir les filtres — réécriture, redirection, mutation d'en-tête — des annotations vers des filtres de route déclarés
3. Module 3

   Kong de bout en bout

   Objectif. Déployer le jeu de routes de référence sur Kong et relever les comportements exigeant une extension propre à Kong.

   • Installer le contrôleur et lier une GatewayClass, puis réconcilier tout le jeu de routes sans aucune édition manuelle
   • Attacher 3 policies — authentification, limitation de débit, transformation de requête — et relever lesquelles sont portables et lesquelles sont propres à Kong
   • Lire explicitement l'ordre d'exécution des plugins ; un changement de priorité entre versions réordonne silencieusement une chaîne de policies
4. Module 4

   Traefik de bout en bout

   Objectif. Déployer le jeu de routes identique sur Traefik et produire le rapport de divergence entre les deux data planes.

   • Réconcilier le même jeu de routes sur un second data plane et compter les ressources n'ayant demandé aucune modification
   • Comparer le comportement des 2 implémentations sur la précédence du matching, le traitement des en-têtes et les réponses d'erreur
   • Consigner chaque divergence comme écart de conformité ou extension propre à l'implémentation, preuve à l'appui
5. Module 5

   L'identité à la frontière

   Objectif. Mettre en œuvre la vérification OAuth 2.0 et OIDC sur la gateway et prouver l'identité réellement reçue par le backend.

   • Valider les JWT en frontière — émetteur, audience, expiration, rotation de clés — et rejeter sur ces 4 critères sans atteindre le backend
   • Terminer puis ré-initier TLS pour un partenaire en TLS mutuel, en gardant l'identité client lisible en aval
   • Comparer la requête avant et après la gateway pour prouver qu'aucun en-tête d'autorisation n'est supprimé ni remappé au passage
6. Module 6

   Des limites qui tiennent

   Objectif. Configurer une limitation de débit dont l'application est mesurée sous partition plutôt que supposée d'après la configuration.

   • Choisir délibérément une stratégie de comptage : local, cluster et magasin partagé diffèrent d'un facteur égal au nombre N de nœuds
   • Couper le magasin de compteurs 60 secondes sous charge et relever ce que le limiteur a réellement appliqué pendant la panne
   • Comparer les implémentations data plane de la même limite sur Envoy et Kong, et documenter la précision atteinte par chacune
7. Module 7

   Réconcilier, observer, prouver

   Objectif. Exploiter le parc en GitOps et démontrer son comportement sous un profil de charge correspondant au pic de production.

   • Réconcilier configuration déclarée et configuration active à chaque merge et faire échouer le build à la moindre dérive
   • Émettre métriques RED et traces distribuées depuis le data plane, avec une trace échantillonnée sur au moins 1 % des requêtes
   • Tester en charge sur le profil de pic des 4 régions et relever latence p99 et taux d'erreur face à une cible de 400 ms

Références & documentation officielle chaque affirmation ci-dessus a une source

Module 1

• Kubernetes Gateway APIDoc MuleSoft

Module 2

• HTTPRouteDoc MuleSoft

Module 3

• Kong plugin execution and priorityDoc MuleSoft

Module 4

• Traefik Proxy documentationDoc MuleSoft

Module 5

• OpenID Connect Core 1.0Spécification
• RFC 7519 — JSON Web Token (JWT)Spécification

Module 6

• Envoy global rate limitingDoc MuleSoft
• Rate Limiting Advanced pluginDoc MuleSoft

Dans la filière Architecture