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
CiliumGatewayClassConfigfor 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:
egressGateways:
- nodeSelector:
matchLabels:
egress-node: "true"
egressIP: "192.168.60.100"
- nodeSelector:
matchLabels:
egress-node-2: "true"
egressIP: "192.168.60.101"
- nodeSelector:
matchLabels:
egress-node-3: "true"
egressIP: "192.168.60.102"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:
apiVersion: cilium.io/v2
kind: CiliumEgressGatewayPolicy
metadata:
name: egress-sample
spec:
selectors:
- podSelector:
matchLabels:
org: tenant-a
# Specify which destination CIDR(s) this policy applies to.
# Multiple CIDRs can be specified.
# IPv4 and IPv6 prefixes can both be listed.
destinationCIDRs:
- "0.0.0.0/0"
- "::/0"
# Configure the gateway node.
egressGateway:
# Specify which node should act as gateway for this policy.
nodeSelector:
matchLabels:
node.kubernetes.io/name: node2
# The first IPv4 or IPv6 address assigned to this interface, will be chosen as the egress IP respectively
interface: "eth0"
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:
spec:
advertisements:
- advertisementType: "Service"
service:
aggregationLengthIPv4: 24 <<<<<<<<<<<<<< New Field
aggregationLengthIPv6: 120 <<<<<<<<<<<<<< New FieldThese 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:
bgpControlPlane:
routerIDAllocation:
mode: ip-pool
ipPool: {IPv4 CIDR Range}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:
apiVersion: cilium.io/v2alpha1
kind: CiliumGatewayClassConfig
metadata:
name: cilium-gateway-config
namespace: default
spec:
service:
type: LoadBalancer
loadBalancerSourceRanges:
- 10.10.10.10/32This resource is then referenced for use in a GatewayClass object:
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
name: cilium-with-config
spec:
controllerName: io.cilium/gateway-controller
parametersRef:
group: cilium.io
kind: CiliumGatewayClassConfig
name: cilium-gateway-config
namespace: defaultWith 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.
# First HTTPRoute: versioned paths
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: versioned-routes
spec:
parentRefs:
- kind: Service
name: echo
rules:
- matches:
- path:
type: Exact
value: /v1
backendRefs:
- name: echo-v1
port: 80
- matches:
- path:
type: Exact
value: /v2
backendRefs:
- name: echo-v2
port: 80
---
# Second HTTPRoute: catch-all prefix
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: default-route
spec:
parentRefs:
- kind: Service
name: echo
rules:
- matches:
- path:
type: Prefix
value: /
backendRefs:
- name: echo-v1
port: 80Policy & 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:
--policy-default-local-cluster=trueOr, via Helm:
clustermesh:
policyDefaultLocalCluster: true
⚠️ 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:
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: cross-cluster-policy
spec:
endpointSelector:
matchLabels:
app: frontend
egress:
- toEndpoints:
- matchLabels:
app: backend
io.cilium.k8s.policy.cluster: cluster-bTo allow traffic to any connected cluster, you can match on the presence of the label instead:
egress:
- toEndpoints:
- matchLabels:
app: backend
matchExpressions:
- key: io.cilium.k8s.policy.cluster
operator: ExistsEven 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:
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: policy-log-demo
spec:
endpointSelector: {}
egress:
- toCIDR:
- 0.0.0.0/0
log:
value: "demo"Which then results in a Hubble flow similar to the below example;
{
"flow": {
"verdict": "FORWARDED",
"traffic_direction": "EGRESS",
"policy_match_type": 1,
"egress_allowed_by": [
{
"name": "policy-log-demo",
"namespace": "foo",
"labels": [
"k8s:io.cilium.k8s.policy.derived-from=CiliumNetworkPolicy",
"k8s:io.cilium.k8s.policy.name=policy-log-demo",
"k8s:io.cilium.k8s.policy.namespace=foo",
"k8s:io.cilium.k8s.policy.uid=20d7f85c-c214-4c90-9d5f-44a851928829"
],
"revision": "2",
"kind": "CiliumNetworkPolicy"
}
],
"policy_log": [
"demo"
]
}
}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.
{
"flow": {
"time": "2025-07-03T09:22:01.538485834Z",
"uuid": "d8b2b28b-feef-4b89-a434-b269b4420c62",
"verdict": "FORWARDED",
"ethernet": {
"source": "f2:c5:d5:44:75:b9",
"destination": "ae:60:d4:48:ea:a5"
},
"IP": {
"source": "10.244.1.150",
"destination": "10.244.2.152",
"ipVersion": "IPv4"
},
"l4": {
"TCP": {
"source_port": 51142,
"destination_port": 80,
"flags": {
"ACK": true
}
}
},
"tunnel": {
"protocol": "VXLAN",
"IP": {
"source": "172.18.0.4",
"destination": "172.18.0.3",
"ipVersion": "IPv4"
},
"l4": {
"UDP": {
"source_port": 43140,
"destination_port": 8472
}
}
},
"source": {
"identity": 6,
"namespace": "default",
"labels": [
"reserved:remote-node"
],
"pod_name": "netshoot-client"
},
"destination": {
"ID": 99,
"identity": 2096,
"cluster_name": "kind-kind",
"namespace": "default",
"labels": [
"k8s:app=nginx",
"k8s:io.cilium.k8s.namespace.labels.kubernetes.io/metadata.name=default",
"k8s:io.cilium.k8s.policy.cluster=kind-kind",
"k8s:io.cilium.k8s.policy.serviceaccount=default",
"k8s:io.kubernetes.pod.namespace=default"
],
"pod_name": "nginx-deployment-979f5455f-fm9vg",
"workloads": [
{
"name": "nginx-deployment",
"kind": "Deployment"
}
]
},
"Type": "L3_L4",
"node_name": "kind-kind/kind-worker2",
"node_labels": [
"beta.kubernetes.io/arch=arm64",
"beta.kubernetes.io/os=linux",
"kubernetes.io/arch=arm64",
"kubernetes.io/hostname=kind-worker2",
"kubernetes.io/os=linux"
],
"event_type": {
"type": 4,
"sub_type": 10
},
"trace_observation_point": "FROM_NETWORK",
"interface": {
"index": 46,
"name": "eth0"
},
"Summary": "TCP Flags: ACK"
},
"node_name": "kind-kind/kind-worker2",
"time": "2025-07-03T09:22:01.538485834Z"
}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:
k8sClientExponentialBackoff:
enabled: true
backoffBaseSeconds: 1
backoffMaxDurationSeconds: 120Updated 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
Nico Vibert, Principal Technical Marketing Engineer
Nico Vibert is a Principal Technical Marketing Engineer at Isovalent, the company behind the open-source cloud-native solution Cilium. Prior to joining Isovalent, Nico worked in many different roles - operations and support, design and architecture, and technical pre-sales - at companies such as HashiCorp, VMware, and Cisco. In his current role, Nico focuses primarily on creating content to make networking a more approachable field and regularly speaks at events like KubeCon and Cisco Live. Nico has held over 15 networking certifications, including the Cisco Certified Internetwork Expert CCIE (# 22990). Nico is the co-author of the "Cilium: Up and Running" O'Reilly book and is the Lead Subject Matter Expert on the Cilium Certified Associate (CCA) certification.
Dean Lewis, Senior Technical Marketing Engineer
Dean Lewis is a Senior Technical Marketing Engineer at Isovalent - the company behind the open-source cloud native solution Cilium. Dean had a varied background working in the technology fields, from support to operations to architectural design and delivery at IT Solutions Providers based in the UK, before moving to VMware and focusing on cloud management and cloud native, which remains as his primary focus. You can find Dean in the past and present speaking at various Technology User Groups and Industry Conferences, as well as his personal blog.
Dan Finneran, Principal Community Advocate
Dan Finneran is a Principle Community Advocate at Isovalent. His journey to today has included bare-metal, jails, zones, vms and containers where he is currently enjoying the fast paced ride in the cloud native space. He also created & maintains a popular Open-Source load-balancer for Kubernetes and contributes to upstream Kubernetes. He's also been fortunate to present at events ranging from the British computing society, HPE Technical solutions summit to DockerCon and KubeCon amongst others.