Bonnes pratiques Envoy Gateway : rendez service à votre futur vous avant la production

"Ça tourne" et "le système est réellement stable" sont deux univers complètement différents. La plupart des incidents sur la couche d'entrée ne viennent pas d'un manque d'Envoy Gateway, mais d'une configuration montée trop légèrement, qui transforme l'exploitation en boîte à surprises permanente. Cet article rassemble les recommandations les plus utiles sous forme de checklist.

Pratiques recommandées

1. Soyez clair sur qui possède Gateway et qui possède les Routes

Si plusieurs personnes sont impliquées, séparez les responsabilités :

L'équipe plateforme gère GatewayClass, Gateway
Les équipes applicatives gèrent leur propre HTTPRoute

Le bénéfice : la sécurité et la surface d'exposition de la couche d'entrée ne sont pas modifiées au hasard par chaque application qui arrive, tandis que les équipes applicatives conservent la flexibilité de routage. C'est précisément pour cela que la conception de Gateway API vaut la peine d'être utilisée ; ne l'aplatissez pas à nouveau en un énorme blob YAML monolithique.

2. Traitez TLS comme la valeur par défaut dès le départ

Ne vous dites pas "d'abord HTTP, on ajoutera HTTPS plus tard." Ce "plus tard" se transforme presque toujours en urgence un vendredi soir.

Au minimum :

Les listeners externes utilisent HTTPS par défaut
Les sources de certificats suivent un processus de gestion défini
Les workflows de test, auto-signés et CA de production restent séparés

Si vous avez déjà cert-manager, intégrez-le. La rotation automatique des certificats est bien plus fiable que de patcher des Secrets à la main à chaque renouvellement.

3. Écrivez les règles de route explicitement, n'optimisez pas trop pour la commodité

Des règles comme celle-ci sont pratiques, mais elles finissent souvent en trous noirs :

rules:
  - backendRefs:
      - name: backend
        port: 8080

Ce n'est pas faux, mais à mesure que le système grossit, trop de règles "attrape tout" rendent le débogage pénible. Si vous pouvez écrire hostnames, si vous pouvez écrire path, écrivez-les clairement.

4. Faites des découpes de trafic petites, ne basculez pas tout d'un coup

Lorsque vous lancez une nouvelle version, commencez par un faible pourcentage de trafic :

backendRefs:
  - name: api-v1
    port: 8080
    weight: 90
  - name: api-v2
    port: 8080
    weight: 10

C'est beaucoup plus doux que de "retourner tout le selector du service en une seule fois". Quand les choses tournent mal, le rollback est aussi bien plus rapide, et à 3 heures du matin, vous en serez très reconnaissant.

5. Prenez l'habitude de vérifier `status` et les événements

Lire le YAML ne suffit pas, il faut voir si le contrôleur a réellement accepté votre configuration :

kubectl get gateway -A
kubectl get httproute -A
kubectl describe gateway eg
kubectl describe httproute app-route

Ces catégories de problèmes ne se voient souvent pas uniquement à partir de spec :

Route non acceptée
Référence inter-namespace bloquée
Anomalies sur le status du listener

Le pire, ce n'est pas un bug, c'est "je croyais que c'était pris en compte, mais ça n'a jamais été traité."

Pièges courants

Piège 1 : traiter Envoy Gateway comme une boîte noire stupide de forwarding

Ce n'est pas juste un outil qui déplace des paquets de A vers B. La documentation officielle le présente explicitement comme un API Gateway natif Kubernetes, avec de la place pour superposer plus tard des politiques de trafic et de sécurité. Si vous ne l'utilisez que comme remplaçant d'Ingress, vous sous-exploitez massivement l'outil.

Piège 2 : référencer des certificats inter-namespace sans `ReferenceGrant`

Beaucoup de gens voient que certificateRefs prend en charge un champ namespace et pointent directement vers un autre namespace, puis se demandent pourquoi rien ne se passe. La réponse n'a rien de paranormal : il manque généralement un ReferenceGrant.

Piège 3 : ne tester que le happy path

Ne testez pas seulement :

curl http://... réussit une fois

Testez aussi :

Des hostnames différents
Des paths différents
La validité du certificat TLS
Si les ratios de répartition du trafic se comportent comme prévu

La couche d'entrée est la plus dangereuse quand le happy path paraît parfait mais que les cas limites cassent immédiatement.

Piège 4 : utiliser la configuration de démo telle quelle en production

Le quickstart officiel est excellent pour apprendre, mais il reste positionné comme un quickstart. Pour la production, ajoutez au minimum :

L'automatisation des certificats
Le monitoring et l'alerting
Un processus de gestion des changements
Des conventions de nommage pour les routes

Sinon, le quickstart d'aujourd'hui devient la chute rapide de demain.

Une checklist minimale avant mise en ligne

Utilisez ceci avant la mise en production :

Le listener du Gateway sépare-t-il clairement HTTP / HTTPS ?
Le Secret de certificat et le processus de rotation sont-ils bien définis ?
HTTPRoute possède-t-il des hostnames / matches clairs ?
Les changements significatifs sont-ils déployés via de petites découpes de trafic ?
Pouvez-vous localiser rapidement les problèmes à partir de status et des événements ?

Si les cinq points sont en place, vous opérez déjà à un niveau supérieur à "ça marche donc c'est bon".

Résumé en une ligne

La vraie valeur d'Envoy Gateway, ce n'est pas seulement de router du trafic, c'est de rendre la configuration de votre couche d'entrée plus standardisée, plus divisible et plus gouvernable. Les fonctionnalités sont temporaires ; l'exploitation est de long terme. Être gentil avec votre futur vous compte vraiment.

Étape suivante

Si vous gardez encore cette question dans un coin de la tête :

"Je comprends le concept, mais quand une nouvelle exigence arrive, quel type de route dois-je réellement choisir ?"

L'article suivant est votre antisèche : 👉 Antisèche des types de routes