# ovn-kubernetes puts OVN and Open vSwitch under Kubernetes networking > ovn-kubernetes, OVN-Kubernetes, is an open-source networking project that provides a Kubernetes networking platform with OVN and Open vSwitch at its core, written as a conformant plugin to the CNI specifications. The repository is mostly the controller and the charts, while the documentation lives on a project site built with MkDocs and a plugin stack, and the project carries a full governance file set with adopters, meetings and a code of conduct. **ovn-kubernetes/ovn-kubernetes** — A robust Kubernetes networking platform - Repository: https://github.com/ovn-kubernetes/ovn-kubernetes - Website: https://ovn-kubernetes.io/ - Stars: 1,078 · Forks: 489 - Language: Go - License: Apache-2.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/ovn-kubernetes-ovn-kubernetes ## A conformant CNI plugin, not a proxy OVN-Kubernetes, Open Virtual Networking for Kubernetes, is an open-source project that provides a Kubernetes networking platform with OVN, Open Virtual Networking, and Open vSwitch, Open Virtual Switch, at its core. Two things in that sentence define the project. The first is that it is a plugin written according to the CNI, Container Network Interface, specifications, and that it is Kubernetes networking conformant, which means it satisfies the network plugin conformance tests rather than merely implementing the interface. The second is that it is a networking platform rather than a pod-to-pod mechanism, because OVN brings a logical switch and a logical router abstraction and Open vSwitch brings the datapath, and the Kubernetes-specific layer is a controller that translates objects into that model. The audience is a platform team that wants network policy and routing decided centrally rather than by a per-node agent. ## The documentation lives on its own site, and it is the primary artefact The README is a signpost, and the links it gives are the product. There is the welcome page for an overview, an architecture page, and then two deployment paths, deploying an OVN-Kubernetes cluster using KIND for a local cluster and deploying the OVN-Kubernetes CNI using Helm for a real one. There is a contributing page for how to get involved, a code of conduct file for the standards expected from everyone in the community, and a meet the community page for the details on community meeting details, which tells you that this project is run with a visible governance process rather than by whoever happens to have commit access. The badges make the same point from the other side, with a read the book badge pointing at the site, a build status badge for the test workflow on the master branch, a Go report card, a Go doc badge, a FOSSA status badge for licence scanning, and a Slack badge into the cloud-native workspace. A project that has a book, a meeting schedule and a code of conduct is a project that expects to be operated by more than one organisation. ## What is in the repository, and what is not The top-level entries describe the split between the code and everything around it. The Go source is in go-controller/, which is the controller that turns Kubernetes objects into OVN state, and the container images and deployment artefacts are in dist/ and helm/, with the Helm chart being the supported installation path. There is contrib/ for community contributions, hack/ for the scripts that maintainers use, test/ for the test suites, and docs/ for the parts of the documentation that live with the code rather than on the site, with a crd-docs-config.yaml that appears to generate reference documentation for the custom resource definitions. The documentation site itself is built with MkDocs, and the mkdocs.yml at the root is its configuration. The rest of the top level is process, with ADOPTERS.md listing organisations that use the project, CONTRIBUTING.md, CODEOWNERS, MAINTAINERS.md, MEETINGS.md, REVIEWING.md, SECURITY.md, GOVERNANCE.md and a CODE_OF_CONDUCT.md, plus a .licenserc.yaml and a LICENSES/ directory. The density of process files is itself informative about the maturity of the project. ## A documentation site assembled from MkDocs plugins The requirements.txt for the site is a long list of Python packages, and it is a good map of what the documentation does. MkDocs itself with the material theme and its extensions, the awesome pages plugin for structuring pages, the macros plugin for including content, mermaid2 for diagrams, glightbox for zoomable images, and a set of plugins that operate on the built output, with minify-html, jsmin and the minify plugin for making the HTML smaller, and redirects for keeping old URLs working, along with a git revision date localized plugin so pages show when they changed. There is also the mike tool pinned at 2.1.4, which is the tool for versioning documentation, so the site can publish the documentation for each release rather than only for the current branch. The rest are the ordinary content tooling, with Jinja2, Markdown, Pygments for syntax highlighting, Click, Tornado and livereload for the local preview, and PyYAML, MarkupSafe and six. It is a heavy dependency list for a documentation site, and it is what it takes to publish one set of docs for many Kubernetes and OVN versions. ## Governance, adopters and the code of conduct The Who uses OVN-Kubernetes section points at an ADOPTERS.md file and asks organisations or projects that use it to file a pull request and update the list, and to say hello on Slack as well. That request is a deliberate signal, because an adopter list is how a platform project argues for continued investment by other people. The rest of the governance surface is the set of files at the repository root. GOVERNANCE.md describes who decides, MEETINGS.md records the community meeting details, REVIEWING.md sets out how reviews happen, MAINTAINERS.md and CODEOWNERS say who looks after which part, CONTRIBUTING.md is where to start, SECURITY.md is how to report a vulnerability, and CODE_OF_CONDUCT.md is the standards the project expects from everyone. The copyright and licence position is Apache 2.0 for everything, with the LICENSES/ directory and its README explaining how the third-party licence files are determined for the repository, which is the detail a legal review will ask about. ## The release line and what changed in it The recent tags show a steady yearly line rather than a fast one, which is what you would expect from a component whose releases are tied to Kubernetes versions. OVN-Kubernetes v1.2.0 was published on 2025-12-22, v1.3.0 on 2026-05-06 and v1.4.0 on 2026-09-04, and the last push to the repository was on 2026-10-15. The default branch is master, and the project is not archived. The maintenance picture is therefore a healthy but not frantic one, with a release roughly every six months and continuous work between them. The pattern is worth holding in mind when you plan an upgrade, because a networking component that moves on a half-yearly cadence is not something you will pick up the day a Kubernetes version is released, and the compatibility between an OVN-Kubernetes release and a Kubernetes release is a question the documentation, rather than the release notes, will answer. ## What it costs to run, and what it replaces The honest comparison is with the lighter CNI options a cluster would otherwise use. A plugin that programs the node's network stack directly, without a central controller, has less to run and fewer failure modes, and it is the right choice for a cluster whose networking requirements are simple. OVN-Kubernetes is the other end of that trade, with a controller that owns logical switch and router state, which is what makes centralised network policy, multi-cluster networking and the other things a software defined network is for possible, and it is also what makes the system have a component that can become a single point of failure if it is misconfigured. The practical advice is to read the architecture page before deploying, because the overview says what the project is and the architecture page says what will be running in your cluster and where the state lives. And because this is a conformant plugin, the migration question is whether you want the conformance and the platform features, or whether you want the smallest possible networking footprint, because those are different products. ## Conclusion ovn-kubernetes is the right choice for a Kubernetes platform team that wants a software defined network with an explicit controller rather than a per-node overlay, because the controller is the component that makes network policy and routing decisions centrally instead of on every node. It is the wrong choice for a cluster that wants the smallest possible networking footprint, since the project brings OVN, Open vSwitch and its own controller into the picture, and it is a poor fit if you cannot run the KIND or Helm based deployment and read a large documentation site. Before you adopt it, read the architecture page rather than the overview, since the overview tells you what it is and the architecture page tells you what will be running in your cluster, and check the version you deploy against the Kubernetes version you run. ## FAQ ### What is ovn-kubernetes? It is an open-source project providing a Kubernetes networking platform with OVN, Open Virtual Networking, and Open vSwitch at its core. It is a Kubernetes networking conformant plugin written according to the CNI, Container Network Interface, specifications, and it runs a controller in the go-controller/ directory. ### How do I try ovn-kubernetes locally? The README links a guide for deploying an OVN-Kubernetes cluster using KIND for a local cluster, and a separate guide for deploying the OVN-Kubernetes CNI using Helm, which is the supported installation path with the chart in the helm/ directory of the repository. ### What is the release cadence of ovn-kubernetes? The recent releases are v1.2.0 on 2025-12-22, v1.3.0 on 2026-05-06 and v1.4.0 on 2026-09-04, with the last push to the repository on 2026-10-15. The project is not archived and the default branch is master. ### Under which licence is ovn-kubernetes distributed? Everything is distributed under the Apache License version 2.0. The LICENSES/ directory and its README describe how the third-party licence files are determined for the repository, and the README also carries a FOSSA status badge for licence scanning. ## Sources - [License: Apache-2.0](https://github.com/ovn-kubernetes/ovn-kubernetes/blob/master/LICENSE) - [ovn-kubernetes/ovn-kubernetes on GitHub](https://github.com/ovn-kubernetes/ovn-kubernetes) - [Project website](https://ovn-kubernetes.io/) - [README](https://github.com/ovn-kubernetes/ovn-kubernetes/blob/master/README.md) - [Releases](https://github.com/ovn-kubernetes/ovn-kubernetes/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ovn-kubernetes-ovn-kubernetes