openskills.info
Cilium logoCourse Preview

Cilium

Cilium is a Kubernetes networking, observability, and security project that uses eBPF to enforce policies and route traffic at the Linux kernel level. It provides high-performance pod networking, transparent encryption, and identity-based access control without sidecar proxies.

itCloud native tools and technologies

Don't Panic: Cilium

Cilium is the part of a Kubernetes cluster that takes the hopeful suggestions made by Pods, Services, labels, and policies, then has the Linux kernel carry them out. It is networking, security, and flow visibility living close to the traffic. This is useful because Pods are temporary creatures. Their IP addresses behave accordingly.

The important idea is security identity. Cilium derives it from labels, so a policy can describe which workloads may talk instead of chasing every new pod address around the cluster like a person trying to label migrating birds. Addresses and routes still matter. They have merely stopped being the only words available for saying who is allowed to do what.

The traffic path is where the plot happens. The Cilium agent on every node turns Kubernetes state into eBPF programs and maps. An eBPF datapath can forward traffic, choose a Service backend, enforce policy, or report a verdict. The operator handles shared work. Hubble reports observed flows. This arrangement means a configuration object is not the end of a networking change. It is the beginning of a question: what did the path actually do?

Routing has two broad moods. Encapsulation carries pod traffic through a VXLAN or Geneve tunnel, which asks less of the underlay and spends some packet room. Native routing avoids that Cilium overlay, then asks the surrounding network to know the pod ranges. Neither gets a medal for being modern. The suitable choice is the one whose routing and failure behavior the operating team can explain.

Policy is similarly literal. Ingress and egress are separate, selectors decide which endpoints are involved, and a matching deny rule wins over an allow rule. Start by observing dependencies with Hubble, then test both the request that should work and the request that should fail. Hubble is not a replacement for logs, metrics, or traces. It is the useful witness standing beside the network path.

The surprise is that sidecar-free does not mean proxy-free. IP, TCP, and UDP processing stays in the eBPF path. HTTP, gRPC, DNS detail, and Gateway API work can introduce Envoy because somebody must understand the protocol rather than stare politely at port numbers.

Read the Intro for the component and traffic map. Use Slides to compare the layers and decisions. Keep the Cheatsheet nearby for routing modes, policy evaluation, flow commands, and failure signals. Then use the Practice Reference and Exercise to make one policy change in a disposable cluster and prove its verdict. That is where Cilium stops being a promising diagram and becomes infrastructure you can reason about.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources