KubeVPN : connecter votre poste au réseau du cluster Kubernetes sans VPN d'entreprise

Ce que KubeVPN résout concrètement

Le problème est connu de toute personne qui développe une application destinée à Kubernetes : en local, vous n'avez pas accès au réseau du cluster. Vous ne pouvez pas joindre un Service par son nom DNS, ni tester votre code contre une base de données qui tourne dans un Pod. KubeVPN attaque ce problème en créant un tunnel réseau entre votre machine et le cluster. Une fois connecté, vous pouvez ping un Pod par son IP, faire un curl vers un Service par son nom complet, et même intercepter le trafic entrant d'un Service pour le rediriger vers votre poste. L'outil vise les développeurs qui veulent un environnement de développement identique à la production, sans pour autant déployer chaque modification dans le cluster. La documentation le présente comme un environnement de développement cloud natif, mais l'usage réel est plus modeste : c'est un client VPN dédié à Kubernetes, avec une fonction d'interception en plus.

Le mécanisme sous le capot : un tunnel et un traffic manager

KubeVPN ne se contente pas d'établir un tunnel VPN générique. Il déploie dans le cluster un ensemble de ressources nommé `kubevpn-traffic-manager`. La sortie de la commande `kubevpn connect` le montre clairement : l'outil crée un ServiceAccount, des Roles, un RoleBinding, un Service et un Deployment. Ce Deployment lance un Pod avec deux conteneurs, l'un nommé `xds` et l'autre `vpn`. Le conteneur `xds` agit probablement comme un serveur de configuration qui transmet les informations réseau du cluster (CIDR des Pods, des Services, du réseau CNI) à votre client local. Le conteneur `vpn` établit le tunnel proprement dit. Sur votre machine, la commande demande le mot de passe sudo pour créer une interface TUN (par exemple `utun4` sur macOS, visible dans la sortie de `kubevpn status`). Une fois le tunnel établi, votre poste fait partie du réseau du cluster : les paquets destinés aux IP des Pods ou des Services sont routés à travers cette interface. La résolution DNS est aussi prise en charge, puisque vous pouvez utiliser `productpage.default.svc.cluster.local` directement.

Installation et prise en main : cinq méthodes, une seule commande

L'installation est variée, ce qui est un point fort pour un outil en Go. Sur macOS et Linux, vous avez le script `curl -fsSL https://kubevpn.dev/install.sh | sh` ou la formule Homebrew `brew install kubevpn`. Sous Linux, Snap est disponible avec `sudo snap install kubevpn`. Sous Windows, Scoop fonctionne avec `scoop bucket add extras` puis `scoop install kubevpn`. Enfin, pour ceux qui vivent dans kubectl, l'installation via Krew est possible : `kubectl krew index add kubevpn https://github.com/kubenetworks/kubevpn.git`, puis `kubectl krew install kubevpn/kubevpn`. La commande principale est `kubevpn connect`. Elle demande le mot de passe de votre session pour créer l'interface TUN, puis elle affiche une progression pas à pas : récupération des CIDR, création des ressources dans le namespace `default`, attente que le Pod `kubevpn-traffic-manager` soit prêt. L'état de la connexion se vérifie avec `kubevpn status`, qui affiche l'ID de connexion, le cluster, le kubeconfig utilisé, le namespace et l'interface réseau. Pour tester, la documentation propose d'appliquer le manifeste `bookinfo.yaml` fourni dans le dépôt, puis de pinger un Pod ou de faire un curl vers un Service.

Ce que la résolution DNS apporte de plus qu'un simple VPN

Un VPN classique vous donne un accès IP, mais pas la résolution de noms Kubernetes. KubeVPN, lui, gère la résolution DNS directement. La documentation indique qu'un Pod ou Service nommé `productpage` dans le namespace `default` est joignable par trois noms : `productpage`, `productpage.default`, et `productpage.default.svc.cluster.local`. C'est un gain de confort non négligeable : vous n'avez pas à chercher l'IP d'un Service avant de lancer un test. Cela signifie aussi que l'outil intègre un mécanisme de résolution DNS qui doit intercepter les requêtes de votre système. Sur macOS, cela passe probablement par une configuration du résolveur, mais la documentation ne précise pas le détail. Ce point est important à vérifier si vous utilisez déjà un VPN d'entreprise ou un outil de résolution DNS local : il peut y avoir des conflits.

Interception de trafic : la promesse du mesh, mais avec des limites

