DEV Community: Tigera Inc

Introducing AI Assistant for Calico, Calico Load Balancer, and Seamless VM-to-Kubernetes Migration

Alister Baroi — Mon, 23 Mar 2026 07:01:36 +0000

SAN JOSE, Calif., March 23, 2026 — Tigera, the creator and maintainer of Project Calico, today announced a major expansion of its Unified Network Security Platform for Kubernetes, aimed at helping enterprises consolidate infrastructure and accelerate the migration of legacy workloads to cloud-native platforms.

The new capabilities include:

Al Assistant for Calico: A proactive, conversational intelligence layer that replaces complex manual log analysis with natural-language troubleshooting and proactive security audits.
Calico Load Balancer: A high-performance, eBPF-based, software-defined load balancer that replaces expensive, rigid hardware appliances with a Kubernetes-native solution.
Seamless VM-to-Kubernetes Migration: Advanced Layer 2 (L2) networking support eliminates migration friction by allowing virtual machines to move into Kubernetes clusters without changing their original IP addresses or existing VLAN dependencies.

These innovations help organizations tackle the rising “complexity tax” in managing high-scale Kubernetes clusters and provide a high-velocity path to consolidate virtual machines and containers into a single, standardized platform.

“The industry is at a breaking point where the operational overhead of managing legacy hardware and fragmented VM silos is no longer sustainable. By building a distributed load balancer into the fabric of Calico, launching an Al assistant that ‘troubleshoots at the speed of thought,’ and introducing live migration support to move VMs to Kubernetes, we are giving platform teams the power to innovate rather than spend hours managing and troubleshooting.”

— Ratan Tipirneni, president and CEO, Tigera

Troubleshooting at the Speed of Thought: Introducing an Al Assistant for Calico

Despite the wealth of telemetry available in modern clusters, SREs often struggle to find the “connecting thread” across isolated events. Calico’s Al Assistant provides a context-aware intelligence layer to extract actionable insights from raw telemetry.

Ask, Don’t Query: Engineers can move away from rigid query languages and toward articulating intent in plain English. For example: “What are the unrestricted egress destinations currently receiving traffic from my pods?”
Context-Aware Explanations: The assistant provides summaries and recommendations generated from real telemetry and policy context, explaining exactly why traffic is being denied and offering remediation advice.
Proactive Security: Beyond troubleshooting, the Al assistant maintains cluster stability by detecting unused network policies, identifying misconfigurations, and surfacing exposure risks before they cause an outage.

Explore the full capabilities: How the AI Assistant for Calico simplifies troubleshooting at the speed of thought.

Eliminating Hardware Bottlenecks: The Calico Load Balancer

On-premises Kubernetes teams have traditionally relied on legacy hardware appliances to expose services, creating significant operational overhead and rigid dependencies between networking and platform teams. These external solutions often lack visibility into Kubernetes service context, do not scale horizontally, and require manual coordination for even basic software upgrades.

Tigera is disrupting this model with the Calico Load Balancer, a modern, software-defined solution built natively into the Calico platform. By transforming existing cluster nodes into a distributed, session-stable load-balancing tier, platform teams gain full control over service advertisement and configuration using the same Kubernetes workflows they already use.

This Kubernetes-native innovation delivers several critical advantages:

Session Persistence for Stateful Apps: A high-performance, eBPF-based data plane ensures that latency-sensitive, stateful applications like Kafka or RabbitMQ maintain active connections even during node failures or changes in network paths.
Graceful Node Restarts: Platform teams can mark nodes for maintenance and take them offline without impacting user sessions, preventing lost transactions for critical business services.
Reduced Latency: By enabling return traffic to take a shorter path back to the client, the solution reduces latency compared to traditional appliances where traffic must pass through the same central hardware twice.
Simplified Scaling: The load balancer scales horizontally with the cluster; adding more nodes automatically adds more load-balancing capacity without vertical scaling limits or vendor upgrade cycles.
Self-Service and Declarative Control: Configuration is handled through standard Kubernetes resources and GitOps workflows, removing cross-team bottlenecks and eliminating the need for tickets or separate management consoles.

Technical Deep Dive: Simplifying network traffic management with eBPF and the Calico Load Balancer.

The Great Migration: Seamlessly Moving VMs to Kubernetes

Historically, migrating virtual machines to Kubernetes meant a forced network redesign because VMs rely on static IP addresses and legacy Layer 2 VLAN configurations. Tigera’s new L2 networking support removes this friction.

Zero-Change Migration: VMs can be migrated from VMware to Kubernetes (KubeVirt) while keeping their original IP addresses, ensuring business continuity for applications with hardcoded dependencies.
Instant Security Upgrade: Once migrated, VMs are automatically protected by Calico’s microsegmentation, allowing organizations to retire costly third-party security tools.

Once migrated, the VMs in Kubernetes benefit from Calico’s advanced network security and observability capabilities. For users familiar with technologies like VMware NSX, Calico provides NSX-like functionality, including software-defined networking, microsegmentation, a workload-based firewall, and egress gateways for VMs running in Kubernetes.

Step-by-Step Guide: Lift and shift VMs to Kubernetes with Calico L2 bridge networks.

One Platform for Networking, Security, and Observability

The new Calico Unified Network Security Platform provides platform teams with a single, operator-managed solution. This allows teams to gain consistent network policy enforcement across L3-L7 layers with unified visibility, eliminating the overhead of managing multiple tools. Calico works consistently across any Kubernetes distribution, virtual machines, and bare-metal servers, ensuring enterprises can avoid vendor lock-in.

About Tigera

Tigera provides Calico, a unified network security and observability platform to prevent, detect, and mitigate security breaches in Kubernetes clusters. Tigera’s open-source offering, Calico Open Source, is the most widely adopted container networking and security solution. Powering more than 100M containers across 8M+ nodes, Calico is supported across all major cloud providers and Kubernetes distributions.

Media Contact

Media relations, Tigera

contact@tigera.io

Next Steps: Get Hands-on with These Innovations

Learn more about AI Assistant, Calico Load Balancer, and L2 networking support within the Calico ecosystem. Whether you are looking to optimize troubleshooting, reduce hardware dependency, or accelerate your VM migration, we provide the tools to get started today.

Experience the Platform: Start a free trial of Calico Cloud
Personalized Deep Dive: Request a technical demo with our engineering team

Attending KubeCon Amsterdam? Stop by the Tigera booth #400 to learn more about these features.

The post Introducing AI Assistant for Calico, Calico Load Balancer, and Seamless VM-to-Kubernetes Migration appeared first on Tigera - Creator of Calico.

Secure and Scale VMware VKS with Calico Kubernetes Networking

Alister Baroi — Sun, 22 Mar 2026 18:50:39 +0000

Co-authors

Abhishek Rao | Tigera

Ka Kit Wong, Charles Lee, & Christian Rauber | Broadcom

VMware vSphere Kubernetes Service (VKS) is the CNCF-certified Kubernetes runtime built directly into VMware Cloud Foundation (VCF), which delivers a single platform for both virtual machines and containers. VKS enables platform engineers to deploy, manage, and scale Kubernetes clusters while leveraging a comprehensive set of cloud services. And with VKS v3.6, that foundation just got significantly more powerful: VKS now natively supports Calico Enterprise — part of the Calico Unified Platform — as a validated, lifecycle-managed networking add-on through the new VKS Addon Framework.

Even better, VKS natively integrates Calico Open Source by Tigera as a supported, out-of-the-box Container Network Interface (CNI). This gives organizations a powerful open source baseline right from day one:

Pluggable Data Planes: The flexibility to run high-performance eBPF, standard Linux iptables, modern nftables, or Windows data planes based on specific workload needs.
Wire-Speed Routing: Direct BGP peering with the underlying VMware NSX infrastructure, eliminating the performance overhead of traditional overlay networks.
Foundational Zero-Trust: Global default-deny policies to instantly secure pod-to-pod traffic.
Observability: Includes Whisker, a visual UI tool that simplifies access to flow logs, making it easier to analyze network communication and debug policies.

VKS and Calico Open Source build the perfect house for your applications. However, as Kubernetes adoption explodes across the enterprise, platform engineering and security teams inevitably hit a new wall.

What happens when your security team mandates strict compliance audits across 50 different clusters? What happens when you need to route ephemeral Kubernetes traffic through your legacy physical firewalls? Or when a critical microservice drops traffic at 2 AM and you need to know exactly why?

To conquer the complex realities of production scale, organizations running VKS are supercharging their environments with the Calico Unified Platform (available via Calico Enterprise and Calico Cloud). Here is how Calico transforms your baseline VKS clusters into a fully observable, enterprise-grade networking and security platform.

The Calico Unified Platform Reference Architecture

As you scale your VKS environment, your architecture must evolve from providing basic pod connectivity to delivering a comprehensive security, routing, and observability mesh.

The reference architecture below illustrates how Calico Unified Platform wraps your VKS worker nodes in advanced Layer 7 protections, granular egress controls, and deep forensic logging capabilities—all while maintaining the high-performance eBPF and BGP foundation of your clusters.

Calico Unified Platform Architecture

Figure 1: Calico Unified Platform reference architecture for VKS – showing how Calico Enterprise wraps VKS worker nodes with Layer 7 security, egress controls, and deep observability while preserving the eBPF and BGP performance foundation.

1. Secure the Perimeter: Bridging Kubernetes with Legacy Firewalls

Traditional network security teams often struggle with Kubernetes because Pod IP addresses are ephemeral—they spin up and die in seconds. This makes it virtually impossible to write static firewall rules on your external Palo Alto or Fortinet appliances.

The Calico Unified Platform bridges this gap seamlessly for VKS environments:

Egress Gateway & Source NAT: Calico allows you to map dynamic Kubernetes namespaces to highly available, static IP Egress Gateways. When a pod talks to the outside world, your external firewall only sees the static IP. No more fighting with the NetSec team over IP tracking!
Native WAF and IDS/IPS: Secure your inbound traffic right at the Calico Ingress Gateway. Calico integrates a powerful Web Application Firewall (WAF) using the ModSecurity Core Rule Set. Coupled with native Intrusion Detection/Prevention (IDS/IPS) and DDoS protection, Calico detects and blocks malicious payloads before they impact performance.
DNS Policies & Threat Feeds: Do not just block IPs; block malicious domains. Calico dynamically ingests global threat intelligence feeds to automatically halt traffic to known bad actors.

2. Enforce Zero-Trust at Scale: Unified Policy Across Kubernetes, VMs, and Bare Metal

Open-source network policies are fantastic, but managing them across dozens of teams and clusters can quickly turn into the “Wild West” of YAML files. Calico brings true enterprise governance to your VKS environment—and extends it well beyond Kubernetes:

Network Policy Tiers & Staged Policies: A hierarchical, RBAC-driven approach to security. The Security team can create non-overrideable “Tier 1” guardrails, while Developers get full freedom to write microsegmentation rules for their specific namespaces. Even better, with Staged Policies, you can preview and test the impact of any rule on live traffic before fully enforcing it, ensuring zero downtime.
Unified Protection for Legacy VMs & Bare Metal: Your VKS clusters do not exist in a vacuum. Calico extends its policy engine beyond Kubernetes, allowing you to secure traditional VMware VMs and bare-metal servers using the exact same single-pane-of-glass dashboard—a headline differentiator of the Calico Unified Platform.
Sidecar-Less Service Mesh (Istio Ambient Mode): Get the deep L7 visibility and mTLS encryption of a service mesh without the crippling performance overhead. Calico seamlessly integrates with Istio Ambient Mesh, managed through a single Calico operator—no standalone Istio expertise required.

3. Total Visibility: One Management Plane for Every Traffic Flow

When a connection fails in a standard K8s cluster, troubleshooting usually involves blindly digging through kubectl logs. It is slow, frustrating, and drastically inflates your Mean Time to Resolution (MTTR).

Calico acts as the ultimate CCTV system for your VKS clusters—with a single console covering every traffic type, from ingress to egress to pod-to-pod:

Dynamic Service Graph & Alerts: Get a real-time visual map of all microservice traffic across your clusters. Instantly see performance metrics, blocked traffic, and active connections. You can even configure automated alerts and incident response to deploy mitigating policies the second an anomaly is detected.
Deep Forensic Logging: Calico goes far beyond basic flow logs. It provides granular DNS Logs, L7 Logs, and Ingress Logs, allowing you to pinpoint exactly which layer of the stack is failing.
On-Demand Packet Capture: Did a specific pod trigger an anomaly? Trigger a targeted packet capture (pcap) directly from the Calico UI for deep forensic analysis, without ever having to SSH into the vSphere worker nodes.

4. Scale Without Limits: Multi-Cluster Management and AI-Powered Operations

As your VMware footprint grows, managing clusters individually becomes impossible. Calico’s Multi-Cluster Management provides a single pane of glass to view, secure, and troubleshoot all your VKS clusters—and even your public cloud EKS/AKS clusters. You can seamlessly federate identities and extend resilient multi-cluster networking with Cluster Mesh.

