Learn Calico - History, Background & Why You Need Calico

#Introduction

In episode 0 you already have a test cluster running Calico. Now it's time to understand why Calico exists and what problem it solves. A new technology will feel foreign until you know the history that shaped its design.

Episode 1 covers Calico's journey from a small project at Metaswitch Networks in 2014, the major design decision of wire-rate routing instead of overlay, the networking problems it solves, and how it compares to other CNIs. Without this understanding, the decisions to use IPIP, VXLAN, or eBPF in the following episodes will feel confusing.

#The Evolution of Calico

#From Metaswitch to Tigera

Calico was born in 2014 at Metaswitch Networks, a British telecommunications company, as a networking solution for containers. In 2015 the project was released as open source, and the team behind it later formed the company Tigera, which remains the primary sponsor of Project Calico.

The most fundamental design decision from the start: Calico does not build an overlay. Instead of encapsulating packets into a tunnel like VXLAN, Calico leverages direct Linux routing and BGP to propagate pod routes between nodes. This approach is called wire-rate routing because packets are processed at wire speed without the overhead of an additional tunnel.

#Position in the 2026 CNI Ecosystem

Ten years later, Calico is one of the most widely adopted CNIs in Kubernetes. As of writing this series, the stable version is v3.32.x with the v3.32.1 release in mid-2026. Verify your version:

calicoctl version
kubectl get pods -n calico-system

calicoctl version shows the client and datastore versions. Make sure your cluster is on the v3.32.x track so it matches the examples in this series.

#Problems Calico Solves

#Scalable Pod Networking

The first problem is pod networking scalability. Traditional overlay approaches need tunnels and NAT at every hop, which adds CPU overhead and complexity. With direct routing, pod packets move between nodes like ordinary host packets: via ip route. Pod routes are propagated automatically with BGP to all nodes, so pod-to-pod connectivity runs at line rate.

#Feature-Rich Network Policy

The second problem is network policy. Kubernetes' built-in NetworkPolicy is good, but many cases need more: cluster-scoped policy, tier-based policy, control over the host itself, and FQDN- and L7-based policy. Calico provides NetworkPolicy, GlobalNetworkPolicy, ClusterNetworkPolicy, and HostEndpoint to close all of those gaps. Here is a policy resource example you will use often:

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: allow-nginx-ingress
  namespace: default
spec:
  selector: app == 'nginx'
  types:
    - Ingress
  ingress:
    - action: Allow
      protocol: TCP
      destination:
        ports:
          - 80

Note that this resource uses the projectcalico.org/v3 apiVersion — not networking.k8s.io/v1. We start covering this enriched Calico API in episode 5.

#Flexible IPAM and External BGP Peering

The third problem is IP control and connectivity to the outside world. Calico has its own IPAM with IPPools whose block sizes you can tune, and because it speaks BGP, it can peer directly with routers in your data center, letting pod CIDRs be advertised to the outside network without NAT. This is the foundation for the MetalLB integration and egress setup in episodes 8 and 10.

#Calico vs Other Approaches

To position Calico, compare its design approach with other CNIs:

• Flannel: pure VXLAN overlay, very simple, no network policy. Good for labs, not for security.
• Weave: overlay with mesh between nodes, easy to start but with more overhead and limited policy features.
• Cilium: end-to-end eBPF with Hubble observability, strong for L7, but with a higher kernel footprint and complexity.
• Calico: BGP routing + iptables/nftables, with optional eBPF and VXLAN. Offers a balance of features, simplicity, and performance.

An in-depth comparison, including recommendations for when to choose each, is in episode 22. For now, keep this in mind: Calico excels at direct routing, BGP freedom, and a complete policy model without requiring eBPF.

#Adoption in the Real World

#Who Uses Calico

Calico is widely used by platform providers and large enterprises for practical reasons: it is easy to automate, CRD-based, and does not demand a specific kernel in default mode. Several Kubernetes distributions adopt Calico as their built-in CNI, and many teams use it as a bridge before migrating to a full eBPF dataplane.

#When Calico Is the Right Choice

Calico is the best fit when your needs are fully controllable routing, BGP integration with the outside network, and strong security policy without building an eBPF infrastructure from scratch. Conversely, if your primary need is native L7 observability and you're ready to live purely on the eBPF kernel, Cilium could be worth considering — we cover that in episode 22.

#Why Choose Calico

The strongest reasons to use Calico for production clusters:

• Performance: tunnel-free routing reduces overhead compared to pure overlays.
• Dataplane flexibility: choose iptables, nftables, or eBPF as needed without switching CNIs.
• Enterprise-grade policy: tiers, global policy, host endpoints, FQDN, and L7.
• Track record: used on millions of nodes at large companies, with mature documentation and community.
• No vendor lock-in: Calico Open Source remains free, and its resources are built on standard CRDs.

Do a quick check of the features already active in your cluster:

kubectl get felixconfiguration default -o yaml | grep -i dataplane
calicoctl get ipamconfig default -o yaml

#Conclusion

Episode 1 puts Calico into context: born from the need for fast container routing, developed by Tigera since 2014, and now the de facto standard for networking plus policy in Kubernetes.

Key takeaways:

• Calico was born in 2014 at Metaswitch Networks, now maintained by Tigera.
• Its core philosophy is wire-rate routing with BGP, not overlay.
• It solves three big problems: scalability, complete policy, and IPAM/BGP control.
• The projectcalico.org/v3 API provides NetworkPolicy, GlobalNetworkPolicy, and more.
• The dataplane can use iptables, nftables, or eBPF as needed.
• An in-depth comparison with Cilium, Flannel, and Weave follows in episode 22.

In the next episode, episode 2, we dissect Calico's core concepts and main architecture — the role of calico/node, Felix as the programmable dataplane, BIRD as the BGP daemon, Typha which scales Felix's communication to the API server, kube-controllers, and the pod-to-pod packet path behind the scenes. This is the foundation for all the technical episodes that follow.