La fonction la plus avancée de KubeVPN est l'interception du trafic entrant d'un Service Kubernetes pour le rediriger vers votre machine locale. La description parle de 'service mesh', ce qui suggère que l'outil peut injecter un sidecar ou modifier les règles de routage pour capturer les requêtes destinées à un Service et les envoyer à votre poste. Cependant, la documentation tronquée que nous avons ne donne pas d'exemple concret de cette fonction. Aucune commande du type `kubevpn intercept` ou `kubevpn proxy` n'apparaît dans le README. Il faut donc se méfier : la fonction existe peut-être, mais elle n'est pas documentée dans les extraits fournis. Si vous avez besoin d'interception, il faudra consulter le wiki ou les sources pour comprendre comment l'activer. C'est un manque de documentation qui peut freiner l'adoption, car l'interception est souvent la raison principale pour laquelle on choisit un outil comme celui-ci.

Limites et cas où KubeVPN est le mauvais choix

La première limite est l'exigence de privilèges. `kubevpn connect` demande le mot de passe root pour créer une interface TUN. Sur un poste d'entreprise verrouillé, cela peut être impossible. Ensuite, l'outil déploie des ressources dans le cluster : un ServiceAccount, des Roles, un RoleBinding, un Service et un Deployment. Si votre cluster a des politiques de sécurité strictes (PodSecurityPolicies, NetworkPolicies, admission controllers), le Pod `kubevpn-traffic-manager` risque de rester en état `Pending`, comme le montre la sortie de la commande dans le README. L'outil modifie aussi le namespace `default` en le labelisant, ce qui peut avoir des effets de bord si vous avez des contrôles automatiques. Enfin, KubeVPN n'est pas un outil de production : il est conçu pour le développement local. L'utiliser sur un cluster partagé avec d'autres équipes peut perturber le trafic, surtout si vous activez l'interception. Si vous avez juste besoin d'accéder à un Service précis, `kubectl port-forward` est plus simple et ne demande aucun privilège supplémentaire.

Alternatives : Telepresence et le port-forward classique

L'alternative la plus connue est Telepresence, qui suit une approche différente : il injecte un agent sidecar dans le Pod de votre application, puis redirige le trafic vers votre machine locale. Telepresence ne crée pas d'interface TUN sur votre poste, il utilise un processus local qui écoute sur les ports. Cela évite la demande de mot de passe root. En revanche, Telepresence nécessite de modifier le Deployment de votre application, ce que KubeVPN ne fait pas, du moins dans la partie que nous avons vue. L'autre alternative, plus rudimentaire, est `kubectl port-forward`, qui ne donne accès qu'à un seul Service ou Pod, sans résolution DNS, mais qui est intégré à kubectl et ne demande aucune installation. Pour un besoin ponctuel, c'est souvent suffisant. KubeVPN se positionne donc entre les deux : plus complet que le port-forward, mais moins invasif que Telepresence. Le choix dépend de votre besoin : accès réseau complet ou simple redirection de port.

Maintenance et licence : un projet actif sous MIT

Le dépôt est actif, avec des versions récentes : v2.11.6 en juillet 2026, précédée de v2.11.5 et v2.11.4. La branche par défaut est `master`, et le projet n'est pas archivé. La licence est MIT, ce qui autorise une utilisation commerciale sans restriction majeure, à condition de conserver la notice de copyright. C'est un point positif pour une adoption en entreprise. La maintenance semble régulière, mais il faut noter que le projet est porté par une seule organisation (kubenetworks) et que la documentation est encore lacunaire sur certaines fonctions. Le coût de mise à niveau est faible : il suffit de télécharger la nouvelle version binaire, car les commandes restent stables. Toutefois, les changements dans les versions mineures peuvent modifier le comportement du traffic manager, donc il est prudent de vérifier les notes de version avant de mettre à jour sur un cluster partagé.

Conclusion éditoriale

KubeVPN s'adresse aux développeurs qui travaillent sur des applications déployées dans Kubernetes et qui veulent les exécuter en local tout en conservant l'accès aux autres Services du cluster. Ce n'est pas un outil pour les équipes qui cherchent une solution de mesh complète ou qui n'ont pas les droits d'admin sur le cluster. Avant de l'adopter, vérifiez que votre cluster accepte la création d'un Deployment et d'un ServiceAccount dans le namespace cible, et que votre poste peut créer une interface TUN (sudo requis). Testez d'abord avec la commande `kubevpn connect` sur un cluster de développement, car l'outil modifie le namespace et les règles réseau. Si votre besoin se limite à un accès ponctuel, un simple `kubectl port-forward` suffit. Pour de l'interception avancée, comparez avec Telepresence, qui utilise un agent sidecar.

Sources officielles

1. Official documentation
2. Official README
3. Project repository
4. Release notes