And when things get truly complex? AI Assistant for Calico serves as your platform co-pilot. You can use natural language prompts to generate declarative Policy as Code, query flow logs, and diagnose active threats, drastically reducing the learning curve for new team members.

The Ultimate VKS Experience

VMware VKS gives you a world-class, CNCF-certified Kubernetes platform built directly into VCF. Calico Enterprise — part of the Calico Unified Platform — takes that foundation further, delivering a single management plane for networking, network security, and observability across every cluster, every workload type, and every environment. No stitching tools together. No integration tax. Just the enterprise-grade performance and security your most critical workloads demand.

Ready to see it in action?

Request a Demo of Calico Enterprise →

Start your free trial of Calico Cloud today →

The post Secure and Scale VMware VKS with Calico Kubernetes Networking appeared first on Tigera - Creator of Calico.

Calico Load Balancer: Simplifying Network Traffic Management with eBPF

Alister Baroi — Sat, 21 Mar 2026 20:00:55 +0000

Authors: Alex O’Regan, Aadhil Abdul Majeed

Ever had a load balancer become the bottleneck in an on-prem Kubernetes cluster? You are not alone. Traditional hardware load balancers add cost, create coordination overhead, and can make scaling painful. A Kubernetes-native approach can overcome many of those challenges by pushing load balancing into the cluster data plane. Calico Load Balancer is an eBPF powered Kubernetes-native load balancer that uses consistent hashing (Maglev) and Direct Server Return (DSR) to keep sessions stable while allowing you to scale on-demand.

Below is a developer-focused walkthrough: what problem Calico Load Balancer solves, how Maglev consistent hashing works, the life of a packet with DSR, and a clear configuration workflow you can follow to roll it out.

Why a Kubernetes-native load balancer matters

On-prem clusters often rely on dedicated hardware or proprietary appliances to expose services. That comes with a few persistent problems:

Cost and scaling friction – You have to scale the network load balancer vertically as the size and throughput requirements of your Kubernetes cluster/s grows.
Operational overhead – Virtual IPs (VIPs) are often owned by another team, so simple service changes require coordination.
Stateful failure modes – Kube-proxy load balancing is stateful per node, so losing an ingress node can break active sessions.
Configuration drift – Kubernetes is declarative, but the upstream load balancer is not, which causes divergence over time.

Calico Load Balancer flips that model. Instead of dedicated hardware, it uses the Calico eBPF data plane on ordinary Linux nodes in the cluster, advertises service IPs via BGP, and makes the load balancing decision consistent across nodes. The result is a system that is cheaper to scale, easier to operate, and more resilient to node or path changes.

How Calico Load Balancer works (and why Maglev matters)

The core idea is consistent hashing. Instead of each node picking a backend at random and storing that decision in per-node state, Calico Load Balancer computes the same backend choice on any node for the same flow. This is implemented with Maglev, a consistent hashing algorithm that:

Evenly distributes connections across backends.
Minimizes disruption when load balancer nodes come and go.
Allows any load balancer node to make the same backend selection, even mid-connection.

Kube-proxy uses random selection plus per-node state, which is fine for many cases but can fail under node churn or route changes. Maglev avoids that by making the decision deterministic. Nodes may still cache the mapping for performance, but the flow-to-backend decision can be reproduced anywhere, which is what keeps sessions stable when traffic lands on a different node.

Strategic Assessment: Is This Right for Your Deployment?

Questions you can ask your team to identify if Calico Load Balancer can help your environment:

Which services are most impacted by node churn today?
Where do we see the most operational overhead in Virtual IP (VIP) provisioning?
How do we secure access to service VIPs?
Does the network have Equal Cost Multi-Path (ECMP) access to service VIPs?
How do we handle VIP failover?
Are there services with high-throughput requirements?

The Life of a Packet

A key design goal is to keep client sessions stable while enabling horizontal scale. Here is a simplified flow for a typical ECMP + BGP setup:

This diagram shows how Direct Server Return (DSR) allows the return path to bypass the load balancer node, reducing latency and hop count.

A few important details:

The top-of-rack router uses ECMP to pick a load balancer node to receive the packet.
That node runs the Maglev algorithm to choose the backend pod. It DNATs the packet and tunnels it to the node that hosts the pod.
The pod replies, and the node SNATs the packet back to the service VIP before it leaves.
With DSR (Direct Server Return), the return path bypasses the load balancer node and goes straight back to the client. The client always sees responses from the advertised service VIP.

That DSR path is important. It keeps the data path efficient and reduces load balancer hop count on the return path. It also prevents the client from seeing internal pod IPs.

DSR compared to a traditional return path

If you have only worked with classic NAT-based load balancers, DSR can feel unusual. The key difference is that the response does not have to traverse the same load balancer node that handled the inbound packet. That has two practical benefits: less work for the load balancer nodes and lower return-path latency.

Maglev and caching: deterministic and fast

There are two pieces working together in Calico Load Balancer:

The Maglev lookup table: Provides the deterministic backend choice. Any node can compute the same result for the same flow, which is why mid-connection packets can land on a different node without breaking the session.
A per-flow cache: (for example, via conntrack) can retain that decision for efficiency, and to preserve existing connections when the backend lookup table changes. It is not the source of truth for correctness.

This is a subtle but important difference from kube-proxy. In kube-proxy, the per-node conntrack decision is the only thing tying a flow to a backend. In Calico Load Balancer which uses Calico’s eBPF dataplane, the decision can be reproduced on any node, which is what makes failover or ECMP rehash events non-disruptive.

What happens during failures or path changes

Consistent hashing is not just about distribution. It is about resilience. In practice, you can test this by intentionally re-routing traffic for an existing TCP connection to a different node. Even if the new node has no prior per-flow state, it can recompute the same backend decision using Maglev, so the connection can continue without disruption.

Calico uses Maglev consistent hashing to ensure TCP sessions remain stable even if a load balancer node fails or is drained

This matters when:

A load balancer node fails or is drained.
ECMP next hops reshuffle due to network outages.
You scale the load balancer pool up or down.

Because the decision is deterministic, the packet can land on any node and still find the correct backend. The whole cluster then seemingly acts as a single, distributed load balancer, with per-node caches for additional performance and resilience.

Configuration workflow (high level)

Calico Load Balancer is configured and managed declaratively just like any other Kubernetes resource. A typical configuration flow looks like this:

Create a dedicated IP pool for Calico LB IPAM, marked for LoadBalancer use.
Create a Service of type LoadBalancer. Calico IPAM allocates a VIP from that pool.
Advertise the VIP to the upstream network using Calico BGP (optional BFD for faster detection of outages).
Ensure your upstream router uses ECMP to send traffic for the VIP to the Calico load balancer nodes.

# Calico IP pool for load balancer VIPs
apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  name: loadbalancer-ip-pool
spec:
  cidr: 192.210.0.0/20
  blockSize: 24
  assignmentMode: Automatic
  allowedUses:
    - LoadBalancer


# Kubernetes Service using Calico LB
apiVersion: v1
kind: Service
metadata:
  name: my-app
  annotations:
    lb.projectcalico.org/external-traffic-strategy: maglev
spec:
  type: LoadBalancer
  selector:
    app: my-app
  ports:
    - port: 443
      targetPort: 8443

From there, the VIP is advertised and traffic can arrive through the ECMP paths to any load balancer node. Calico handles the rest.

Platform Benefits

The benefits discussion above can translate into real operational advantages for platform teams:

Remove Hardware Dependency: Scale load balancing capacity by adding standard Kubernetes nodes rather than purchasing expensive appliances or coordinating with vendors and avoid vendor lock-in.
Kubernetes-native approach: Reduces complexity by keeping all service configuration within your existing GitOps workflows – no separate load balancer management interfaces or external ticketing systems.
Session persistence: Addresses one of the most common causes of user-facing outages in traditional setups, where losing an ingress node would drop all active connections.
Self-service capability: Empowers development teams to provision and modify load balancer configurations without waiting for network team approvals, significantly reducing time-to-market for new services.
Predictable traffic distribution: Maglev’s consistent hashing ensures that traffic distribution remains predictable and fair even as backend pods scale up and down, preventing the “hot spot” issues that can occur with simpler load balancing algorithms.

Conclusion

Calico Load Balancer gives you a Kubernetes-native way to scale your load balancer and protect critical services without the operational drag of traditional appliances.

Ready to scale your on-prem networking?

If you want to try this in your environment, here is a safe, incremental path:

1. Identify a non-critical service that is a good LoadBalancer candidate.
2. Create a Calico IP pool for LoadBalancer VIPs and advertise it via BGP to your upstream network.
3. Enable a LoadBalancer Service with Maglev for that service and confirm the VIP is reachable.
4. Validate failover: remove a load balancer node or change ECMP next hops and verify sessions continue.
5. Document the workflow and replicate to other services.

Learn more about Calico eBPF

The post Calico Load Balancer: Simplifying Network Traffic Management with eBPF appeared first on Tigera - Creator of Calico.

Lift-and-Shift VMs to Kubernetes with Calico L2 Bridge Networks

Alister Baroi — Sat, 21 Mar 2026 06:12:02 +0000

On paper, lift-and-shift VM migration to Kubernetes sounds simple. Compute can be moved. Storage can be remapped. But many migration projects stall at the network boundary. VM workloads are often tied to IP addresses, network segments, firewall rules, and routing models that already exist in the wider environment. That is where lift-and-shift becomes much harder than it first appears.

Why lift-and-shift migration is challenging

In a traditional hypervisor environment:

A VM connects to a network the rest of the data center already understands.
Its IP address is a first-class citizen of the network.
Firewalls, routers, monitoring tools, and peer applications know how to reach it.
Existing application dependencies are often built around that network identity.

Default Kubernetes pod networking works very differently:

Pod IPs usually come from a cluster-managed pod CIDR.
Those IPs are mainly meaningful inside the Kubernetes cluster.
The upstream network usually does not have direct visibility into pod networks.
The original network segments from the VM world are not preserved by default.

This creates a major problem for VM migration:

The workload can no longer keep the same network presence it had before.
Teams often need to introduce VIPs or reconfigure the networking settings of the VM.
That adds more complexity since changing the IP of the VM also requires changes to network firewall and load balancer configuration.
At scale, it can make migration slower, more expensive, and harder to justify.

So while Kubernetes can be a strong platform for running VM workloads, default pod networking is often not a natural fit for lift-and-shift migration. The networking gap is one of the biggest reasons these projects become more complex than expected.

The lack of network continuity is shown in the image below.

Default pod networking often creates a gap in network continuity, forcing complex reconfigurations and breaking existing dependencies like firewalls and load balancers.

Introducing Calico L2 Bridge Networks

Calico L2 Bridge Networks are designed to close that gap. Instead of forcing the VM to adapt to the Kubernetes pod network, Calico allows administrators to extend the existing layer 2 network all the way to the virtual machine running in Kubernetes.

Administrators can define a network resource in Kubernetes, and Calico creates a bridge on the cluster nodes to extend external networks. A trunk interface can be attached to the bridge, allowing VLANs to be carried all the way to the virtual machine. During migration, the migration tool can map the VM’s existing interface to interface definitions in the cluster and also inform Calico of the VM’s IP address, so Calico can keep track of that address throughout the VM’s lifecycle. Calico does all the underlying plumbing to ensure that the VM retains its network connectivity after migration.

The key point is that the VM does not need a brand new networking model just because it moved to Kubernetes. The same layer 2 network structure can be preserved, which makes lift-and-shift migration much more practical.

Why this matters

Existing VLAN-based connectivity can be extended directly to the VM.
Administrators do not need to re-address the VM or place it behind VIPs just to make migration work.
Multiple VLANs can be supported through the same trunk-backed bridge.
The network can move with the VM, instead of becoming a separate redesign project.

The network continuity offered by Calico L2 Bridge Networks is shown in the image below.

Calico L2 Bridge Networks allow you to extend existing Layer 2 infrastructure directly into Kubernetes, enabling “lift-and-shift” migrations that preserve original IP addresses and VLANs.

Readiness Assessment: Is L2 Bridge Networking Right for Your Migration?

Ask your infrastructure and networking teams:

Do our existing VMs rely on specific VLAN tags for firewall policy enforcement?
Will re-addressing our workloads require updating multiple external load balancers or hardcoded application dependencies?
Do we need to maintain L2 adjacency between our legacy VM clusters and new Kubernetes nodes during a phased migration?
Is network observability (via eBPF) a requirement for our compliance or troubleshooting workflows post-migration?

Benefits After Migration

Calico L2 Bridge Networks do more than simplify the move into Kubernetes. Once the VM is running in Kubernetes, Calico can also bring the same operational advantages that teams already expect for cloud-native workloads.

Network Observability

One major benefit is observability. Calico provides visibility into network traffic for these VM interfaces, giving administrators a much clearer view of how workloads are communicating after migration. Because Calico uses eBPF, it can capture deep insights into network behavior without relying on external tooling or guesswork. That makes it easier to understand traffic patterns, troubleshoot issues, and operate migrated VMs with more confidence.

