Cilium

Cilium is a networking, security, and observability platform for Linux and Kubernetes. It uses eBPF programs in the Linux kernel to connect workloads, load-balance services, enforce policy, and expose network behavior.

The central mental model is identity-aware control attached to the network path.

Kubernetes intent             Cilium control plane
pods, services, policies ---> agents and operator
                                  |
                                  v
application traffic ------> eBPF datapath ------> destination
                                  |
                                  +------> Hubble flow data

Cilium can be your Kubernetes Container Network Interface plugin, or CNI plugin. It can also replace kube-proxy, enforce extended policies, provide Hubble observability, connect clusters, encrypt traffic, and implement Gateway API routes. Those features share a datapath, but you do not need to enable them all.

Why Cilium exists

Kubernetes workloads appear, disappear, and move between nodes. Their IP addresses change with them. A rule system built only around changing IP addresses can become difficult to operate at cluster scale.

Cilium assigns security identities to endpoints based on labels. Policy can then describe which workload identities may communicate. The datapath enforces that decision as traffic crosses kernel hooks.

This separates security intent from a specific pod IP. It also connects networking and observability. The same datapath that forwards or drops traffic can report what it observed and why.

eBPF makes this model possible. eBPF lets verified programs run at defined hooks inside the Linux kernel. Cilium loads programs at networking hooks and supplies them with state held in eBPF maps. The kernel executes those programs as packets or socket operations reach the hooks.

You do not write eBPF programs to use Cilium. The Cilium agent translates cluster state and configuration into datapath programs and map entries.

The main components

A typical Kubernetes deployment has several cooperating components.

The Cilium agent

The Cilium agent runs on each node. It watches Kubernetes events, manages local endpoints, loads eBPF programs, updates maps, and exposes local health and debugging information.

The agent is close to the datapath because each node must make forwarding and policy decisions for its own traffic. A broken agent can affect new configuration on that node even when already-loaded datapath state continues to exist.

The Cilium operator

The operator handles cluster-wide control-plane work that should not run independently on every node. Its exact responsibilities depend on enabled features. Examples include address-management tasks and processing resources for some service features.

The CNI plugin

Kubernetes invokes a CNI plugin when a pod network interface must be created or removed. Cilium connects the pod to the node network and prepares the endpoint for datapath enforcement.

Hubble

Hubble is Cilium's networking and security observability layer. A Hubble server on each node receives flow information from Cilium. Hubble Relay aggregates node-local data for cluster-wide queries. Hubble UI presents service relationships and flow events.

Hubble shows observed flows. It does not replace metrics, logs, traces, or application-level instrumentation. Use it to understand network behavior and policy decisions, then correlate those observations with the rest of your telemetry.

Envoy

Cilium uses eBPF for IP, TCP, and UDP processing. Features that must understand application protocols can use Envoy. Examples include Layer 7 policy and Gateway API traffic.

This boundary matters. eBPF does not make an application-layer proxy unnecessary when a feature must parse HTTP or gRPC. Cilium connects the kernel datapath and proxy so you can enable application-aware features without placing a sidecar in every application pod.

The datapath mental model

An endpoint is a workload network attachment managed by Cilium. In Kubernetes, a pod is the common example.

When traffic leaves or enters an endpoint, Cilium's eBPF programs can perform several actions:

• identify the source and destination;
• enforce ingress or egress policy;
• translate a Kubernetes Service to a backend;
• route, encapsulate, or redirect traffic;
• record a flow verdict and useful metadata;
• hand application-layer processing to Envoy when configured.

The exact hook and sequence depend on the traffic path and enabled features. Avoid one universal packet diagram. A local pod-to-pod flow, a remote-node flow, a service connection, and Gateway API traffic take different paths.

Use three questions when reasoning about a flow:

1. Which endpoint or host originated it?
2. Which datapath feature makes the forwarding or policy decision?
3. Which component exposes the evidence you need to verify that decision?

Networking and routing

As a CNI plugin, Cilium gives pods connectivity and integrates that connectivity with Kubernetes Services and policy.

Two broad routing modes frame the design choice.

Encapsulation

Encapsulation places pod traffic inside a VXLAN or Geneve packet between nodes. The underlay needs node-to-node IP reachability and must allow the tunnel protocol.

This is the lower-requirement option because the underlay does not need routes for every pod address range. The tradeoff is tunnel overhead, including a smaller effective maximum transmission unit for payloads.

Native routing

Native routing sends pod traffic through the regular routing capabilities of the node and surrounding network. The network must know how to reach pod address ranges.

This avoids tunnel overhead, but it shifts routing requirements to the underlay, cloud integration, direct node routes, or a routing protocol such as BGP.

Neither mode is universally better. Choose from underlay capability, address management, performance requirements, failure behavior, and the operating team's routing skills.

Kubernetes Service load balancing

A Kubernetes Service gives clients a stable virtual destination while its backend pods change. Cilium can implement Service load balancing with eBPF.

Cilium can also run Kubernetes without kube-proxy by replacing kube-proxy's Service handling. This is an architectural choice, not a required property of every Cilium installation.

When you consider kube-proxy replacement, verify platform compatibility, Kubernetes API server connectivity, Service behavior, source-address requirements, traffic policy, and the selected load-balancing mode. Test the exact north-south and east-west paths your applications use.

Identity-aware network policy

Cilium supports the standard Kubernetes NetworkPolicy resource. It also provides two custom resources:

• CiliumNetworkPolicy for namespaced, extended policy;
• CiliumClusterwideNetworkPolicy for cluster-scoped policy.

