Learn Calico - Core Concepts & Main Architecture

#Introduction

In episode 1 you learned why Calico exists. Now it's time to open the hood: who does what, and how a packet moves from one pod to another. Episode 2 is the most important foundation in this series because every following episode will reference the components we cover here.

Calico's architecture is essentially simple: one agent per node (calico-node) running several processes, one scaler (Typha), a set of controllers, and one operator for installation. After this episode, you will be able to read kubectl get pods -n calico-system and explain the function of every pod.

#Main Calico Components

#calico-node and Felix

calico-node is the DaemonSet that runs on every node. Several processes live inside this pod:

• Felix: the programmable dataplane. Its job is to translate the desired policy and routing into iptables/nftables or eBPF, and to manage routes and interfaces on the node. Felix is the only component that touches the networking kernel.
• BIRD: the BGP daemon that propagates pod routes between nodes and to external peers.
• calico-node: the process that manages IPAM, membership, and coordination between components.

See the processes running inside the calico-node pod:

kubectl get pods -n calico-system -l app.kubernetes.io/name=calico-node
kubectl exec -n calico-system ds/calico-node -- ps aux | grep -E "felix|bird|calico"

kubectl exec ... ps aux will show felix, bird, and the calico-node process inside a single pod. If you don't see Felix running, the dataplane won't work at all.

#Typha

Typha is the scaler of Calico's architecture. The problem it solves: in large clusters, the Felix on every node watches policy resources and endpoints on the API server. If a thousand nodes watched directly, the API server would be overwhelmed. Typha sits in the middle — one connection to the API server, then broadcasts changes to hundreds of Felix instances.

With Typha, the API server load stays relatively constant even as the node count grows. The default Typha Deployment runs two replicas:

kubectl get deploy -n calico-system typha
kubectl logs -n calico-system deploy/typha --tail=10 | grep -i "connected"

#BIRD and kube-controllers

BIRD is fully responsible for BGP: building the full-mesh between nodes by default, accepting peer configuration from BGPPeer, and advertising pod routes. kube-controllers handles reconciliation tasks — such as creating a profile per namespace and updating endpoint status — so policy and networking always stay in sync with Kubernetes objects.

#calico-apiserver and calicoctl

calico-apiserver provides a Kubernetes API for Calico resources (NetworkPolicy, IPPool, and others), so those resources can be accessed with regular kubectl. calicoctl/calico are CLIs that read the same datastore. This data model is important: Calico resources are CRDs, so everything can be managed as code — we'll leverage that in episode 18.

#Tigera Operator

The Tigera Operator manages the lifecycle of all the components above. It watches the Installation and APIServer resources, then deploys calico-node, typha, kube-controllers, and related configuration. The benefit: upgrading Calico is just a matter of changing the operator or image version, without editing manifests by hand.

kubectl get installation default -o yaml
kubectl get tigerastatus

kubectl get tigerastatus shows the status of every Calico component (apiserver, calico-node, typha, and more) in a single table.

#The Pod-to-Pod Packet Path

#Packet Path Within a Single Node

When pod A sends a packet to pod B on the same node, the path is short: from pod A's veth into the route table, the kernel finds the destination is on this node, then forwards to pod B's veth. Felix only installs iptables rules to allow traffic according to policy — if no policy forbids it, the packet is forwarded directly.

#Packet Path Between Nodes

For different nodes, BIRD has already advertised pod B's route to all nodes. So node A has a route 192.168.1.5/32 via <IP node B> dev eth0. The packet leaves pod A's veth, gets routed directly to node B, then enters pod B's veth:

pod A -> veth A -> routing table -> NIC node A
      -> network (original packet, no tunnel) -> NIC node B
      -> routing table -> veth B -> pod B

This is what wire-rate routing means: there is no encapsulation on this path. The IPIP or VXLAN modes that add a tunnel will be covered in episode 9.

#Verify Routes with calicoctl

To see the routes BIRD has propagated:

calicoctl node status
kubectl exec -n calico-system ds/calico-node -- ip route | grep 192.168

#Data Model and Profiles

Every Kubernetes namespace automatically gets a Calico profile with the same name. This profile provides the default label-based allow policy and is where NetworkPolicies attach. So the data synchronization flow is: kube-controllers watches namespaces → creates profiles → Felix installs the relevant rules on each node.

#Design Principles to Remember

There are three principles that tie this whole architecture together and that you'll see again often:

• Separation of concerns: BIRD only handles routes, Felix only handles the dataplane and policy, controllers only handle synchronization. This lets each component be scaled and debugged independently.
• Desired state: configuration is written as resources (CRDs), and components continuously reconcile the actual state with the desired state. You never force a node; you declare.
• Everything is queryable: all state can be read — routes, endpoints, policy, and BGP status — via kubectl or calicoctl, which is the main asset for troubleshooting in episode 19.

As long as you hold onto these three principles, episodes 8 through 17, full of new components, will feel like variations of the same architecture.

#Conclusion

Episode 2 opens up Calico's architecture from components to packet flow: Felix programs the dataplane, BIRD propagates routes, Typha scales, kube-controllers synchronizes, and the operator manages it all.

Key takeaways:

• calico-node runs Felix (dataplane), BIRD (BGP), and the node management process.
• Typha mediates between Felix and the API server to keep large clusters light.
• kube-controllers syncs Kubernetes objects into Calico's data model.
• Calico resources are CRDs, accessible via both kubectl and calicoctl.
• Inter-node pod-to-pod packets are routed directly, without a tunnel by default.
• A profile per namespace is where policies attach.

In the next episode, episode 3, we do a deeper setup and installation: comparing ways to install the Tigera Operator, the iptables versus eBPF dataplane modes with their kernel prerequisites, and a thorough post-install verification process. Get your cluster ready, because starting this episode we'll run all the commands together.