Summer is a busy time in nature, especially for bees. Long days and warmer weather bring an intense focus on building, refining, and maintaining the hive. That same energy has been mirrored in the open source Cilium project over the past few months. The 1.18 release brings a set of targeted improvements across networking, security, and observability, shaped by practical feedback and real-world needs from adopters using Cilium at scale. Cilium 1.18 – New features at a glance The latest open source release of Cilium includes all these new features and improvements. Networking Encrypted overlay: Protects tunnel metadata by applying IPsec after VXLAN or Geneve encapsulation, securing identity information in transit.(more details) Ingress rate limiting: Apply fine-grained ingress bandwidth caps to pods using annotations, improving tenant isolation and mitigating DoS risks.(more details) Load balancing control plane redesign: A complete internal rework of the service LB engine reduces memory usage and improves long-term maintainability. (more details) Multiple Egress Gateway nodes: Assign traffic to a pool of egress gateway nodes with deterministic, sticky selection for each endpoint.(more details) Multi-Pool IPAM enhancements: Improved support of Cilium's most flexible IPAM mode, including tunnel mode, kvstore sync, and IPsec with VXLAN support. (more details) AWS Prefix Delegation on bare metal: Use delegated IP prefixes on Nitro-based bare metal EC2 instances. (more details) IPv6 IPv6 underlay for encapsulation mode: Cilium VXLAN/Geneve overlays now support IPv6-only underlays.(more details) IPv6 underlay for kube-proxy replacement: Run Cilium’s eBPF-based kube-proxy replacement on top of IPv6-first networks. (more details) IPv6 support for Egress Gateway: Extend egress policies to support IPv6 destination CIDRs. (more details) BGP BGP route aggregation: Collapse large numbers of /32 or /128 service IPs into summarized prefixes, reducing BGP route churn. (more details) BGP Router ID pool: Assign unique BGP Router IDs from a configurable IP pool, simplifying setup in large or IPv6-only clusters. (more details) Service Mesh & Gateway API Gateway API v1.3.0 support: Keep pace with the latest upstream spec, including support for request mirroring, retry budgets, and enhanced CORS. (more details) Improved GatewayClass configuration: Fine-tune gateway behavior with the new CiliumGatewayClassConfig for validation and policy controls. (more details) Multiple HTTPRoutes per Service (GAMMA): Attach more than one HTTPRoute to a single Kubernetes Service for east-west traffic control. (more details) Security & Observability Cluster Mesh policy isolation: New default behavior restricts policies to the local cluster unless explicitly targeting a remote one. (more details) Hubble log field support – Add searchable, plain-text log messages to network policies for easier troubleshooting.(more details) Overlay traffic decoding in Hubble – VXLAN/Geneve encapsulated traffic is now decoded in Hubble flow logs.(more details) Enhanced policy dashboard – Grafana metrics now track latency across identity updates, policy calculation, kernel apply, and L3/L7 denies.(more details) Performance & Operations 1,000-node scale testing and optimization: Reduced policy latency by up to 40%, Cilium agent CPU usage by up to 43% under service churn, and 30% smaller arm64 image. (more details) High availability for API server communication: Configure multiple API server endpoints to improve resilience and failover handling.(more details) Updated kernel requirements: Cilium now requires Linux kernel 5.10+ (or RHEL 8.6).(more details) Networking Encrypted Overlay Cilium provides native encryption capabilities, ensuring data integrity and confidentiality for pod-to-pod traffic. Cilium’s encryption is compatible in both routing modes: native (where the nodes and the underlying network are aware of all pod networks and can forward the traffic accordingly) and encapsulation (where Cilium builds a mesh of overlay tunnels, hiding the pod network details from the underlying infrastructure). In previous Cilium versions, when IPsec encryption was enabled, the datapath encrypted traffic first, then applied VXLAN or Geneve encapsulation. While this approach secured the packet payload, the tunnel metadata - including security identities used for policy enforcement - remained visible on the wire. With Cilium 1.18, this behavior has been reversed. The datapath now performs tunnel encapsulation first, then encrypts the resulting overlay packet using ESP. This change means that security identities and other VXLAN/Geneve metadata are now protected by IPsec encryption. This updated design improved confidentiality for identity-based metadata in environments where tenant isolation or traffic inspection concerns exist. Be aware that, disruptionless upgrade from v1.17 to v1.18 can only be achieved from v1.17.3 onwards. Once patched to v1.17.3 and beyond, a normal upgrade to v1.18 can be performed. Make sure to consult the Cilium documentation and upgrade notes. Ingress Rate Limiting In shared Kubernetes environments, especially multi-tenant platforms or SaaS offerings, it's common for some workloads to consume more than their fair share of network bandwidth. A single misbehaving tenant or a noisy neighbor can saturate the network interface of a node, affecting performance for other pods on the same host. Cilium's bandwidth manager already supports egress rate limiting, allowing teams to restrict how much outbound traffic a pod can send. But until now, there was no equivalent support for ingress rate limiting, which means workloads could still be overwhelmed by bursty or excessive inbound traffic. With Cilium 1.18, platform engineers can now apply ingress bandwidth limits to pods using a simple Kubernetes annotation (e.g. kubernetes.io/ingress-bandwidth: 10M). This provides fine-grained control over how much traffic a pod can receive. It's particularly useful for: Tenant isolation: prevent one user's workload from overwhelming another Circuit breaking: apply pressure on misbehaving clients without dropping the service entirely Security: mitigate low-volume DoS attempts by capping bandwidth at the interface level When running network performance tests prior to enabling this feature, we saw ingress traffic exceeding 1Gbps. After annotating the pod with kubernetes.io/ingress-bandwidth: “20M”, we observed that traffic was rate-limited, as expected. To see a live demo, check out the following video: Load Balancing Redesign The v1.18 release of Cilium includes a complete redesign of the load balancing control plane that handles how requests for Kubernetes services are forwarded to backend pods. This is now enabled by default (this is available in v1.17 but requires opt-in). As a user, you might not notice any differences, other than a reduced memory footprint, but for Cilium contributors it makes the code simpler and easier to maintain and enhance going forward. To understand more, please refer to this README in the cilium repository. Multi Egress Gateway Nodes Many Kubernetes users rely on Egress Gateway to control how traffic exits the cluster. This capability is especially valuable in regulated environments or multi-tenant platforms, where preserving the source IP and routing through specific nodes is critical for compliance, auditing, or integration with external firewalls. Cilium provides Egress Gateway policies that allow platform teams to route traffic from specific pods or namespaces through designated nodes. This helps maintain predictable IP addressing and simplifies network policy enforcement outside the cluster. Cilium 1.18 introduces support for multiple gateway nodes in a single Egress Gateway Policy. In previous versions of Cilium, each policy could only assign traffic to a single egress node. In Cilium 1.18 onwards, you can now specify an egressGateways list, each with its own nodeSelector, to define a pool of eligible nodes for egress traffic: Cilium deterministically assigns each endpoint to one of the selected gateway nodes, based on the endpoint’s UID. The assignment is sticky, meaning that as long as the list of matching gateway nodes remains unchanged, the endpoint will continue using the same gateway. As with single-gateway setups, changing the selected node can disrupt existing flows. This limitation is being tracked in GitHub issue #39245. IPAM Back in the day, IP Address Management was conducted using a spreadsheet. Things have moved on since then, and now with advanced networking solutions including Cilium, they are a lot smarter and more automated than ever before. In 1.18, there are a number of minor additions to improve the experience of Cilium deployed to underlying cloud platforms, and also across datacenters: AWS Prefix Delegation for Bare Metal support: AWS ENI IPAM mode enables users to assign IP addresses from secondary IP addresses on EC2 Elastic Network Interface (ENIs). Cilium 1.12 introduced support for AWS ENI Prefix Delegation, enabling entire prefixes to be assigned to EC2 nodes, rather than individual IP addresses. While it overcame IP address exhaustion for many users, it hadn't been available on bare metal instances. Cilium 1.18 addresses this limitation: you can now use Prefix Delegation on bare-metal instances (except on Xen-based hypervisors). Multi-Pool IPAM enhancements: Introduced in Cilium 1.14, Multi-Pool is the most flexible Cilium IPAM mode. It supports allocating PodCIDRs from multiple different IPAM pools, depending on properties of the workload defined by the user, e.g., annotations. In Cilium 1.18, it’s further enhanced with the following improvements: Support for KVStore Mode: Cilium now ensures that pod CIDR updates in Multi-Pool IPAM mode are correctly propagated across nodes when using a kvstore backend. By syncing these updates through the kvstore, each agent is made aware of remote node CIDRs and can update its datapath to support overlay routing accordingly. Support with tunnel routing mode: Cilium now supports tunnel routing in Multi-Pool IPAM mode without relying on the tunnel map as a fallback, instead using pod CIDR entries in the IPCache to direct traffic. This approach maintains compatibility and the ability to upgrade safely. Support for IPSec transparent encryption with tunnel routing mode: Cilium now supports Multi-Pool IPAM with IPSec enabled in tunnel mode, thanks to VXLAN in IPSec integration. Encryption is applied at the native egress device after tunneling, so only remote node-level XFRM entries are needed, simplifying compatibility with dynamic pod CIDRs. IPv6 IPv6 Underlay for Encapsulation Routing Mode Platform teams operating large Kubernetes clusters often rely on Cilium in encapsulation mode (VXLAN or Geneve) to abstract away physical network complexity. These overlays simplify routing and provide a consistent datapath across diverse infrastructure. Until now, Cilium's encapsulation modes have assumed an IPv4 underlay. With Cilium 1.18, encapsulation routing mode now supports an IPv6 underlay. This means your physical network can operate entirely over IPv6, while Cilium continues to encapsulate pod-to-pod traffic using VXLAN or Geneve as needed. IPv6 Underlay Support for Kube Proxy Replacement We’ve talked in the past about kube-proxy’s limitations: iptables was not a technology designed for the scale and churn of microservices. We highly recommend you switch over to Cilium’s kube-proxy replacement (KPR). KPR offloads service translation to eBPF and performs much better than iptables-based kube-proxy, especially at scale. Traditionally, KPR has assumed an IPv4 underlay. In Cilium 1.18, KPR now supports service translation on IPv6 underlays. This enhancement lets you fully replace kube-proxy in IPv6-first environments while preserving Cilium’s performance benefits and simplifying your datapath. IPv6 Support for Egress Gateway Policies Another notable improvement to Egress Gateway Policies in Cilium 1.18 is support for matching IPv6 destination CIDRs. This extends source IP preservation and egress control to IPv6 workloads, allowing the same level of control and flexibility as IPv4. Egress Policies can now be configured like this: BGP BGP Route Aggregation In previous releases, each service IP was advertised as its own /32 to each BGP peer, which can result in large amounts of routes being sent back and forth between BGP peers. As shown in the first diagram below, each of the Service IPs are being pushed upstream to the router. With route aggregation enabled, individual routes are combined into a single advertisement that covers the entire CIDR. For example, advertising addresses from a /24 prefix reduces from a theoretical maximum of 254 routes down to a single route. To enable this feature the following fields are added to the CiliumBGPAdvertisement spec: These values for IPv4 and IPv6 determine the prefix length that a collection of routes should be aggregated to. For more information, watch the video (the feature was first available in Isovalent’s enterprise edition of Cilium but is now available in the open source edition): BGP Router ID Pool Cilium 1.18 adds support for configurable BGP Router ID assignment using a new ip-pool mode. This makes it easier to manage Router ID allocation across large or IPv6-only clusters, where manually assigning a unique ID per node can become a burden. By default, Cilium will continue to derive the Router ID from a node’s IPv4 address, or fall back to a value based on the MAC address of the cilium_host interface in IPv6-only setups. With the new ip-pool mode, you can define a dedicated pool of IPv4 addresses from which Cilium will automatically assign Router IDs. Below is an example helm configuration to create a BGP Router ID Pool: Service Mesh & Gateway API As has become customary with Cilium releases, this version includes a set of updates aimed at improving Gateway API and Service Mesh capabilities. Cilium can take advantage of the latest Gateway API improvements immediately by applying updated CRDs, and where needed, extends the core functionality to support more advanced use cases out of the box. At a glance, we have available the following updates; Gateway API v1.3.0 support: Cilium now supports the latest Gateway API v1.3.0, keeping compatibility in line with the evolving Kubernetes networking standard. This ensures access to new features and ongoing support from upstream Gateway API improvements. Improved GatewayClass configuration: Operators can now fine-tune gateway behavior using the new CiliumGatewayClassConfig, which enables validation of service types and configuration of fields like LoadBalancerSourceRangesPolicy. This brings more control and flexibility when managing multiple gateway classes across the cluster. Multiple HTTPRoutes per Service: You can now attach multiple HTTPRoute resources to the same Kubernetes Service using the GAMMA reconciler. This makes it easier to segment traffic handling for different teams, apps, or APIs without needing to duplicate services. Route reconciliation on all changes: Cilium now watches for all changes to Gateway API routes, including label updates, and triggers reconciliation accordingly. This ensures routing decisions stay accurate and up to date even with subtle changes to route definitions. Let’s dive into these updates in more detail. Gateway API v1.3 support Cilium now supports Gateway API v1.3, bringing in new features such as request mirroring by percentage, enhanced CORS configuration, and retry budget support. These capabilities are available as soon as the updated CRDs are applied, allowing Cilium users to build more flexible and testable HTTP traffic behaviors while continuing to rely on Cilium’s out-of-the-box integration with Gateway API and service mesh use cases. You can read more information about the Gateway API v1.3 release on the official Kubernetes website. Improved GatewayClass configuration Cilium 1.18 introduces native support for configuring GatewayClasses using the CiliumGatewayClassConfig resource. This allows operators to define additional settings per GatewayClass, such as validating the type of Service that backs a Gateway or applying custom LoadBalancerSourceRangesPolicy and ParametersRef fields. These options provide greater control over how traffic is exposed and secured, especially in environments that rely on managed load balancers or IP allowlisting. This capability was previously made available to enterprise customers in the 1.17 release as part of Isovalent Enterprise for Cilium, more details can be found in the original announcement. Here’s a minimal example of a CiliumGatewayClassConfig resource: This resource is then referenced for use in a GatewayClass object: With this in place, Cilium applies additional validation and behavior to any Gateway using the associated class, helping enforce consistent traffic exposure rules across environments. Multiple HTTPRoutes per Service Support for GAMMA - Gateway API for Service Mesh - was introduced in Cilium 1.16, providing the same level of controls offered by Gateway API (North/South) to service-to-service communications (East/West). Instead of attaching HTTPRoutes to a Gateway, GAMMA enables users to apply them to services. In prior versions, GAMMA only supported one HTTPRoute per Service, making it difficult to manage complex routing scenarios. In Cilium 1.18, Cilium’s GAMMA reconciler now supports attaching multiple HTTPRoute resources to a single Kubernetes Service. With this update, teams can define separate routes for different API paths, versions, or downstream consumers while using the same Service backend. This enables finer-grained HTTP traffic segmentation, simplifies routing configuration, and reduces duplication of Service objects. It’s particularly useful for multi-tenant or multi-team deployments where different groups need to independently own their own routes pointing to a shared Service backend. In the example below: The first HTTPRoute steers traffic requests for a suffix of /v1 to a v1 deployment and /v2 to v2 deployment A second HTTP Route is installed, again using the same service, but configured as a catch all to a default backend. Both route to the same service backend. Policy & Observability Opt-In Safety for Cluster Mesh Policies Cilium’s Cluster Mesh enables seamless pod-to-pod communication across multiple Kubernetes clusters. Until now, network policies would match workloads across all connected clusters unless explicitly scoped to the local one. This default behavior could lead to unintended access if identical labels existed in multiple clusters. Cilium 1.18 introduces an opt-in safety feature that changes this behavior. When enabled, policies will match only local endpoints by default, unless the target cluster is explicitly referenced using the io.cilium.k8s.policy.cluster label. This enforces clearer isolation boundaries between clusters and better aligns with user expectations in multi-cluster environments. To enable this safer behavior, set the following option: Or, via Helm: ⚠️ Note: Enabling this option is a breaking change for existing policies that rely on the default global behavior. Policies that do not explicitly reference a cluster will apply only to the local cluster once this is enabled. To migrate safely, refer to the guidance in the official Cilium documentation. With this feature enabled, policies that do not include a cluster label will apply only to endpoints in the local cluster. To explicitly allow traffic to a remote cluster, you must add the io.cilium.k8s.policy.cluster label to the match: To allow traffic to any connected cluster, you can match on the presence of the label instead: Even if the feature is not enabled, policies with an explicit io.cilium.k8s.policy.cluster label will still be respected. The opt-in feature only changes the behavior of policies without a cluster label, restricting them to local endpoints by default. Teams using Cluster Mesh should consider enabling this option in 1.18 to adopt safer cross-cluster defaults ahead of its promotion to the default behavior in Cilium 1.19. Doing so now gives you time to migrate gradually, rather than being forced to adapt when the behavior changes automatically. If more time is needed during the 1.19 upgrade, the feature can still be temporarily disabled. Hubble Flow Policy Log Field Sifting through all of the enriched data provided by Hubble flows can sometimes be daunting; not only do they contain network connection information, but also Kubernetes metadata about the workload source and destination for the flow. Combine this with the vastly powerful Cilium Network Policy engine, which has the ability to manage traffic across Layer 3, 4 and 7, and the Hubble flows are enriched further with fields such as ingress/egress_allowed/denied_by, linking the flow to which policy has affected the verdict assigned to the traffic flow. Sometimes this is enough to help you track down the necessary flows in your data when troubleshooting. Other times you need a simpler method. In 1.18, a new key/value pair, log:value was added to Cilium Network Policies, that places a plain text log field into Hubble flow verdict outputs. This provides a simpler way to search and filter through the data. Below you can see an example policy which makes use of this new configuration option: Which then results in a Hubble flow similar to the below example; Decoding encapsulated traffic for deeper introspection With Cilium 1.18, Hubble can now decode traffic from VXLAN and Geneve-based overlays, surfacing previously hidden overlay metadata directly within flow logs. This enhancement is powered by updates across the stack. Cilium now includes dedicated eBPF classifiers that recognize VXLAN and Geneve headers, allowing encapsulated traffic to be parsed at the source instead of treated as opaque payload. At the same time, the tracing logic has been extended to account for the full size of encapsulated packets, preventing truncated flow data. The result is significantly improved observability in environments that rely on overlay networking. Hubble flows now reveal not just that traffic passed through a tunnel, but also the inner source and destination addresses and the protocols in use. This level of visibility is essential for debugging, auditing, and enforcing network policies, particularly in multi-tenant or hybrid environments where encapsulation is widely used. In the example below, we have a new section, tunnel, which provides details about the protocol in use and the IP and Layer 4 information for the communication. Enhanced Policy Dashboard The Policy section of the Grafana dashboard has been reworked to provide more actionable insight into the performance of policy-related operations. The following panels and associated metrics have been added in Cilium 1.18: Policy Identity Update Latency Time taken to update identity mappings when endpoints or labels change. Policy Calculation Time Measures how long the policy engine takes to compute policy changes. Policy Apply Latency Tracks how long it takes to push changes into the kernel datapath. Policy Denies L3.L4 Counts deny decisions enforced at the IP and transport layer, helping identify blocked connections based on source, destination, and port. Policy Denies L7 Tracks application-layer deny actions, such as blocked HTTP methods or paths when using L7 policies. This breakdown helps you identify exactly where time is being spent when policies change. For example, you can now distinguish between delays in user label processing and bottlenecks applying rules in the datapath. This is especially valuable in large clusters or those with frequent policy updates, where understanding these phases can help optimize response time and capacity planning. Performance Cilium 1.18 delivers a broad set of performance improvements across multiple dimensions, helping users build faster and more resilient platforms at scale. The Cilium performance and scale team recently extended its testing to 1,000-node clusters (PR #40227). This reflects the growing demands of platform engineers operating increasingly large Kubernetes environments. These tests revealed significant gains compared with Cilium 1.17, such as a 40% reduction in policy implementation latency at the 99th percentile. Cilium agent CPU usage during high service churn is down 43% from 1.17 to 1.18 (service churn tests measure CPU and memory usage of the Cilium agent under dynamic conditions in a 1,000-node cluster with 2,500 identities, 2,500 services of varying sizes, 40,000 total backends, and continuous creation, churn, and deletion of backend endpoints) Additional improvements include: More efficient DNS proxy handling for large sets of IPs (PR #39340) Reduced overhead in global identity distribution via KVStoreMesh (PR #36471) Lower CPU usage for egress gateway policies that match large numbers of pods (PR #37714) A 30% reduction in container image size on arm64, making the platform leaner and faster to deploy in CI and edge environments (PR #40005) Together, these enhancements help Cilium run faster, scale further, and operate more predictably across a wide range of production scenarios. Operations Kubernetes API server improvements Replacing kube-proxy requires the Cilium agent to communicate with the Kubernetes API server so that it is made aware of changes within the cluster (such as new or updated services and endpoints). Prior to 1.18, the Cilium agent could only be configured to speak with a single instance of the API server. Unfortunately, in most production environments, multiple API servers are deployed to provide high availability. To provide the required High Availability in the event of an API server failure, a new flag (--k8s-api-server-urls) has been added that allows a user to specify a number of Kubernetes API servers. Cilium finds a working API server from this list for an initial conversation, and then changes over to using the internal Kubernetes API service address which has load balancing and high availability. In some scenarios, retrieving information from the Kubernetes API server can overload or be detrimental to the API server's availability (especially the LIST request). In order to ensure that Cilium doesn’t place the API server within that scenario we can now expose configurable parameters for exponential back-off when trying to retrieve data from the API server. Here are some example Helm values: Updated Kernel Requirements Cilium 1.17 had a kernel requirement of 5.4, which will be End of Life at the end of this year (2025). In preparation for this, most common Linux distributions have now adopted newer kernels, and Cilium will now require a minimum of 5.10 / RHEL 8.6 moving forward. Conclusions Since the previous release, many new end users have stepped forward to tell their stories of why and how they're using Cilium in production: ByteDance Canopus Networks Corner Banca DB Schenker eBay ECCO G-Research Social Network Company Preferred Networks The community gathered at CiliumCon and the Cilium Developer Summit in London. Getting started To get started with Cilium, use one of the resources below: Learn more about Cilium (Introduction, tutorials, AMAs, …) Get involved in the Cilium community Join Cilium Slack to interact with the Cilium community Previous releases Cilium 1.16 – High-Performance Networking With Netkit, Gateway API Gamma Support, BGPV2 and More! Cilium 1.15 – Gateway API 1.0 Support, Cluster Mesh Scale Increase, Security Optimizations and more! Cilium 1.14 – Effortless Mutual Authentication, Service Mesh, Networking Beyond Kubernetes, High-Scale Multi-Cluster, and Much More Cilium 1.13: Gateway API, mTLS datapath, Service Mesh, BIG TCP, SBOM… Cilium 1.12: Ingress, Multi-Cluster, Service Mesh, External Workloads, and much more Cilium 1.11: Service Mesh Beta, Topology Aware Routing, OpenTelemetry, … Cilium 1.10: WireGuard, BGP Support, Egress IP Gateway, New Cilium CLI, XDP Load Balancer, Alibaba Cloud Integration and more Cilium 1.9: Maglev, Deny Policies, VM Support, OpenShift, Hubble mTLS, Bandwidth Manager, eBPF Node-Local Redirect, Datapath Optimizations, and more