Kubernetes has come a long way since its debut in 2014. It’s gone from running a couple of containerized microservices to orchestrating fleets of production workloads spanning everything from AI agents to full scale VMs running in pods. As Kubernetes adoption grows, and its use cases stretch to cover more ground, managing its increasingly complex networking and security landscape demands operational maturity and a platform that supports it.
The Spring 2026 release of Calico provides that support in two key areas:
Unified operations across Kubernetes pods and VMs
KubeVirt Live Migration in Bridge Mode allows you to migrate VM workloads with IPs preserved, minimal packet loss, and fast route convergence. VMs can move between nodes for planned maintenance, load balancing and to support high availability without interrupting network connectivity.Egress Gateway Layer 2 Advertisements(Enterprise exclusive) lets pod traffic egress with IPs from the host’s own subnet so workloads get a stable identity the rest of your network already recognizes eliminating the need for BGP Peering to advertise Egress Gateway IPs.Policy recommendations for VMs and hosts(Enterprise exclusive) automates and scales policy authoring for Calico-managed workloads running outside of your Kubernetes clusters.OpenStack Live Migration Improvements lets you migrate VM workloads running in high availability OpenStack environments with minimal risk of service disruption during maintenance. Pre policies on the target node keeps downtime inside the single-digit-second SLOs regulated workloads require.
Production-grade operations at scale
Whisker Policy Verdict and UI Improvements reveal connectivity blockers in minutes by letting you see the actual tier, policy, and rule that denied a flow.Calico Load Balancer – Maintenance Mode(Enterprise exclusive) supports graceful node maintenance by excluding backends on nodes marked for maintenance from new Maglev assignments, allowing existing connections to drain naturally. Operators can monitor active connections via Prometheus metrics to determine when it is safe to proceed with node maintenance
What’s new in Calico Open Source v3.32 #
Two new noteworthy features headline this release: Kubevirt Live Migration and Whisker UI improvements.
KubeVirt Live Migration in Bridge Mode
Running VMs in Kubernetes comes with many challenges, among them the need to preserve a VMs IP during live migration so that network traffic can continue uninterrupted. One way to handle this is with Multus and a bridge CNI, statically configuring the VM’s IP and plumbing it directly into the underlay. That preserves the IP, but the VMs sit outside of Calico which means no microsegmentation, no observability and no shared tooling with pods running alongside these VMs. With Calico v3.32, Calico IPAM assigns persistent IPs to KubeVirt VMs. The IP survives live migration and pod restarts and can be advertised upstream over BGP. VMs share the same Kubernetes-native pod network as containers, with the same CNI, policies, observability, load balancing, QoS, and Layer 7 traffic management.
Key Benefits of KubeVirt Live Migration in Bridge Mode:
Migrate VMs With Live Connections: Ensure long-lived TCP sessions such as database queries stay connected across the migration so applications don’t have to reconnect.Keep VM Workloads Reachable During Maintenance: Live migrate VMs to new nodes without blocking user access to applications.Monitor VM Migrations in a Shared Dashboard: Track live-migration success rates, duration, and post-move network metrics in the same place you track pod activity.Run One Network, Not Two: Stop maintaining parallel networking layers with VMs sharing the CNI, policy framework, and observability stack with your pod workloads.
Scenario: Live Migration That Keeps VMs on the Pod Network
The Situation:
A financial services enterprise is consolidating its virtualization estate onto KubeVirt on Kubernetes. The VM count sits in the six figures across dozens of clusters. Live migration is part of routine operations: VMs move between nodes during patching, capacity rebalancing, and host failures. The current workaround is Multus and a bridge CNI plumbed into the underlay, which keeps the IP through the move but leaves the VMs outside Calico’s pod network. The platform team would like to implement microsegmentation and observability for VMs as they do for containerized applications.
The Calico Solution:
Calico IPAM assigns each KubeVirt VM a persistent IP that survives live migration and pod restarts, advertised to the upstream network over BGP. Every VM runs on the same Kubernetes-native pod network as the containers next to it, with the same network policies, observability, load balancing, QoS, and Layer 7 traffic management. When nodes go down for maintenance, VMs move and connections survive. The microsegmentation and observability story stays intact.
Whisker Policy Verdict and UI Improvements
Knowing a flow was blocked by policy is a good start to troubleshooting a connection problem. It does not, however, answer the more important question: what policy is responsible and why? Without knowing the reason a flow is denied, the problem cannot be fixed and tracing a flow’s journey across multiple policy tiers and rules can be unreliable and time consuming, potentially prolonging an outage.
The Whisker updates in v3.32 put the verdict, the matching policy, and the full tier chain right in the flow log view. See all the policies that were invoked by drilling down into a flow. Filter by policy kind, tier, namespace and policy name to find out which flows selected policies take action on.
Key Benefits of Whisker Verdict Improvements:
See the Policy Kind, Tier, and Rule Behind Every Verdict: Surface the full evaluation chain, not just the allow/deny decision.Filter by Verdict or Policy: Narrow the flow log view to just denies or filter by kind, tier, namespace and name, or any combination, to see which flows a set of policies affects.Close Policy-Denial Tickets in Minutes: Reduce the troubleshooting path from a lengthy and painstaking analysis of policy layers to a thirty-second click into the matching rule.Let Application Teams Self-Serve: Trace your team’s own policy denies without waiting on the platform team.
Scenario: The Five-Minute Incident That Used to Take an Hour
The Situation:
A developer on the web-app team opens a ticket: their new service can’t reach the payment service. An on-call platform engineer pulls up Whisker, sees the flow was denied, and starts the usual investigation, checking tiers, scanning policies and cross-referencing rules, while walking the developer through each step. Forty minutes later, they find the issue: the payment tier has a default-deny policy that doesn’t include web-app in its allowed-set.
The Calico Solution:
With the Whisker verdict view, the platform engineer opens the flow log, filters by denied flows for the web-app service, and clicks the first matching row. The verdict panel immediately shows the tier, policy, and rule that produced the deny with enough context to describe the fix. The incident is resolved in five minutes, and the ticket closes with a clear remediation path. The platform engineer then stages the fixed policy and then in Whisker filters by kind, tier and policy name to see if any other flows will be affected, averting potential problems.
ClusterNetworkPolicy: Cluster-Wide Policy Goes Standard
Calico has had GlobalNetworkPolicy for years, cluster-scoped policy that sits above namespace boundaries and gives platform teams a place to define org-wide guardrails, default-deny baselines, and cross-namespace controls. The Kubernetes SIG-Network ClusterNetworkPolicy spec is the upstream community’s version of the same idea, and Calico Open Source v3.32 implements it.
While this is more housekeeping than a headline feature, it has two important implications. First, for the Kubernetes community, Calico’s conformant implementation keeps the spec moving and helps cement cluster-wide policy as a first-class part of the standard. Second, for platform teams already running Calico, ClusterNetworkPolicy provides the same cluster-level control surface as GlobalNetworkPolicy, but utilizes the standard upstream API. This means that tooling built around the spec remains reusable and consistent, regardless of the underlying network implementation.
If you’ve been using GlobalNetworkPolicy in your policy pipelines, you don’t need to do anything; everything keeps working. If you’re starting fresh or building tooling that needs to work across multiple CNIs, ClusterNetworkPolicy is now an option to consider.
Key Benefits of ClusterNetworkPolicy:
Define Policy Cluster-Wide With the Standard API: Use the upstream SIG-Network ClusterNetworkPolicy spec at the cluster level, no vendor-specific CRD required.Adopt the Standard Without Re-Learning: ClusterNetworkPolicy mirrors GlobalNetworkPolicy in shape and behavior, so platform teams already running Calico’s cluster-scoped policy keep the same mental model and tooling.Stay Aligned With Where Kubernetes Is Heading: Calico’s early implementation moves the SIG-Network ClusterNetworkPolicy spec toward general adoption, cementing cluster-wide policy as a first-class Kubernetes concept.
OpenStack Live Migration Improvements
Calico’s route management work in v3.32 closes the gap that’s kept regulated workloads out of OpenStack live migration. By pre network policies on the target node ahead of a migration, traffic resumes the moment the VM lands instead of waiting for the network to catch up. This solution, which leverages the same route management code that powers KubeVirt Bridge-Mode live migration, addresses the pain of migration for specific industries that measure downtime in single-digit seconds.
Key Benefits of OpenStack Live Migration Improvements:
- Migrate Within Your Downtime SLO: Complete OpenStack live migrations within the single-digit-second SLOs that regulated workloads require.
- Live Migration During Active Hours: Run live migration without having to wait for off-hours maintenance windows.
Scenario: Migrating a Trading Workload During Market Hours
The Situation:
A regulated financial-data provider runs a trading workload on OpenStack with a single-digit-second downtime SLO for live migrations. Their current KVM live migration routinely stalls long enough to violate it. The platform team has been limited to performing host maintenance during narrow after-hours windows, and some migrations have simply been deferred indefinitely.
The Calico Solution:
After upgrading to Calico v3.32, the team measures live-migration downtime against their reference workload and finds it consistently within SLO. Host maintenance is now possible during trading hours. Deferred migrations can be scheduled and completed without requiring an after-hours rotation.
Also in this release: Istio Ambient Mode comes to Calico Open Source
Not new, but new here. Calico Enterprise v3.22.1 bundled Istio Ambient Mesh in the Tigera Operator bringing the production hardened and one hundred percent upstream Istio images with sidecarless mTLS to the Calico stack.
As of Calico Open Source v3.32, the same capability is available in the open-source edition. If your platform team is running Istio in sidecar mode, or has given up on service mesh because of its complexity and resource usage, Istio’s ambient mode is worth a second look. In ambient mode there are no sidecars to wrangle on every upgrade, no per-pod CPU and memory overhead, and a much smaller surface to patch when the next CVE lands.
For the full story including architecture, migration path, and a sidecar-tax deep dive, read the Winter 2026 launch blog post.
What’s new in Calico Enterprise and Calico Cloud #
KubeVirt Live Migration in Bridge Mode that is part of Calico Open Source v3.32 is also available in Calico Enterprise where it arrives as a tech preview in v3.23 EP2. For organizations evaluating KubeVirt as their landing spot for VMs, this is the release that makes Calico a supported production target.
Beyond KubeVirt, three Platform-exclusive capabilities help you achieve operational maturity at scale, keeping your policy estate clean, unifying management across cluster and non-cluster workloads, and running load-balancer maintenance without customer impact.
Last Evaluated Metrics, Now via API (Cloud and Enterprise)
As customers extend microsegmentation across Kubernetes, the policy set grows sometimes into the thousands for large enterprises. Workloads change, applications change, and the policies that were essential six months ago may not match traffic anymore. Unused policies don’t announce themselves, they lurk, no longer evaluating traffic, but still on the books, a security and compliance risk that violates the least-privileged posture you’ve spent years building towards.
The Winter 2026 release introduced the “Last Evaluated” metric to surface policies and rules that haven’t matched traffic within a configurable window. Spring 2026 adds API access. Platform teams can now query the metric programmatically and feed it into automated cleanup workflows, compliance reports, scheduled alerts, or command line utilities. The same data that supports a PCI DSS v4.1 audit conversation can now flow into a Prometheus alerting rule or a nightly cleanup-candidate report.
One thing worth being explicit about: the metric tells you whether a policy is evaluating traffic, not whether it should still exist. Customers still make the call about what’s genuinely unused, based on knowledge of the workloads. The API uncovers the candidates. The platform team makes the decision.
Key Benefits of Last Evaluated Metrics:
Automate Policy Hygiene: Pipe Last Evaluated data into Prometheus alerts, scheduled reports, or any other workflow you already run.Generate Compliance Evidence on Demand: Show auditors that every active rule is in use, the proof PCI DSS v4.1 and similar standards require.Troubleshoot From the CLI: Query last-evaluated state directly via terminal during an incident, no browser required.Decommission Unused Policies Without Guesswork: Confidently clean up unused policies, not only to maintain that least-privileged posture but to reduce etcd memory pressure and shorten policy-engine evaluation time.
Scenario: Pruning a Microsegmentation Estate at Scale
The Situation:
A large financial-services platform team has been running Calico for several years. Their policy set has grown to several thousand policies accumulated from successive microsegmentation projects, decommissioned services, and one-off tickets. PCI DSS v4.1 audit is approaching, and the auditor wants evidence that every active rule is actually serving a purpose. Manually reviewing several thousand rules isn’t feasible, and the team can’t safely delete what they don’t understand.
The Calico Solution:
The platform team uses the Last Evaluated Metrics API to pull a list of policies and rules that haven’t matched traffic in the last 90 days. They route the output to a CSV, distribute it to the owning teams, and ask each team to confirm or contest each candidate. Within two weeks the policy set is several hundred rules smaller and the auditor gets the evidence trail directly from the metric output, not from a manual investigation.
Egress Gateway Layer 2 Advertisements
With Egress Gateway Layer 2 Advertisements to Calico 3.23 EP2 eliminates the need for cluster-specific egress IP pools and for BGP peering with ToR switches. You can now assign addresses from the hosts subnet to egress gateways, SNAT egress traffic to the gateway’s host node IP and forward packets using ARP. This means less reliance on coordinating with the network team, more efficient use of routable IP addresses and simplified firewall rules for reduced operational overhead.
Key Benefits of Egress Gateway Layer 2 Advertisements:
Reduce the Need for Coordination with the Network Team: Allocate IPs to new egress gateways without extensive intervention by the networking team significantly increasing deployment velocity.Forward Packets Using ARP: Decrease operational overhead doing away with BGP session on top-of-rack switches.Avoid Depleting Routable IPs in Large Environments: Configure a shared set of allow-listed IPs rather than a per-tenant pool preserving scarce routable IPs.Maintain One Firewall Ruleset: Pod egress IPs come from the host’s own subnet, so the firewall team works with the same address space it already maintains for hosts and VMs making firewall configuration and ongoing maintenance much simpler.
Scenario: Cluster Scale-Up Without a Firewall Ticket
The Situation:
A financial services platform team exposes a set of cluster services to external partner systems through a corporate firewall. Pod egress traffic uses IPs from a cluster-managed pool that the network team registers in the firewall ruleset. Every time the platform team scales the cluster, the pool changes, the firewall ruleset needs updating, and a change-control ticket flows between the two teams. They meet monthly to reconcile drift.
The Calico Solution:
Egress Gateway Layer 2 Advertisements moves pod egress identity into the host’s own subnet. Pod traffic now exits the cluster using a uniquely identifiable IP address from the host’s routable subnet, which can be allowed by the network firewall. Cluster scale-ups stop triggering firewall changes. The reconciliation meeting comes off the calendar.
Policy Recommendations for VMs and Hosts
Calico’s policy recommendations engine has been a valuable tool in a platform engineers arsenal giving teams a head start authoring policies for Kubernetes pods. Until now, however, they could not take advantage of this productivity boost when it came to hosts running outside a cluster. A new VM or bare-metal workload meant manually combing through flow logs and hand-authoring policies which, at scale, often became a significant microsegmentation bottleneck. Policy Recommendations for VMs and Hosts extends the policy recommendation engine to non-cluster workloads. As of v3.23 EP2, Calico observes traffic to and from VMs and bare-metal hosts generating recommended starting policies just as it does for the workloads running in your cluster. The same review-and-apply process platform engineers use for pods now applies to every workload Calico manages.
Key Benefits of Policy Recommendations for VMs and Hosts:
Dispense with Hand-Rolling Policies for VMs and Hosts: Calico generates starting points for non-cluster workloads from observed traffic, the same way it does for pods.Scale Microsegmentation Across the Whole Estate: Bring least-privilege policies to hundreds or thousands of non-cluster workloads without writing each one by hand.Use One Authoring Workflow for Every Workload: Work with the same tooling and the same review pattern across pods, VMs, and bare-metal hosts.
Scenario: Microsegmenting a Thousand VMs Without a Thousand Authoring Tasks
The Situation:
A telco runs Kubernetes workloads for 5G edge services alongside thousands of VMs for legacy signaling systems. The platform team has automated policy recommendations for pods, but every new VM workload comes with a manual policy-authoring task. The team cannot keep pace with the VM side, so default policies on VMs trend toward permissive over time.
The Calico Solution:
With Policy Recommendations for VMs and Hosts, the team’s existing recommendation workflow now covers VMs and bare-metal workloads. Recommendations come in based on observed traffic. The team reviews and applies them at the same rate they already review and apply pod recommendations. Microsegmentation extends across the entire estate without doubling the authoring workload.
Calico Load Balancer – Maintenance Mode (Enterprise Exclusive)
Choosing a software load balancer was already the right call for platform teams who wanted declarative service exposure and consistent-hash session affinity, capabilities Calico Load Balancer has delivered since v3.23 EP1.
With v3.23 EP2, the call gets easier. The fast, predictable failover that a pair of hardware load balancers in HA handles cleanly is now native to Calico’s software LB and ready to take over from that expensive 2018 LB you thought you had to replace. Calico Load Balancer now supports label-based node exclusion. Setting maglev.tigera.io/exclude=true
on a node tells Calico Load Balancer to stop forwarding new connections to the backends the node hosts while keeping existing sessions flowing until they complete naturally. Prometheus metrics expose per-node active session counts so operators can watch them decline to zero before proceeding with the drain.
Key Benefits of Graceful Maglev Session Handling:
Patch Nodes During Business Hours: Take nodes out of load-balancer rotation for kernel patches, kubelet upgrades, or hardware work without scheduling around customer traffic.Drain a Node With a Single Label: Setmaglev.tigera.io/exclude=true
on a node and Calico Load Balancer stops forwarding new connections to its backends, with no custom scripts or out-of-band coordination.Drain Without Forcing Disconnects: Active sessions on the excluded node keep flowing until they complete naturally so maintenance doesn’t cut off in-flight work.Know When It’s Safe to Drain: Prometheus metrics expose per-node session counts so operators can watch them decline to zero before proceeding with maintenance.
Scenario: Maintenance That Customers Never Notice
The Situation:
Scheduled maintenance on a node serving live customer traffic has always been a balancing act. Take the node out of rotation too early and customers with in-flight transactions get cut off mid-session. Wait too long and the maintenance window slips. Most teams have either accepted some level of session disruption or built bespoke tooling to coordinate their load balancer’s health checks with the drain workflow.
The Calico Solution:
The platform engineer labels the node with maglev.tigera.io/exclude=true
. From that moment, Calico routes new connections to backends elsewhere in the cluster. Existing sessions on the excluded node keep flowing until they complete, so customers with in-flight transactions finish them naturally. The engineer watches per-node session counts in Prometheus, and when the count reaches zero, drains the node. The maintenance happens. The customers don’t notice.
Get Started with Calico Spring 2026 #
The Spring 2026 release closes some critical Day 2 operations gaps unifying operations across Kubernetes pods and VMs, collapsing two operational worlds into one network, one policy model and one observability stack. It removes long-standing operational friction and clears the way for scaling infrastructure securely and efficiently helping teams take that next step towards Kubernetes operational maturity.
Environment | Action Required | Documentation Link | | Calico Open Source | Upgrade to Calico v3.32 | |
Upgrade Calico Enterprise documentationUpgrade Calico Cloud instructionsTo learn more about these new product capabilities and see them in action, schedule a demo.