Today, enterprise infrastructure rarely fits into one clean boundary. Platform teams run Kubernetes clusters across clouds and data centres, migrate virtual machines onto new platforms, expose applications through shared load balancing services, and work with security teams that need rich signals without slowing production systems down.
Isovalent Enterprise Platform 26.05 is aimed at the work platform teams are doing now: standardising Kubernetes networking, moving virtual machines without breaking their network assumptions, centralising load balancing for tenant clusters, and connecting runtime signals to observability. The release introduces Isovalent Networking for Virtualization as a generally available product, adds ExternalLB to Isovalent Load Balancer, and continues the move to Hubble Timescape for investigation and policy work.
If You Only Read One Section
The challenge for most platform teams is no longer whether Kubernetes, virtual machines, load balancers, and runtime security tools can each work well on their own. The challenge is operating them together without creating a new set of handoffs, blind spots, and upgrade paths for every team involved.
The Isovalent Enterprise Platform is built for that operating model. It gives teams one set of controls for connectivity, security, load balancing, and observability across the places where applications actually run: Kubernetes clusters, virtual machines, cloud environments, data centres, and the network paths between them.
Release 26.05 moves that platform forward in five practical ways:
- It brings virtual machines further into the platform model: Isovalent Networking for Virtualization launches as a generally available product, with Isovalent Private Network, DHCP support, and Isovalent Network Bridge for migration projects that need to preserve existing IPs.
- It makes shared load balancing easier to operate: ExternalLB lets one ILB cluster provide load balancing as a service for tenant Kubernetes clusters, without installing an ILB agent in every tenant cluster.
- It strengthens Kubernetes networking operations: Isovalent Networking for Kubernetes 1.19 adds policy-controlled BGP route import, more structured network policy evaluation, FQDN HA offline mode, and stricter encryption guidance for teams standardising on Cilium.
- It adds runtime context to platform operations: Isovalent Runtime Security 1.19 introduces process-aware
TetragonNetworkPolicy, stronger File Integrity Monitoring policy guidance, and shield status reporting to help teams apply more precise, explainable runtime controls. - It makes Timescape the investigation path: Hubble Timescape brings CEL filtering, policy editing, process ancestry, OpenShift operator support, and multicast observability into the 26.05 release.
For operators, the practical effect is simpler day-two work: less software to run in every cluster, fewer VM networking exceptions to preserve during migration, and better context when traffic or policy behaves unexpectedly.
Highlights At A Glance
- Isovalent Networking for Virtualization launches GA: INV extends Isovalent networking to virtual machines on KubeVirt and OpenShift Virtualization, with Isovalent Private Network, DHCP support, and Isovalent Network Bridge for IP-preserving migration.
- Isovalent Networking for Kubernetes 1.19: Policy-controlled BGP route import, more structured network policy evaluation, FQDN HA offline mode, and continued service datapath validation help teams standardise Cilium with more operational confidence.
- Isovalent Load Balancer 1.19: introduces ExternalLB. ExternalLB provides load balancing as a service from a shared ILB cluster to tenant Kubernetes clusters, without placing an ILB agent in every tenant cluster.
- Isovalent Runtime Security 1.19: adds workload context. Runtime signals help security and platform teams connect process activity, policy events, and observability.
- Hubble Timescape 1.19: becomes the investigation path for networking and policy. The release adds CEL filtering, policy editing, process ancestry, OpenShift operator support, and multicast observability.
A Platform Release For Mixed Infrastructure
The Isovalent Enterprise Platform is built on Cilium, Tetragon, Hubble, and eBPF. Those projects provide the shared foundation for high-performance networking, identity-aware policy, runtime visibility, and observability from the kernel through the application layer.
In 26.05, those controls reach more of the environments customers operate every day. Kubernetes remains central, but the release also speaks directly to virtual machines, shared load balancing services, runtime security signals, OpenShift deployment models, and long-running observability workflows.
Customers can still adopt individual products on their own schedule. A team can deploy Isovalent Networking for Kubernetes without ILB, or evaluate Isovalent Networking for Virtualization as part of a VM migration project. The platform release keeps those paths aligned, so upgrades, documentation, support conversations, and product planning follow the same 26.05 release identity.
Isovalent Networking For Virtualization 1.19
Isovalent Networking for Virtualization 1.19 is generally available in this release. INV brings the Isovalent networking model to virtual machines running on KubeVirt and OpenShift Virtualization, helping teams modernise infrastructure without forcing every application to change its network assumptions at once.
The key abstraction is Isovalent Private Network. IPN gives VM workloads a Kubernetes-native private network model with tenant segmentation, route control, and address-space isolation. This matters where teams need overlapping CIDRs, separated environments, or a way to map VM applications into a modern platform model without redesigning the application network first.
INV also adds DHCP support for virtual machine environments that depend on dynamic address assignment. That matters for teams moving VM estates where address management is part of the application contract, not a detail hidden below the platform. The deeper fabric-specific guidance, including Cisco ACI and Nexus 9K validation caveats, belongs in the dedicated INV launch post.
For migration projects, Isovalent Network Bridge helps preserve IP addresses as workloads move. That is important because many VM applications still bind configuration, dependencies, allow lists, or operational runbooks to existing addresses. Network Bridge gives teams a way to move in phases while maintaining reachability and reducing application disruption.
Zyzygy is an approved public proof point for the 500-VM migration use case. It shows the shape of the INV use case: move a meaningful estate, keep the network assumptions critical applications rely on, and avoid turning migration into an application rewrite. You can read more about the details in the workload migration report.
Introducing Isovalent Networking for Virtualization
Isovalent Networking for Virtualization: Enterprise-Grade Network Segmentation and Multi-Tenancy for VMs in Kubernetes
Isovalent Networking For Kubernetes 1.19
Isovalent Networking for Kubernetes 1.19 is for platform teams standardising on Cilium as a production dataplane. The release focuses on routing control, policy governance, DNS-aware resilience, encryption posture, and Timescape-based troubleshooting.
BGP route import gives teams a policy-controlled way to decide which external routes should enter the cluster routing view. That matters for organisations connecting Kubernetes clusters to established network fabrics, where route learning needs to be intentional, reviewable, and aligned with the wider routing design.
Network policy also gets more structure for shared-platform operations. Clearer policy layering and ordering help platform teams separate baseline guardrails from application-team policy while keeping evaluation predictable.
Kube-Proxy Replacement remains part of the product-ready service datapath story. The 1.19 work continues to validate the production combinations customers rely on, so service handling stays predictable across upgrades, operating modes, and observability workflows.
The netkit datapath continues its readiness work in 1.19. For platform teams evaluating higher-performance pod networking, the release keeps netkit on a measured adoption path while support coverage and operational checks continue to mature. In 1.20, netkit will become the default datapath mode, with failback for customer environments who are not ready to adopt. You can read a technical deep dive on netkit from our earlier blog post covering the topic.
FQDN HA offline mode is another enterprise-focused improvement. Name-based egress policy depends on DNS state remaining available through maintenance windows and restarts. Offline mode helps preserve the policy-relevant mappings that applications depend on, making policy enforcement steadier during routine operations.
The Isovalent Networking for Kubernetes 1.19 deep dive expands on BGP route import, network policy evaluation, FQDN HA offline mode, strict encryption mode, Timescape UI direction, encrypted-flow filtering, and the upgrade checks platform teams should review before rollout.
Isovalent Load Balancer 1.19
In public cloud environments, Kubernetes teams are used to a simple load balancing experience. They create a Service type LoadBalancer, and the cloud platform provisions the load balancer, assigns an address, and connects the service to the network with very little direct interaction from the application team.
Private datacentres and private cloud platforms need the same experience, but with more control. Platform teams often need to decide where VIPs come from, how addresses are advertised, how health checks are handled, and how load balancing is offered across many tenant Kubernetes clusters.
That is the role of ExternalLB in Isovalent Load Balancer 1.19. ExternalLB lets a shared ILB environment provide load balancing as a service for tenant Kubernetes clusters, without requiring an ILB agent inside every tenant cluster. Application teams keep the familiar Kubernetes workflow, while the platform team keeps control of the load balancing infrastructure.
This is especially useful for cluster-as-a-service platforms, private cloud environments, and organisations running tenant clusters across different CNIs or ownership boundaries. It gives platform teams a way to offer a cloud-like load balancing experience in environments where they still need full control over the network.
ILB 1.19 also adds Backend TLS Policy support and zone-aware load balancing with PreferSameZone for L7 traffic.
Isovalent Runtime Security 1.19
In 1.19, Isovalent Runtime Security (Tetragon enterprise) added support for TetragonNetworkPolicy, a process-aware policy model for host and Kubernetes environments. Unlike traditional network policies that primarily key off addresses, ports, or labels, this model can restrict traffic based on the binary that initiated it. For teams trying to reduce broad port-based allow rules, that creates a clearer path to policy based on workload behaviour.
File Integrity Monitoring also continues to mature. The file visibility and file enforcement documentation now includes stronger policy-writing guidance, and runtime checks on FILE_EXEC events can evaluate binary privilege-change properties such as setuid, setgid, or file capabilities. That gives security teams more precise tracing and enforcement options when they are tuning policy to reduce noise without losing important signals.
The tracing policy library also introduces the concept of a shield. A shield is a policy abstraction hiding the underlying tracing policy and or alert with a name. This allows an operator to deploy the shield by referring to it by name and setting the status as monitoring or enforcing. Agents can report on shield status, making it easier to reason about what is active in a ruleset during rollout and incident response.
When creating Tetragon Policies, selectors for host processes are improved as well. Teams can now apply one policy across host workloads and pod workloads through spec.hostSelector, which helps reduce split policy logic in mixed environments.
To see what this looks like in production, read our new Splunk case study, Splunk and Isovalent Runtime Security: Protecting the Platform Behind Splunk. Splunk uses Isovalent Runtime Security to protect the systems behind the customer-facing services it runs, including Splunk Cloud and Splunk Observability Cloud, deploying Tetragon across tens of thousands of virtual machines and Kubernetes clusters. That kernel-level telemetry flows directly into Splunk for detection, investigation, and response, and where it replaced older sidecar-based collection in Kubernetes it cut CPU utilisation by 66.5% and memory by 74%. It is a clear proof point for runtime security protecting the environments customers actually depend on, at production scale.
Hubble Timescape 1.19
In this release, Hubble Timescape is delivering a shortened path from observed traffic to an action: filter the flows, inspect the context, create or adjust policy, and keep the evidence available for review.
The redesigned UI centres on a CEL-based query bar. Operators can use dropdowns for common filters such as namespace, cluster, and verdict, then refine the generated CEL expression directly. Saved and suggested queries help teams repeat common investigations, while the map and flow table update as the query changes.
The policy editor builds on that same idea. Teams can move from observed traffic to policy creation, compare policy changes over time, and copy generated YAML in a form that is easier to review through GitOps workflows. Policy flow annotations such as log: <value> help explain why a flow appears in the UI and how it relates to enforcement decisions.
Process ancestry returns in the 1.19 UI, giving teams a way to connect network activity with the process tree behind it. This is useful when investigating whether a connection came from expected application behaviour or from a late-running shell, troubleshooting tool, or unexpected process inside a workload, powered by Isovalent Runtime Security.
OpenShift teams also get a simpler operational path. The Timescape OpenShift operator supports deployment and reconciliation through the same operator-driven model that OpenShift platform teams already expect.
Ready to learn more?
Isovalent Enterprise Platform 26.05 gives platform teams a concrete set of upgrade and migration tools: Kubernetes networking that is steadier to run, VM networking for staged migration projects, load balancing as a service for tenant clusters, runtime context for security investigations, and Timescape for inspecting traffic and policy behaviour.
If you are planning an upgrade, evaluating VM migration, or building a shared Kubernetes platform, the Isovalent team can help with architecture review, migration planning, and operational guidance.
Schedule a Demo With Our Engineers
Learn how our solution map to your challenges.
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.