Calico is an open-source, Apache-2.0 licensed cloud native networking and network security project for Kubernetes clusters, maintained by Tigera and aimed at platform engineers, cluster operators and network teams who need container networking, network policy enforcement and encryption across on-premises, cloud and bare-metal environments.
What it is
Project Calico is a container networking and network security stack written in Go and distributed under the Apache-2.0 licence. It is a CNI (Container Network Interface) plugin, which places it in the Kubernetes ecosystem: it installs into a cluster as the component that assigns pod IP addresses, programs routes between nodes and enforces network policy. The project is created and maintained by Tigera and reports that Calico Open Source powers more than 8 million nodes daily across 166 countries, with over 200 contributors from a range of companies.
The concrete thing it replaces is the default and third-party cluster networking layers that ship with or get bolted onto Kubernetes: the basic pod network that gives connectivity but no policy, plus separate add-ons for policy enforcement, encryption and route advertisement. Calico bundles those concerns into a single system with a selectable data plane — eBPF, standard Linux, Windows or VPP — and flexible routing options including BGP, VXLAN and service advertisement. Rather than running one networking plugin, one policy engine and one encryption tool side by side, operators deploy Calico and configure the pieces they need.
Key capabilities
- Selectable data plane: eBPF, standard Linux, Windows and VPP, so the same control plane can run on different node operating systems and kernel feature sets.
- CNI plugin functionality for Kubernetes pod networking, with interoperability across distributions, multiple clouds, bare metal and virtual machines.
- Kubernetes network policy support, plus identity-aware policy through the
identity-aware-policy topic for granular access control.
- WireGuard encryption for traffic between nodes.
- Flexible routing and connectivity tools including BGP, VXLAN and service advertisement.
- Host protection features for the node itself, alongside container-level policy (
host-protection topic).
- Companion projects maintained by the same organisation: the Calico Golang API, the Calico operator, the VPP dataplane and Calico BIRD.
Who uses it and how
- Kubernetes platform teams standardising networking across a mixed fleet of clusters, clouds and bare-metal hosts, using one policy model instead of per-environment stacks.
- Clusters with Windows nodes, where
kubernetes-windows support lets Windows and Linux workloads share a networking and policy layer.
- Security-conscious operators who need pod-level access control and WireGuard encryption between nodes without adding a separate encryption product.
- Performance-sensitive workloads that choose the eBPF data plane to reduce CPU overhead, or VPP where higher throughput is required.
- Network engineers who want BGP peering and route advertisement so cluster pods are reachable from existing network infrastructure.
Deployment scale in the project's own reporting reaches millions of nodes, and the community operates through Slack, regular community meetings, a "good first issue" label for new contributors and an ambassador programme.
Getting started
The README points to a Quickstart and hosts the operator as a Helm chart, projectcalico/tigera-operator, published on ArtifactHub; installation and full configuration documentation live at the project's docs site.
How it compares
No comparable or paid products are named in the facts provided, so on the evidence available Calico stands alone in this registry rather than being contrasted against a named alternative.
When to use it — and when not to
A self-hoster takes on operating a CNI and policy engine inside the cluster, including choosing and tuning a data plane and, where used, BGP peering and WireGuard key handling — that is real operational work, not a drop-in default. Teams that want only basic pod connectivity with no policy, encryption or routing requirements should look at simpler options rather than adopting this. Honest caveats: the project carries 279 open issues and a large surface area, the README is oriented toward community and project links rather than installation detail, and the GitHub description is a single line, so the docs site rather than the repository is the real entry point.