Cilium: Up and Running

Chapter 2. Inside Cilium

In Chapter 1 we explored the main use cases for Cilium—networking, security, and observability—and how eBPF enables them. In this chapter, we will take a closer look at the components that make up Cilium. Understanding how these pieces fit together will make it easier to follow how each feature works in later chapters.

Cilium’s architecture is modular, with each component focusing on a specific responsibility. Some are present on every node, while others are optional and become relevant only when certain features are enabled.

Cilium at a Glance

Cilium’s versatility comes from a modular design built around several key components:

Cilium agent

Runs on every node and forms the core of Cilium. It loads and manages the eBPF programs and maps in the kernel, and it watches Kubernetes objects and Cilium custom resources to keep the datapath state up-to-date.

Cilium CNI plugin

Connects Cilium to Kubernetes through the Container Network Interface framework. It is responsible for wiring new pods into the network when they are created, using the configuration files and binaries installed by the agent.

Cilium operator

Provides cluster-level coordination. It manages Cilium’s custom resources and allocates IP addresses, as well as other cluster-wide operations.

eBPF programs and maps

Provide the foundation of the datapath. Programs handle connection tracking, NAT, load balancing, and policy enforcement, while maps store shared state between programs and the ...