The Role of Cilium in Kubernetes: CCA practice questions

In a Kubernetes cluster Cilium takes on several jobs that are otherwise spread across separate tools. First it is the CNI plugin: when a pod is scheduled, Kubernetes calls cilium-cni on the node, the pod gets an address from the node's prefix, and the agent attaches eBPF programs to its network device. Without any network policy, every pod can reach every other pod, which matches the Kubernetes networking model. Traffic from pods to destinations outside the cluster is masqueraded to the node address as it leaves the node by default.

Second, Cilium enforces policy. It implements the standard NetworkPolicy resource for Layer 3 and 4 isolation, and adds CiliumNetworkPolicy for Layer 7 rules such as HTTP methods and paths, CIDR-based egress and DNS names. Enforcement is tied to identities derived from pod labels rather than to pod IP addresses, which keeps rules stable while pods come and go.

Third, Cilium can take over Service load balancing. kube-proxy watches Services and endpoints and writes iptables rules; Cilium watches the same objects but writes eBPF map entries on each node. With kubeProxyReplacement=true it handles ClusterIP, NodePort, LoadBalancer and externalIPs Services and also hostPort, so the portmap plugin is not needed. The replacement depends on socket-LB: for east-west traffic the backend is chosen when the application calls connect(), so the socket is attached to a backend address and no per-packet translation is required. Maglev consistent hashing, selected with loadBalancer.algorithm=maglev, applies only to north-south traffic for that reason.

Running without kube-proxy has one installation detail that often surprises people. A cluster created with kubeadm init --skip-phases=addon/kube-proxy has nothing that serves the ClusterIP of the API server Service when Cilium starts, so k8sServiceHost and k8sServicePort must point the agent at the real API server address.

Cilium can also sit next to another plugin. In CNI chaining mode the other plugin, for example the AWS VPC CNI, keeps responsibility for connectivity and address management, and Cilium attaches its programs to the devices that plugin created to add visibility and policy.

Finally, installation order matters. Pods that were already running before Cilium was deployed are not managed by it. Either nodes are created with the node.cilium.io/agent-not-ready taint so that workloads wait for the agent, or every pod that is not in host-networking mode is restarted after installation so it receives Cilium networking and its policies apply. On top of these core roles, Hubble adds flow visibility, Cluster Mesh joins several clusters, and the service mesh features add Ingress, Gateway API and encryption.