Cilium Component Roles: CCA practice questions

Knowing which Cilium component does what is mostly about drawing the line between per-node and cluster-wide work, and between the tools an operator types.

The agent, cilium-agent, runs as a DaemonSet pod on every node. It listens for Kubernetes events to learn when workloads start and stop, accepts configuration for networking, load balancing, policy and visibility, and manages the eBPF programs that control traffic in and out of the containers. Policy enforcement is therefore local to each node. The agent also generates the CNI configuration: it installs the cilium-cni binary into /opt/cni/bin and, once it is ready to handle pod sandboxes, writes /etc/cni/net.d/05-cilium.conflist. With cni.exclusive at its default of true, it removes other CNI configuration files from that directory.

The CNI plugin, cilium-cni, is short-lived. Kubernetes invokes it when a pod is scheduled or terminated, and it calls the local agent API to set up or tear down the datapath for that pod.

The operator runs as a Deployment and handles duties that should happen once per cluster. Examples are allocating per-node PodCIDRs in cluster-scope IPAM, answering multi-pool requests, and in AWS ENI mode being the only component that talks to the EC2 API. The operator is never in the critical path of forwarding or policy. If it is down, traffic keeps flowing, but IP allocation for new pods can be delayed and, with a kvstore, a missed heartbeat makes agents declare it unhealthy and restart. Identity allocation is done by the agents by default; the beta identityManagementMode setting can move it to the operator to reduce duplicate identities created by agents racing each other, with a transitional both mode for migration.

Two command-line tools are easy to mix up. cilium-dbg ships inside the agent container, talks to the agent's REST API on the same node and can dump eBPF maps, so it answers node-local questions. The cilium CLI is installed on a workstation and uses kubeconfig and the Kubernetes API to install, upgrade, inspect and test Cilium across the cluster.

Hubble has its own split. The Hubble server is embedded in each agent and offers a gRPC API for flows and metrics. hubble-relay connects to all servers and presents one cluster-wide API, the hubble CLI connects to either Relay or a local server, and hubble-ui draws its service map from Relay. When the UI is empty but a node shows flows locally, Relay is the component to check.