Antrea: Kubernetes networking and policy on an Open vSwitch data plane

The gap Antrea fills between stock NetworkPolicy and a service mesh

Kubernetes ships a NetworkPolicy API and nothing to implement it. Every cluster therefore picks a CNI plugin that also enforces policy, and the choice matters because the API itself is narrow. Stock NetworkPolicy has no notion of ordering, no cluster-scoped rules, no policy for a Node as an object, and no way to attach policy to a virtual machine outside the cluster. Antrea's answer is a second policy model layered on the Kubernetes one: Antrea-native policies add policy tiering, rule priorities, cluster-level policies and Node policies, documented in docs/antrea-network-policy.md. The audience is platform teams running multi-tenant clusters where one team's deny rule must not silently override another's allow rule, and operators who want to see flow data rather than infer it from dropped packets.

The project describes itself as Kubernetes native and operates at Layer 3/4. That scope matters. Antrea is not a service mesh: it does not terminate or route application-layer traffic, and the README does not claim L7 policy. If your requirement is mutual TLS between services or HTTP-aware routing, this is the wrong layer, and the README points elsewhere for that work.

How Open vSwitch becomes the data plane

The mechanism is stated plainly in the README: Antrea leverages Open vSwitch as the networking data plane, and uses it to implement all networking functions including Kubernetes Service load balancing. That single decision explains most of the project's shape. Because OVS is a programmable virtual switch, policy enforcement becomes a matter of programming flows rather than inserting iptables rules per endpoint, which is the efficiency argument the README makes for implementing Network Policies. The Go module list confirms the plumbing: antrea.io/libOpenflow, antrea.io/ofnet and ovn-kubernetes/libovsdb are direct dependencies, so the agent talks to the switch over OpenFlow and OVSDB rather than through a shell wrapper.

The same portability is why the README can claim Windows Node support with the same data plane implementation on Linux and Windows. The trade-off is a hard prerequisite: the Open vSwitch kernel module must be present on every Kubernetes node. That is not a soft dependency you can install later from a DaemonSet in all environments. On managed node images where you cannot add kernel modules, Antrea is simply not deployable, and the README does not offer a userspace fallback for that case.

Installing Antrea and reading your first policy

The README states that Antrea is deployed by applying a single YAML manifest file and that getting started takes only a few minutes, with the detailed walkthrough in docs/getting-started.md. Before applying anything, confirm the two prerequisites: Kubernetes 1.23 or later, and NodeIPAMController enabled. The README gives the kubeadm case explicitly: when deploying a cluster with kubeadm the --pod-network-cidr option must be specified.

kubeadm init --pod-network-cidr <cidr>

The README notes that NodeIPAMController must be enabled, and that alternatively Antrea Controller's own NodeIPAM feature should be enabled and configured. If neither is true, pod IP allocation has no source. The manifest itself is not reproduced in the README, so take the apply command from docs/getting-started.md rather than guessing a URL. After the DaemonSet rolls out, the CLI the project ships is antctl, and the Makefile exposes it as a build variable.

ANTCTL_BINARY_NAME ?= antctl

The Makefile builds Go binaries with CGO disabled by default, which is what you want for a binary you copy between hosts. For policy work, the object to learn is the Antrea-native policy rather than the Kubernetes one, because tiering and priorities only exist there. The README points at docs/antrea-network-policy.md for the full feature list; read that before writing rules, since a rule placed in the wrong tier will not behave the way a stock NetworkPolicy would.

Where Antrea is the wrong tool

The kernel module requirement is the first real boundary, and it is not negotiable in the documentation. A cluster on a node image that cannot load Open vSwitch has no supported path here. The second boundary is scope: Antrea operates at Layer 3/4, so anything that needs application-layer inspection belongs to a different component. The README's own observability story leans on a separate project, Theia, for flow visualization in Grafana dashboards and for recommending Network Policies, which tells you the core repository is not trying to be the analytics product.

The third boundary is operational surface. Antrea is not a single binary you drop on a node. It brings a controller, per-node agents, a CNI plugin, CRDs for the Antrea-native policy model, and optionally multi-cluster and VM policy components. The README lists encryption via IPsec or WireGuard, multi-cluster federation, and Windows support as features, and each of those is a subsystem with its own failure modes. A team that wants pod-to-pod connectivity and nothing more is paying for a policy engine and a flow pipeline it will not use. Nothing in the README documents a rollback procedure for removing Antrea from a running cluster, so plan the exit before the entry.

Antrea versus Calico: different data planes, different defaults

The comparison people actually search for is Antrea against Calico, and the meaningful difference is architectural rather than a feature checklist. Antrea's data plane is Open vSwitch, a programmable virtual switch with OpenFlow and OVSDB as its control surfaces, and the README ties Service load balancing and hardware offloading to it. Calico's widely known approach is routing and iptables/eBPF-based policy without a virtual switch in the path. That changes what you can express at the flow level and what you must install on the host.

The practical consequence: Antrea gives you a switch you can program and observe, at the cost of a kernel module on every node. A routing-based design avoids that module but gives up the OVS programming model. Neither is strictly better; the deciding question is whether your node images can carry Open vSwitch and whether you want switch-level flow control. The README does not contain a Calico comparison, so treat any detailed feature-by-feature table you find elsewhere as someone else's work, not the project's claim. For Cilium the split is similar in spirit, since Cilium's identity and policy model is built around eBPF rather than a virtual switch.

Release cadence, licence and the cost of staying current

The repository is not archived, and the most recent push recorded is 2026-08-15, the same day as the v2.7.0 release. Three release lines moved that day: v2.7.0, v2.6.3 and v2.5.3. Maintaining parallel patch releases across two older minor lines is real work, and it is the signal that matters here rather than any count of stars or issues. For an operator it means upgrade paths exist from at least two prior minors, but it also means you should read CHANGELOG/ before jumping a minor version, since the project keeps a per-release changelog directory.

The licence is Apache-2.0, stated in the README and present as LICENSE at the repository root. That is a permissive licence with an explicit patent grant, and it imposes no copyleft obligation on your own code. It does not answer the question of what your distribution or your managed Kubernetes vendor does with the components, and it says nothing about the licences of the third-party modules in go.mod. If you redistribute Antrea inside a product, that dependency review is yours to run; nothing in the README performs it for you. Note also that the Go module path is versioned, antrea.io/antrea/v2, so any code importing Antrea packages must use that path.

Editorial conclusion

Adopt Antrea if your nodes already carry the Open vSwitch kernel module and you need policy tiering, cluster-level and Node policies, or flow export that stock Kubernetes NetworkPolicy cannot express. Do not adopt it if you cannot install or cannot guarantee that kernel module on every node, or if you only need plain pod-to-pod connectivity and default NetworkPolicy semantics. Before committing, verify three things on your own hardware: that the OVS kernel module loads on each node image, that NodeIPAMController is enabled or Antrea's own NodeIPAM feature is configured, and that your Kubernetes version is 1.23 or later.

Frequently asked questions

Official sources

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