Calico Policy Enforcement

Another major benefit is policy enforcement. Administrators can apply declarative network policy directly to these VM interfaces using Kubernetes-native constructs. Policies can be based on labels, which fits naturally into Kubernetes operations, and selectors can be used to target specific VLANs or external networks when defining policy. Teams can also migrate networking policy from their previous hypervisor environment into Calico network policy, helping them maintain the same security posture as workloads move into Kubernetes. In practice, that means teams can preserve the connectivity model they need while still applying consistent, modern security controls to VM workloads inside Kubernetes.

Live Migration

Live migration is another important benefit. Once the VM is running in Kubernetes, it can be moved from one node to another while retaining the same network configuration. That is critical for day-2 operations, because it means teams can take advantage of Kubernetes-based VM mobility without having to rework network settings each time a workload moves. The network identity stays consistent even as the VM is migrated across the cluster.

By decoupling compute and networking, Calico ensures that migrated VMs can move between cluster nodes while retaining their original network configuration and identity.

Conclusion

Lift-and-shift VM migration to Kubernetes often breaks down because the network model does not move with the workload. That forces teams to introduce workarounds such as VIPs, re-addressing, and additional operational complexity, which can quickly turn a simple migration plan into a much larger project.

Calico L2 Bridge Networks help remove that barrier by extending existing layer 2 networks all the way to the VM inside Kubernetes. That means teams can preserve familiar network configurations during migration while also gaining the advantages of running VMs on Kubernetes, including observability, declarative policy, and live migration. Instead of treating networking as a migration blocker, organizations can use Calico to make it part of a cleaner and more practical path forward.

Webinar Recording

Available on demand

Calico L2 bridge networking for virtual machines

Migrating VMs to Kubernetes? Learn how to preserve your existing IPs, VLANs, and security policies — no network rebuild required.

“Lift and shift” VM migrations with zero IP changes

Maintain existing VLANs and security dependencies

Expert guidance from Tigera’s networking team

Watch the recording

The post Lift-and-Shift VMs to Kubernetes with Calico L2 Bridge Networks appeared first on Tigera - Creator of Calico.

AI Assistant for Calico: Troubleshooting at the Speed of Thought

Alister Baroi — Thu, 19 Mar 2026 20:36:45 +0000

Despite the wealth of data available, distilling a coherent narrative from a Kubernetes cluster remains a challenge for modern infrastructure teams. Even with powerful visualization tools like the Policy Board, Service Graph, and specialized dashboards, users often find themselves spending significant time piecing together context across different screens. Making good use of this data to secure a cluster or troubleshoot an issue becomes nearly impossible when it requires manually searching across multiple sources to find a single “connecting thread.”

Inevitably, security holes happen, configurations conflict causing outages, and teams scramble to find that needle-in-the-haystack cause of cluster instability. A new approach is needed to understand the complex layers of security and the interconnected relationships among numerous microservices. Observability tools need to not only organize and present data in a coherent manner but proactively help to filter and interpret it, cutting through the noise to get to the heart of an issue. As we discussed in our 2026 outlook on the rise of AI agents, this represents a fundamental shift in Kubernetes management.

Key Insight: With AI Assistant for Calico, observability takes a leap forward, providing a proactive, conversational, and context-aware intelligence layer to extract actionable insights from a sea of raw telemetry. SREs can interrogate their data through a natural language interface instead of having to painstakingly construct complex queries, removing knowledge barriers and reducing MTTR (Mean Time to Repair).

Beyond Manual Log Analysis

To understand the impact of the AI Assistant for Calico, it is helpful to look at the traditional workflow through the lens of the challenges platform teams face daily. Troubleshooting connectivity issues, for example, typically starts with a look at traffic flows, identifying ones that may be problematic, then drilling down into the details while looking up possibly relevant policies, network configuration, ingress rules, and hostname resolution in different dashboards and sets of logs. Often one or more multi-step queries have to be run and then the results have to be filtered to start getting an idea of what may be going wrong. This is particularly difficult when Kubernetes flat networks fail at scale, increasing the complexity of every query.

This sort of manual navigation slows down problem resolution and imposes a high cognitive cost on SREs. Even for seasoned engineers, debugging can take hours or even days when the answer must be excavated from multiple sources of information.

Natural Language Insights

The AI Assistant for Calico resolves these bottlenecks by replacing cumbersome queries with a seamless, natural-language interface that interprets telemetry instead of just displaying it and synthesizes data from multiple sources so you don’t have to. By moving away from rigid query languages, the assistant changes how engineers interact with their cluster data in three primary ways:

Ask, Don’t Query: Troubleshooting now starts with an articulation of intent instead of a lengthy session wrestling with search fields and operators. Being able to simply ask “What are the unrestricted egress destinations currently receiving traffic from my pods?” without painstakingly cobbling together and testing a multi-layered query is a paradigm shift. It moves the engineer’s focus from the mechanics of the search to the logic of the solution.
Context-Aware Explanations: The assistant doesn’t just return raw data; it provides summaries and recommendations generated from real telemetry and policy context. It can explain, for instance, that “Traffic is denied because policy X in namespace Y blocks TCP 443.” It also suggests further troubleshooting steps and offers remediation advice.
Unified Visibility Across the Cluster: The assistant provides insights across clusters, namespaces, and workloads, extracting details that would previously require drilling down into, for example, a specific flow or policy configuration. All of a sudden, that “connecting thread” between seemingly isolated events becomes a lot clearer.

AI Assistant for Calico allows engineers to quickly zero in on relevant information using a conversational form of root-cause analysis that even junior members of the team can have success with.

AI Assistant for Calico can quickly get you the information you need

Proactive Security and Policy Optimization

While reactive troubleshooting is critical, the AI Assistant for Calico also enables a proactive security posture by identifying misconfigurations and security gaps that might otherwise go unnoticed:

- Surfacing Exposure Risks: The AI Assistant can identify workloads exposed to the internet or detect egress exposure risks, such as pods communicating with unrestricted external destinations.
- Policy Recommendations and Generation: Instead of starting from scratch, users can ask the AI to recommend a base policy or generate a specific snippet, such as a policy to block all egress traffic from a specific training pod.
- Cleaning up the Mesh: The assistant helps maintain cluster stability and security hygiene by detecting unused or missing network policies.
- Identifying Gaps: It proactively surfaces network flows that have no policies applied to them, ensuring that the principle of least privilege is maintained across the cluster—a key requirement highlighted in the 2025 GigaOm Radar for Container Networking.

These capabilities streamline the time-consuming and error-prone process of manually managing intricate policy syntax, making for more stable, performant, and secure clusters.

Real-World Scenario: Rapidly Resolving a Blocked Service Connection

To see the impact of these capabilities, consider a common high-pressure situation for a platform engineer. An engineer receives an urgent alert that a critical production service is unable to communicate with its database.

In a traditional environment, the engineer would spend 30 to 60 minutes manually checking network policies, inspecting flow logs, and verifying namespace labels across multiple clusters to find the culprit. Every minute of manual investigation increases the risk of service downtime and customer frustration.

The AI Solution: Instead of manual log diving, the engineer asks the AI Assistant for Calico a direct question: “Why is the frontend-service in the production namespace unable to reach the db-service?”. The AI instantly analyzes the environment and identifies that a recent policy update is missing a necessary egress rule for the specific database port. Total resolution time is reduced from over an hour to just a few minutes.

Thinking ahead, the engineer asks for an audit of all staged policies. AI Assistant for Calico finds another incorrect policy—this one with a misspelled label selector—averting a future outage.

View Interactive Demo: Exploring Assistant for Calico →

A New Standard for Platform Operations

The introduction of the AI Assistant for Calico in the Winter 2026 release is the next step in observability and Kubernetes management. By adding the ability to interrogate a cluster in plain English, Calico’s unified platform bridges the gap between high-fidelity telemetry data and practical solutions

Beyond the immediate operational gains, this AI-powered approach fits into a broader strategy of defense in depth and operational simplicity, specifically regarding ingress security for AI workloads. It removes the friction of complex debugging, accelerates onboarding for new team members, and ensures that your security posture remains consistent even as your architecture scales.

Experience the Power of AI Assistant for Calico

Ready to see how AI can accelerate your Kubernetes troubleshooting and network policy management?

Watch the On-Demand Demo

Sign Up for Calico Cloud (Free Trial)

The post AI Assistant for Calico: Troubleshooting at the Speed of Thought appeared first on Tigera - Creator of Calico.

What Your EKS Flow Logs Aren’t Telling You

Alister Baroi — Wed, 18 Mar 2026 21:06:48 +0000

If you’re running workloads on Amazon EKS, there’s a good chance you already have some form of network observability in place. VPC Flow Logs have been a staple of AWS networking for years, and AWS has since introduced Container Network Observability, a newer set of capabilities built on Amazon CloudWatch Network Flow Monitor, that adds pod-level visibility and a service map directly in the EKS console.

It’s a reasonable assumption that between these tools, you have solid visibility into what’s happening on your cluster’s network. But for teams focused on Kubernetes security and policy enforcement, there’s a significant gap — and it’s not the one you might expect.

In this post, we’ll break down exactly what EKS native observability gives you, where it falls short for security-focused use cases, and what Calico’s observability tools, Goldmane and Whisker, provide that you simply cannot get from AWS alone.

What EKS Gives You Out of the Box

AWS offers two main sources of network observability for EKS clusters:

VPC Flow Logs capture IP traffic at the network interface level across your VPC. For each flow, you get source and destination IP addresses, ports, protocol, and whether traffic was accepted or rejected at the VPC level, by security groups and network ACLs. Useful for infrastructure-level visibility, but with no awareness of the Kubernetes layer.

Container Network Observability, introduced more recently and powered by Amazon CloudWatch Network Flow Monitor, goes meaningfully further. Once you’ve installed the NFM agent as a DaemonSet and configured the required IAM permissions, Scope, and Monitor resources, you get access to:

Performance metrics — pod and node-level metrics including ingress/egress flow counts, packet counts, bytes transferred, and bandwidth limit events, exposed in OpenMetrics format and scrapable by Prometheus
A service map — a visualization of traffic between pods and deployments in the EKS console, showing retransmissions, retransmission timeouts, and data transferred between communicating workloads
A flow table — a breakdown of top-talking workloads across three views: within the cluster (east-west), to AWS services (S3, DynamoDB), and to external destinations

This is a genuinely capable performance observability tool. If your primary concern is understanding network throughput, identifying bandwidth hotspots, tracking cross-AZ traffic costs, or detecting retransmission anomalies, Container Network Observability gives you a solid foundation.

But if your primary concern is Kubernetes network security, specifically understanding policy behavior, debugging denied connections, and moving toward a least-privilege posture, it leaves critical gaps.

What EKS Native Observability Doesn’t Tell You

Understanding what EKS observability doesn’t show you is just as important as knowing what it does. Several gaps become significant once you’re actively managing network policies or investigating a security incident.

No policy verdict context. This is the most important gap. Neither VPC Flow Logs nor Container Network Observability have any awareness of Kubernetes network policies. If a Calico policy is denying traffic between two pods, you will not see that denial in AWS observability tooling. You’ll see a connection failing with no indication of which policy rule fired, which tier it belonged to, or whether the traffic was intentionally blocked or the result of a misconfiguration. For teams actively managing network policies, this makes AWS observability tools nearly useless for the most common debugging scenario you’ll face.

Performance metrics, not security metrics. The flow-level metrics in Container Network Observability (retransmissions, retransmission timeouts, and bytes transferred) are designed to answer performance questions. They are not designed to answer security questions like: which namespaces are communicating that shouldn’t be, which egress destinations are being reached, or which policy rules are being evaluated for a given flow. These are fundamentally different observability needs, and AWS’s tooling is built for the former.

Top 500 flows only, over a 1-hour window. The NFM agent collects the top 500 network flows by volume every 30 seconds, and the console visualizations are scoped to a 1-hour time range. For security investigations, this matters: less frequent or lower-volume connections — exactly the kind that might indicate lateral movement or exfiltration — may not appear in the top 500 and will be invisible to the service map and flow table.

No namespace-level policy context. While the service map does show pod and deployment-level topology, it shows you traffic volume and performance — not whether that traffic is authorized by your network policies, which policies evaluated it, or whether any of it should be blocked. Understanding the security posture of your namespace boundaries requires a different layer of data entirely.

Setup complexity. Enabling Container Network Observability requires installing the NFM agent add-on, configuring IAM permissions with Pod Identity or IRSA, and creating NFM Scope and Monitor resources either through the console, AWS CLI, or Terraform. For teams managing this with IaC, that means defining additional resource dependencies and managing the Terraform AWS Provider version requirements. It’s not prohibitively complex, but it’s meaningful infrastructure to own and maintain.

What Calico Adds: Goldmane and Whisker

Calico’s observability capabilities are built on two components introduced in Calico 3.30: Goldmane, a flow log API that generates enriched, Kubernetes-native flow data, and Whisker, a web-based UI for visualizing and filtering that data in real time. Together they give you a fundamentally different class of observability — one built specifically for the Kubernetes security layer.

