VPN par Pod dans Kubernetes ou passerelle de sortie : à qui appartient le tunnel ?

Vous déployez un Pod nommé vpn-gateway, pointez un client de test vers son adresse et voyez les paquets disparaître. Rien dans le manifeste n’est faux et le kubelet n’a rien à redire. La raison est structurelle et non configurationnelle : Kubernetes donne à chaque Pod son propre espace de noms réseau, donc un nom, une étiquette ou un espace de noms d’API partagé ne changent rien à l’endroit où vont les paquets. Décider comment le trafic VPN quitte le cluster commence donc par une question de propriété, pas d’images de conteneur.

Deux mécanismes couvrent la plupart des déploiements réels, et ils ne sont pas interchangeables. L’un place le tunnel dans l’espace de noms réseau de la charge de travail elle-même. L’autre demande au CNI d’acheminer un trafic sélectionné via un nœud de passerelle désigné. Ils échouent différemment, montent en charge différemment et répondent à des équipes différentes, ce qui explique pourquoi la question du conteneur produit souvent des débats qui ne se règlent jamais.

La frontière d’un Pod est un espace de noms, pas un hôte de saut

Un espace de noms réseau Linux possède ses interfaces, adresses, routes et règles de pare-feu, et chaque Pod en reçoit un. Les conteneurs de ce Pod le rejoignent, et c’est exactement pourquoi un conteneur auxiliaire peut réécrire des routes que l’application suit ensuite. Un Pod voisin possède une pile d’apparence identique mais entièrement séparée. Il n’existe aucune table partagée qu’un Pod passerelle pourrait hériter, ni de transfert implicite de trafic d’un espace de noms à un autre.

C’est aussi pourquoi le modèle du Pod passerelle ne fonctionne que lorsque quelque chose en amont lui envoie réellement des paquets : un Service, une route statique sur le nœud ou une politique d’acheminement dans le CNI. Une adresse seule n’attire rien.

Ce qu’un tunnel par Pod apporte, et ce qu’il coûte

Un tunnel exécuté dans l’espace de noms de la charge de travail donne à celle-ci sa propre identité client, que de nombreux services d’accès distant exigent avant d’autoriser ou de comptabiliser une session. Le rayon d’impact reste local lui aussi : un tunnel cassé retire un Deployment au lieu du chemin partagé utilisé par tout le reste. La façon dont il s’exécute dépend de l’implémentation, et c’est là que les gens se trompent.

Une installation qui n’a besoin que de l’état du noyau peut se terminer dans un conteneur init et sortir. Un démon en espace utilisateur qui doit rester vivant pendant toute la durée de vie du Pod a besoin de la forme de conteneur init redémarrable introduite comme sidecar natif dans Kubernetes 1.29, et cette distinction vient de l’implémentation du tunnel, pas du goût. Le coût de ce modèle est la duplication : chaque réplique s’authentifie, reçoit sa propre adresse de tunnel et consomme un créneau de session distante, si bien qu’un événement d’autoscaling devient un événement de capacité de l’autre côté du lien. Copier un seul identifiant dans toutes les répliques ne supprime pas ce coût, cela supprime la piste d’audit. Les capacités méritent le même examen, car un tunnel qui veut NET_ADMIN dans son propre espace de noms n’a aucune raison d’hériter de l’autorité sur tout l’hôte d’un exemple avec privileged: true.

Quand le CNI possède la sortie

Si le CNI le permet, une passerelle de sortie sélectionne le trafic par charge de travail et plage de destination, puis l’envoie via des nœuds choisis sous une adresse source prévisible. La version de Cilium est la référence courante, et sa documentation précise que la fonction nécessite une configuration Cilium spécifique ainsi que des nœuds de passerelle dotés des bonnes interfaces et adresses. Elle signale aussi une période initiale après la création du Pod pendant laquelle l’acheminement n’est pas encore appliqué, ce qui est une donnée de conception et non une note de bas de page.

Lisez ce délai à la lumière de votre propre promesse. Si la règle est qu’aucun trafic ne peut sortir par un autre chemin, un nouveau Pod qui émet pendant l’intervalle l’a déjà enfreinte, donc la séquence de démarrage a besoin de sa propre réponse : retenir l’application jusqu’à ce que la politique s’applique, ou accepter la fenêtre et la documenter.

Gardez l’affirmation étroite. Une passerelle de sortie choisit et traduit un chemin. Elle ne met pas fin à un VPN, et elle ne transforme pas le cluster en client de votre réseau distant sans une connexion prise en charge derrière elle.

La traduction change discrètement ce que voit le côté distant

Une fois que la passerelle réécrit la source, les adresses par Pod disparaissent, donc une liste d’autorisation fondée sur l’identité devient une liste fondée sur une adresse partagée. C’est un compromis et non un défaut : moins de règles à maintenir, une attribution plus grossière quand quelque chose se comporte mal.

L’authentification au niveau applicatif et la journalisation des requêtes doivent porter ce que le réseau ne rapporte plus. Traitez la capacité et le remplacement de la passerelle comme une infrastructure partagée, car le redémarrage d’un seul nœud interrompt désormais chaque charge de travail derrière lui, et vérifiez tôt le chemin de retour : l’extrémité distante doit savoir joindre l’adresse traduite, généralement via une route ou un NAT qu’une personne, pas un manifeste, doit posséder. La planification d’adresses en fait partie aussi, car des plages de cluster et distantes qui se chevauchent cassent l’un ou l’autre modèle et adopter IPv6 n’excuse pas un plan contradictoire.

Décidez par la propriété, puis testez la panne que vous avez promise

Choisissez le tunnel par Pod lorsque le service distant authentifie des charges de travail individuelles, lorsque seuls quelques Deployment ont besoin du lien et lorsqu’une panne doit rester locale. Choisissez la passerelle lorsqu’une équipe réseau possède déjà le chemin, lorsque de nombreuses charges partagent une destination et lorsqu’une adresse source stable est tout l’objet de l’exercice.

Dans tous les cas, vérifiez la propriété que vous avez vendue plutôt que le régime permanent. Créez un Pod, laissez-le émettre immédiatement et observez les premières secondes si la promesse était que rien ne s’échappe du tunnel. Passez à cinq répliques et comptez les sessions que l’extrémité distante rapporte si la promesse était l’identité par charge de travail. Ces deux contrôles exposent les limites du mécanisme bien plus vite qu’une revue du manifeste, et ils vous disent quelle équipe possède le prochain incident.