I85PREP
⌘ K
Cilium Certified Associate study materials
Cilium Certified Associate study resources

Cilium Certified Associate: Cilium Architecture and Fundamentals

Cilium Certified Associate · Work through your exam, one topic at a time.

All guide sections

Cilium Architecture and Fundamentals

The Architecture and Fundamentals domain tests whether you understand where Cilium's logic runs and what it operates on. Nearly every other domain builds on two answers: eBPF programs in the kernel datapath, and numeric security identities instead of IP addresses.

The two binaries

  • cilium-agent runs as a DaemonSet, one pod per node. It compiles and loads eBPF programs, manages the local datapath, owns local endpoints, and answers the CNI plugin invocation. Programs attach at tc ingress/egress on each veth pair; XDP is used for very early filtering and socket-level hooks (sockops, sk_msg) accelerate service translation for local pods.
  • cilium-operator is a Deployment that does cluster-wide work which must not be duplicated per node: IPAM allocation for modes such as cluster-pool, garbage collection of CiliumEndpoint objects, and kvstore-related syncing.

Identities and endpoints

Every pod becomes an endpoint with a numeric security identity derived from its label set, not from the pod itself. Three replicas carrying app=web,tier=frontend share one identity, so policy scale tracks distinct label combinations rather than pod count. Reserved identities cover non-pod peers: host (1), world (2), plus health, init, remote-node, and kube-apiserver, which policy selectors reference as entities.

What the datapath decides

For each packet, agent-installed programs answer: is this identity allowed to that identity on this port (L3/L4 policy); does the destination match a service (load balancing); and, where L7 rules exist, should the flow be redirected to the per-node Envoy proxy. Connection tracking and NAT state live in eBPF maps, which is why querying the maps is a routine diagnostic step.

Worked example

A policy selects app=web for ingress on 8080 from app=api, and four web pods exist. Cilium computes one identity for those four pods and programs a single allow pair: api-identity to web-identity on 8080. Now add the label canary=true to one pod. It gains a new identity, stops matching app=web exactly, and loses connectivity until the selector is widened. This relabelling effect is the most common "it worked yesterday" report.

Traps that cost marks

Writing policy against pod IPs; confusing which component performs IPAM; assuming identities are per-pod; forgetting that entities - not CIDRs - describe host, world and kube-apiserver traffic; and expecting L7 filtering without the proxy redirect that an L7 rule triggers.