Goldmane: Flow Logs That Speak Kubernetes Security

Where AWS Container Network Observability speaks in performance metrics, Goldmane speaks in Kubernetes policy context. Every flow log entry generated by Goldmane includes:

Source and destination namespace, pod name, and deployment — Kubernetes identity is always present, regardless of IP churn
Service names — traffic is attributed to the service it passed through, not just the backend pod IP
Policy verdicts — each flow includes which Calico policy rule evaluated it, whether the action was Allow or Deny, and which tier the policy belonged to
Port, protocol, and domain information — including DNS-based destinations for egress traffic

The policy verdict data is what changes the debugging experience most fundamentally. When a network policy misconfiguration breaks Prometheus scraping, blocks a health check probe, or silently drops traffic between namespaces — scenarios that are routine for any team actively managing network policies — Goldmane tells you exactly which rule fired and why. You’re not correlating IP addresses and timestamps across multiple tools; the answer is in the flow log.

Goldmane exposes its data via a gRPC API, making it straightforward to consume from your existing observability stack, whether that’s Elasticsearch, Grafana, or a custom pipeline. It covers all flows in your cluster, not just the top 500 by volume.

Whisker: Real-Time Policy Visibility Without Additional Infrastructure

Whisker is a lightweight web console that surfaces Goldmane’s flow data without requiring any additional tooling. You can filter flows by namespace, pod, policy verdict, or direction, and see in real time which traffic is being allowed and denied across your cluster.

For teams moving from a default-allow posture toward namespace isolation or zero trust, Whisker is particularly valuable during the transition: you can watch policy verdicts update live as you apply and adjust rules, rather than inferring policy behavior from downstream signals like application errors and health check failures.

Whisker is included in Calico Open Source as of 3.30. Access it via a local port-forward — no agent DaemonSet configuration, no IAM policies, no cloud service dependencies required.

Going Further: Calico Cloud Free Tier

Goldmane and Whisker give you a significantly richer observability foundation for security and troubleshooting than AWS native tooling. If you want to go further, Calico Cloud’s free tier adds a hosted experience that requires no additional infrastructure to operate.

The Calico Cloud Service Graph provides a live, visual map of communication between namespaces, services, and pods.

Connecting your EKS cluster to Calico Cloud gives you access to the Service Graph, which provides a live visual map of how your namespaces, services, and pods are communicating, overlaid with Calico policy evaluation data. Unlike the AWS console service map, which surfaces performance metrics for your top flows, the Calico Cloud Service Graph shows you the security posture of your traffic: which connections are authorized, which are being denied, and where your policy coverage has gaps. Teams that see it for the first time consistently describe it as the moment their cluster’s network finally became legible from a security perspective.

The free tier also includes the policy recommendation engine, which analyzes your cluster’s actual traffic patterns and automatically generates staged network policies to implement namespace isolation. Staged policies let you audit the recommended rules and see exactly which traffic they would allow and deny before you enforce them. It’s the fastest path from a default-allow EKS cluster to one where every namespace is isolated and secured.

Calico Cloud’s free tier is genuinely free, with no sales engagement required. It supports a single cluster with 24-hour data retention — enough to experience the Service Graph and understand what your cluster’s traffic actually looks like from a security perspective.

A Quick Comparison

Feature	VPC Flow Logs	EKS Container Network Observability	Calico Open Source (Goldmane + Whisker)	Calico Cloud Free Tier
Pod / namespace identity	✗	✓
(deployment/pod view)	✓	✓
Service-level visibility	✗	✓
(service map)	✓	✓
Network performance metrics	Partial	✓
(RT, RTO, bytes)	✗	✗
Calico policy verdict (allow/deny + which rule)	✗	✗	✓	✓
All flows (not just top N by volume)	✓	✗
(top 500)	✓	✓
Security posture / policy gap visibility	✗	✗	✓	✓
Real-time policy visualization	✗	✗	✓
(Whisker)	✓
(Service Graph)
Policy recommendations	✗	✗	✗	✓
Setup complexity	Low	Medium
(NFM agent, IAM)	Low
(port-forward)	Low
(single manifest)

Sign up for the free tier

Goldmane and Whisker, available today in Calico 3.30+, fill the gaps in EKS observability. They’re purpose-built for the Kubernetes security layer and give every EKS operator richer policy-level observability at no cost.

If you want to go further and have a live service graph that surfaces policy context, hosted dashboards, and automated policy recommendations, Calico Cloud’s free tier is the next step.

Conclusion

AWS Container Network Observability is a meaningful improvement over VPC Flow Logs and a genuinely useful tool for understanding network performance in your EKS environment. If you’re tracking retransmissions, monitoring cross-AZ traffic, or trying to identify bandwidth hotspots, it’s worth enabling.

But it was designed for performance observability, not security observability. It has no awareness of Kubernetes network policy behavior, no policy verdict data, and no visibility into whether your namespace boundaries are being respected. For teams actively managing network policies or trying to move toward a least-privilege security posture, these are not minor gaps.

Goldmane and Whisker, available today in Calico 3.30+, fill exactly those gaps. They’re purpose-built for the Kubernetes security layer and give every EKS operator richer policy-level observability at no cost. If you want to go further and have a live service graph that surfaces policy context, hosted dashboards, and automated policy recommendations, Calico Cloud’s free tier is the next step.

The post What Your EKS Flow Logs Aren’t Telling You appeared first on Tigera - Creator of Calico.

What’s New in Calico: Winter 2026 Release

Alister Baroi — Wed, 04 Mar 2026 20:52:31 +0000

AI Powered Intelligence, Unified Traffic Observability and Scalable Infrastructure Management

As anyone managing one or more Kubernetes clusters knows by now, scaling can introduce an exponentially growing number of problems. The sheer volume of metrics, logs and other data can become an obstacle, rather than an asset, to effective troubleshooting and overall cluster management. Fragmented tools and manual troubleshooting processes introduce operational complexity leading to the inevitable security gaps and extended downtime. As the number of clusters grows it becomes more important than ever to find ways of reducing the observability noise, decluttering the monitoring stack and eliminating the bottlenecks that get in the way of keeping your clusters stable and secure.

The Winter 2026 release of Calico Enterprise and Calico Cloud addresses the pain points of scaling clusters with three key enhancements:

1. AI-Powered Intelligence

AI Assistant for Calico: Efficiently navigate disparate data sources to quickly get answers through natural language, or proactively identify problems before they arise.

2. Unified Traffic Observability

Unified Ingress Gateway Dashboard: Monitor gateway traffic volume, latency, and request behavior alongside east-west traffic observability.
Last Evaluated Policy Metrics: Identify and decommission unused security policies to maintain a lean, least-privileged posture.

3. Scalable Infrastructure and Expanded Ecosystem Support

Deterministic NetworkSet Matching: Ensure stable policy enforcement in large environments with predictable, namespace-aware lookups.
Projects Hierarchy: Connect and organize an unlimited number of clusters with self-service grouping and regional data residency compliance.
Expanded OS Support: Extend unified security policies to traditional workloads with official support for Debian and Ubuntu on VMs.

AI-Powered Intelligence

AI-Powered Intelligence and Enhanced Observability

AI Assistant for Calico: Natural Language Insights for Faster Troubleshooting

Understanding what is going on in a Kubernetes cluster is a challenge for most, if not all, platform and DevOps teams. Calico Cloud provides an abundance of networking and security telemetry from flow logs, metrics, service connectivity, and policy evaluation events across workloads, namespaces, and clusters. However, making good use of this data to properly secure a cluster and efficiently troubleshoot issues becomes next to impossible when it involves manually searching across multiple sources to find that connecting thread. Debugging and resolving an issue can take hours and sometimes days causing frustration not only for platform and DevOps engineers but for customers too, ultimately costing the organization revenue.

To accelerate troubleshooting and reduce operational complexity, the Winter 2026 release of Calico Cloud introduces AI Assistant. This AI powered context-aware intelligence layer replaces cumbersome queries and time consuming log analysis with the ability to resolve issues through natural language.

How it Works: Instead of creating complex filters to sift through pages of log entries, teams will simply ask questions such as “Why is traffic between service A and service B blocked?” or “What are the policies applied to the production-frontend namespace?”

Key Benefits of AI Assistant for Calico:

Accelerated Troubleshooting: Reduce MTTR (Mean Time To Resolution) by asking concise and pertinent questions instead of manually creating queries and filters to retrieve the troubleshooting data you need.
Natural Language Interaction: Interact with cluster data using plain English, without needing the specialized expertise required for complex debugging.
Proactive Security Insights: Identify security gaps, egress exposure risks, and misconfigurations that might otherwise go unnoticed.
Policy Optimization: Use AI Assistant’s recommendations to clean up unused objects and improve overall cluster stability.

AI Assistant for Calico can quickly get you the information you need.

Scenario: Rapidly Resolving a Blocked Service Connection

The Situation: Imagine a platform engineer receiving an urgent alert that a critical production service is unable to communicate with its database. Traditionally, the engineer would spend 30-60 minutes checking network policies, flow logs, and namespace labels across multiple clusters to find the culprit.

The AI Assistant for Calico Solution: Instead of manual investigation, the engineer asks the AI Assistant: “Why is the frontend-service in the production namespace unable to reach the db-service?” The AI Assistant instantly analyzes the environment and identifies that a recent policy update lacks the necessary egress rule for the specific database port. It provides a summary of the issue and a recommended policy snippet to fix it, reducing the resolution time from an hour to minutes.

Unified Traffic Observability

Dashboard for the Calico Ingress Gateway

The recent release of Calico Ingress Gateway created a need for observability into this new component. Users need to be able to access metric and troubleshooting insight in the same Calico in-product dashboards they use to view the rest of their cluster traffic. Not being able to easily troubleshoot their gateways could slow adoption and make it difficult to migrate to Gateway API. It adds unnecessary administrative overhead and makes a critical component of cluster security opaque.

To bridge this visibility gap and simplify cluster management, the Calico Winter 2026 release adds the Calico Ingress Gateway dashboard to Calico UI. Users now have out-of-the box access to traffic volume, latency, and request data across all gateways and routes in the same place they see their east-west traffic.

Key Benefits of Ingress Gateway Dashboards:

Unified Observability: Easily view ingress, egress, and east-west traffic data using the same in-product UI.
Real-Time Performance Tracking: Track live metrics such as requests per minute, duration, and latency at the namespace, service, and route levels.
Gateway Health Monitoring: Get a clear view of Gateway Classes, hosts, instances, and listener status to verify and maintain your cluster’s stability and availability.
No extra tools or collectors are required: Get access to gateway metrics without having to install additional components.
Rapid Error Detection: Drill down into individual requests for detailed troubleshooting of gateway-managed APIs.

See metrics across all gateways, namespaces and routes with the Ingress Gateway Dashboard.

Scenario: Isolating Latency in a High-Traffic Application

The Situation: A DevOps engineer notices a spike in user reports regarding slow response times for a specific web application. Using traditional tools, they would have to check the external load balancer, then the ingress controller logs, and finally the backend application metrics to find the bottleneck.

The Calico Solution: The engineer opens the Calico Ingress Gateway dashboard and immediately sees a “Request Latency per Minute” chart. They filter by route and notice that while the gateway itself is healthy, one specific route is showing high latency samples. By looking at the “Traffic Performance” list, they confirm the delay is occurring at the backend service destination rather than the gateway layer, allowing them to escalate the issue to the correct application team in seconds.

Unified Traffic Observability

Identifying and Cleaning Up Unused Policies with “Last Evaluated” Metrics

As Kubernetes environments grow, clusters can accumulate hundreds of network policies. Over time, changes in application architecture or service decommissions leave many of these policies active but no longer utilized. Maintaining a “least-privileged” security posture becomes nearly impossible when the environment is cluttered with stale rules. These unused policies not only create operational noise but can also lead to accidental security gaps and performance overhead as the CNI continues to process redundant logic.

To eliminate this operational noise and strengthen security posture, the Winter 2026 release introduces visibility into policy evaluation. The ‘Last evaluated’ metric has been added to policy data to provide visibility into which policies and rules have not seen traffic in a while. Platform engineers can investigate unused policies and confidently decommission them, ensuring the cluster remains lean and secure. By identifying and removing “dead” rules, teams improve the overall performance of the policy engine and strictly adhere to micro-segmentation best practices.

Key Benefits of Last Evaluated Metrics:

Confident Policy Decommissioning: Clearly identify policies that have not seen traffic for a specific number of days.
Maintain Least Privilege: Ensure your micro-segmentation strategy remains effective by removing obsolete permissions.
Improved UI Visibility: See the “Last Evaluated” date and time displayed directly on your Policy and View Boards.

Scenario: Automating a “Zero-Trust” Monthly Audit

The Situation: A security engineer at a healthcare company is tasked with a monthly audit to ensure no unnecessary network paths are open. Previously, this meant manually comparing flow logs against the entire policy set—a process that took days and was prone to human error.

