Cilium is an open source cloud-native networking, security, and observability platform built on eBPF and designed for Kubernetes. It acts as a Kubernetes Container Network Interface (CNI), but thinking of it only as a CNI undersells what it does. Cilium can connect workloads, enforce identity-based security policies, provide deep network visibility through Hubble, replace kube-proxy, support multi-cluster networking, and power Kubernetes-native ingress and service mesh use cases. In other words, Cilium uses eBPF to make Kubernetes networking faster, more secure, and easier to observe without requiring application changes. That matters because Kubernetes networking is not just about getting packets from one pod to another. In production, platform teams need policy enforcement, load balancing, service discovery, observability, encryption, and troubleshooting across clusters that are constantly changing. Cilium was built for that kind of environment. Why Kubernetes Needed a Better Networking Solution Kubernetes made application deployment more dynamic, but it also made networking harder to operate at scale. Pods are created and destroyed constantly. Services move. IP addresses change. Workloads may span multiple nodes, clusters, clouds, and teams. Traditional networking tools were not designed for this level of churn. Older Kubernetes networking approaches often rely heavily on iptables, IP-based rules, and per-node rule updates. That model works, but it can become difficult as environments grow. Large clusters may end up with many rules to manage, and security policies tied too closely to IP addresses become harder to reason about when pod IPs are temporary. Cilium takes a different approach. Instead of treating workload IPs as the primary identifier, Cilium uses identity derived from Kubernetes metadata such as labels, namespaces, and service accounts. It then uses eBPF programs in the Linux kernel to enforce networking and security decisions close to where packets are processed. For Kubernetes teams, this means Cilium can improve three things at the same time: connectivity, security, and visibility. It helps keep the Kubernetes networking model intact while giving platform and security teams a more scalable way to control what workloads are allowed to do. What Is eBPF and Why Does Cilium Use It? eBPF is a Linux kernel technology that lets programs run safely inside the kernel at specific hook points. In networking, that means eBPF programs can inspect, redirect, drop, load balance, and observe packets without requiring a traditional userspace networking path for every decision. Cilium uses eBPF because Kubernetes networking decisions often need to happen quickly and with context. When a packet leaves a pod, Cilium can use eBPF to understand which workload sent it, what identity is attached to that workload, what policy applies, and where the traffic should go. This is different from older security models that depend mostly on IP addresses and large sets of node-level rules. In a busy Kubernetes cluster, using IP addresses as an identifier proved to be a weak security boundary because they change frequently. Kubernetes labels, service accounts, and namespaces are closer to the way teams actually think about applications. The performance advantage comes from doing more work in the kernel and avoiding unnecessary hops through legacy packet processing paths. The security advantage comes from combining packet-level enforcement with Kubernetes-aware identity. The observability advantage comes from eBPF's ability to expose network events without relying on sidecar containers or bolting on a separate packet capture system for every issue. This is why eBPF is central to Cilium. It is the foundation that lets Cilium operate as a high-performance datapath, an identity-aware policy engine, and a source of real-time network visibility. How Cilium Works Cilium works through a set of components deployed into the Kubernetes cluster. The Cilium agent runs on each node and watches Kubernetes for workload, service, and policy changes. The Cilium CNI plugin is called when pods are created or removed, while the Cilium Operator handles cluster-wide tasks that do not need to run on every node. The agent then programs the eBPF datapath so networking, load balancing, and policy enforcement are ready for those workloads. Networking As a Kubernetes CNI, Cilium provides pod networking and service connectivity. It can run in overlay mode using VXLAN or Geneve, or in native routing mode when the underlying network can route pod addresses directly. Cilium can also replace kube-proxy. Instead of relying on kube-proxy and iptables for Kubernetes Service load balancing, Cilium can implement service handling with eBPF. This supports common Kubernetes Service types such as ClusterIP, NodePort, LoadBalancer, externalIPs, and hostPort, depending on configuration. The practical result is a networking layer that can support high service density, lower latency, and more efficient load balancing across Kubernetes workloads. Security Cilium security starts with identity. Workloads that share the same relevant Kubernetes labels can share a security identity. Policies can then allow or deny traffic based on identity rather than constantly changing IP addresses. Cilium supports standard Kubernetes NetworkPolicy and extends the model with CiliumNetworkPolicy and CiliumClusterwideNetworkPolicy. These policies can enforce Layer 3 and Layer 4 rules, but they can also go further into Layer 7 for protocols such as HTTP, DNS, Kafka, and gRPC. For example, a policy can allow traffic to a service on TCP port 80, but only allow GET /public at the HTTP layer. Cilium can also enforce policies based on Kubernetes service accounts, DNS names, namespace labels, and cluster identity in multi-cluster environments. Observability Observability comes through Hubble, which is built on top of Cilium and eBPF. Hubble provides visibility into network flows, service dependencies, DNS activity, policy drops, and L7 protocol behavior. This is useful because many Kubernetes networking issues are not obvious from logs alone. A service might be failing because DNS resolution broke, a policy denied traffic, a TCP connection timed out, or an HTTP request returned an error. Hubble helps answer those questions with flow-level context. Hubble can run at node scope, cluster scope through Hubble Relay, and even across clusters in a Cluster Mesh scenario. Hubble UI can also show a service map so teams can see how workloads are communicating. Key Benefits of Using Cilium Cilium is popular in Kubernetes environments because it brings several production concerns into one platform: High-performance Kubernetes networking through eBPF kube-proxy replacement for efficient service load balancing Identity-based network security Support for Kubernetes NetworkPolicy and richer Cilium policies Layer 7 policy enforcement for application-aware controls DNS-aware and FQDN-based egress policy Deep observability with Hubble Multi-cluster networking through Cluster Mesh Gateway API and service mesh capabilities Reduced operational complexity by combining networking, policy, and visibility The important part is not just that Cilium has many features. It is that those features share the same foundation. The same identity model that helps with policy also helps with observability. The same eBPF datapath that powers pod connectivity also supports efficient load balancing and visibility. Common Cilium Use Cases Secure Kubernetes Networking Cilium is often used as the primary CNI for Kubernetes clusters that need production-grade networking and security. It connects pods and services while giving platform teams stronger control over traffic. Kubernetes Network Policies Teams use Cilium to enforce both standard Kubernetes NetworkPolicy and Cilium-specific policies. This is especially useful when teams need namespace isolation, service account-based access, DNS-aware egress, or Layer 7 filtering. Multi-Cluster Networking Cilium Cluster Mesh connects multiple Kubernetes clusters. It supports pod-to-pod connectivity across clusters, cross-cluster service discovery, load balancing, and cluster-aware policy enforcement. API Connectivity Because Cilium can understand Layer 7 protocols, it can help secure API communication between services. Policies can be written around HTTP methods, paths, headers, DNS names, and service identities. Service Mesh Cilium can provide service mesh capabilities without requiring every workload to run a sidecar proxy. It uses eBPF for the network datapath and Envoy for application-layer protocol handling when L7 features are needed. Workload Segmentation Cilium helps reduce lateral movement by enforcing least-privilege connectivity between workloads. Instead of relying on IP addresses alone, teams can define policies using Kubernetes identities such as labels, namespaces, and service accounts, making it easier to control which services are allowed to communicate. Cloud-Native Observability With Hubble, teams can monitor service communication, identify policy drops, troubleshoot DNS issues, and understand how applications behave across the network. Cilium vs Traditional Kubernetes Networking Cilium does not change the core Kubernetes idea that pods and services need reliable connectivity. It changes how that connectivity is implemented, secured, and observed. Cilium vs Other Kubernetes Networking Solutions Cilium is one of several Kubernetes CNI options. Calico, Flannel, OVN Kubernetes, and other network plugins all solve Kubernetes networking in different ways. The right choice depends on the environment, operating model, and the level of networking, security, and observability the platform needs. Where Cilium stands out is its maturity and adoption across the Kubernetes ecosystem. Cilium is a CNCF graduated project, and major cloud providers have adopted Cilium or Cilium-based eBPF dataplanes in their Kubernetes offerings, including Azure, Google Cloud, and AWS. That broader adoption is one reason Cilium is increasingly treated as a standard foundation for modern Kubernetes networking. Cilium also tends to stand out when teams need more than basic pod connectivity. Its strengths include eBPF-based performance, kube-proxy replacement, identity-based policy, deep observability, Layer 7 enforcement, multi-cluster support, and Gateway API or service mesh capabilities. That does not mean every cluster needs every Cilium feature on day one. Many teams start with Cilium as the CNI, then enable Hubble, network policy, kube-proxy replacement, Gateway API, Cluster Mesh, or service mesh capabilities as their platform matures. How Isovalent Extends Cilium for Enterprise Isovalent helps enterprises run Cilium in production with support, operational tooling, advanced networking, observability, security, and multi-cluster capabilities. That matters because adopting Cilium is not only a technology choice. It is also an operating model for how platform, network, and security teams collaborate around Kubernetes. Enterprise environments often need compliance controls, consistent policy management, deeper troubleshooting workflows, and support across hybrid or multi-cloud infrastructure. Isovalent Networking for Kubernetes builds on the open source foundation to help teams standardize Cilium across those environments. If your organization is evaluating Cilium for production Kubernetes networking, Isovalent can help with architecture, operations, and enterprise support. The Future of Cilium Cilium sits at the intersection of several major infrastructure trends. Kubernetes continues to be the platform layer for modern applications. eBPF is becoming a standard way to add programmable networking, security, and observability to Linux systems. Platform engineering teams are looking for reusable cluster patterns instead of one-off networking setups. Security teams are moving toward identity-aware and zero trust controls. Cilium fits into those trends because it gives teams a Kubernetes-native way to connect, secure, and observe workloads without treating each concern as a separate system. Gateway API adoption also points in the same direction: more traffic management expressed through portable Kubernetes resources rather than controller-specific annotations. That same pattern is now extending beyond traditional microservices. Kubernetes has become the platform for more than containers, with teams using it for AI workloads, platform services, and virtual machines through projects like KubeVirt. Those workloads still need reliable connectivity, strong isolation, visibility, and multi-cluster operations. As Kubernetes becomes the common platform for containers, AI, and VMs, the value of a consistent eBPF-based networking layer increases. Frequently Asked Questions About Cilium Is Cilium a CNI? Yes. Cilium can run as a Kubernetes CNI plugin, but it also provides security policy, observability, load balancing, multi-cluster networking, Gateway API, and service mesh capabilities. What is Cilium used for? Cilium is used for Kubernetes networking, network policy enforcement, kube-proxy replacement, service load balancing, multi-cluster connectivity, API-aware security, and network observability with Hubble. How does Cilium use eBPF? Cilium programs eBPF into the Linux kernel to process traffic, enforce policy, perform load balancing, and collect visibility data close to where packets move through the system. Does Cilium replace kube-proxy? Cilium can replace kube-proxy with eBPF-based service load balancing. This is optional and depends on how Cilium is configured. What is Hubble in Cilium? Hubble is Cilium's observability layer. It provides flow visibility, service maps, DNS and HTTP insight, policy drop information, and troubleshooting data for Kubernetes networking. Summary Cilium is more than a Kubernetes CNI. It is an eBPF-powered platform for Kubernetes networking, security, and observability. It connects workloads, replaces kube-proxy when configured to do so, enforces identity-based policies, exposes traffic visibility through Hubble, and supports advanced use cases like Cluster Mesh, Gateway API, and service mesh. If you are trying to understand what Cilium is, the short answer is this: Cilium gives Kubernetes a modern networking foundation built for dynamic cloud-native infrastructure. For teams running Kubernetes in production, that foundation can make networking faster, security more precise, and troubleshooting much less painful. Learn more about Isovalent Enterprise for Cilium or request a demo to see how Cilium can fit into your Kubernetes platform.