Calico: Kubernetes Networking, IP Pools & Network Policy

Calico

Calico is one of the most widely deployed networking and network policy solutions for Kubernetes. As a CNI plugin it assigns Pod IP addresses and routes traffic between nodes; as a policy engine it enforces Kubernetes NetworkPolicy and its own richer policy resources, including cluster-wide rules with explicit ordering and deny actions. It runs on Linux and Windows nodes, in clouds and on premises, and is often used for policy enforcement alongside a cloud provider's own networking.

Calico's strengths are flexibility and routing: it can route Pod traffic natively with BGP, encapsulate it with IP-in-IP or VXLAN where the network does not allow direct routes, and run on several dataplanes, including iptables and eBPF. Choosing those options well at install time avoids most of the problems people later debug.

TL;DR

Install with the Tigera operator, configured through an Installation resource kept in Git.
Pick a routing mode: native BGP where the network allows, VXLAN or IP-in-IP encapsulation where it does not.
Plan IP pools (CIDR, block size, encapsulation, outbound NAT) before workloads arrive.
Calico policies add ordering, deny, log, and pass actions, and GlobalNetworkPolicy for cluster-wide rules.
Start with a cluster-wide baseline that allows DNS, then add per-application rules.
Troubleshoot with node status, IPAM, routes, MTU, and Felix logs — in that order.

Quick Example

A cluster-wide default-deny for application namespaces that still allows DNS, adapted from Calico's recommended pattern:

Every application Pod now denies traffic unless another policy allows it — except DNS lookups, which would otherwise break every service at once. Teams then add namespaced allow policies for their own services.

Core Concepts

Components

Dataplanes

Calico supports a standard Linux dataplane using iptables (with nftables options in recent versions), an eBPF dataplane that can also replace kube-proxy, and a Windows dataplane. The eBPF dataplane offers lower latency and better scaling for Services, with kernel version requirements to check first.

Routing Modes

Encapsulation adds headers, so the Pod MTU must be smaller than the node MTU. Calico can detect the right value automatically; a wrong MTU shows up as large transfers hanging while small requests work.

IP Pools and IPAM

An IPPool defines the address range for Pods and how traffic from it is handled:

Calico allocates small blocks (a /26 is 64 addresses) to each node. Choose a pool large enough for peak Pods and block sizes that fit your Pods per node, and make sure it does not overlap other networks you need to reach. See IP Addressing, Subnets, and IPv6.

Policy Model

Calico enforces standard Kubernetes NetworkPolicy and adds:

NetworkPolicy (Calico): namespaced, with an order field, rule actions (Allow, Deny, Log, Pass), and richer selectors.
GlobalNetworkPolicy: cluster-wide rules, including for host endpoints.
Tiers (in recent versions): groups of policies evaluated in sequence, so a platform team's guardrails run before application teams' rules.

Lower order values are evaluated first, and the first matching rule with Allow or Deny decides. Pass skips to the next tier, which lets platform policies delegate decisions to application policies.

Troubleshooting Connectivity

Node health: kubectl get pods -n calico-system and calicoctl node status to confirm BGP sessions are established when using BGP.
IP allocation: calicoctl ipam show — exhausted blocks leave new Pods without addresses.
Routes: check that routes or tunnel interfaces for other nodes' blocks exist on the node.
MTU: test large packets between Pods; reduce the Pod MTU if encapsulated traffic stalls.
Policy: use flow logs where available, or temporarily add Log rules, to see which policy blocks traffic.
Felix logs on the affected node for programming errors.

Best Practices

Decide Networking Before the First Workload

Pod CIDR, routing mode, and dataplane are hard to change on a live cluster. Write them into the Installation resource and review them like any other architecture decision.

Separate Platform and Application Policy

Platform teams own global guardrails — default deny, DNS, monitoring, control plane access — in an early tier or low order. Application teams own namespaced allow rules for their services.

Keep Configuration in Git

Manage Installation, IP pools, and policies declaratively through GitOps, so changes are reviewed and reproducible.

Upgrade Through the Operator

Let the operator roll Calico components node by node, test upgrades on staging first, and read release notes for dataplane and policy changes.

Common Mistakes

Overlapping Pod CIDRs

Encapsulation With the Wrong MTU

Default Deny Without DNS

FAQ

What does Calico do in Kubernetes?

It assigns IP addresses to Pods, routes traffic between Pods across nodes using BGP or encapsulation, and enforces network policy — both standard Kubernetes policies and Calico's own policies with ordering and deny actions.

Should I use BGP, IP-in-IP, or VXLAN?

Use native BGP routing when the underlying network can carry Pod routes, for the best performance and simplest packets. Use VXLAN in most clouds or when Windows nodes are involved, and IP-in-IP where it is supported and VXLAN is not needed. CrossSubnet modes encapsulate only when traffic leaves a subnet.

Can Calico enforce policy on a cloud provider's CNI?

Yes. Calico can run in policy-only mode alongside some provider networking, enforcing Kubernetes and Calico policies while the provider handles IP addresses and routing. Check the supported combinations for your provider.

How is Calico different from Cilium?

Both provide networking and policy. Calico offers several dataplanes and strong BGP integration; Cilium is built around eBPF with HTTP- and DNS-aware policies and Hubble flow visibility. See Cilium.

Why do some requests hang while others work?

Usually MTU: small packets fit, larger ones are dropped after encapsulation adds headers. Check the Pod MTU against the node MTU and the encapsulation in use.