The Calico Solution: Using the new “Last Evaluated” metric, the engineer creates a report for all policies that haven’t been evaluated in the last 30 days. He quickly identifies five policies belonging to a decommissioned billing service. After discussion with his team he is able to decommission the policies before they can become vulnerabilities.

Scalable Infrastructure

Deterministic Matching for Overlapping NetworkSets

In large-scale enterprise environments, organizations often manage a high volume of NetworkSets. As these environments grow, it is common for different teams to define overlapping CIDR ranges across multiple NetworkSet objects. When CIDRs overlap, it becomes difficult for platform engineers to identify exactly which NetworkSet is being applied to a specific traffic flow. This ambiguity can lead to unpredictable policy enforcement, making it harder to troubleshoot connectivity issues or ensure that security rules are hitting the intended targets.

To resolve these policy conflicts and ensure predictable enforcement, Calico now introduces namespace awareness and a deterministic tie-breaker for NetworkSet lookups.

The lookup process follows a strict priority: first, it checks for a NetworkSet in the workload’s own namespace; second, it evaluates GlobalNetworkSets; and finally, it considers NetworkSets in other namespaces. If an overlap still exists, a lexicographic ordering tie-breaker is used to ensure the result is always consistently reproducible removing the “guesswork” from policy matching in complex environments. By providing a predictable, hierarchical lookup, Calico ensures that the most relevant security context is applied to every flow. This results in more stable policy enforcement and significantly simplifies auditing and troubleshooting for large organizations.

Key Benefits of Improved NetworkSet Matching:

Namespace-First Priority: Preference is now given to NetworkSets in the same namespace as the connection initiating workload.
Deterministic Results: Get the same results each time with lexicographic ordering acting as a tie-breaker.
Scalable Policy Management: Allow multiple teams to define NetworkSets without worrying about unpredictable global side effects.

Scalable Infrastructure

Streamlining Multi-Cluster Management with Projects Hierarchy

As organizations grow, they need to manage an increasing number of clusters across different teams and geographical regions. Previously, Calico Cloud users were limited to a set number of clusters per tenant and had to rely on manual support requests to create projects and organize their environments into logical groupings. A hard limit on cluster count and the lack of self-service organization tools created operational bottlenecks for large-scale deployments. Furthermore, without the ability to strictly assign clusters to specific regions, meeting stringent data residency and compliance requirements was a complex, manual task.

To remove these scaling bottlenecks and simplify global infrastructure management, Calico Cloud now introduces Projects.

With the Calico Winter 2026 release Calico Cloud now introduces “Projects,” a grouping mechanism that allows users to organize an unlimited number of managed clusters into meaningful logical structures. This feature is entirely self-service, enabling platform teams to create projects, group clusters by department or environment, and assign projects to specific geographic regions. It significantly improves operational efficiency by allowing platform engineers to manage vast, global infrastructures with ease. By enabling regional assignments for projects, organizations can more easily meet compliance and data residency requirements. Additionally, the removal of cluster limits ensures that Calico Cloud can scale alongside your business without friction.

Key Benefits of Projects Hierarchy:

Self-Service Organization: Empower teams to manage their own groupings without external support.
Unlimited Scalability: Connect an unlimited number of clusters to Calico Cloud.
Simplified Compliance: Assign projects to specific regions to ensure data residency requirements are met.
Improved Management: Organize clusters by environment (e.g., Prod, Staging, Dev) or business unit.

Expanded Ecosystem Support

Expanding Hybrid Cloud Reach with New OS Support for VMs

Many enterprises operate in hybrid environments where critical workloads run on a mix of Kubernetes clusters and traditional virtual machines (VMs). To maintain a unified security posture, these organizations need to run the Calico agent directly on their VM hosts. Previously, Calico’s support for non-Kubernetes hosts was limited primarily to RHEL 8 and 9. This restricted customers who preferred or already standardized on other popular Linux distributions, forcing them to either maintain inconsistent security stacks or manage multiple OS versions just to support Calico.

To extend consistent security policies across the hybrid cloud and support broader infrastructure requirements, the Winter 2026 release adds official support for Debian and Ubuntu.

This allows customers to extend Calico’s unified networking and security policies to these popular distributions, ensuring consistent protection across their entire infrastructure. By supporting a broader range of operating systems, Calico provides customers with the flexibility to choose the VM host OS that best fits their operational needs. This expansion simplifies management by allowing a single, unified security and networking platform to govern both modern Kubernetes clusters and traditional VM-based applications.

Get Started with Calico

The Winter 2026 release of Calico Enterprise and Calico Cloud introduces powerful new capabilities designed to simplify, secure, and scale your infrastructure. By integrating AI Assistant into Calico Cloud, we are helping platform teams cut through the noise with natural language troubleshooting and proactive insights that reduce MTTR and identify security gaps before they become incidents. Together, these enhancements give platform engineers the confidence to manage complex, high-performance environments with greater efficiency and less manual intervention.

Environment	Action Required	Documentation Link
Calico Enterprise	Upgrade to the latest Enterprise version.	Upgrade Calico Enterprise documentation
Calico Cloud	Follow instructions to update your connected clusters.	Upgrade Calico Cloud instructions

Ready to see the Winter 2026 release in action? Reach out for alive demo or Sign up for a Calico Cloud trial to experience the new AI Assistant firsthand.

The post What’s New in Calico: Winter 2026 Release appeared first on Tigera - Creator of Calico.

Join Calico at KubeCon Europe 2026: AI Agents, Silent Discos, and Dutch Delights!

Alister Baroi — Wed, 25 Feb 2026 21:57:29 +0000

The cloud-native community is heading to the historic canals and vibrant tech scene of Amsterdam for KubeCon + CloudNativeCon Europe 2026! From March 23–26, Amsterdam will be buzzing with the latest in Kubernetes, platform engineering, and, of course, all things Calico.

Whether you’re a long-time Calico user or just starting your cloud-native security journey, Tigera has a packed schedule to make your KubeCon experience both educational and unforgettable.

Meet Our International Team

Our international team, hailing from Vancouver, Toronto, San Francisco, Cork, London, and Cambridge , is converging on Amsterdam to welcome you! Whether you’re a first-time attendee or a KubeCon veteran, our crew has been through the trenches and is ready to share tips on everything from eBPF security to the best bitterballen in the city.

Securing the Future: AI Agent Workshop

The biggest shift in the ecosystem this year? Autonomous AI Agents. But as we move these agents into production, how do we ensure they are secure, compliant, and observed?

Join us for our featured workshop: Securing Autonomous AI Agents in Production. We’ll dive deep into how to implement zero-trust security for AI workloads and protect the underlying infrastructure that powers them.

Shane Walsh, Corporate Account Executive (Cork, Ireland)

_ Thoughts on KubeCon: “This is my 5th KubeCon. My 1st KubeCon was in Valencia in 2022. It’s a great event, so it’s always worth coming back for.”_

Pro Tip: “Take your time and talk to all vendors. Wear comfy shoes!”

JOIN US FOR HAPPY HOUR

After a deep dive into AI security, you’ll need a place to decompress and network with your peers. We’re hosting an exclusive Happy Hour at one of Amsterdam’s most iconic spots. Join us for relaxed vibes, great views, and even better conversations with the creators of Calico.

Monday, March 23, 2026

AI Agent Workshop 2:00 PM – 5:00 PM

Happy Hour 5:00 PM – 7:00 PM

LEARN MORE AND REGISTER HERE

Ramon Slingerland, Sales Manager (Cork, Ireland)

What are you looking forward to in Amsterdam: “Proper Dutch fries with mayonnaise and a particular fried item called ‘bitterballen‘. (goes really well with a cold beer!)”

The “Silent Disco” Demo Stage

Tired of shouting over the expo hall floor to hear a presentation? We’re bringing back our Silent Disco Demos! Grab a pair of high-fidelity wireless headphones at the Tigera booth and tune into live, deep-dive sessions hosted by our engineers. It’s the best way to get a front-row seat to:

EBPF-based security and observability.
Micro-segmentation for high-scale clusters.
Real-time threat detection in action.

Nell Jerram, Principal Software Engineer (Cambridge, England)

Amsterdam activity she’s looking forward to: “Visiting the Van Gogh museum and Anne Frank house.”

Expert Advice: “There is a lot going on and it can be intense. So plan your time accordingly. Be sure to make time to chat with people in an adhoc basis.”

Reza Ramezanpour, Senior Developer Advocate (Vancouver, Canada)

Amsterdam activity he’s looking forward to: “Visiting Vondel park.”

Pro Tip: “Buy compression socks!”

The Tigera Booth Experience: Fun is Mandatory

Visit us at Booth #400! This year, our booth is designed to be a hub for both technical deep-dives and high-energy networking. We believe KubeCon should be as fun as it is informative. Stop by for:

Daily Silent Disco: Grab a pair of headphones and tune into live demos of Kubernetes topics.
Quizzes & Prizes: Think you know Calico? Take our daily technical quizzes to win fantastic prizes and exclusive swag.
The SWAG: Our legendary Calico-themed t-shirts, stickers, and a few “Amsterdam-exclusive” surprises are waiting for you.

Shaun Crampton, Distinguished Engineer (London, England)

Veteran Tip: “The din of 10 thousand people talking can be overwhelming, consider getting some attenuators.”

Quizzes, Swag, and Prizes

No KubeCon is complete without the loot. Stop by the Tigera booth to:

Test Your Skills: Take our daily technical quizzes for a chance to win premium prizes (did someone say Lego?).
Collect the Classics: We’ll have our legendary Calico t-shirts and brand new stickers, plus some Amsterdam-themed surprises.

Eunice Cao, Events & Marketing Manager (Vancouver, Canada)

“I quickly learned that the currency of the cloud native world is stickers and LEGO sets.”

Travel Tip: “Leave some space in your suitcase for all the cool swag you can pick up!”

Karl Power, Corporate Account Executive (Cork, Ireland)

_ KubeCon Must Do: “Make sure you come to Tigera’s booth, our T-Shirts are the best at Kubecon!”_

_ Pro Tip: “Enjoy it. Speak to people and enjoy the interactions.”_

Plan Your Visit

Booth Location: #400
Workshop: Monday, March 23 | 2:00 PM – 5:00 PM
Happy Hour: Monday, March 23 | 5:00 PM – 7:00 PM at The Harbour Club

Want to skip the lines? Book a 1:1 Meeting with a Calico Expertto discuss your specific security and observability challenges.

Aadhil A. Majeed, Senior Solutions Architect (Toronto, Canada)

_ Thoughts on KubeCon “What brings me back is the opportunity meet with the Calico community, engage with partners, make new connections and get a sense for where the industry is headed.”_

Amsterdam Goal: “Hoping to get a taste of European hospitality.”

We can’t wait to see you in Amsterdam. Let’s make KubeCon 2026 the best one yet! Proost!

The post Join Calico at KubeCon Europe 2026: AI Agents, Silent Discos, and Dutch Delights! appeared first on Tigera - Creator of Calico.

Project Calico 3.30+ Hackathon: Show Us What You Can Build!

Alister Baroi — Tue, 17 Feb 2026 22:45:34 +0000

Build the Future of Cloud-Native Networking!

The Calico community moves fast. With the releases of Calico 3.30 and 3.31 , brings improvements in scalability, network security, and visibility. Now, we want to see what YOU can do with them!

We’re excited to officially invite you to the Project Calico 3.30+ Community Hackathon.

Whether you’re a seasoned eBPF expert or a newcomer to the Gateway API, we welcome your innovation and your ideas!

Table of Contents

- What’s in the Toolkit?
- Hackathon Starter Kit (GitHub)
- Inspiration: What Can You Build?
- Prizes & Swag
- Hackathon Timeline
- Judging Criteria: How to Win
- Register Now

What’s in the Toolkit?

We’ve packed Calico 3.30+ with powerful features ready for you to hack on:

Goldmane & Whisker: High-performance flow insights meets a sleek, operator-friendly UI.
Staged Policies: The “Safety First” way to test Zero Trust before enforcing it.
Calico Ingress Gateway: Modern, Envoy-powered traffic management via the Gateway API.
Calico Cloud Ready: Connect open-source clusters to a free-forever, read-only tier for instant visualization and troubleshooting.
IPAM for Load Balancers: Consistent IP strategies for MetalLB and beyond.
Advanced QoS: Fine-grained bandwidth and packet rate controls.

Hackathon Starter Kit

No need to start from a blank screen. Use these progressive GitHub guides to stand up your environment and verify your features in minutes.

Level 1: Bootstrap

Set up a 3-node Kind cluster and install Calico in under 5 minutes.

View GitHub Guide →

Level 2: Verification

Ensure your environment is correctly configured for Goldmane, Whisker, and Staged Policies.

View GitHub Guide →

Level 3: Expert

Deep-dive into component status and health for advanced observability and automation hacks.

View GitHub Guide →

Inspiration: What Can You Build?

Whether you’re a networking guru or an automation enthusiast, Calico 3.30+ provides a massive playground for innovation. Here are three major tracks to spark your imagination:

