Kubernetes networking - Flannel and Calico

 

1. Kubernetes networking and CNI

Kubernetes uses the Container Network Interface, usually called CNI, to plug different networking implementations into the cluster.

A CNI plugin is responsible for things like:

• Giving pods IP addresses

• Setting up routes and rules so that pods can reach each other and the outside world

• Optionally enforcing network policy for security

Popular CNI plugins include Flannel, Calico, Cilium and Weave Net.

Flannel and Calico are two of the most common choices, but they focus on slightly different goals.

---

2. Flannel

2.1 Main purpose

Flannel is a simple, lightweight layer 3 network fabric for Kubernetes. It gives each pod a unique IP and provides connectivity between nodes in the cluster.

You can think of it as “just make the pods talk to each other” without many extra features.

2.2 How it works (high level)

• Flannel runs an agent called flanneld on every node

• It allocates a subnet to each node from a larger cluster network

• Packets between nodes are usually carried using an overlay format such as VXLAN, or via a simpler host gateway mode

• Flannel often acts as a “meta plugin” that wraps basic CNI reference plugins like the bridge plugin

Encapsulation with VXLAN means packets are wrapped inside another UDP packet while moving between nodes, which simplifies routing but adds some overhead.

2.3 Features and strengths

• Very easy to deploy and operate

• Good enough performance for many small and medium clusters

• Supports several back ends such as VXLAN and host gateway

• Widely supported by distributions and installers

2.4 Limitations

• Flannel focuses on basic connectivity and does not implement network policy by itself, so you need another component if you want policy enforcement.

• Lacks more advanced security and observability features

• Overlay networks introduce extra headers which can reduce raw throughput compared to a pure underlay design

---

3. Calico

3.1 Main purpose

Calico is both a networking provider and a powerful network policy engine for Kubernetes and other platforms.

It aims at high performance, strong security and good scalability for large clusters.

3.2 How it works (high level)

By default Calico builds a pure IP layer 3 network using standard routing protocols, usually BGP, to advertise pod networks between nodes. This underlay style avoids an extra overlay in many setups, which can improve performance and simplify troubleshooting.

Calico can also use encapsulation modes such as IP in IP or VXLAN when direct routing is not possible, so it is quite flexible.

3.3 Network policy

Calico implements and enforces Kubernetes NetworkPolicy resources and also provides its own extended policy model with richer features:

• Policy ordering and priority

• Explicit deny rules

• Policies for pods, host interfaces and virtual machines

• More flexible matching based on labels and other selectors

Kubernetes itself defines the NetworkPolicy API but depends on a plugin such as Calico to actually enforce those rules.

3.4 Features and strengths

• High performance networking using routed layer 3 design

• Rich and mature network policy implementation

• Good fit for large or security sensitive clusters

• Works across Kubernetes, virtual machines and host interfaces, not just pods

3.5 Limitations

• More components and concepts to learn, especially BGP and its configuration

• Setup can be more complex than Flannel, particularly in very simple lab environments

• Some cloud managed Kubernetes offerings already include their own policy engine, which may overlap with Calico features

---

4. Similarities between Flannel and Calico

Flannel and Calico have quite a lot in common:

1. Both are CNI plugins that integrate natively with Kubernetes

2. Both create a flat pod network where each pod gets its own routable IP

3. Both have agents running on every node that program routes and rules

4. Both support different back end modes to adapt to various environments

5. Both are open source and widely used in the community

In other words, both solve “pods on different nodes should always be able to reach each other using IP”.

---

5. Key differences

Here is a conceptual comparison, without trying to be vendor marketing.

5.1 Networking model

• Flannel

  • Primarily focuses on an overlay model such as VXLAN or a simple host gateway mode

  • Routing logic is relatively simple, which keeps operations easy

• Calico

  • Prefers a routed underlay model using BGP so that pods are directly reachable in the network

  • Can also use encapsulation (IP in IP or VXLAN) when needed

  • Often gives better raw performance, especially at scale

5.2 Network policy support

• Flannel

  • Does not implement network policy itself

  • If you need Kubernetes NetworkPolicy you usually combine Flannel with another policy engine or choose a different CNI

• Calico

  • Full Kubernetes NetworkPolicy support and an extended policy language

  • Frequently used primarily because of its policy features, even when basic connectivity is covered elsewhere

5.3 Complexity and operational model

• Flannel is easier to understand and maintain, which makes it attractive for very small or simple clusters such as test labs or single purpose clusters.

• Calico introduces more components (for example BGP speakers and policy controllers) and more configuration options, but in exchange it handles complex topologies and scaling better.

5.4 Typical use cases

• Flannel

  • Small to medium clusters

  • Environments where you only need basic connectivity and do not plan to use network policy

  • Educational or lab clusters that should stay simple

• Calico

  • Production clusters with stricter security requirements

  • Large deployments with many nodes and namespaces

  • Environments that require detailed control over traffic flows, including east west traffic inside the cluster

---

6. Other CNI alternatives

If you are choosing networking for Kubernetes, Flannel and Calico are not the only options.

Some notable alternatives:

1. Cilium

   • Uses eBPF for data plane processing

   • Very strong focus on security and observability and on higher layer policies

   • Frequently ranked highly in recent performance comparisons

2. Weave Net

   • Simple to deploy, creates an encrypted mesh overlay between nodes

   • Supports features like automatic encryption and network isolation

3. Canal

   • A combination of Flannel for networking and Calico for network policy

   • Often used as a convenient middle ground when you want simple deployment plus policy features

4. Cloud provider specific CNI plugins

   • Amazon VPC CNI, Azure CNI and others integrate pods directly into the cloud provider network

   • These are often used alongside or instead of Calico or other policy engines, depending on the platform

5. CNI Genie and similar meta plugins

   • Allow a cluster to choose or combine multiple CNIs, for example Calico, Flannel or Weave, inside one environment

---

7. How to think about the choice

A quick mental model:

• Choose Flannel when you want the simplest possible solution that just gives pod to pod connectivity, typically for smaller or low risk clusters.

• Choose Calico when you care about performance, need strong network policy and plan to scale to many nodes or tenants.

• Consider Cilium, Weave Net or Canal when you want extra capabilities such as eBPF based security, built in encryption or an integrated blend of Flannel style networking with Calico style policy.