# Cilium > Cilium is an open source, CNCF graduated project that uses eBPF to deliver networking, security, and observability for Kubernetes and cloud native platforms. It provides a high-performance Container Network Interface (CNI), an eBPF-based kube-proxy replacement, identity-based network policy, transparent encryption, multi-cluster connectivity, a sidecar-free service mesh, and deep network observability through Hubble. Cilium was created by Isovalent part of Cisco and runs in production at Google, Amazon, Microsoft Azure, Adobe, Bell Canada, The New York Times, Datadog, Bloomberg, TikTok, Alibaba Cloud, and thousands of other companies. Official site: https://cilium.io. Documentation: https://docs.cilium.io **What is Cilium** Cilium is a cloud native networking and security platform for Kubernetes built on eBPF, a Linux kernel technology that runs sandboxed programs inside the kernel without changing kernel source or loading modules. By programming the dataplane in eBPF, Cilium replaces iptables-based packet processing with a more scalable, lower-latency, identity-aware dataplane. Cilium operates at the network (L3/L4) and application (L7) layers. It assigns a security identity to each Kubernetes workload, enforces policy based on identity rather than IP address, and provides visibility into every network flow. The Hubble sub project adds flow logs, metrics, and a service dependency map; the Tetragon sub project adds eBPF-based runtime security and enforcement. Cilium graduated in the Cloud Native Computing Foundation (CNCF) in 2023 and is the default or recommended CNI for many managed Kubernetes platforms and distributions, including Google GKE Dataplane V2, Microsoft AKS, Digital Ocean Kubernetes, Red Hat OpenShift, kind, and more. Cilium is often compared to other CNIs such as Calico and Flannel. It differs primarily in its eBPF dataplane, which enables identity-aware policy, scalability, and observability that IP-table-based CNIs can't provide natively. For service mesh, Cilium's sidecar-free approach and eBPF dataplane separate it from others like Istio or Linkerd. **Core capabilities** - **Container networking (CNI):** Kubernetes pod networking with an eBPF dataplane, IPAM, overlay (VXLAN/Geneve) and native/direct routing modes, ENI/Azure delegated IPAM, and BIG TCP and netkit for high throughput. - **kube-proxy replacement:** eBPF-based service load balancing for ClusterIP, NodePort, and LoadBalancer services, with Maglev consistent hashing, Direct Server Return (DSR), and XDP acceleration, eliminating iptables scaling bottlenecks. - **Network policy and security:** identity-based microsegmentation with Kubernetes NetworkPolicy and CiliumNetworkPolicy (CNP) at L3/L4/L7, DNS/FQDN-aware policy, and host firewall for zero-trust networking. - **Observability with Hubble:** identity-aware L3/L4/L7 network flow logs, DNS visibility, Prometheus and OpenTelemetry metrics, Grafana dashboards, and a real-time service dependency map. - **Transparent encryption:** WireGuard and IPsec pod-to-pod in-transit encryption with no application changes and ztunnel for mTLS, supporting compliance and FIPS requirements. - **Multi-cluster (Cluster Mesh):** cross-cluster service discovery, global services, and pod-to-pod connectivity, observability, and security across clusters, regions, and clouds. - **Sidecar-free service mesh:** eBPF and Envoy-based L7 traffic management and mutual TLS (mTLS) without per-pod sidecar proxies, reducing latency and resource overhead. - **Runtime security (Tetragon):** eBPF-based process execution, file access, and network monitoring with kernel-level enforcement for threat detection and forensics. --- This is the **full** version (`llms-full.txt`). [llms.txt](https://cilium.io/llms.txt) is the map and this file is the territory: it contains one section per page linked from llms.txt, in the same order. Content pages on cilium.io are inlined in full, the Blog entry expands to the full text of every post published on the site plus an index of external posts, and map entries without substantive on-site text keep their one-line description. For deep technical specifications, see the official documentation at https://docs.cilium.io. ## Use cases ### High Performance Cloud Native Networking (CNI) URL: https://cilium.io/use-cases/cni Category: Networking _Enhance the speed and efficiency of your Kubernetes and cloud native networks_ **How can I have scalable and consistent networking across clouds?** There are dozens of CNIs available for Kubernetes but, their features, scale, and performance vary greatly. Many of them rely on a legacy technology (iptables) that cannot handle the scale and churn of Kubernetes environments leading to increased latency and reduced throughput. Most CNIs also only offer support for L3/L4 Kubernetes network policy but little beyond. Many Cloud Provider have their own custom CNIs which results in operational complexity for customers operating in multi-cloud environments. #### High Performance Cloud Native Networking CNI Cilium’s control and data plane has been built from the ground up for large-scale and highly dynamic cloud native environments where 100s and even 1000s of containers are created and destroyed within seconds. Cilium’s control plane is highly optimized, running in Kubernetes clusters with 1,000s of nodes and 100K pods. Cilium’s data plane uses eBPF for efficient load-balancing and incremental updates, avoiding the pitfalls of large iptables rulesets. #### Scalability Cilium is built to scale. Whether you're running a few nodes or managing a cluster with thousands, Cilium can handle it. Cilium’s eBPF-powered networking is optimized for large scale operations. This means you can grow your operations without worrying about the network becoming a bottleneck. #### Network Security Cilium doesn't just excel in performance, it also brings robust security features. With identity-based security that goes beyond traditional IP address-based ACLs, Cilium provides fine-grained policy enforcement. This allows you to control who can talk to whom, reducing the attack surface and helping secure your cloud native applications. #### Integration Cilium integrates seamlessly with Kubernetes, providing networking and security through a CNI plugin. Cilium has been tested, validated, and optimized across multiple clouds and Kubernetes distributions. All major cloud providers have already standardized on Cilium for cloud native networking and security needs with Kubernetes. Managed Kubernetes offerings from Google Cloud, AWS, Azure, Alibaba, DigitalOcean, and several smaller platforms like Civo, Linode, etc, leverage Cilium for their CNI. _Adopters & resources referenced on this page:_ AWS picks Cilium for Networking & Security on EKS Anywhere; Cilium in Anthos and Google Kubernetes Engine (GKE) as Dataplane V2; Azure CNI Powered by Cilium in Azure Kubernetes Service; Alibaba Cloud turns to Cilium for improved Network Performance and Scalability; SysEleven Picks Cilium as the Preferred Networking Solution for their Platform; CNI Benchmark: Understanding Cilium Network Performance. ### Kube-proxy Replacement URL: https://cilium.io/use-cases/kube-proxy Category: Networking _Enhanced networking speed and efficiency for your Kubernetes clusters_ **Liberating Kubernetes From kube-proxy and IPtables** IPtables and Netfilter are the two foundational technologies of kube-proxy for implementing the Service abstraction. They carry legacy accumulated over 20 years of development grounded in more traditional networking environments that are typically far more static than your average Kubernetes cluster. In the age of cloud native, they are no longer the best tool for the job, especially in terms of performance, reliability, scalability, and operations. #### Kubernetes Without Kube-Proxy Cilium’s control and data plane has been built from the ground up for large-scale and highly dynamic cloud native environments where 100s and even 1000s of containers are created and destroyed within seconds. Cilium’s control plane is highly optimized, running in Kubernetes clusters of up to 5K nodes and 100K pods. Cilium’s data plane uses eBPF for efficient load-balancing and incremental updates, avoiding the pitfalls of large IPtables rulesets. #### Seamless Integration and Upgrade If you already have kube-proxy running as a DaemonSet, transitioning to Cilium is a breeze. Replacing kube-proxy with Cilium is a straightforward process, as Cilium provides a Kubernetes-native implementation that is fully compatible with the Kubernetes API. Existing Kubernetes applications and configurations can continue to work seamlessly with Cilium. #### Unlock Advanced Configuration Modes Cilium's kube-proxy replacement offers advanced configuration modes to cater to your specific needs. Features like client source IP preservation ensure that your service connections remain intact, while Maglev Consistent Hashing enhances load balancing and resiliency. With support for Direct Server Return (DSR) and Hybrid DSR/SNAT modes, you can optimize traffic routing and improve performance. _Adopters & resources referenced on this page:_ Post Finance picks Cilium for Cloud Native Networking; SmartNews leverages Cilium to improve performance and scaling; Service Load-Balancing Without Kube-Proxy on Kubermatic; Kakao improves network performance and lowers costs with Cilium; Why is the kernel community replacing iptables with BPF?. ### Layer 4 Load Balancer URL: https://cilium.io/use-cases/load-balancer Category: Networking _High performance load balancing with low overhead_ **How can I implement efficient L4 load balancing with low overhead and cost?** Configuring and managing load balancing into your cluster can be challenging due to the complexity involved in setting up connectivity and synchronization between the clusters and the outside world. Traditional hardware load balancers can be very costly while software load balancers may not provide the performance you need. External-to-Pod (North-South) LB also typically requires additional tooling, adding more complexity, cost, and overhead. #### XDP and eBPF powered scalable Load Balancing and Ingress Cilium can attract traffic with BGP and accelerate it leveraging XDP and eBPF. Together these technologies provide a very robust and secure implementation of Load Balancing. Cilium and eBPF operate at the kernel layer. With this level of context intelligent decisions can be made about how to connect different workloads whether on the same node or between clusters. With eBPF and XDP Cilium enables significant improvements in latency and performance. Cilium's standalone load balancer offers a high-performance LB, providing huge throughput gains at a reduced CPU overhead. #### Cilium Standalone Layer 4 Load Balancer XDP Cilium's high performance, robust load balancing implementation is tuned for the scale and churn of cloud native environments. You can replace expensive legacy boxes in your network with Cilium as a standalone load balancer. This unlocks the potential of DSR and Maglev for handling north/south traffic in on-premises environments without requiring Kubernetes to manage the network border. _Adopters & resources referenced on this page:_ Efficiently handling production traffic with Cilium Standalone Layer 4 Load Balancer XDP; Software L4 Load Balancing for Kubernetes Services at Yahoo. ### Advanced Network Policy URL: https://cilium.io/use-cases/network-policy Category: Security _Maintain identity based policies effectively at scale_ **How can I implement granular security policies when IPs change quickly?** Kubernetes network policies provide an application-centric construct for defining security policies at L3/L4 level. One of the primary challenges is how to effectively enforce security policies when traditional IP rules don't apply. Modern systems often churn IPs dynamically making it difficult to rely entirely on TCP/UDP ports and IP addresses for scaling security policies. #### Application and DNS Aware Policies with Cilium Cilium implements Kubernetes Network Policies for L3/L4 level and extends with L7 policies for fine grained API-level security for common protocols such as HTTP, Kafka, gRPC, etc. For example, the endpoint with label role=frontend can only perform the REST API call GET /userdata/[0-9]+, all other API interactions with role=backend are restricted. #### Scaling policies with Identities not IPs Cilium decouples security from network addressing using workload identity derived from labels and metadata, allowing for more flexible and efficient scaling without constant security rule updates. #### Policy visualization and editing Cilium provides a simple and intuitive network policy editor UI easing the cognitive overhead of writing network policies. It can often be painful to get the YAML syntax and formatting right when implementing network policies. There are many subtleties in the behavior of the network policy specification (e.g. default allow/deny, namespacing, wildcarding, rules combination, etc) that can result in misconfiguration. #### Multi-cluster Policies Cluster Mesh, Cilium's multi-cluster implementation features Network policy enforcement spanning multiple clusters. The same policy enforcement you are familiar with from a single cluster simply expands and works across multiple clusters. #### Cluster-wide Policies Cilium also features cluster wide policies which are non-namespaced and cluster scoped via the extended CiliumClusterwideNetworkPolicy CRD. Using cluster-wide policies, administrators can enforce consistent policies across all namespaces, simplifying network management. _Adopters & resources referenced on this page:_ Scaling for the future with Cilium; Observability for a highly available multi cluster environment with Hubble; How ClickHouse is Using Cilium to Implement Efficient Network Policies; Self-service, Zero Trust Network Security; Enforcing Network Policies for Host Processes via eBPF; Migrating to Cilium for Better Networking, Visibility and Security; Implementing Zero Trust Security with Cilium. ### Transparent Encryption URL: https://cilium.io/use-cases/transparent-encryption Category: Security _Encryption without operational headache_ **How can I encrypt traffic on my clusters while minimizing operational overhead?** Many compliance frameworks require encryption, but Kubernetes lacks native pod-to-pod encryption. Two common solutions to this problem are embedding encryption within the application or using a service mesh. Embedding encryption within the app is complex and requires application and security expertise. On the other hand, most service mesh implementations are very complex and challenging to manage and operate. #### What does Cilium provide? Cilium provides a straightforward solution for enabling the encryption of all node-to-node traffic with just one switch, no application changes or additional proxies. Cilium features automatic key rotation with overlapping keys, efficient datapath encryption through in-kernel IPsec or WireGuard, and can encrypt all traffic, including non-standard traffic like UDP. Simply configuring all nodes across all clusters with a common key and all communication between nodes is automatically encrypted. _Adopters & resources referenced on this page:_ Achieving HIPAA compliance with Cilium’s transparent encryption; Seamless Network Security and Privacy with Cilium. ### Cluster Mesh URL: https://cilium.io/use-cases/cluster-mesh Category: Networking _Unleashing the power of multi-cluster networking with Cilium Cluster Mesh_ **Seamless connectivity for multiple Kubernetes clusters** Multi-cluster Kubernetes setups are often adopted for reasons like fault isolation, scalability, and geographical distribution. This approach can lead to networking complexities. With such multi-cluster setups, traditional networking models struggle with service discovery, network segmentation, policy enforcement, and load balancing across clusters. Additionally, managing security protocols and policies across multiple environments can be a challenging endeavour due to the distributed nature of services. #### Cluster Mesh, Cilium's Multi-Cluster Networking Implementation Cilium Cluster Mesh allows you to connect the networks of multiple clusters in such as way that pods in each cluster can discover and access services in all other clusters of the mesh, provided all the clusters run Cilium as their CNI. This allows effectively joining multiple clusters into a large unified network, regardless of the Kubernetes distribution or location each of them is running. #### High Availability and Fault Tolerance Cluster Mesh enhances your services high availability and fault tolerance. It supports the operation of Kubernetes clusters in multiple regions or availability zones. If resources become temporarily unavailable, are misconfigured in one cluster, or offline for upgrades, it enables failover to other clusters, ensuring your services remain accessible at all times. #### Transparent Service Discovery Cluster Mesh automates service discovery across your Kubernetes clusters. Using standard Kubernetes services, it automatically merges services with identical names and namespaces across clusters into a global service. This means your applications can discover and interact with services, irrespective of the cluster they reside in, greatly simplifying cross-cluster communication. #### Effortless Pod IP Routing Cluster Mesh is able to handle Pod IP routing across multiple Kubernetes clusters at native performance. By using either tunneling or direct-routing, it circumvents the need for any gateways or proxies. This allows your pods to communicate across clusters seamlessly, enhancing the overall efficiency of your microservice architecture. #### Shared Services Across Clusters Cluster Mesh enables sharing of services such as secrets management, logging, monitoring, or DNS between all clusters. This reduces operational overhead, simplifies management, and maintains isolation between tenant clusters. #### Uniform Network Policy Enforcement Cluster Mesh extends Cilium's Layer 3-7 network policy enforcement to all clusters in the mesh. It standardizes the application of network policies, ensuring a consistent security approach across your entire Kubernetes deployment, irrespective of the number of clusters involved. _Adopters & resources referenced on this page:_ Most mature multi cluster application management technology; Transforming Networking with Cilium at Ecco; Multi-cluster networking with Cilium at Form3; Building ClickHouse Cloud From Scratch in a Year; How Wildlife Studios built a Global Multi Cluster Gaming Infrastructure with Cilium; Strengthening Security Across Distributed Kubernetes Clusters; High Performance Data Backend for Your AI/ML with MinIO and Cilium Cluster Mesh. ### Cilium Service Mesh URL: https://cilium.io/use-cases/service-mesh Category: Networking _Revolutionizing networking and simplify operations_ **Performance Meets Simplicity** Traditional service meshes, despite their benefits, can present significant challenges. These include the complexity and error-prone nature of IP and port-based network policies, performance overhead due to their proxy-based architecture, limited granularity in visibility of service-to-service communication, interoperability issues with existing infrastructure, scalability challenges as the number of services and traffic volumes increase, and operational and resource overhead. #### Cilium's Next-Generation Service Mesh Cilium Service Mesh redefines traditional service mesh frameworks by integrating the mesh layer directly into the kernel using eBPF, thus eliminating the need for sidecar proxies. It manages connectivity at both the networking and application protocol layers, handling protocols like IP, TCP, UDP, HTTP, Kafka, gRPC, and DNS with greater efficiency. #### Superior Networking with eBPF At the heart of Cilium is eBPF, a revolutionary technology built into the Linux kernel. With eBPF, Cilium delivers lightning-fast, efficient, and scalable networking. This bypasses the performance drawbacks of traditional proxies, enabling direct and efficient communication between your services. #### Control Plane Options Cilium Service Mesh gives users the choice of control plane options for the ideal balance of complexity and richness, from simpler options such as Ingress and Gateway API to richer options with Istio, to the full power of Envoy via the Envoy CRD. #### Sidecar-free Option With Cilium Service Mesh, users now have the choice to run a service mesh with sidecars or without them, based on their specific requirements and constraints. This flexibility reduces the complexity and overhead impact of sidecars. #### Hands-On: eCHO Playlist Whether you’re bootstrapping a service mesh from the ground up or adopting Cilium’s eBPF-powered service mesh later in your service mesh journey, the eCHO Recaps: Cilium Service Mesh playlist shows the entire timeline starting from the first demo and hands-on commands. Follow each episode as to see how service mesh includes ingress and Gateway API traffic management, all on real clusters with CLI walk throughs you can replay on-demand. _Adopters & resources referenced on this page:_ How Roche Manages Network Connectivity for 1000+ Edge Clusters; Strengthening Security Across Distributed Kubernetes Clusters; Revolutionizing Mesh Layers: Transitioning from Istio to Cilium at the New York Times; Simplifying Service Mesh with Encryption from Cilium. ### Gateway API URL: https://cilium.io/use-cases/gateway-api Category: Networking _Robust Kubernetes Ingress for traffic management_ **Evolving Past Ingress** Gateway API addresses the limitations of the Kubernetes Ingress API, which has traditionally been used to route traffic into Kubernetes clusters. While the Ingress API supports basic routing based on path and host rules, it lacks support for advanced routing features, only supports HTTP and HTTPS traffic, doesn’t separate out user/operator concerns, and can lead to inconsistencies due to vendor-specific annotations. Gateway API overcomes these constraints, providing a more robust, extensible, and role-oriented approach to traffic engineering.​ #### Advanced Routing and Protocol Support Cilium’s Gateway API implementation provides a fully conformant implementation of Kubernetes Ingress and offers advanced routing capabilities that go beyond the limitations of the Ingress API. It supports features such as traffic splitting, header modification, and URL rewriting. Additionally, it extends beyond HTTP and HTTPS traffic, with support of other protocols such as TCP, UDP, and gRPC. This allows for a more flexible and sophisticated routing strategies. #### Role-Oriented and Extensible Cilium’s Gateway API implementation was designed with different operational roles in mind, such as Infrastructure Providers, Cluster Operators, and Application Developers. By decomposing the Ingress API into several Gateway API objects, different personas can be assigned the appropriate access and privileges according to their responsibilities. This means that, for example, application developers would be allowed to create Route objects in a specified namespace, but would not be able to modify the Gateway configuration or edit Route objects in other namespaces.​ #### Reducing Tool Sprawl Cilium aims to simplify operations by reducing the number of cloud native networking, observability, and security tools required. It natively supports not just the Gateway API but also features like a sidecar-less Service Mesh, Transparent Encryption, Network Policies, and built-in observability with Hubble. This approach makes life easier for cluster operators, who only need a single tool to manage and upgrade for many, if not all, of their Kubernetes networking needs​​. #### Gateway API for Service Mesh (GAMMA) By leveraging the standard Kubernetes Gateway API for Mesh Management and Administration(GAMMA), Cilium can be used for sophisticated East-West traffic management within the cluster. Cilium support for GAMMA translates into simplicity for operators while providing advanced traffic management. ### Ingress URL: https://cilium.io/use-cases/ingress Category: Networking _Enhancing Kubernetes Ingress With Cilium_ **How can I expose my services with a protocol-aware mechanism?** The Kubernetes ecosystem is rich with ingress controllers, yet they often introduce complexity and limitations. Kubernetes ingress solutions often fall short when it comes to scalability, visibility, and security in dynamic cloud native environments. Many rely on iptables or other legacy networking constructs, which can lead to inefficient resource usage, performance bottlenecks, and limited observability. Additionally, ensuring source IP visibility, seamless TLS handling, and integration with advanced network policies often requires complex workarounds or additional tools, complicating operations and increasing overhead. #### Flexible Load Balancer for Simplified Management Cilium Ingress introduces flexible load balancer modes, enabling you to choose between dedicated and shared configurations tailored to your needs. In shared mode, resources are conserved by utilizing a single load balancer across all ingress resources. In dedicated mode, each ingress receives an independent load balancer, preventing conflicts like overlapping path prefixes. This adaptability ensures that scaling your application architecture never compromises performance or resource efficiency. #### Seamless Source IP Visibility Cilium Ingress ensures that backend applications retain access to the original source IP, a common pain point with other solutions. By leveraging TPROXY and the intelligent configuration of Envoy, Cilium maintains transparency in HTTP headers such as X-Forwarded-For and X-Envoy-External-Address. This seamless visibility is vital for debugging, logging, and implementing IP-based access controls without additional overhead. #### Advanced TLS Management With support for TLS termination and passthrough, Cilium Ingress simplifies secure traffic handling. It enables multi-TLS backend sharing while dynamically routing based on SNI. This eliminates configuration complexity and ensures robust security, even in highly dynamic environments. Applications benefit from simplified setup and seamless performance. #### eBPF Powered Network Security Cilium embeds security directly into the network layer using eBPF. This approach allows fine-grained enforcement of CiliumNetworkPolicies for traffic entering and exiting the cluster. Traffic passes through an Envoy proxy integrated with Cilium's policy engine, enabling precise control over network behavior. This dual-layer security ensures compliance with organizational policies while protecting against advanced threats. ### BGP URL: https://cilium.io/use-cases/bgp Category: Networking _Harness the infinite potential of Border Gateway Protocol (BGP) with Cilium_ **Supercharge Your Routing Protocol** Traditional IP routing can be static and inflexible, especially in cloud native environments where workloads are constantly being created, moved, and deleted. BGP's inherent ability to manage complex network topologies and routing data makes it an excellent fit for the dynamic and distributed nature of modern cloud native environments. #### Elevate your Networking Infrastructure with Cilium’s BGP Cilium amplifies the power of BGP, the backbone of the internet, to bring you high-speed, scalable, and secure routing for your cloud environments. Seamlessly integrating with existing infrastructure, Cilium's BGP is perfect for a range of deployments, from hybrid to multi cloud to edge. With advanced traffic engineering features, you'll have granular control over your network traffic, optimizing your network's performance and security. #### Effortless Integration of Existing Network Infrastructure Cilium's BGP support is designed to be simple and easy to integrate with your existing networking infrastructure. Wherever your application is running, Cilium can ensure efficient BGP routing for all your workloads. Many network infrastructures already use BGP for routing. By leveraging BGP, Cilium can seamlessly integrate with existing infrastructure, allowing Kubernetes pods to communicate with other parts of the network. _Adopters & resources referenced on this page:_ Trip.com's Hybrid Cloud Approach with Cilium for Workload Routing; Sidecar BGP Peering Pattern with Cilium at Preferred Networks; Leveraging Cilium’s BGP in Private Data Centers. ### Egress Gateway URL: https://cilium.io/use-cases/egress-gateway Category: Networking _Enhancing network security and traffic control exiting Kubernetes environments_ **Integrating Unpredictable IPs** Pods typically have ever-changing IP addresses in Kubernetes environments. Even if masquerading is used to mitigate this, the IP addresses of nodes can also change frequently. Egress gateways provide a way to route all outbound traffic from certain pods through a specific node with a predictable IP address. This predictable IP can be useful for scenarios where the traffic destination requires a known source IP, for instance, when working with legacy systems or firewall rules. #### Harness the Power of Egress Gateway with Cilium Egress Gateway with Cilium fundamentally transforms Kubernetes networking by addressing dynamic IP challenges, ensuring seamless integration with legacy systems and enhancing network security. It provides precise control over traffic routing, enabling selective direction of pod traffic through stable, predictable IP addresses. This feature enables granular traffic management, effective monitoring and filtering, and workload-specific routing, all while facilitating interoperability with systems requiring known source IPs. #### Selective Traffic Control The egress gateway allows fine-grained control over which pods' traffic should be routed through the gateway node. This is done by applying egress gateway policies that use label selectors to target specific pods. This selective routing can help in implementing security policies, achieving network isolation, and managing network costs. #### Workload-Specific Routing In multi-tenant Kubernetes clusters, different workloads might need to interact with different external systems that have specific network requirements. Egress gateways can help meet these requirements by allowing the configuration of workload-specific routing rules. _Adopters & resources referenced on this page:_ Zero Trust Networking at Scale (20k+ VCPUs, 100+ Dev Teams); Cilium Egress Gateway at Corner Banca SA. ### Host Firewall URL: https://cilium.io/use-cases/host-firewall Category: Networking _Host Security That Scales With Kubernetes_ **How can I secure the host namespace with same consistent security model?** Kubernetes nodes are the backbone of any cluster, but securing them presents unique challenges beyond the capabilities of traditional firewalls. Without granular host-level controls, nodes are vulnerable to unauthorized access, exposing critical cluster components, like kube-apiserver or etcd, to potential breaches. Static firewall rules struggle to adapt to the dynamic nature of Kubernetes environments, leaving gaps in protection during workload changes or updates. Additionally, misconfigurations in restrictive policies can disrupt essential communications, while limited visibility into host-level traffic makes monitoring and troubleshooting difficult. #### Consistent Security for Nodes and Pods Traditionally, securing Kubernetes environments required managing separate security models for nodes and pods, resulting in operational complexity and potential blind spots. Cilium Host Firewall eliminates this inconsistency by applying the same network policy model to the host. This approach extends Kubernetes declarative, policy-driven security model to the nodes hosting your workloads, delivering seamless, consistent protection across your entire environment. By leveraging YAML manifests, administrators can define, apply, and manage host-level policies with the same ease and precision as Kubernetes Network Policies, creating a unified approach to securing both pods and their underlying hosts. #### Host Security That Scales With Kubernetes Cilium Host Firewall empowers administrators to enforce fine-grained policies for node-level traffic. By matching on node labels, you can create targeted rules that allow or deny traffic based on specific needs, such as permitting only SSH or ICMP traffic to specific nodes. This level of control ensures that your nodes are protected from unauthorized access while maintaining the flexibility required for smooth operations. Cilium Host Firewall ensures consistent, granular, and adaptable security for every node in your cluster, giving you the confidence to scale securely in even the most demanding environments. ### Bandwidth and Latency Optimization URL: https://cilium.io/use-cases/bandwidth-optimization Category: Networking _Simple and intuitive network performance optimization_ **Offering Latency and throughput improvements while controlling pod network contention** Kubernetes lacks native traffic control capabilities, making Traffic Rate-Limiting essential for optimal resource consumption and to prevent bandwidth exhaustion. While Kubernetes does offer Bandwidth Rate-Limiting, it is still experimental and can have detrimental effects on latency. Furthermore, connecting to external-facing Kubernetes clusters may result in a poor user experience due to most TCP congestion protocols not being designed for today's diverse networks. #### Optimal Bandwidth Management with Cilium’s Bandwidth Manager Cilium’s Bandwidth Manager allows rate-limiting per Pod with just one line of YAML. Compared to other alternatives, the Bandwidth Manager provides a 4x reduction in latency, ensuring a smooth network experience and isn’t detrimental to performances and is designed for multi-queue and multi-core NICs. #### Accelerate network performance with Cilium BBR Cilium supports BBR, a congestion control algorithm developed by Google, making it the first platform to do so. Google observed up to 2,700x improvement in throughput when testing BBR, making it a valuable addition for optimizing network performance. Cilium’s BBR provides exceptional improvements in throughput and latency for external-facing applications, offering consumers a delightful user experience #### 100Gbit/S Clusters With Cilium: Building Tomorrows Networking Cilium BIG TCP allows for larger packets than the traditional 64KB limit by leveraging IPv6's Hop-by-Hop header, which can specify payload lengths up to 512KB. This is particularly useful for organizations building networks capable of 100Gbps and beyond. BIG TCP does not require modifying the MTU on network devices, making it easier to implement than Jumbo Frames. With BIG TCP, Cilium offers enhanced network performance for nodes, enabling users to extract as much performance as possible from the network. _Adopters & resources referenced on this page:_ How Flipkart Implements Bandwidth QoS with Cilium; BIG Performances with BIG TCP on Cilium. ### IPv6-Native Kubernetes Networking with Cilium URL: https://cilium.io/use-cases/ipv6 Category: Networking _Cloud native networking at IPv6 scale, powered by eBPF_ **IPv6-Native Kubernetes Networking with Cilium** IPv6 adoption is accelerating across modern infrastructure. Address exhaustion, large-scale cluster growth, and cloud native connectivity are pushing platform teams toward IPv6-first designs. Cilium brings IPv6 deep into the Kubernetes datapath, enabling clusters to operate at scale without sacrificing performance, visibility, or control. Rather than treating IPv6 as a compatibility layer, Cilium integrates it directly into how traffic flows through the cluster. IPv6 unlocks massive address space, simplified routing, and long-term scalability. Cilium turns those advantages into practical outcomes for Kubernetes by combining IPv6-native networking with high-performance eBPF data paths. The result is a Kubernetes networking layer ready for the next decade of growth. #### IPv6 Underlay with Overlay Simplicity Operating Kubernetes across diverse infrastructure often requires abstraction from the physical network. Encapsulation modes such as VXLAN and Geneve provide that abstraction, allowing clusters to behave consistently regardless of where they run. Cilium enables these overlays to operate on top of an IPv6-only physical network. The underlay can be entirely IPv6 while pod-to-pod traffic continues to flow through a stable encapsulated datapath. This allows platform teams to modernize their networks to IPv6 without rethinking how Kubernetes connectivity is designed or operated. The result is an IPv6-native foundation with the same predictable networking model teams already trust. #### IPv6-Aware Egress Control Service networking is one of the most performance-sensitive paths in Kubernetes. Legacy approaches based on iptables introduce latency, complexity, and scaling challenges, problems that become more pronounced in large IPv6 environments. Cilium delivers IPv6 service handling directly in eBPF. Load balancing, service translation, and traffic steering all happen at the kernel level without relying on iptables or kube-proxy. IPv6 traffic benefits from the same high-performance, low-latency datapath that has made Cilium a standard for large-scale clusters. This creates a clean, efficient service model for IPv6 workloads that scales naturally as clusters grow. #### A Unified IPv6 Datapath Built on eBPF IPv6 in Cilium is implemented with the same eBPF-based datapath that powers IPv4 networking, security, and observability. This creates a unified model in which IPv4, IPv6, and dual-stack clusters share the same architecture and operational semantics. For platform teams, this means fewer special cases, simpler troubleshooting, and confidence that IPv6 workloads behave exactly as expected at scale. _Adopters & resources referenced on this page:_ TikTok's IPv6 Journey To Cilium: Pitfalls and Lessons Learned; IPv6 First, Not Just Ready: Kubernetes Without IPv4 Using Cilium at ESnet. ### Multicast URL: https://cilium.io/use-cases/multicast Category: Networking _eBPF-Powered Efficiency for Multicast in Kubernetes_ **Smarter Network Utilization** IP multicast is a bandwidth-conserving technology that reduces traffic by simultaneously delivering a single stream of information to potentially thousands of recipients. Multicast addresses the technical challenge of efficiently delivering data from a single source to multiple recipients simultaneously over a network. Multicast has found its use case in traditional networking, but Kubernetes networking often relies on unicast and broadcast methods.