Observability & Visibility

Leverage Goldmane and Whisker to make the invisible, visible.

Flow Insight Dashboards: Create a specialized Grafana dashboard that visualizes the high-performance flow data collected by Goldmane.
AI Traffic Analysis: Use an LLM to analyze Whisker flow logs to identify and explain unusual traffic patterns in plain English.
Visual Troubleshooting: Build a workflow that uses the Calico Cloud free tier to pinpoint exactly where a packet is being dropped in a complex microservice architecture.

Zero Trust Security

Use Staged Policies to modernize security without the fear of outages.

Safe Policy CI/CD: Create a GitHub Action that automatically deploys a policy in “Staged” mode and only promotes it to “Enforced” after 24 hours of zero blocked traffic.
Policy Migration Tool: A script that converts legacy Kubernetes NetworkPolicies into advanced Calico Staged Policies for better auditability.
Dynamic Quarantine: A tool that detects threats and automatically stages a restrictive policy for an affected namespace.

Traffic & Infrastructure

Integrate Ingress Gateway and IPAM for rock-solid connectivity.

Gateway API Demo: Build a multi-tenant app that uses the Calico Ingress Gateway to handle traffic routing and security at the edge.
MetalLB + IPAM Automation: Showcase a self-healing infrastructure where Calico IPAM dynamically manages LoadBalancer IPs for bare-metal clusters.
QoS Optimizer: Build a performance-testing tool that demonstrates how Calico’s Advanced QoS controls prevent “noisy neighbors” from slowing down critical workloads.

$1,750 in Total Cash Prizes!

1st Place

$1,000

USD

2nd Place

$500

USD

3rd Place

$250

USD

Plus: Exclusive Calico Hackathon Swag Packs for all winners!

Mark Your Calendars

All times in Pacific Time (PT). Don’t let the clock run out!

Phase	Date
Hackathon Announced: Save the date	Feb 17, 2026
Hackathon Officially Opens	Feb 24, 2026
Submission Deadline	Mar 31, 2026 @ 11:59 PM PT
Showcase & Winners Announced	April 2026

Judging Criteria: How to Win

Our panel of Calico maintainers and community leaders will be scoring projects based on five key pillars. To take home the top prize, aim for a balance of technical execution and real-world impact.

Technical Depth

Does the project meaningfully implement Calico 3.30+ features? We’re looking for high-quality code and a deep understanding of how Goldmane, Whisker, or Staged Policies function.

Creativity & Innovation

Is the idea unique? We love “outside-the-box” thinking—whether it’s a new use case for the Gateway API or a clever integration we haven’t seen before.

Practical Value

Could a real-world Calico user deploy this tomorrow? We value projects that solve actual pain points in networking, security, or cluster operations.

Clarity of Demo

Is your video walkthrough easy to follow? A great project needs a great story—explain the Why, the How, and show us the Result clearly.

Community Impact

Does this benefit the wider open-source ecosystem? Projects that provide educational value, helpful tutorials, or reusable templates will score high here.

Note to Participants: Our judges aren’t just looking for complex code; they’re looking for clarity and usefulness. A simple, well-documented tool that solves a specific problem is often more valuable than a massive, unfinished dashboard!

Ready to show the world what you can build?

View Official Terms & Conditions

The post Project Calico 3.30+ Hackathon: Show Us What You Can Build! appeared first on Tigera - Creator of Calico.

Kubernetes Network Observability: Comparing Calico, Cilium, Retina, and Netobserv

Alister Baroi — Wed, 11 Feb 2026 21:10:35 +0000

Calico, Cilium, Retina, and Netobserv: Which Observability Tool is Right for Your Kubernetes Cluster? Network observability is a tale as old as the OSI model itself and anyone who has managed a network or even a Kubernetes cluster knows the feeling: a service suddenly can’t reach its dependency, a pod is mysteriously offline, and the Slack alerts start rolling in. Investigating network connectivity issues in these complex, distributed environments can be incredibly time consuming. Without the right tools, the debugging process often involves manually connecting to each node, running tcpdump on multiple machines, and piecing together logs to find the root cause. A path that often leads to frustration and extended downtime.

This is the problem that Kubernetes Network Observability was built to solve. By deploying distributed observers, these cloud-native solutions take the traditional flow entries and enrich them with Kubernetes flags and labels to allow Kubernetes users to get insight into the inner workings of their clusters.

This blog post aims to give you a rundown of the leading solutions in the CNCF ecosystem, and compare how they track a packet’s journey across your cluster.

Feature Comparison Matrix

Before diving into the specifics, let’s look at how these four major players (Calico, Cilium, Microsoft Retina, and Netobserv) stack up against one another.

Feature	Calico Observability	Cilium Observability	Microsoft Retina	Netobserv (Red Hat)
CNI Agnostic	No (Requires Calico)	No (Requires Cilium)	Yes	Yes
UI Experience	Calico Whisker / Grafana	Hubble UI / Grafana	Grafana / Azure Monitor / Hubble UI*	OpenShift Plugin / Grafana
Installation	Easy (Helm/Operator)	Easy (CLI/Helm)	Easy (Helm)	Moderate (Operator)**
Monitoring Backend	eBPF (Linux) / HNS (Win)	eBPF (Linux)	eBPF (Linux) / HNS (Win)	eBPF (Linux)
Flow Type	Flow Aggregation	Individual Flows	Individual Flows + Metrics	Flow Aggregation (IPFIX)
Enrichment	K8s Metadata (Pod/NS)	K8s Metadata + Identity ***	K8s Metadata	K8s Metadata + Owner Ref
Observability Domain	Cluster and Host	Cluster based	Cluster and Host	Cluster and Host
Prometheus Export	Yes	Yes	Yes	Yes
Policy Insights	Full Policy Hierarchy	Verdict (Allow/Deny)	Verdict + Drop Reason	Verdict + Policy Name

* Microsoft Retina has a couple of modes, one of these modes offers a smaller set of features but allows you to use Hubble as its UI.

** Netobserv installation experience can differ depending on your cluster, in a non OpenShift cluster you might hit some bumps while installing.

*** Identity is an internal Cilium value that is assigned to cluster resources.

Understanding Flow Types

Before focusing on specific observability solutions, let’s take a look at flow types. Any network observability application is made up of two parts. A collector that gathers information related to networking activities in that environment and an exporter that emits this information via pulling or pushing.

These flows can be stored in two different formats, individual or aggregated.

Aggregated Flows

Aggregated Flows group similar packets together over a window of time (e.g., “50 packets went from Pod A to Pod B in the last 10 seconds”).

Pros : Significantly lower storage costs; better for long-term trend analysis and capacity planning.
Cons : You lose the precise timestamp of a single packet drop; smooths out “micro-bursts.”

Individual Flows

Individual Flows treat every connection attempt or significant network event as a discrete log entry.

Pros: You can see exactly which specific request failed at what time.
Cons: Can generate massive amounts of data in high-traffic clusters; usually requires a short retention period (e.g., rolling buffer).

Now that we have established the foundational flow types and data collection methods, let’s see how the leading tools in the ecosystem apply these concepts to real-world cluster monitoring.

Calico Observability Stack

Calico is a modern unified security platform designed not just for Kubernetes, but also for Virtual Machines, OpenStack and bare metal systems.

How it works

Observability in Calico is deeply integrated into its core components. In Linux Calico eBPF programs hook into the inner workings of the kernel, allowing it to extract deep network telemetry directly from the kernel. Calico observability also works on Windows, where it relies on its Windows data plane based on the HNS technology to gather all the information related to each flow. All this information is accessible via a gRPC channel to Calico Whisker for visualization.

To see how this context-driven approach differs from legacy monitoring, check out our deep dive on why context matters in Kubernetes networking.

Key Data Types

Calico provides deep visibility into the decision-making process of the network:

Direction Aware: Calico intelligently categorizes each flow as reported by the sender or a receiver. This is a problem solver in troubleshooting or writing policy scenarios.
Enriched Logs: Each flow provides a list of aggregate information enriched with Kubernetes metadata (Namespace, Owner, Resource).
Policy Evaluation: On top of highlighting the final verdict and policy name, by default, Calico also outputs all the policies that matched against a flow allowing for policy performance tuning and easier troubleshooting.
L7 Visibility: Optionally, Calico Ingress Gateway can report application-layer data (like HTTP methods and URLs) for deeper debugging.

Cilium Observability Stack

Cilium is an open-source, cloud-native solution for providing, securing, and observing network connectivity between workloads, Cilium networking is established via eBPF programs and its observability components are funneled to Hubble via a gRPC channel.

How it Works

Cilium leverages eBPF programs to tap into the system. It captures network events directly from the kernel as they happen and streams them in real-time via a gRPC channel. (For a broader look at how these architectures compare, see our guide on the key differences between Calico and Cilium). Hubble taps into the Cilium gRPC channel and visualizes each flow.

Key Data Types

Cilium uses an internal concept called identities to distinguish resources within clusters:

Flow Verdicts: It tracks the state of every packet: forwarded, dropped, or audited, mapped directly to the Cilium Network Policies enforcing them.
Enriched Logs: Each flow provides a list of information enriched with Kubernetes metadata (Namespace, Owner, Resource).
L7 Visibility: Optionally, Hubble has integrations that can be enabled to provide L7 Visibility. However, since it requires traffic to be redirected to an embedded user-space Envoy proxy for parsing, it introduces an additional latency.

Microsoft Retina

Microsoft Retina is a cloud-agnostic observability platform that leverages the power of eBPF to provide deep, actionable insights into network traffic. Since its open-source debut on GitHub, it was specifically designed to address the challenges of monitoring modern Kubernetes environments, which often span multiple clouds and hybrid deployments.

How it Works

The defining feature of Retina is its CNI Agnostic design. Whether you are running Flannel, Calico, Cilium, or Azure CNI, Retina can be used to start collecting data from your environment. By using eBPF programs, Retina offers a transparent, low-overhead window into the kernel’s networking stack without requiring any modifications to your applications.

Key Data Types

Retina focuses heavily on actionable metrics for Site Reliability Engineers:

Enriched Logs: Correlates raw IPs with Kubernetes metadata (Namespace, Owner, Resource).
Drop Reasons: Insights into why a packet was dropped (e.g., IPTABLES_DROP, CONN_TRACK_ERR). Not detailed as others due to policy limitations.
DNS Latency: Specialized metrics to track DNS resolution times and timeout occurrences.
TCP State: Metrics regarding TCP retransmissions and connection resets, which are vital for debugging latency issues.

Netobserv (Red Hat)

Netobserv (Network Observability Operator) is an OpenShift-native (but Kubernetes compatible) solution that brings flow-based observability to the cluster. It leverages an eBPF agent to generate flows and a flow collector pipeline (often using Loki) to store and query them.

How it Works

Netobserv is designed to be a “plug-and-play” flow collection system. It deploys an eBPF agent (Flow Logs Pipeline) to all nodes to sample traffic and export it in the IPFIX standard or JSON. It integrates tightly with the OpenShift console but can be visualized via standard Grafana dashboards in vanilla Kubernetes.

Key Data Types

Netobserv provides a “NetFlow-like” experience for Kubernetes:

Enriched Logs: Correlates raw IPs with Kubernetes metadata (Namespace , Pod, Labels, Resource).
Connection Tracking: It visualizes traffic as conversations, calculating Round Trip Time (RTT) to help identify network latency versus application processing latency.
Interface Metrics: Visibility into the specific network interfaces (veth pairs, physical nics) where traffic is ingressing or egressing.

Conclusion

While we highlighted multiple choices when it comes to network observability for Kubernetes, Calico Whisker with its unique design is our recommendation. All you need to consider is the 3 Rules of Kubernetes Network Observability.

The 3 Rules of Kubernetes Network Observability

1. The Native Stack Rule

If you want to be in control of your cluster (on-premises/self-managed), make sure to use a custom CNI which allows you the most control. For example, Calico in such a scenario gives you the most control over your cluster networking and security capabilities. Simply by using Tigera Operator to deploy Calico Whisker observability is achieved and you can go even further using other Calico capabilities to get rid of all other third-party projects and use Calico as your unified network and security platform. This allows you to move beyond flat networks and implement a robust security hierarchy across your entire infrastructure.

2. The Cloud Pragmatist Rule

If you are using a cloud-provider setup (managed cluster) with the default CNI (AWS VPC CNI, Azure CNI, etc.), you can still take advantage of other CNI features. In such a setup the default cloud provider CNI will provide the networking foundation and Calico provides the more advanced features such as Observability, Gateway API, WireGuard, and mTLS, allowing you to have the best of both worlds.

3. The Red Hat Rule

In an OpenShift environment you could choose any of the previous rules depending on your networking choices at the time of cluster creation.

Keep in mind that NetObserv, and Microsoft Retina can be installed on any cluster and are not locked to any CNIs.

Regardless of the tool you pick, moving away from individually running tcpdump on workloads and nodes, toward continuous observability is the only way to maintain a secure and reliable distributed environment.