Standard Kubernetes NetworkPolicy expresses Layer 3 and Layer 4 ingress or egress controls. Cilium policies add features such as Layer 7 rules, DNS-aware egress rules, explicit deny behavior, and Cilium-specific selectors.

Policy is additive in ways that can surprise operators. Once an endpoint is selected for ingress or egress enforcement, traffic must match an applicable allow rule for that direction. Cilium deny rules take precedence over allow rules.

Start policy design with observed dependencies, then move toward default denial. Keep selectors narrow and readable. Treat DNS rules as controls on name resolution and matching destinations, not as proof of the remote service's identity or behavior.

Application-layer policy adds a proxy path and protocol awareness. It can distinguish requests such as HTTP methods or paths, but it also adds configuration and operational dependencies. Use it when the security requirement truly depends on application semantics.

Hubble observability

Hubble answers questions such as:

• Which workloads are communicating?
• Was a flow forwarded or dropped?
• Which policy decision affected it?
• Which DNS names or application protocol details were observed?
• Where does a dependency appear in the service map?

Flow evidence helps during policy rollout. You can observe dependencies, apply a policy, and examine denied flows. A successful connectivity test and clean Hubble evidence together are stronger than checking only that a policy object exists.

Hubble visibility still has scope and retention boundaries. Node-local, Relay, metrics, and UI deployments expose different views. Plan access control, storage, sampling, and telemetry retention according to your investigation needs.

Optional feature families

Several major features extend the same platform.

Transparent encryption

Cilium supports transparent encryption for traffic between managed endpoints. WireGuard and IPsec are documented options. Encryption coverage depends on the selected mode, traffic pair, platform, and configuration.

Do not reduce the question to an enabled flag. Verify actual encryption status and test representative traffic. Understand same-node behavior, host traffic coverage, tunnel overhead, key management, and firewall requirements.

Cluster Mesh

Cluster Mesh connects Cilium-managed Kubernetes clusters. It can provide cross-cluster pod connectivity, policy enforcement, and service discovery or load balancing.

The clusters need compatible datapath configuration, non-overlapping pod address ranges, node connectivity, and deliberate identity and service design. A mesh expands the failure and trust boundary. Adopt it only when cross-cluster connectivity is worth that cost.

Gateway API and service-mesh features

Cilium can act as a Gateway API implementation. The operator watches Gateway API resources and translates accepted configuration. Cilium agents supply Envoy configuration, and Envoy handles application-layer traffic.

Gateway API support has prerequisites, including installed Gateway API custom resources and relevant Cilium features. Check the documentation for the Cilium and Gateway API versions you deploy.

Cilium also groups application-aware connectivity, security, and observability under its service-mesh capabilities. Some of these features use a sidecar-free model, but Envoy remains part of the architecture for application protocols.

Where Cilium fits

Cilium is a strong fit when:

• Kubernetes networking, policy, and flow visibility should share one operating model;
• label-based identity is useful for dynamic workloads;
• eBPF-based Service handling or kube-proxy replacement meets a real requirement;
• you need Cilium's extended policy, encryption, Gateway API, or multi-cluster features;
• your team can operate Linux networking and Cilium as critical cluster infrastructure.

Cilium may be a weaker fit when:

• the platform already supplies a managed network stack that meets every requirement;
• the hosts or kernel do not meet supported requirements;
• the team cannot own a cluster-wide datapath and its upgrade path;
• a simpler CNI and standard NetworkPolicy provide enough capability;
• the required application traffic controls depend on another established gateway or service mesh.

Feature breadth is not a reason to enable everything. Each enabled feature changes the data path, control plane, dependencies, or failure modes. Begin with the smallest configuration that meets a named requirement.

Operating Cilium safely

Cilium sits on a critical path. Treat changes as network changes, not ordinary application rollouts.

Before installation, confirm host architecture, kernel support, Kubernetes distribution guidance, firewall rules, address ranges, routing mode, and CNI ownership. Managed Kubernetes platforms can impose specific installation or lifecycle constraints.

After installation, verify agent and operator status. Run Cilium's connectivity test. Inspect node-level health, Kubernetes resources, and Hubble flows. A green DaemonSet alone does not prove every traffic path works.

For upgrades, read the version-specific upgrade guide. Preserve a tested rollback plan. Validate policy behavior, Service traffic, external traffic, DNS, encryption, observability, and optional features in a representative environment.

During troubleshooting, work from symptom to layer:

1. Confirm the endpoint and Kubernetes object state.
2. Check Cilium status across nodes.
3. Observe the flow and verdict in Hubble.
4. Inspect the policy that selects the endpoint.
5. Check routing, tunnel, Service, or proxy state for that path.
6. Collect Cilium diagnostics before changing several settings at once.

A practical learning path

1. Learn Kubernetes pod networking, Services, CNI, and NetworkPolicy.
2. Read Cilium's introduction and component overview.
3. Learn the endpoint, identity, agent, operator, eBPF datapath, Hubble, and Envoy boundaries.
4. Compare encapsulation and native routing against your underlay.
5. Install Cilium in a disposable cluster with the documented quick-install path.
6. Run the connectivity test and inspect the same flows with Hubble.
7. Apply one standard NetworkPolicy. Observe allowed and denied traffic.
8. Compare that policy with a CiliumNetworkPolicy that uses one extended feature.
9. Evaluate kube-proxy replacement, encryption, Gateway API, or Cluster Mesh separately. Enable only the feature you are testing.
10. Practice an upgrade and failure investigation before using Cilium in production.