Calico vs. Cilium: How Do They Compare?

Detailed Answer

Calico and Cilium are the two leading CNI (Container Network Interface) plugins for Kubernetes. Both provide Pod networking and network policy enforcement, but they differ significantly in architecture, performance characteristics, and feature sets.

Architecture Comparison

Calico

Calico traditionally uses iptables for packet filtering and BGP (via BIRD) for route distribution. In newer versions, Calico also supports an eBPF dataplane.

Pod → veth pair → Host routing table → iptables/eBPF → Wire
                         ↑
                    BIRD (BGP daemon)

Cilium

Cilium is built entirely on eBPF (extended Berkeley Packet Filter), which runs programs directly in the Linux kernel:

Pod → veth pair → eBPF programs (kernel) → Wire
                         ↑
                    Hubble (observability)

Feature Comparison

| Feature | Calico | Cilium | |---------|--------|--------| | Dataplane | iptables, eBPF, or Windows HNS | eBPF (native) | | Network Policy | Kubernetes + Calico NetworkPolicy | Kubernetes + CiliumNetworkPolicy | | L7 Policy | Via Envoy integration | Native (HTTP, gRPC, Kafka) | | Encryption | WireGuard | WireGuard or IPsec | | Observability | Basic flow logs | Hubble (deep eBPF-based flow visibility) | | Service mesh | N/A | Cilium Service Mesh (sidecar-less) | | BGP support | Native (BIRD) | BGP Control Plane (newer) | | kube-proxy replacement | eBPF mode | Native eBPF | | Multi-cluster | Calico Federation | Cluster Mesh | | Minimum kernel | 3.10+ (iptables), 5.3+ (eBPF) | 4.19+ (5.10+ recommended) |

Network Policy Capabilities

Standard Kubernetes NetworkPolicy

Both Calico and Cilium fully support the standard NetworkPolicy API:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
spec:
  podSelector:
    matchLabels:
      app: api
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - port: 8080

Cilium L7 Network Policy

Cilium extends network policy with L7 awareness:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-l7-policy
spec:
  endpointSelector:
    matchLabels:
      app: api
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: GET
                path: "/api/v1/.*"
              - method: POST
                path: "/api/v1/orders"

This policy allows only specific HTTP methods and paths — something standard NetworkPolicy cannot express.

Calico Network Policy

Calico's extended policy supports global rules and non-Kubernetes endpoints:

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: deny-external
spec:
  selector: app == "database"
  types:
    - Ingress
  ingress:
    - action: Allow
      source:
        selector: app == "api"
    - action: Deny

Performance

In eBPF mode, both Calico and Cilium bypass iptables:

| Metric | iptables (Calico) | eBPF (Calico) | eBPF (Cilium) | |--------|-------------------|---------------|---------------| | Service routing | O(n) rule walking | O(1) hash lookup | O(1) hash lookup | | Throughput (10K Services) | Degraded | Near line-rate | Near line-rate | | Connection setup latency | Higher | Lower | Lower | | CPU overhead | Higher | Lower | Lower |

Observability: Hubble

Cilium's Hubble provides network observability without additional tools:

# Install Hubble CLI
cilium hubble enable

# Observe flows in real-time
hubble observe --namespace production
hubble observe --protocol http --verdict DROPPED
hubble observe --to-label app=api

# Access the Hubble UI
cilium hubble ui

Hubble shows L3/L4/L7 flow data, DNS queries, and policy verdicts — all powered by eBPF with minimal overhead.

When to Choose Calico

1. Established environments with proven Calico deployments
2. BGP peering with physical network infrastructure
3. Older kernels (< 4.19) that cannot run eBPF
4. Windows node support required
5. Simplicity — Calico's iptables mode is well-understood

When to Choose Cilium

1. Large clusters where iptables performance degrades (1000+ Services)
2. L7 network policy requirements (HTTP, gRPC, Kafka)
3. Deep observability needs without deploying additional tools
4. Sidecar-less service mesh — Cilium can replace Istio for many use cases
5. Transparent encryption between Pods without application changes
6. Modern kernel available (5.10+ recommended)

Migration Considerations

Migrating CNI plugins is disruptive — it typically requires draining all nodes and reinstalling the network layer. Plan carefully:

# This is NOT a live migration — requires cluster downtime or node-by-node rebuild
# 1. Cordon and drain nodes
# 2. Remove old CNI configuration
# 3. Install new CNI
# 4. Uncordon nodes
# 5. Verify Pod networking