Take the Next Step

Ready to master your cluster visibility? Explore these resources to learn more about modern network observability.

See it in Action: Try Calico Whisker

Deep Dive: Read ‘Why Context Matters in Kubernetes Networking’

Compare More: Calico vs. Cilium

The post Kubernetes Network Observability: Comparing Calico, Cilium, Retina, and Netobserv appeared first on Tigera - Creator of Calico.

Migrating from Ingress NGINX to Calico Ingress Gateway: A Step-by-Step Guide

Alister Baroi — Thu, 05 Feb 2026 21:00:48 +0000

From Ingress NGINX to Calico Ingress Gateway

In our previous post, we addressed the most common questions platform teams are asking as they prepare for the retirement of the NGINX Ingress Controller. With the March 2026 deadline fast approaching, this guide provides a hands-on, step-by-step walkthrough for migrating to the Kubernetes Gateway API using Calico Ingress Gateway. You will learn how to translate NGINX annotations into HTTPRoute rules, run both models side by side, and safely cut over live traffic.

A Brief History

The announced retirement of the NGINX Ingress Controller has created a forced migration path for the many teams that relied on it as the industry standard. While the Ingress API is not yet officially deprecated, the Kubernetes SIG Network has designated the Gateway API as its official successor. Legacy Ingress will no longer receive enhancements and exists primarily for backward compatibility.

Why the Industry is Standardizing on Gateway API

While the Ingress API served the community for years, it reached a functional ceiling. Calico Ingress Gateway implements the Gateway API to provide:

Role-Oriented Design: Clear separation between the infrastructure (managed by SREs) and routing logic (managed by Developers).
Native Expressiveness: Features like URL rewrites and header manipulation are first-class citizens in the spec, not vendor-specific annotations.
Unified Security: Ingress traffic is finally governed by the same Calico Network Policies that secure your east-west traffic.

Feature Comparison	Calico Ingress Gateway	Ingress NGINX
Foundation	100% based on K8s Gateway API (Vendor-agnostic)	Built on the legacy Kubernetes Ingress API specification (no longer being enhanced)
Lifecycle	Enterprise support / CVE protection	No support/updates after March 2026
Traffic Control	Wide range of native features	Less features; reliant on custom annotations
RBAC	Extremely granular / flexible	Less flexible / granular
Installation	Tigera Operator	More difficult to install/maintain
Unified Platform	Part of a single solution for networking and security	A separate product; not part of a unified platform

Prerequisites & Preparation

Before you begin the migration, ensure your environment meets these requirements:

Calico version
- Calico Open Source 3.30+
- Calico Cloud
- Calico Enterprise 3.21+
Gateway API CRDs
- Installed automatically by the Tigera Operator
Ingress inventory
- Audit existing Ingress resources and annotations (timeouts, rewrites, headers)
TLS certificates
- TLS secrets must exist in each gateway namespace

Create TLS Secrets (Required for HTTPS)

kubectl create secret tls gateway-tls-secret -n your-gateway-namespace --cert=path/to/tls.crt --key=path/to/tls.key

Migration Guide: Table of Contents

Phase 1: Environment Setup & Gateway Deployment
- • Step 1.1: Enable the Gateway API Resource
- • Step 1.2: Verify Resource Availability
- • Step 1.3: Deploy and Configure the Gateway
Phase 2: Transitioning Ingress to HTTPRoute
- • Translation: NGINX Annotations to HTTPRoute Filters
- • Technical Examples: Path-Based, Rewrites, and HTTPS Redirects
Phase 3: Verification & Final Cutover
- • Parallel Testing and Traffic Weight Shifting
- • Post-Migration Monitoring and Decommissioning

Migration Walkthrough: NGINX to Gateway API

Phase 1: Enabling Calico Ingress Gateway

Setting up the Calico Ingress Gateway involves two main steps: creating the Gateway configuration and deploying the actual Gateway instance.

1.1. Enable the Gateway API Resource

First, you need to enable Calico Ingress Gateway capabilities. Calico implements Gateway API by integrating with a hardened Envoy Gateway image that is based in Envoy Gateway 1.3.2.

kubectl create -f - <<EOF
apiVersion: operator.tigera.io/v1
kind: GatewayAPI
metadata:
 name: default
EOF

1.2. Verify Gateway API Resource Availability

Verify that the Gateway API resources and an Envoy Gateway implementation are available.

# Make sure Gateway API resources have been installed
kubectl api-resources | grep gateway.networking.k8s.io

Output:

backendtlspolicies btlspolicy gateway.networking.k8s.io/v1alpha3 true BackendTLSPolicy
gatewayclasses gc gateway.networking.k8s.io/v1 false GatewayClass
gateways gtw gateway.networking.k8s.io/v1 true Gateway
grpcroutes gateway.networking.k8s.io/v1 true GRPCRoute
httproutes gateway.networking.k8s.io/v1 true HTTPRoute
referencegrants refgrant gateway.networking.k8s.io/v1beta1 true ReferenceGrant
tcproutes gateway.networking.k8s.io/v1alpha2 true TCPRoute
tlsroutes gateway.networking.k8s.io/v1alpha2 true TLSRoute
udproutes gateway.networking.k8s.io/v1alpha2. true UDPRoute

You should see a list of resources including gatewayclasses, gateways, and httproutes.

Next, confirm the Envoy Gateway controller is active:

# There should be an Envoy Gateway implementation
kubectl get gatewayclass -o=jsonpath='{.items[0].spec}' | jq

Output:

{
  "controllerName": "gateway.envoyproxy.io/gatewayclass-controller",
  "parametersRef": {
    "group": "gateway.envoyproxy.io",
    "kind": "EnvoyProxy",
    "name": "tigera-gateway-class",
    "namespace": "tigera-gateway"
  }
}

1.3. Deploy and Configure the Gateway

Now, create the Gateway resource. Calico will automatically provision the underlying pods and a LoadBalancer service to handle incoming traffic. In this example we will deploy the Gateway with an HTTPS listener included because security should not be optional. Ideally you will want to automate certificate management.

In this example we will deploy the Gateway with an HTTPS listener included because security should not be optional. Ideally you will want to automate certificate management. An example of how to do this with Let’s Encrypt can be found at the end of this document.

kubectl create -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
 name: your-calico-ingress-gateway
 Namespace: your-gateway-namespace
spec:
 gatewayClassName: tigera-gateway-class
 listeners:
   - name: http
     protocol: HTTP
     port: 80
   - name: https
     protocol: HTTPS
     port: 443
     hostname: your-domain.com
     tls:
       mode: Terminate
       certificateRefs:
       - kind: Secret
         name: gateway-tls-secret
EOF

Optional: Cross-Namespace Routing with `ReferenceGrant`

If you plan to have your gateway in one namespace and the services it routes traffic to in another you will need to create a ReferenceGrant. This is a very flexible and secure way to do cross-namespace routing.

Pro Tip: Optional but recommended for cross-namespace routing.

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: your-reference-grant
  namespace: your-workload-namespace
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    namespace: your-gateway-namespace
  to:
  - group: ""
    kind: Service

1.4. Verify the Setup

Check that the Gateway has been assigned a public IP address (or hostname if you are on a cloud provider like AWS/Azure)

kubectl get svc -n tigera-gateway

Output:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
envoy-default-eg-e41e7b31 LoadBalancer 10.108.183.215 192.168.10.120 80:30161/TCP 4d20h

Phase 2: Converting Ingress Resources to Gateway API

The next step is to convert any Ingress resources to the new HTTPRoute resources that are a part of Kubernetes Gateway API.

When moving from Ingress NGINX Controller to Calico Ingress Gateway, the biggest challenge is moving away from annotations and converting them to HTTPRoute rules. In the old Ingress model, you had to “hint” at what you wanted using metadata. In the Gateway API, these functions are built directly into the HTTPRoute spec.

Common Ingress NGINX Controller Annotation Mapping
Feature
---
Path Rewrite
Redirects
Request Headers
Response Headers
App Root
Security

See the full list of Ingress NGINX Controller annotations for description of each annotation to help you find the best replacement HTTPRoute rule.

Examples of Ingress to HTTPRoute conversion

Example 1: Basic Path-Based Routing

In this scenario, we are routing traffic to a “backend” service based on the URL path.

Before: NGINX Ingress (Legacy Configuration)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: basic-ingress
spec:
  rules:
  - http:
      paths:
      - path: /your-api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

After: Calico HTTPRoute (Gateway API)

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
spec:
  parentRefs:
  - name: your-calico-ingress-gateway # References the Gateway we created in Section 3
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /your-api
    backendRefs:
    - name: api-service
      port: 80

Example 2: URL Rewriting & Header Manipulation

Use case: Strip a path prefix and inject a request header.

This is a more complex example where we need to strip a prefix before the request hits the application and add a custom header. In the NGINX model, this required specific annotations and snippets; in Gateway API, these are handled by native filters.

Before: NGINX Ingress (Legacy Configuration)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: rewrite-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
    nginx.ingress.kubernetes.io/configuration-snippet: |
      more_set_headers "X-Source: Calico-Migration";
spec:
  rules:
  - http:
      paths:
      - path: /old-path(/|$)(.*)
        pathType: ImplementationSpecific
        backend:
          service:
            name: app-service
            port:
              number: 80

After: Calico HTTPRoute (Gateway API)

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: rewrite-route
spec:
  parentRefs:
  - name: calico-ingress
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /old-path
    filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplacePrefixMatch
          replacePrefixMatch: /
    - type: RequestHeaderModifier
      requestHeaderModifier:
        add:
        - name: X-Source
          value: Calico-Migration
    backendRefs:
    - name: app-service
      port: 80

Example 3: Redirect to HTTPS

Use case: Redirect HTTP traffic to HTTPS using a 301.

Enforcing HTTPS is a production requirement for modern applications. In the legacy NGINX model, this was typically handled via a global or per-Ingress annotation. With Calico Ingress Gateway, since we configured an HTTPS listener in Step 2, we simply add a RequestRedirect filter to our HTTPRoute to enforce a permanent 301 redirect.

Before: NGINX Ingress (Legacy Configuration)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/ssl-redirect: "true" 
spec:
  rules:
    - host: foo.example.com
      http:
        paths:
          - path: /your-api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 80

After: Calico HTTPRoute (Gateway API)

Since we configured an HTTPS listener in step 2 we just need to create a filter to redirect everything to HTTPS with a 301 response code.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: https-redirect
spec:
  parentRefs:
  - name: my-gateway
  hostnames:
  - "your-domain.com"
  rules:
  - filters:
    - type: RequestRedirect
      requestRedirect:
        scheme: https
        statusCode: 301

Phase 3: Verification & Cutover Strategies

Running NGINX and Gateway API Side-by-Side

The final phase of the migration is moving your live traffic from NGINX to the Calico Ingress Gateway.

Since the two controllers can run simultaneously in the same cluster, you can perform a “canary” style cutover to minimize risk.

There are two ways to do this:

Cutover Option 1: Load Balancer Canary Traffic

Configure your load balancer to send a certain percentage of your traffic to the new gateway if there is support for it. For example:

AWS Application Load Balancer (ALB): Supports canary releases using weighted target groups, allowing you to send a small percentage (e.g., 10%) of traffic to a new version while the rest goes to the old.
Google Cloud Load Balancing: Offers capabilities for percentage-based canaries, often with Cloud Run or GKE, for fine-grained traffic control.
Azure Load Balancer/Application Gateway: Can be orchestrated with tools for canary strategies, working with services like App Mesh.

Cutover Option 2: Parallel Load Balancer Testing

Deploy a second load balancer to send traffic to the gateway
Test using the external IP or DNS record
Validate routing with curl: Use curl to test the Calico Gateway’s external IP directly to ensure the application responds correctly

# include the host header if you have hostnames configured in your HTTPRoutes
curl -H "Host: your-domain.com" http://<CALICO_GATEWAY_LOAD_BALANCER_IP>/your-api

Final Traffic Cutover

Once you have verified that the Calico Ingress Gateway is routing traffic correctly, you can begin transitioning live traffic. In a production environment, your gateway will reside behind a load balancer to which your DNS will route requests.

Step 1: Redirect Traffic to the New Gateway

Choose the cutover strategy that best fits your infrastructure:

Option 1: DNS-Based Cutover (Parallel Load Balancers)

Reduce TTL: Lower the Time to Live (TTL) on your DNS records to 5 minutes or less before the move.
Update DNS: Change your DNS A-records or CNAMEs to point to the new Calico load balancer.
Maintain Fallback: Keep the legacy NGINX Controller and its load balancer active for 24–48 hours to allow for an immediate rollback if needed.

— OR —

Option 2: Load Balancer Canary Cutover

If you are using a cloud load balancer (e.g., AWS ALB, Azure App Gateway) that supports weighted target groups, incrementally adjust the weights to send 100% of traffic to the Calico Ingress Gateway.

Why this matters: Canary-based cutovers allow platform teams to validate real production traffic against the new gateway with minimal risk, making it easier to detect regressions before the final migration.