In data transmission to containers within a Kubernetes cluster, packets are replicated and sent to every container regardless of their need. This approach might not be ideal for some applications with specific requirements and can lead to significant network congestion, high bandwidth, and overhead. #### Muticast the Cloud Native Way Cilium's multicast feature enables efficient network communication. By leveraging multicast, Cilium can efficiently transmit and replicate a single data stream to reach multiple consumer containers in a Kubernetes cluster, reducing the overall network bandwidth and overhead. This approach is particularly beneficial for industries like financial services, media, and entertainment, which typically have multiple services and endpoints that need to communicate simultaneously. #### Bringing the eBPF Revolution to Multicast Cilium's multicast implementation is not just efficient, it's also technically advanced. It's based on eBPF, a technology known for its exceptional efficiency and performance. By leveraging eBPF, Cilium ensures that the same level of optimization is brought to multicast as it does to a variety of other networking use cases. ### Identity-aware L3/L4/DNS Network Flow Logs URL: https://cilium.io/use-cases/network-flow-logs Category: Observability _Holistic view of your network traffic_ **How can you trace traffic to a specific workload in a complex environment?** Traditional network flow logs often lack the necessary level of detail and context needed to monitor and troubleshoot network issues in complex environments making it difficult to trace traffic back to specific workloads. This makes debugging difficult and time-consuming and makes it challenging to identify the source and scope of security incidents. #### Real time visibility for Network Flows By providing real-time visibility into network flows with enhanced metadata, including identity-based information about Kubernetes workloads, Cilium simplifies the process of monitoring and troubleshooting network traffic in Kubernetes clusters. This makes it easier to trace traffic back to specific workloads, simplifying the process of monitoring, troubleshooting, and addressing network issues, and enabling operators to quickly identify and respond to security incidents. #### Kubernetes-aware Network Flow Logs Cilium enhances network flow logs with additional information about the identity of the Kubernetes workloads generating or receiving the traffic. This identity information is based on the Kubernetes labels and annotations assigned to the workloads, as well as any other metadata that can be retrieved from the Kubernetes API server. _Adopters & resources referenced on this page:_ Observability for a highly available multi cluster environment with Hubble; Building Data Sandboxes at Bloomberg. ### Metrics & Tracing Export URL: https://cilium.io/use-cases/metrics-export Category: Observability _Valuable insights for troubleshooting, optimization, and performance monitoring_ **Monitor and analyze the performance and behavior of your Cilium-managed Kubernetes environment** Metrics alone may lack context for effective issue diagnosis. Configuring metrics exporters and integrating them with monitoring systems can be error-prone and manual. Inadequate, inconsistent, or incorrect metrics can be misleading, resulting in incorrect conclusions about the application state. Troubleshooting often requires correlating metrics with traces for a comprehensive system understanding. #### Metrics and Tracing With Cilium Cilium's Metrics and Tracing export feature provides a seamless and integrated solution empowering users to monitor, analyze, and optimize their Kubernetes environments with ease. By leveraging the power of Prometheus metrics, combined with Hubble's network behavior insights, Cilium enables users to gain deep visibility into their applications and network while simplifying the setup and configuration process. Cilium also integrates with various tracing systems, such as Jaeger, Zipkin, and OpenTelemetry, to provide distributed tracing capabilities. Cilium is optimized to handle high data volumes without compromising on performance. #### Comprehensive and Rich Set of Metrics Cilium captures a plethora of metrics, including latency, request rates, and error rates for your applications. These metrics are exported in a standardized Prometheus format, which can be easily integrated with your existing monitoring and visualization tools, enabling you to track your network performance in real-time. #### Distributed Tracing Cilium supports popular distributed tracing frameworks like Jaeger and Zipkin. With this, you can visualize request flow through your services, identify bottlenecks and optimize for efficiency. Cilium’s tracing provides a granular view of service interactions, bringing clarity to complex distributed systems. _Adopters & resources referenced on this page:_ eBPF-powered observability for Kubernetes and cloud native infrastructure; Cilium-powered Enterprise Kubernetes Management for Platform Teams. ### Advanced Network Protocol Visibility URL: https://cilium.io/use-cases/protocol-visibility Category: Observability _Insights into workload communication at the protocol level_ **How can I understand my workload’s communication at the protocol level?** Traditional network observability tools provide packet-level visibility, which can be insufficient in cloud native and other environments with complex communication patterns and diverse application protocols. In such scenarios, troubleshooting network issues can be challenging, and gaining protocol-level visibility becomes critical to ensure observability and security. #### Gain deep insights into your workload communication at the protocol level with Cilium Cilium's protocol-aware visibility provides application owners with deep insights into their workload’s communications at the protocol level. This means that Cilium is capable of native understanding of various application protocols, such as TLS, gRPC, Kafka, DNS, and HTTP, and other ones like SCTP enabling fine-grained observability of API-specific endpoints and DNS-identities for external endpoints. #### Hubble, eBPF-based Observability for Kubernetes Hubble is an eBPF-based observability platform for Kubernetes. Hubble leverages the Cilium CNI and eBPF technology to provide fine-grained visibility into network traffic and application behaviour, without the need to modify applications. With Hubble, administrators to interactively troubleshoot complex network issues and write custom metrics to benefit from eBPF's superpowers without the need to write or understand any kernel code. _Adopters & resources referenced on this page:_ Enhanced observability with Hubble; A more consumable network infrastructure with Cilium at Ikea. ### Service Map URL: https://cilium.io/use-cases/service-map Category: Observability _Detailed visibility into the communication and behavior of your workloads_ **How can I gain detailed visibility into the communication and behavior of my workloads?** When troubleshooting cloud native environments, the issue could be lurking between any layer of the network, environment, or its dependencies. For instance, it may be difficult to determine if DNS is working properly, or if an application is failing due to policy-related issues. Identifying the latest policy-related drops or determining if essential traffic between service components is being blocked can also prove to be challenging. On the other hand, examining logs for answers can be a difficult and time-consuming process. #### Hubble, eBPF powered Network, Service, and Security Observability for Kubernetes Hubble provides a range of monitoring capabilities, including service dependencies and communication maps, network monitoring, application monitoring, and security observability. By relying on eBPF, all visibility is programmable and allows for a dynamic approach that minimizes overhead while providing deep and detailed visibility. #### Service Dependency Graph Simply looking at `kubectl get pods` does not indicate dependencies between each service or external APIs or databases. Hubble offers effortless automatic discovery of service dependencies within Kubernetes Clusters at L3/L4 and L7 levels. This allows for user-friendly visualization and filtering of dataflows as a Service Map, enabling easy management of service dependencies. _Adopters & resources referenced on this page:_ Building a Secure and Maintainable PaaS; Saving Cost and Accelerating Insights with Hubble; Providing Observability to Customers With Hubble; Transforming Scientific Computing Infrastructure for IPv6 with Cilium at ESnet. ### Runtime Security URL: https://cilium.io/use-cases/runtime-security Category: Security _Prevent threats and enforce policies in real-time_ **Achieve threat prevention in cloud native environments while maintaining operational agility** Cloud native environments are often dynamic and distributed, requiring a security approach that encompasses detection and prevention. Observing and filtering events in user space can be resource-intensive and lead to blind spots in security monitoring, leaving systems vulnerable to attacks. #### Security Observability and Runtime Enforcement with Cilium’s Tetragon Tetragon enables transparent security observability and real-time runtime enforcement through its eBPF-based technology. It provides deep visibility without requiring changes to the application and operates with low overhead through in-kernel filtering and aggregation logic built into the eBPF-based kernel-level collector. Tetragon's embedded runtime enforcement layer offers access control capabilities at various enforcement levels, including system call control. #### Kubernetes-aware Real Time Enforcement Tetragon is Kubernetes-aware, meaning it recognizes Kubernetes identities like namespaces and pods. This enables security event detection that can be tailored to individual workloads. Using eBPF, Tetragon can access the Linux kernel state and combine it with Kubernetes awareness and user policy to generate rules that are enforced by the kernel in real-time. This allows for capabilities like process namespace and capabilities annotation and enforcement, process file descriptor to filename association, and socket to process control. _Adopters & resources referenced on this page:_ Don't Get Blown up! Avoiding Configuration Gotchas for Tetragon Newbies; Integrating Tetragon for Secured Build Pipelines; Pollenating Build Attestations on Kubernetes with Tetragon and eBPF; Hubble + Tetragon at Palantir; Who Owns Your Pod? Observing and Blocking Unwanted Behavior at eBay With eBPF. ## Business outcomes ### Zero Trust Networking URL: https://cilium.io/outcomes/zero-trust _Enforce what matters, where it matters._ Traditional network security measures can be ineffective in cloud native systems due to the transient nature of IP addresses, the dynamic nature of workloads, and the rapid growth of east-west traffic. These internal communication routes are undefended by standard firewall-based security, and it becomes next to impossible to maintain static IP rules or network segments across numerous environments. Zero Trust Networking directly addresses these challenges by shifting the focus from trusting the network to explicitly verifying each connection and workload. Instead of assuming anything inside the network is safe, Zero Trust Networking requires all communication to be authenticated and authorized based on what a workload is, not where it runs. Cilium makes this practical in cloud native environments by enforcing identity-aware policies tied to Kubernetes service accounts and labels, applying them efficiently in the kernel with eBPF, supporting multi-cluster and multi-cloud deployments, and providing deep visibility into and security for service-to-service communication. #### Keep internal traffic secure at any scale In modern infrastructure, internal communication is often the largest and most vulnerable attack surface. In the absence of Zero Trust controls, attackers who breach one service have the ability to extend their attacks laterally, gain access to sensitive data, and escalate their attacks. For regulatory frameworks like PCI DSS, GDPR, and HIPAA, protection of internal communication is becoming increasingly necessary in order to comply, and firewall-based controls aren’t enough. Cilium helps you meet these security and compliance demands by enforcing Zero Trust Networking policies that protect every connection, no matter how large or complex your environment becomes. #### Enforcing identity driven policies instead of IP-based rules As workloads scale, restart, or move across nodes and clusters, IP addresses change constantly, creating gaps or needing constant rule updates. Cilium solves this by applying security policies tied to Kubernetes-native identities like service accounts, pod labels, and namespaces. These identities stay consistent even as workloads shift or restart, so policies automatically follow the correct services wherever they run, removing the need to manage static network rules and ensuring reliable Zero Trust Networking enforcement at scale. #### Implement policies in the kernel Typically, enforcing Zero Trust Networking relies on proxies, sidecars, or userspace components to inspect and control traffic. These methods can make things more complicated to run, especially as systems scale. Cilium takes a different approach by using eBPF to apply security policies directly in the Linux kernel. This allows high-performance enforcement at the source of the traffic without extra components in the data path. The result is fast, low-latency security that scales cleanly with your infrastructure. #### Secure at the API and application layer, not just at the network layer In cloud native environments, many microservices communicate through APIs. Traditional security solutions stop at IP addresses and ports, leaving critical API traffic and application-level interactions vulnerable to misuse. This creates blind spots that attackers can exploit once inside the network. Cilium extends Zero Trust Networking to Layer 7, enabling network policies that inspect and control traffic based on API paths, HTTP methods, gRPC calls, DNS queries, and more. This ensures services communicate only as intended and minimizes unnecessary exposure within your environment. #### Built-in distributed firewalling for Zero Trust Networking at scale Rather than relying on centralized firewalls or sidecar proxies, Cilium enforces security policies directly at the source of traffic using eBPF inside the Linux kernel. This distributed model applies identity-aware policies consistently across all nodes, clusters, and environments, without introducing bottlenecks. With visibility and control from Layer 3 to Layer 7, Cilium prevents unauthorized lateral movement and delivers scalable, low-overhead Zero Trust enforcement across cloud native infrastructure. #### Keep Zero Trust enforcement consistent across clusters and clouds Applications rarely run in just one cluster, region, or cloud. As environments grow more distributed, keeping security policies consistent across all of them becomes complex, and any gaps in enforcement between environments creates risk. Cilium makes it simple to define and apply Zero Trust Networking policies uniformly, no matter where your workloads run. Whether you operate in a single Kubernetes cluster, across multiple clouds, or in hybrid setups, Cilium helps ensure security stays consistent without duplication or increased complexity. _Adopters & resources referenced on this page:_ Implementing Zero Trust in highly regulated financial systems; Enforcing Zero Trust isolation in a multi-tenant platform; Building Zero Trust into the Choreo platform; Strengthening security and compliance across multi-cloud HR systems; Enforcing Zero Trust data protection and access controls; Network Policy; Advanced Network Protocol Visibility; Identity-aware L3/L4/DNS Network Flow Logs; Host Firewall. ### Tool Consolidation URL: https://cilium.io/outcomes/tool-consolidation _Simplify your networking stack without sacrificing visibility or control_ As cloud native environments grow in complexity, teams often rely on a patchwork of tools for networking, observability, and security, each with its own learning curve, performance trade-offs, and integration overhead. Cilium replaces this fragmented tooling with a unified platform built on eBPF that provides connectivity, security, and deep visibility all in one. #### Replacing a patchwork of tools with Cilium Managing and integrating multiple tools for service mesh, firewalling, load balancing, ingress, observability, and policy enforcement slows teams down. Cilium helps teams consolidate without compromise with one tool for managing network traffic, service discovery, API-aware security, and real-time network visibility. This reduces operational costs, accelerates onboarding, and improves performance, while maintaining full control. #### Consolidating your networking stack With Cilium, you get high-performance networking, API-aware security, and deep observability in a single tool powered by eBPF. It removes the need for standalone network plugins, sidecar-based service meshes, and third-party observability layers, while integrating natively with Kubernetes. #### Observe traffic in real time without extra tools Cilium’s Hubble brings powerful network visibility directly into your Kubernetes environment, surfacing flow logs, a service map, and protocol-level insights (HTTP, gRPC, Kafka, etc.) without installing separate monitoring or tracing tools. #### Enforce policies at Layer 3 to Layer 7 Unlike traditional firewalls, Cilium enforces identity-aware policies tied to Kubernetes primitives and inspects traffic all the way up to Layer 7. That means you can secure microservices based on actual behavior, from DNS queries to API calls, without additional tooling. _Adopters & resources referenced on this page:_ One CNI to Power Customer and Internal Infrastructure; Unified networking and observability for MetaKube; One Platform to Manage Global Scale; Hubble; Kube-proxy Replacement; Gateway API; Border Gateway Protocol (BGP); Layer 4 Load Balancer; Service Mesh. ### Multi-Cloud Connectivity URL: https://cilium.io/outcomes/multi-cloud-connectivity _Seamless service-to-service communication across clouds, clusters, and regions._ Connecting workloads across multiple clouds is often fragile and complex, introducing issues like overlapping IPs and inconsistent rules. Cilium solves this with a unified, eBPF-powered network that offers native service discovery, identity-aware security, and scalable performance that works wherever your infrastructure lives. #### Unified connectivity and service discovery across clusters Cilium’s Cluster Mesh enables services across multiple clusters in any cloud or on-prem environment to connect and discover each other natively, as if running in the same cluster. Connections are fast, encrypted, and identity-aware by default, with no need for complex networking configurations. #### Trusted across cloud providers Cilium powers the default networking for major Kubernetes platforms like GKE, EKS-A, and AKS, and is trusted by leading organizations operating at scale. Its performance and security model have been validated across a wide range of public clouds, private data centers, and edge environments, making it a reliable foundation for multi-cloud and hybrid infrastructure. Whether you're running in one cloud or many, Cilium makes sure your clusters have consistent connectivity, performance, and security. _Adopters & resources referenced on this page:_ From Network Outages to Seamless Connectivity; Scaling secure payments across regions; Simplifying global service communication at scale; Reliable, flexible connectivity for data automation; Bridging Clouds for smarter operations; High Performance Container Network Interface (CNI); Cluster Mesh. ### Network Automation URL: https://cilium.io/outcomes/network-automation _Automate and simplify Kubernetes networking at scale_ Manual network configuration can’t keep up with the speed of cloud native environments. In Kubernetes, where workloads are dynamic and infrastructure is distributed, traditional approaches to networking create bottlenecks, inconsistencies, and operational risk. Cilium brings automation to the core of Kubernetes networking. Cilium makes it possible to configure, secure, and observe network behavior automatically through identity-aware policies that adapt to workload changes, dynamic service discovery, an eBPF-powered datapath, and seamless integration with CI/CD and GitOps workflows. #### Make your networking configuration as dynamic as your workloads As workloads in cloud native environments scale, shift, and redeploy across clusters and clouds, manual network configuration quickly becomes unsustainable. Engineers are left to manage rigid IP rules, duplicate policies across environments, and react to changes rather than design systems that adapt automatically. Cilium addresses this by making the network programmable and declarative. It allows teams to specify intent once, using workload identity and Kubernetes-native components, and then trust that connectivity, security, and observability will respond in real time as the environment changes. This means less time spent developing and debugging YAML, fewer outages due to misconfigured rules, and increased confidence when deploying infrastructure or adding new services. By removing manual steps from the networking stack, Cilium helps platform and security teams move faster, reduce risk, and operate more reliably in even the most dynamic environments. #### Enforcing identity-driven policies instead of IP-based rules As workloads scale, restart, or move across nodes and clusters, IP addresses change constantly, creating configuration gaps, or a need for continual manual updates. Cilium solves this by applying security policies tied to Kubernetes-native identities like service accounts, pod labels, and namespaces. These identities remain consistent even as workloads shift, so policies follow services automatically without requiring engineers to rewrite or reapply static rules. This keeps network behavior predictable, secure, and in sync with your infrastructure design, with little to no manual intervention. #### Dynamic connectivity without manual updates Services in Kubernetes are always changing, either scaling up, down, or shifting across nodes. Manually updating routing or access rules to stay up-to-date is inefficient and error-prone. Cilium automates this by integrating deeply with Kubernetes. As services come and go, Cilium updates routing and policies in real time, ensuring that communication paths stay correct and secure without any effort. #### Consistent policy across clusters and clouds Cilium’s Cluster Mesh and cluster-wide policies make it possible to apply security rules consistently across namespaces, regions, or even different cloud providers. This unified approach removes the need to duplicate network configurations for each environment, reduces operational overhead, and minimizes the risk of inconsistencies, ensuring reliable protection no matter where workloads run. #### eBPF programs and secures the network in the kernel Rather than relying on centralized firewalls or sidecar proxies, Cilium enforces security policies directly at the source of traffic using eBPF inside the Linux kernel. This distributed model applies identity-aware policies consistently across all nodes, clusters, and environments, without introducing bottlenecks. With visibility and control from Layer 3 to Layer 7, Cilium prevents unauthorized lateral movement and delivers scalable, low-overhead [Zero Trust Networking](https://cilium.io/outcomes/zero-trust/) enforcement across cloud native infrastructure. #### Automated networking built for GitOps and CI/CD Modern infrastructure is managed as code, and your networking should be too. With Cilium, network policies are declarative, version-controlled, and Kubernetes-native, making them easy to integrate into the same pipelines and workflows you use for deploying applications. You can define policies in Git, review them through pull requests, and apply them automatically through CI/CD or GitOps tools. This makes your network configuration more consistent, easier to audit, and easier to automate, while ensuring that your infrastructure stays secure and in sync across all environments. _Adopters & resources referenced on this page:_ Solving latency and scaling network performance; Delivering high-performance cloud networking; Automating scalable networking across KubeSphere; Building a scalable, future-ready networking platform; Automating Kubernetes networking and security at scale; Kube-proxy Replacement; Network Policy. ### Cost and Carbon Savings URL: https://cilium.io/outcomes/cost-and-carbon-savings _Do more with less_ Manual and legacy network systems often come with hidden overhead like inefficient IP usage, many network redirects, and cloud charges that add up fast. Cilium removes these inefficiencies with a streamlined, eBPF-powered network engine, lowering costs while reducing compute waste and carbon dioxide emissions. #### Why Sustainability Starts at the Network Layer ​​In Kubernetes environments, inefficiencies in networking can grow quickly. Traditional solutions are often heavy on resource consumption, requiring extra nodes, IP addresses, and compute power. This not only inflates costs but also increases energy use and carbon emissions. Cilium changes that by optimizing network paths, removing unnecessary components, and providing granular observability, meaning teams can reclaim resources, cut bills, and improve sustainability. #### eBPF-powered dataplanes cut CPU costs Cilium replaces traditional kube-proxy and iptables-based networking with an eBPF-based dataplane. This removes the need for userspace proxies and reduces the overhead of managing long rule chains. By processing traffic closer to the source, Cilium shortens the network path, lowers CPU consumption, and frees up compute resources for actual workloads, saving both money and energy. #### High pod density with lean IP allocation Particularly when used at scale, other CNIs may require large blocks of IP addresses for every node, limiting pod density and resulting in wasted resources. Because Cilium manages IP allocation more efficiently, you can run more pods per node without running out of IPs. This improves resource utilisation and decreases infrastructure and electricity costs by reducing the number of nodes needed. #### Eliminate cloud load balancer charges With Cilium's Cluster Mesh, native pod-to-pod communication between clusters is possible without the need for costly cloud load balancers. This simplifies your architecture and prevents excessive data transfer fees. By removing external dependencies, teams gain more control over traffic, reduce latency, and cut down significantly on cloud networking costs. _Adopters & resources referenced on this page:_ Cutting networking overhead at scale; Lowering network costs while debugging faster; Lower costs with high-performance; Cutting storage costs and cloud networking complexity; Reducing cloud bills and IP footprint; Bandwidth and Latency Optimization; High Performance Container Network Interface (CNI); Kube-proxy Replacement. ## Ecosystem and subprojects ### Hubble URL: https://docs.cilium.io/en/stable/observability/hubble/ Networking and security observability layer built on Cilium and eBPF: flow logs, metrics, and service map. ### Tetragon URL: https://tetragon.io EBPF-based runtime security and observability for process, file, and network events. ### eBPF URL: https://ebpf.io The Linux kernel technology Cilium is built on. ## Key pages ### llms-full.txt URL: https://cilium.io/llms-full.txt Full-text version with the complete prose of every use-case, outcome, and industry page and every blog post inlined. (this file). ### Home URL: https://cilium.io/ The Cilium project home page. ### Get started URL: https://cilium.io/get-started What is Cilium and how to get started. ### Adopters URL: https://cilium.io/adopters Adopters and production users. ### Enterprise URL: https://cilium.io/enterprise Enterprise distributions and training. ### Blog URL: https://cilium.io/blog Full text of all 145 posts published on the cilium.io blog, newest first, followed by an index of posts that link to articles hosted elsewhere. #### How k0rdent and Cilium Turn Kubernetes Sprawl into a Platform URL: https://cilium.io/blog/2026/07/08/how-k0rdent-and-cilium-turn-kubernetes-sprawl-into-a-platform Date: 2026-07-08 Categories: Technology If you have spent time running Kubernetes in the real world, you know the catch: standing up one cluster is the easy part. The hard part starts when one cluster becomes ten, then a hundred, spread across cloud providers, bare metal, and on-prem environments. That is where k0rdent and Cilium fit together very well. **k0rdent** gives platform teams a single control plane to provision, template, and manage fleets of clusters declaratively and consistently. **Cilium**, built on eBPF, provides the networking, identity-based security, and observability those clusters need for production. Together, they help turn cluster sprawl into a repeatable platform pattern. Instead of bolting on networking, policy, and visibility one cluster at a time, teams can make them part of the cluster definition from the start. In this post, we will look at why platform teams pair k0rdent and Cilium, then walk through a hands-on example using a k0rdent `ClusterDeployment` with Cilium as the CNI. Let's dig in. ##### Built Once, But is it Consistent Everywhere? If you run a platform team, you're already juggling a growing fleet, workloads that need management, and a list of things that must stay consistent across every cluster. k0rdent and Cilium work well together because they address both sides of that problem: how clusters get built and how they behave once they are running. The drift usually shows up in small but painful ways. One cluster has Cilium configured differently, another is missing a policy that exists everywhere else, and another has incomplete visibility when a service-to-service call starts failing. Those differences are easy to create by hand and hard to debug at 2 a.m. k0rdent's answer is to treat the cluster as a template, and Cilium fits into that model directly. Cilium is available in the k0rdent catalog as a validated service template, meaning it can be attached to a cluster as a reusable add-on. Define it once, and every cluster k0rdent provisions can come up with the same Cilium foundation: CNI, policies, and observability included from the start. Visibility is also a factor. "Service A can't reach service B" is easy or hard depending entirely on what you can see. Cilium ships with Hubble, which gives you L3 through L7 flow visibility without sidecars by leveraging eBPF, and k0rdent helps make that visibility part of the standard cluster template rather than something enabled one cluster at a time. When something breaks, you can see where the traffic was dropped and why, and on which cluster it happened. Put it together and the practical result is that the platform team can run a much larger fleet, because the clusters are built the same way and behave predictably. ##### From Template to Running Cluster With the why out of the way, let's see what this actually looks like in practice. In this section we'll walk through deploying a k0rdent `ClusterDeployment` that uses Cilium as its CNI, so that the cluster comes up already networked the way we want rather than waiting for someone to wire it in afterward. A quick note on assumptions before we start. This walkthrough assumes you already have a k0rdent Management cluster up and running. If you don't, the [official quickstart](https://docs.k0rdent.io/latest/quickstarts/quickstart-1-mgmt-node-and-cluster/#install-a-kubernetes-cluster-as-the-management-cluster) walks you through setting one up. We'll also be deploying onto bare metal hosts, which means we'll be using the `remote-cluster` `ClusterTemplate` to bring those existing machines under management. A `ClusterTemplate` is k0rdent's reusable definition for how a cluster should be created. The `remote-cluster` template is useful when the infrastructure already exists, as it lets k0rdent connect to those machines over SSH and bootstrap them into a managed child cluster.. ###### Deploying the Remote Cluster Template For this example we're working with three Linux machines on the same network. One is the k0rdent node running our Management cluster. The other two, `worker1` and `worker2`, are the bare metal hosts that will become our child cluster. Because k0rdent provisions bare metal remote machines over SSH, the first thing we need is root SSH access to both workers. Let's generate a dedicated key pair for this so we're not reusing anything else, then copy it out to each host. ```shell ssh-keygen -f ~/.ssh/idk0r ssh-copy-id -i ~/.ssh/idk0r.pub root@worker1 ssh-copy-id -i ~/.ssh/idk0r.pub root@worker2 ``` Next, k0rdent needs a credential object so it knows how to authenticate against those workers. We install the `remote-credential` chart, then base64-encode the private key we just created and patch it into the secret k0rdent expects. ```shell helm install remote-credential oci://ghcr.io/k0rdent/catalog/charts/remote-credential -n kcm-system REMOTE_SSH_KEY_B64=$(cat ~/.ssh/idk0r | openssl base64 -A) kubectl patch secret remote-ssh-key -n kcm-system -p='{"data":{"value":"'$REMOTE_SSH_KEY_B64'"}}' ``` Here's where the pairing actually comes together. We install Cilium into k0rdent as a service template, which is what makes it something we can reference from a `ClusterDeployment` later. ```shell helm upgrade --install cilium oci://ghcr.io/k0rdent/catalog/charts/kgst \ --set "chart=cilium:1.19.0" -n kcm-system ``` Once it's installed, a quick check confirms the template is registered and valid. ```shell kubectl get servicetemplates -A | grep cilium ``` Now, we set up the cluster we want. We can do this with a `ClusterDeployment` that references the `remote-cluster` template for the bare metal hosts and the `cilium` service template for the CNI. Create a file called `remote-cld-cilium.yaml`: ``` apiVersion: k0rdent.mirantis.com/v1beta1 kind: ClusterDeployment metadata: name: remote namespace: kcm-system labels: type: remote spec: template: remote-cluster-1-0-22 credential: remote-credential propagateCredentials: false config: controlPlaneNumber: 1 k0smotron: service: type: NodePort machines: - name: worker1 address: 192.168.1.5 user: root port: 22 - name: worker2 address: 192.168.1.6 user: root port: 22 k0s: version: v1.35.3+k0s.0 network: # prepare for cilium calico: null provider: custom kubeProxy: disabled: true serviceSpec: services: - template: cilium-1-19-0 name: cilium namespace: kube-system values: | cilium: cluster: name: cilium hubble: tls: enabled: false auto: method: helm certManagerIssuerRef: {} ui: enabled: false ingress: enabled: false relay: enabled: false ipv4: enabled: true ipv6: enabled: false envoy: enabled: false egressGateway: enabled: false kubeProxyReplacement: "true" serviceAccounts: cilium: name: cilium operator: name: cilium-operator localRedirectPolicy: true ipam: mode: cluster-pool operator: clusterPoolIPv4PodCIDRList: - "192.168.224.0/20" - "192.168.210.0/20" clusterPoolIPv6PodCIDRList: - "fd00::/104" tunnelProtocol: geneve k8sServiceHost: "{{ .Cluster.spec.controlPlaneEndpoint.host }}" k8sServicePort: "{{ .Cluster.spec.controlPlaneEndpoint.port }}" ``` A couple of things worth calling out. We're disabling `kubeProxy` and setting `calico: null` because Cilium is going to take over that job with its eBPF datapath, and `kubeProxyReplacement` is set to `"true"` to make that explicit. Now, we can apply the `remote-cld-cilium.yaml` file, creating the cluster. ```shell kubectl apply -f remote-cld-cilium.yaml ``` From there, k0rdent takes over, reaching out to the workers over SSH, bootstraps k0s, and rolls out Cilium as the CNI as part of the same process. We can get the status of the `ClusterDeployment` with: ```shell kubectl get cld -A ``` Once you see the status of "READY" being "True", the cluster is ready to go\! ```shell NAMESPACE NAME READY SERVICES TEMPLATE MESSAGES AGE kcm-system remote True 1/1 remote-cluster-1-0-22 Object is ready 15m ``` ###### Running a Cilium Test Once the `ClusterDeployment` reports ready, we can pull the child cluster's kubeconfig straight from the secret k0rdent created and have a look around. Extract the secret, decode it, and save it to a file: ```shell kubectl get secret remote-kubeconfig -n kcm-system -o=jsonpath={.data.value} | base64 -d > kcfg_remote.yaml ``` Verify Cilium is up and running: ```shell kubectl --kubeconfig kcfg_remote.yaml get pods -A -l app.kubernetes.io/part-of=cilium ``` The output should show the Cilium pods running in the `kube-system` namespace: ```shell NAMESPACE NAME READY STATUS RESTARTS AGE kube-system cilium-mgw7b 1/1 Running 0 4h42m kube-system cilium-operator-758fc644d7-jjq8h 1/1 Running 0 4h43m kube-system cilium-operator-758fc644d7-nhdr4 1/1 Running 0 4h43m kube-system cilium-rxcfw 1/1 Running 0 4h38m ``` Now that we verified that Cilium is running, we can do a quick `CiliumNetworkPolicy` test. First, we'll deploy a small sample workload: a `webapp` that serves both a `/public` and a `/private` endpoint, along with a `client` pod we can use to reach it. ```shell kubectl --kubeconfig kcfg_remote.yaml \ apply -f \ https://gist.githubusercontent.com/christianh814/0d4c0d9529fe630775fa3f54f1725f80/raw/8e89d8d5d89f014e3d7899e32b4d71fe6498e93d/sample-workload.yaml ``` With no policy in place, the `client` pod can reach both endpoints. Both of these calls return data: ```shell $ kubectl --kubeconfig kcfg_remote.yaml exec -it client-pod -- curl http://webapp/public [ { "id": 1, "body": "public information" } ] $ kubectl --kubeconfig kcfg_remote.yaml exec -it client-pod -- curl http://webapp/private [ { "id": 1, "body": "secret information" } ] ``` That `/private` endpoint handing back "secret information" to anyone who asks is exactly the kind of thing we'd want to lock down. So let's write a `CiliumNetworkPolicy` that only allows the `client` to issue an HTTP `GET` against `/public`, and nothing else. ```shell kubectl --kubeconfig kcfg_remote.yaml apply -f -<