Running Kubernetes at scale works best when everyday operations are calm and predictable. Isovalent Networking for Kubernetes 1.18 focuses on that goal by simplifying routing layouts, strengthening policy workflows, improving L7 traffic continuity, and giving operators clearer insight into cluster behaviour. This release prioritises stability and clarity so teams can keep clusters steady as they grow. The new BGP Route Reflector leads the release by giving larger environments a clear way to organise routing without managing a dense set of peerings. Alongside this, Envoy High Availability improves L7 availability during restarts, Isopolicy makes Cilium network policy design easier to validate, and Timescape adds an improved UI with new views for connectivity mapping and system state overview which makes cluster activity easier to understand. Together these additions make day two operations smoother and easier to support across environments. Highlights at a glance Connectivity BGP route reflector and maintenance mode for smoother operations at scale. Envoy hot restart support for graceful restarts, enabling L7 traffic to continue flowing during Envoy upgrades. Improved handing of complex DNS responses. Cilium DNS HA Proxy now supports an offline mode during restarts for steadier name resolution. Egress Gateway native health checking for faster and more reliable detection of degraded nodes at scale. Network Policy New Isopolicy CLI tooling for managing and operating network policies. Support for wildcard SNI pattern matching in CiliumNetworkPolicy, allowing for expanded rule configuration for TLS based egress. Hubble Timescape New Hubble Timescape UI enhancements including a Connections view, an improved network policy editor with flow based creation, network security assessment and a system status page for clearer visibility into cluster health and service interaction. Integrated RBAC within Hubble Timescape that removes the need for a sidecar and provides a simpler model for authentication and authorisation. Hubble Timescape can now display a richer set of Kubernetes events, enabling better correlation between changes in cluster configuration and traffic flow patterns. Timescape Stream API for low latency ingestion, reducing complexity and improving performance compared to object storage workflows. Mutual TLS support for Timescape ingestion giving clusters authenticated and encrypted ingestion paths aligned with enterprise security expectations. Platform readiness Feature hardening across key networking and policy components, now reaching maturity levels suited for production use. Support for Isovalent Networking for Kubernetes with Red Hat OpenShift Hosted Control Plane. Connectivity The standout networking addition in this release is native BGP Route Reflector support which gives platform teams a way to organise routing at scale without managing a large mesh of peerings. This is a meaningful change for clusters that rely on BGP to connect with data centre networks or cloud routing layers. Alongside this, the 1.18 release also brings improvements that keep traffic steady during upgrades, restarts, and operational changes, especially in environments using advanced routing or L7 policy features. BGP route reflector The addition of BGP Route Reflector support in 1.18 introduces a new way to organise cluster routing without requiring every node to peer with every other node. Instead of maintaining a full mesh, selected nodes take on the route-reflector role and redistribute routes on behalf of others. This brings a structured, scalable model that aligns with how routing is managed in mature data centre and cloud networks. A route reflector reduces the number of BGP sessions each node must maintain and creates a clearer separation between routing distribution and data plane workloads. It fits naturally into clusters that connect to external routers, where administrators prefer a small set of well defined peers rather than many individual connections. Below is a minimal example showing how to configure nodes with the route-reflector role. You can deploy multiple route reflector instances within the same cluster, which is recommended for high availability in production environments: Client nodes then connect to the reflector by adopting the same ASN and cluster ID. The configuration is similar to that of route reflectors, except the role field is set to client and there are no external peers. The clusterID must match those of the route reflector: You can then advertise PodCIDRs or other prefixes using standard IsovalentBGPPeerConfig and IsovalentBGPAdvertisement resources: This approach reduces the operational overhead of maintaining many individual peerings and aligns Kubernetes networking with the routing models that network teams already use. It gives clusters a cleaner BGP footprint and supports environments where external route servers have connection limits or where administrators want a more organised control plane. For those who want to deepen their understanding of how Kubernetes networking functions and how Cilium implements key patterns, we recommend the free book Kubernetes Networking and Cilium. BGP maintenance mode This enhancement provides consistent behaviour during node draining and planned maintenance so routing changes follow a clear and reliable pattern. It builds on earlier support for graceful restart, which informs the peering BGP router to not remove routes during a restart, and complements the use of Bidirectional Forwarding Detection, which is used to detect link or neighbor loss faster, forcing traffic to take an alternate path and greatly reducing downtime. When a node enters maintenance mode we advertise the graceful shutdown community (RFC 8326) which informs routers to prefer other paths without dropping packets during convergence. This helps avoid connection resets during routine cluster operations. Simply adding a NoSchedule taint to the node puts it into BGP maintenance mode, for example using the kubectl node cordon command. Alternatively, you can specify IsovalentBGPNodeConfigOverride.spec.maintenance=true. The below short video shows this feature in action! Envoy hot restart In this release we provide support for Envoy hot restart to keep traffic flowing during upgrades. This mechanism shares state between the old and new Envoy processes so traffic continues while the transition takes place, and restarts triggered by Cilium upgrades or configuration changes no longer interrupt L7 traffic. This is especially helpful for clusters using Cilium Ingress or Gateway API, and for environments that rely on L7 policy enforcement through Envoy. Graceful restart keeps connections active while the new process assumes control which makes routine maintenance more predictable. This feature is opt-in through the following configuration: More predictable behaviour for DNS responses This improvement focuses on environments that use name-based egress policies with toFQDN rules. These policies rely on the DNS proxy within Cilium to observe query and response flows and map destination names to IP addresses. In earlier versions, the DNS parser only accepted answers that matched the structure of the original query. Many real DNS servers return additional records for load sharing, CNAME chains, or DNSSEC, which created situations where valid responses were rejected. This update makes name based egress rules behave more consistently in environments where DNS servers return extra records for balancing or internal resolution. A common example involved responses that contained a CNAME paired with DNSSEC RRSIG signatures. These responses were valid but did not match the strict expectations of the parser. The result was an error similar to the following: This could cause a gap between the policy that was written and the addresses the system learned from DNS. In practice this meant some DNS responses were not recognised correctly, so the expected entries were never added. When that happened, traffic could slip past the intended rules or applications could fail to reach services they were allowed to access. The updated behaviour accepts the full set of records returned by the DNS server and programs them into the internal address cache. This improves compatibility with real world DNS patterns such as CNAME chains, CDN style load distribution, and DNSSEC. Applications that rely on these patterns continue to resolve and connect normally, and name based policies remain enforced in a reliable way. Cilium DNS proxy offline mode Namebased egress rules depend on continuous DNS updates. During agent restarts this flow could pause which created gaps in enforcement. The DNS proxy offline mode keeps learning and recording DNS responses even while the agent is unavailable. This is important for environments that rely on name-based egress policies, since these policies use the DNS proxy to observe responses and map domain names to the correct IP addresses. With offline mode enabled, those mappings continue during the restart window which keeps name-based rules functioning as expected. Enabling offline mode requires updates to both the DNS proxy configuration and the main Cilium agent. The DNS proxy must be allowed to operate independently, and the agent must wait for the proxy to replay any queued updates when it becomes available again. To enable offline mode across both components, apply the following Helm values to the Cilium DNS Proxy and Cilium CNI configurations: With this feature enabled when using the DNS proxy, this will result in more predictable behaviour for applications that rely on name based egress rules, without requiring platform operators to adjust their maintenance processes. Egress gateway native health checking The Egress Gateway acts as the controlled exit point for outbound traffic and is commonly used to keep traffic identities stable, enforce name based policies, support fixed source addresses for external services, and meet audit or compliance requirements around outbound flows. Health checking is essential for quick failover but from our scalability testing, the traditional method does not scale well beyond one hundred Egress Gateway nodes. The new native health checks run from the Cilium operator which removes the load previously placed on individual nodes and allows larger clusters to verify gateway health without additional strain. This provides faster and more reliable detection of degraded nodes and helps keep outbound paths available. It also supports environments that rely on the Egress Gateway for regulated egress patterns, partner integrations that expect known source addresses, or architectures that route outbound traffic through inspection or security layers. This can be enabled with the below Helm values configuration: Network policy Smarter policy design and testing with Isopolicy Network policy design can be demanding, even for experienced teams. It involves balancing application needs with security controls, and small mistakes can lead to unexpected outcomes. This is why we’ve invested heavily in education, including our two free books; Kubernetes Network Policies Done the Right Way and the Cilium Network Policy Deep Dive, and why we continue to improve the tooling around policy creation. Earlier releases added validation status fields to help confirm that policies were interpreted correctly, but many operators asked for a way to check intent before anything reached the cluster. With 1.18, we introduce Isopolicy, a new CLI that adds linting, tuning, and simulation for Cilium network policies. This new tooling gives teams a practical way to check policies before rollout, either locally or against a live cluster. The simulation engine mirrors real behaviour and helps uncover issues such as missing labels, unintended overlaps, or rules that create silent drops. We've previously covered an early deep dive on this tooling: loading a policy file, running a simulation, and seeing exactly which flows are allowed or denied, and then the effects on the traffic when a new proposed network policy is validated. Isopolicy is designed to help make it clear where adjustments are needed, and this creates safer conditions for operators who want to strengthen policy without breaking applications. Isopolicy has a natural place in daily workflows. As a standalone tool, operators use it to explore policy intent, test changes with live data, or review the impact of edits suggested by application teams. In a gitops pipeline, Isopolicy runs during pull requests to lint incoming policy definitions and block merges that introduce obvious mistakes or unsupported constructs. This keeps policy repositories tidy and prevents common misconfigurations from reaching the cluster. The result is a more predictable and less stressful policy lifecycle. Teams can grow their segmentation and application-level rules at a measured pace, knowing they have reliable feedback early in the process. As environments scale and the number of policies rises, this kind of tooling becomes essential for keeping security posture aligned with operational needs. Domain name wildcard pattern matching in egress policy rules Server Name Indication pattern matching in Cilium Network Policies adds support for simple wildcard patterns in TLS destination rules. Server Name Indication is the value presented in the TLS handshake that identifies the hostname a client wants to reach. Many modern services host several domains behind the same IP address, so SNI becomes the only reliable signal for selecting the correct destination. This feature is useful when applications connect to large families of external services that share a naming structure. Earlier versions required exact SNI values which made it difficult to describe access to these related destinations. With this release you can use prefix patterns such as *.veducate.co.uk to express intent for entire service groups without listing every individual host. Below we have crafted a detailed example of how you can implement this feature in your Cilium Network Policies. This is especially useful for organisations that depend on large sets of external services delivered over TLS. Policies become easier to maintain, allowing operators to align rules with how applications consume these services while still enforcing strong connection controls. Hubble Timescape Hubble Timescape receives a significant set of improvements in this release, covering UI updates, clearer cluster health views, and a richer event ingestion combined with faster ingestion path through the new Stream API. These changes make it easier for operators to understand service behaviour, track policy effects, and maintain visibility through upgrades and scaling. Hubble Timescape continues to evolve as the central observability layer in Isovalent Enterprise Platform. The platform now offers flexible deployment options that cover different scale and retention configurations matched to operational models to suit the platform team's available team resources. The deployment model, Integrated Timescape can be enabled directly through the Cilium Helm chart and provides an opinionated setup within Isovalent Networking for Kubernetes, while staying compatible with the Hubble API and CLI. Timescape, also remains available to be deployed via its own helm chart, offering full customization to suit a platform team's requirements. You can learn more about Hubble Timescape’s architecture in our previous blog post “Hubble for the Enterprise”. Timescape UI enhancements Connection Logs for scalable and aggregated visibility This release introduces connection logs which complement Hubble flow events with a more scalable representation of network activity. Connection logs, provided by Isovalent Runtime Security, are aggregated, database friendly, and designed for large clusters where high volumes of flow events are difficult to store or process. They support advanced filtering by leveraging the Common Expression Language (CEL) and underpin the new graph based visualisations within Timescape UI. They work alongside traditional Hubble flows, giving teams a way to control storage use and still access the level of detail they need for troubleshooting. These new visualisations are available within the Connections tab in the Timescape UI. This page presents a live, aggregated map of how entities communicate across the cluster. It builds a connection graph that can be filtered by Common Expression Language (CEL) queries which allows operators to focus on exactly the traffic they want to inspect. Each box in the graph represents a workload or service and each line shows an active communication path. Hovering over a link reveals traffic volume and drop counts and the table beneath the graph lists the same relationships in a structured form for sorting or exporting. The page groups individual observed connections into logical service relationships so teams see clear communication patterns rather than isolated events. It is a practical tool for understanding how applications interact, validating policy intent, and identifying unexpected behaviour at both service and infrastructure levels. Network policy editor Timescape UI now includes a full set of policy editing capabilities so that teams can create secure Cilium network policies directly from what they observe in the interface. Using Timescape UI for network policy management, you can now perform the following actions: View and track network policy create, update and delete per namespace Create new network policies from existing Hubble network flows Compare and differentiate policy changes across time periods Edit existing network policies using the in-built editor, ready to be applied to your cluster manually or via a gitops workflow You can see these features in action in the following recording. Network security assessment Timescape now includes a Network Security Assessment that helps teams measure and improve the security posture of their Kubernetes environments. The feature evaluates clusters against an enterprise benchmark and produces a clear, prioritised view of policy exposure and misconfigurations. The assessment aggregates findings across cluster, namespace, and workload layers. It highlights issues such as missing default deny rules, overly permissive ingress or egress paths, and workloads that are not adhering to expected zero trust patterns. Each assessment run generates a score, a severity breakdown, and a detailed list of affected workloads with remediation guidance. Operators can drill into an individual finding to see when it started, how it has evolved over time, and which workloads or namespaces contribute to the issue. This turns what is normally guesswork into a structured workflow for improving policy hygiene and reducing lateral movement risks. The tool is particularly useful for platform and security teams who need a continuous signal rather than an occasional audit. It provides: A benchmark-based score to track progress over time Issue views by rule, namespace, and severity Clear reasoning for each failure, tied to real network behaviour A visual breakdown of ingress and egress exposure across the environment By surfacing policy gaps and exposure patterns proactively, Network Security Assessment helps teams enforce consistent standards and drive meaningful zero trust improvements without combing through thousands of flows or policies manually. System status health The System Status page brings together cluster health signals into a single view so operators can spot emerging issues quickly. It tracks conditions from Cilium agents and presents them as clear alerts with severity levels, affected nodes, and a timeline that shows how the issue has developed. This makes it easier to understand whether a problem is isolated or spreading across the cluster. Each alert includes a descriptive explanation of what triggered it and a recommended next step. Selecting an alert expands it into a detailed panel that shows the progression over time and the nodes involved. This helps teams diagnose the root of the issue and act before it affects application behaviour. You can see this new page in action in the below images. Role based access control (RBAC) without sidecars Timescape now includes integrated Role Based Access Control which removes the need for an RBAC sidecar and provides a simpler path for authentication and authorisation. This change reduces overhead and simplifies maintenance. Richer cluster events and deeper historical context Timescape 1.18 expands the set of Kubernetes and Cilium events that can be collected and displayed in the UI. The release adds support for CiliumNode events, `Tetragon policy` updates, Tetragon node activity, and connection log events. Teams gain a clearer view of how workloads, policies, and infrastructure evolve over time. Timescape also introduces aggregation features that keep infrequently updated resources visible in long running clusters. Events can be combined using a time to live value before eventual expiry which avoids unnecessary event noise while still preserving meaningful state transitions. These changes strengthen Timescape as a reliable record of cluster activity rather than a stream of isolated signals. The improvements in 1.18 apply across two paths for ingesting Kubernetes related activity. Each serves a different purpose and fits different cluster patterns. Hubble Kubernetes Exporter: Suitable for multi cluster environments where events from several clusters need to be forwarded to a central Timescape deployment. Hubble Timescape Kubernetes Importer: Suitable for clusters that run Timescape locally, especially Timescape Lite or Integrated deployments where ingestion is handled directly by the Timescape Ingester. Hubble kubernetes exporter The Hubble Kubernetes Exporter, which is deployed as a standalone Helm chart that watches Kubernetes resources and exports events to external systems. In 1.18, the exporter gains support for the same expanded set of events as Timescape which includes CiliumNode updates, Tetragon policy changes, and TetragonNodes activity. It also introduces options to disable export of CiliumNetworkPolicy, CiliumClusterwideNetworkPolicy, and Kubernetes NetworkPolicy events for environments that want more control over the volume of exported data. To ingest events from the Kubernetes API, the exporter writes these events to a file interface. They must then be forwarded either directly to the Timescape Ingester through its REST API or written into object storage for the ingester to pick up. This deployment model suits multi cluster setups where each cluster exports its own events and sends them to a single Timescape deployment. Hubble timescape kubernetes importer The Hubble Timescape Kubernetes Importer is an alternative to the standalone exporter. Instead of running as a separate deployment, the importer runs as part of the Hubble Timescape Ingester. This can be seen in the default installation of Timescape Lite, where the importer is deployed automatically. Unlike the exporter, the importer does not rely on writing events to files or object storage. It pulls events directly to the Timescape Ingester which removes several moving parts and simplifies ingestion. As with the exporter, the importer supports the expanded set of event types introduced in 1.18 including CiliumNode updates, Tetragon policy changes, and TetragonNodes activity. The component can be enabled within the Timescape helm chart values as follows: Timescape stream API Before this release, Timescape supported two ways to ingest flows and events. Clusters either wrote data to object storage for the Timescape Ingester to pull, or pushed data into the Timescape Push API over HTTP. Both options work well but introduce extra components, namely needing a component to export the log files and some delay between events happening in the cluster and appearing in the UI. Timescape 1.18 adds a gRPC Stream API to the Ingester component. When used with Isovalent Networking for Kubernetes 1.17.9 and later, which includes a gRPC client that can send flows and events directly to this new Timescape ingester endpoint. This shortens the path from node to database and reduces the amount of CPU and memory needed in the forwarding layer. In practice, the ingestion delay typically found with exporting to object storage first, can be reduced. The Stream API is the default for Integrated Timescape and is available in Timescape Lite for environments that want a simpler ingestion pipeline. Stream API versus Push API With the Stream API, the Cilium agent talks directly to Timescape over gRPC. There is no need for object storage or an intermediate REST server, which simplifies configuration and reduces moving parts, such as conversion of the JSON structure to a suitable format, which is a resource costly exercise. This pattern is well suited to Integrated Timescape and to Lite deployments where you want fast, low effort access to observability data. The Push API continues to be supported and is useful when you need more control over buffering, when you want to rely on object storage for durability, or when your existing observability stack is already built around log forwarders. Mutual TLS support for ingestion Many enterprise environments expect encrypted and authenticated channels for any observability data that leaves the node. Timescape 1.18 adds mutual TLS support across both the Push API and the Stream API so that flows and events are transported over authenticated TLS connections. When authMethod is set to mtls, both the Push API and Stream API enforce client certificate authentication. Provide the client CA that signs the certificates used by your exporters in a ConfigMap: The Push API also supports Basic Authentication based upon a configured Kubernetes secret. Platform readiness Hardening and maturity changes This release strengthens reliability and makes it easier for teams to standardise on a consistent networking posture across clusters. Key capabilities in this release have moved to a maturity status to stable, for overall easing of operational adoption. A Stable feature is one that is defined as “appropriate for production use in a variety of supported configurations due to significant hardening from testing and use.” L7 HTTP Policies moves to Stable, providing consistent enforcement for application traffic and allowing teams to apply fine-grained rules with confidence. Default Deny moves to Stable, giving new namespaces a safer starting point and reducing the chance of accidental exposure. Load Balancer IPAM moves to Stable, simplifying address management and improving clarity for service teams working across shared environments. Together, these changes create a more dependable foundation for platform and security teams looking to enforce consistent policy, reduce configuration drift and strengthen cluster posture. Certified for OpenShift Hosted Control Planes Isovalent Networking for Kubernetes is now certified for Red Hat OpenShift Hosted Control Planes. Hosted Control Planes (HCP) introduce stricter separation between control and worker components which places greater importance on predictable networking and upgrade behaviour. This certification confirms that Isovalent Networking for Kubernetes integrates smoothly with the HCP lifecycle model and follows the operational expectations set by Red Hat. It gives platform teams a dependable choice for identity, policy, routing, and visibility in HCP based clusters. For platform teams running HCP, this certification provides a clear choice for networking. The Cilium data plane, L7 policy engine, and Timescape Integrated observability layer now come with tested support for the hosted model. This means upgrades behave predictably, control plane and worker traffic follow well understood paths, and the environment can take advantage of the full feature set of Isovalent Networking for Kubernetes. Choosing Isovalent as the default CNI for HCP gives clusters a dependable foundation with strong identity, policy, routing, and visibility features. It also aligns networking with the same enterprise support and stability expectations that customers already rely on in their OpenShift environments. Wrap-up Isovalent Networking for Kubernetes 1.18 focuses on making clusters safer and easier to operate. From structured BGP routing to steadier L7 upgrades, clearer policy workflows, and richer visibility through Timescape, the release strengthens day two operations and reduces uncertainty as environments grow. Isovalent Networking for Kubernetes is just part of the Isovalent Enterprise platform for modern, eBPF-based networking, security and observability. Read more about the overall platform in this post about the latest 25.11 platform release. If you require guidance on adopting the new features or simplifying your networking standards in your cloud native platforms, reach out to your Isovalent team and we will help you get started. Further reading: Safely managing Cilium network policies Learn how to design, test, and validate policies with practical techniques that support safer rollouts and clearer intent. State of Kubernetes Networking Report 2025 Read our insights on what cloud native networking in production looks like across real environments and the trends shaping platform design. We look forward to you joining us in our Isovalent Networking for Kubernetes 1.18 highlights webinar, register below.