Step 2: Monitor the Cutover

Watch your Calico logs and metrics to ensure traffic is flowing correctly through the new gateway:

Flow Logs: Check Calico Enterprise/Cloud flow logs for successful 2xx/3xx response codes.
Envoy Metrics: Monitor upstream/downstream latency to ensure performance parity with the legacy setup.

Step 3: Decommissioning NGINX

After the DNS change has propagated and you have confirmed there is no more traffic hitting the old NGINX controller:

Delete the legacy Ingress resources: kubectl delete ingress <name>
Uninstall the NGINX Ingress Controller.
Clean up any remaining NGINX-specific ConfigMaps or Secrets.

Important: Only proceed after zero traffic is confirmed.

Troubleshooting & FAQ

Migrating infrastructure components can sometimes lead to unexpected behavior. Here are the most common questions and issues platform engineers encounter when moving to Calico Ingress Gateway.

Question: Can I run both NGINX Ingress and Calico Ingress Gateway at the same time?

Answer: Yes. Since they use different API resources (Ingress vs. HTTPRoute) and different controller implementations, they can run side-by-side. This is the recommended way to test your migration before cutting over.

Q: What happens if I have an existing Calico Network Policy?

A: Calico Ingress Gateway integrates natively with Calico Network Policies. You can apply policies directly to the Gateway pods to restrict which namespaces or services the Gateway is allowed to talk to, providing much tighter security than a standard NGINX deployment.

Q: I applied my HTTPRoute, but I’m getting a 404 error. What’s wrong?

A: Check the following configuration points:

ParentRef: Ensure the parentRefs name in your HTTPRoute matches the name of your Gateway resource exactly.
Namespace: By default, a Gateway only listens to routes in its own namespace. Confirm that the allowedRoutes field is configured to allow From: All or that a ReferenceGrant has been created for cross-namespace routing.
Hostname: If you defined a hostnames field in the HTTPRoute, ensure your curl request or browser is using that exact header.

Q: How do I view logs for the new Gateway?

A: Since the Gateway is powered by Envoy, you can view the traffic logs by checking the logs of the pods created in the tigera-gateway namespace

# get a list of gateway pods
kubectl get pods -n tigera-gateway
# check the logs
kubectl logs [your envoy gateway pod] -n tigera-gateway

Appendix: Automating Certificate Management (TLS) with Cert-Manager

Manually requesting, applying, and rotating certificates creates significant administrative overhead. If at all possible, this process should be automated. In this example, we will use cert-manager and Let’s Encrypt.

1. Install cert-manager

Deploy the latest version of cert-manager to your cluster:

kubectl create -f https://github.com/cert-manager/cert-manager/releases/download/v1.17.2/cert-manager.yaml

2. Enable Gateway API Support

Patch the cert-manager deployment to enable Gateway API integration. This allows cert-manager to monitor Gateway resources and issue certificates automatically as needed.

kubectl patch deployment -n cert-manager cert-manager --type='json' --patch '
[
  {
    "op": "add",
    "path": "/spec/template/spec/containers/0/args/-",
    "value": "--enable-gateway-api"
  }
]'

3. Configure Let’s Encrypt ClusterIssuer

Deploy a cluster-scoped ClusterIssuer to configure Let’s Encrypt as your Certificate Authority. This is configured to verify domain ownership via the HTTP-01 challenge by routing validation traffic directly through the Calico Ingress Gateway.

kubectl create -f -<<EOF
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: <USER-YOUR-EMAIL-HERE>
    privateKeySecretRef:
      name: letsencrypt-account-key
    solvers:
    - http01:
        gatewayHTTPRoute:
          parentRefs:
          - kind: Gateway
            name: calico-demo-gw
            namespace: default
EOF

4. Annotate Gateways for Certificate Management

Annotate each gateway that needs to handle HTTPS to link it with the ClusterIssuer

kubectl annotate --overwrite gateway/your-calico-ingress-gateway -n your-gateway-namespace cert-manager.io/cluster-issuer=letsencrypt

—

Migration Summary

Migrating from the NGINX Ingress Controller to the Kubernetes Gateway API modernizes how ingress traffic is defined and managed in Kubernetes. While the Ingress API remains for backward compatibility, it has reached its limits and relies heavily on controller-specific annotations.

Using Gateway API with Calico Ingress Gateway gives platform teams a clear separation between infrastructure and application routing, with features like rewrites, redirects, header manipulation, and TLS expressed directly in the API. Ingress traffic is also governed by the same Calico Network Policies used for east-west traffic, creating a consistent and auditable security model.

This migration can be performed incrementally, with NGINX Ingress and Gateway API running side by side until the new configuration is fully validated. For teams responding to the retirement of NGINX Ingress, Calico Ingress Gateway provides a production-ready, low-risk path to align with the Kubernetes ecosystem’s direction.

—

Start Your Gateway API Migration with Calico

Convert existing NGINX Ingress resources automatically

Use the Ingress-to-Gateway API migration tool to generate HTTPRoute resources from your current NGINX Ingress configuration.

→ Ingress to Gateway API migration tool

See the migration in action

Follow along with a live, step-by-step walkthrough of migrating from NGINX Ingress to Calico Ingress Gateway.

→ Launch Arcade Demo

Get expert guidance from Tigera

Talk to the Tigera team about your ingress architecture and see Calico Ingress Gateway in action.

Request a Demo →

The post Migrating from Ingress NGINX to Calico Ingress Gateway: A Step-by-Step Guide appeared first on Tigera - Creator of Calico.

Calico Ingress Gateway: Key FAQs Before Migrating from NGINX Ingress Controller

Alister Baroi — Tue, 03 Feb 2026 23:39:01 +0000

What Platform Teams Need to Know Before Moving to Gateway API

We recently sat down with representatives from 42 companies to discuss a pivotal moment in Kubernetes networking: the NGINX Ingress retirement.

With the March 2026 retirement of the NGINX Ingress Controller fast approaching, platform teams are now facing a hard deadline to modernize their ingress strategy. This urgency was reflected in our recent workshop, “Switching from NGINX Ingress Controller to Calico Ingress Gateway” which saw an overwhelming turnout, with engineers representing a cross-section of the industry, from financial services to high-growth tech startups.

During the session, the Tigera team highlighted a hard truth for platform teams: the original Ingress API was designed for a simpler era. Today, teams are struggling to manage production traffic through “annotation sprawl”—a web of brittle, implementation-specific hacks that make multi-tenancy and consistent security an operational nightmare.

The move to the Kubernetes Gateway API isn’t just a mandatory update; it’s a graduation to a role-oriented, expressive networking model. We’ve previously explored this shift in our blogs on Understanding the NGINX Retirement and Why the Ingress NGINX Controller is Dead.

Bridging the Role Gap: Transitioning from the flat, annotation-heavy Ingress model to the role-oriented Kubernetes Gateway API.

After the workshop, we narrowed down the top questions keeping platform engineers up at night. Here is a detailed breakdown of those key concerns and our answers.

Question 1: Can I use the upstream Envoy Gateway as a PoC before moving to Calico Ingress?

Answer: Yes. Calico Ingress Gateway is built on a 100% upstream distribution of Envoy Gateway. Because we maintain strict compatibility with the Kubernetes Gateway API standard, you can confidently start a Proof of Concept (PoC) using standard Envoy Ingress Gateway.

High-Performance Architecture: How the Calico Ingress Gateway control plane translates your intent into actionable configuration for the Envoy Proxy data plane.

When you are ready to transition to production, the upgrade to Calico is seamless. You gain access to enterprise-grade security hardening and full lifecycle management via the Tigera Operator, which handles the complex deployment and maintenance tasks for you. This allows you to “start standard” and “scale for the enterprise” without rewriting your configuration.

Question 2: What is the difference between Calico Open Source and Calico Enterprise in terms of Gateway API features?

A: Both versions provide a solid foundation by supporting the core Gateway API spec. However, Calico Enterprise is designed for mission-critical environments where visibility and security are paramount.

Key additions include:

Advanced Security: Out-of-the-box integration for a Web Application Firewall (WAF) and IDS/IPS directly at the cluster edge.
Deep Observability: While open source provides basic metrics, Enterprise delivers detailed flow logs and real-time visualization via the Dynamic Service Graph, allowing you to see exactly how traffic traverses your ingress layer.
Lifecycle Support: Access to 24/7 technical support and CVE-scanned, “hardened” images.

Calico Ingress Gateway integrates seamlessly with the broader Calico Cloud framework to provide unified security, from WAF and IDS/IPS to deep network observability.

Question 3: What exactly does a “hardened” image mean? Are they modified, security-validated, or aligned with compliance requirements?

A: In the Tigera ecosystem, “hardening” is a multi-layered security process. We don’t just pull images from public registries; we rebuild our Envoy images using secure, minimal base images to reduce the attack surface.

Security Validation: Every image undergoes continuous CVE scanning and vulnerability patching.
Compliance Alignment: Our build process is designed to meet rigorous standards like FIPS 140-2, ensuring that the traffic entry point for your cluster meets the same compliance requirements (such as PCI DSS or SOC 2) as your internal workloads.

Question 4: Do I need to install the Calico CNI to use Calico Ingress Gateway?

A: No. You do not need the Calico CNI to run the Gateway. While there are “better together” security benefits when using Calico Networking and the Gateway together, the solution is designed to be highly compatible with standard environments.

Broad Compatibility: You can deploy it as a standalone Gateway API implementation on clusters using Flannel, AWS VPC CNI, Azure VNET CNI, or other standard cloud-native providers.
Managed Service Support: It is fully supported on EKS, AKS, and GKE.

For a full list of supported platforms and installation steps, check out the Calico Ingress Gateway documentation.

Question 5: Can I migrate incrementally, or is it an “all-or-nothing” big bang?

A: Incremental migration is highly recommended. One of the greatest strengths of the Gateway API is that it can run side-by-side with your existing NGINX Controller.

Deploy the New Gateway: Set up Calico Ingress Gateway without touching your existing traffic.
Migrate by Route: Use the HTTPRoute resource to move low-risk applications one at a time.
Weighted Shift: Leverage weighted load balancing at the DNS or cloud load balancer level to shift a small percentage (e.g., 5-10%) of traffic to the new gateway, validating performance before the final cutover.

Risk-Reduced Rollouts: Using native Gateway API traffic splitting to shift traffic gradually from NGINX to Calico without a “big bang” cutover.

Question 6: Are there any recommendations or best practices for capturing and evaluating performance with Gateway API?

A: Evaluation should be data-driven. We recommend establishing a baseline using Envoy’s native telemetry before and after the move. Key metrics to track include:

Upstream/Downstream Latency: Measured end-to-end to ensure your data plane meets SLAs.
Data Plane Apply Time: Monitor how long it takes for new routing rules to propagate (Calico metrics provide high visibility here).
Error Rates (4xx/5xx): Use Calico’s observability tools to quickly identify if an error is due to a misconfigured ReferenceGrant or a TLS handshake failure.

Migrating from Ingress API to Gateway API

In our recent workshop, we introduced the Ingress-to-Gateway Migration Tool, an open-source utility designed to automate the heavy lifting of manifest conversion. During the live demo, we successfully migrated NGINX-based setups, highlighting a few key operational realities:

Automation is the Foundation: The tool automatically translates standard NGINX annotations (like weighted traffic and canary rules) into standardized Gateway API resources like HTTPRoute.
The “Manual” Edge: For sophisticated configurations such as complex OIDC flows or custom Lua snippets human review is still necessary. As Meysam Kamali noted during the session: “Automated tools are an incredible accelerator, but ensure you verify complex rules manually to ensure production-grade security.”

Your Roadmap to Modern Ingress

The questions we received from over 40 companies confirm that the community is ready for a more robust and role-oriented way to handle traffic. The retirement of Ingress NGINX is not just a challenge to overcome. It is an opportunity to build a more secure and scalable platform for the future.

Many of you asked whether migration can be incremental. The answer is a resounding yes. In our upcoming migration guide, we will walk through the exact steps, manifests, and traffic-shifting strategies needed to move safely and confidently from NGINX Ingress to Gateway API using Calico Ingress Gateway.

Coming next: A step-by-step NGINX controller migration guide

In the guide, learn how to:

Enable Calico Ingress Gateway and Gateway API
Map NGINX annotations to HTTPRoute resources
Run NGINX Ingress and Gateway API side by side
Configure TLS, redirects, rewrites, and header manipulation
Perform canary traffic shifts, validation, and safe cutover
Troubleshoot common migration issues

See the Migration in Action

With the March 2026 NGINX retirement deadline approaching, don’t wait to modernize your stack. Watch our on-demand workshop to see a step-by-step demonstration of migrating traffic from Ingress NGINX to Calico Ingress Gateway in a production environment.

Watch the Workshop →

Request a Demo →

Prefer the technical docs? Get a sneak peek of the upcoming migration guide here.

The post Calico Ingress Gateway: Key FAQs Before Migrating from NGINX Ingress Controller appeared first on Tigera - Creator of Calico.