Kube-OVN : un pont OVN entre Kubernetes et le réseau physique
Un pont entre SDN et Cloud Native (Projet sous CNCF). Prise en charge Vlan/Underlay : en plus du réseau superposé, Kube-OVN prend également en charge le réseau en mode sous-couche et VLAN pour de meilleures performances et une connectivité directe avec le réseau physique.
En bref
- De quoi s’agit-il ?
- Kube-OVN, projet CNCF Sandbox, intègre la virtualisation réseau OVN à Kubernetes. Cet article détaille son fonctionnement, ses modes overlay et underlay, et ses limites pour vous aider à décider si ce CNI correspond à votre infrastructure.
- À qui s’adresse-t-il ?
- Kube-OVN est adapté aux équipes qui ont besoin de contrôler finement le réseau Kubernetes, notamment avec des exigences de multi-tenant, de sous-réseaux par namespace, ou d'intégration au réseau physique via VLAN ou BGP. Il ne convient pas aux déploiements simples où un CNI classique comme Calico suffit, car sa complexité OVN demande des compétences réseau dédiées.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 1 jour.
- En quel langage est-il écrit ?
- Principalement Go, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 14 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Un CNI qui sort du cadre overlay
Kube-OVN ne se contente pas de fournir un réseau overlay pour les Pods. Il s'appuie sur OVN, un contrôleur de virtualisation réseau, pour offrir une gamme de fonctionnalités qui dépassent les besoins d'un cluster standard. Le projet est un CNI, mais il peut aussi fonctionner en tant que CNI secondaire, aux côtés de Cilium ou Calico. L'objectif est de répondre aux environnements qui ont besoin de connectivité directe avec le réseau physique, de multi-tenant avec des espaces d'adressage indépendants, ou encore de gestion fine des IP. Ce n'est pas un outil pour démarrer un cluster de découverte, mais pour des infrastructures où le réseau est un élément structurant.
Le fonctionnement : OVN au cœur de Kubernetes
Kube-OVN traduit les concepts Kubernetes en objets OVN. Chaque Subnet Kubernetes est adossé à un Logical Switch OVN. Les Pods d'un Namespace reçoivent des adresses IP allouées depuis le Subnet associé, avec possibilité de partager un Subnet entre plusieurs Namespaces. Pour la connectivité externe, le projet propose des modes overlay et underlay. En mode underlay, les Pods sont directement connectés au réseau physique, ce qui améliore les performances et permet une exposition directe des IP. Le trafic peut être géré par des Gateways distribués, où chaque nœud peut faire office de passerelle, ou par des Gateways par Namespace. Le projet intègre aussi un remplacement de kube-proxy avec des load balancers L2 intégrés à OVN, ce qui change l'architecture du trafic de service.
Installation et configuration : ce que dit la documentation
Le README ne donne pas de commande d'installation directe, mais renvoie vers un guide officiel. Il faut donc consulter la documentation stable pour la procédure complète. Le projet est distribué sous licence Apache-2.0 et se lance sur x86_64 et arm64. Les options de configuration passent par des Custom Resources comme Subnet, VPC, ou encore des annotations sur les Pods pour les IP statiques. Le projet fournit aussi un outil de diagnostic, kubectl-ko, mentionné dans la documentation. Pour un premier essai, le plus simple est de suivre le guide d'installation en une étape, qui déploie Kube-OVN dans un cluster existant. Il faut prévoir des ressources pour les composants OVN, qui sont plus lourds qu'un simple agent CNI.
Les fonctionnalités qui font la différence
Kube-OVN se distingue par des fonctionnalités rarement réunies dans un même CNI. Le support du multi-tenant avec des VPC indépendants est un atout pour les plateformes qui hébergent plusieurs équipes. La gestion des IP statiques pour les workloads, y compris KubeVirt, permet de conserver des adresses stables lors de migrations à chaud. Le projet propose aussi un IPAM cluster-wide pour d'autres plugins CNI comme macvlan ou host-device, ce qui est utile si vous utilisez plusieurs interfaces. Le support BGP permet d'exposer les IP des Pods ou des Subnets à l'extérieur, une fonctionnalité avancée pour les intégrations avec des routeurs physiques. Enfin, le Dynamic QoS permet de modifier les débits, priorités, pertes et latences à la volée, ce qui est pratique pour les tests de charge.
Les limites et les pièges à connaître
La complexité est le premier frein. Kube-OVN introduit des concepts OVN que les équipes doivent apprendre. Le mode underlay, s'il offre de meilleures performances, nécessite une planification minutieuse des plages d'adresses et une coordination avec l'équipe réseau. Le projet s'appuie sur OVS, qui peut consommer des ressources CPU importantes, même si le hardware offload est possible sur certains équipements. La documentation est fournie, mais elle ne remplace pas une expertise réseau. De plus, le projet est en phase Sandbox à la CNCF, ce qui signifie que la maturité est encore en cours de validation. Enfin, le support du DualStack est annoncé, mais il faut vérifier les versions de Kubernetes compatibles, car les fonctionnalités évoluent vite.
Comparaison avec une alternative : Calico
Calico est souvent le CNI par défaut pour les clusters Kubernetes. Son approche repose sur la gestion des routes BGP et des politiques réseau, sans virtualisation complète. Kube-OVN, lui, virtualise le réseau avec OVN, ce qui permet des fonctionnalités comme les VPC, les sous-réseaux par namespace, et les load balancers intégrés. Calico est plus simple à déployer et à comprendre, mais il n'offre pas le même niveau d'isolation multi-tenant ni la gestion fine des IP. Si vous avez besoin de connectivité underlay avec le réseau physique, Kube-OVN est plus adapté, car Calico se concentre sur le routage L3. En revanche, pour un cluster standard sans exigences particulières, Calico reste plus léger et plus facile à maintenir.
Maintenance, mises à jour et licence
Le projet est actif, avec des versions récentes comme v1.15.24 publiée en août 2026. Cela indique un cycle de corrections régulier. La maintenance implique de suivre les mises à jour de la branche v1.15, qui semble être la version stable. La licence Apache-2.0 est permissive, ce qui permet une utilisation commerciale sans restriction majeure, mais il faut vérifier les dépendances OVN et OVS, qui peuvent avoir leurs propres licences. La documentation mentionne un guide d'opérations avec kubectl-ko, ce qui suggère des outils de diagnostic intégrés. Pour les mises à jour, il faut planifier des fenêtres de maintenance, car les changements de schéma OVN peuvent nécessiter des migrations.
Conclusion éditoriale
Kube-OVN est adapté aux équipes qui ont besoin de contrôler finement le réseau Kubernetes, notamment avec des exigences de multi-tenant, de sous-réseaux par namespace, ou d'intégration au réseau physique via VLAN ou BGP. Il ne convient pas aux déploiements simples où un CNI classique comme Calico suffit, car sa complexité OVN demande des compétences réseau dédiées. Avant d'adopter, vérifiez la compatibilité de votre version de Kubernetes avec la branche v1.15, testez le mode underlay sur un petit cluster, et validez que vos workloads KubeVirt supportent la migration à chaud sans interruption. La documentation officielle reste la source de vérité pour les options de configuration.
Notes de la communauté