Load Balancing Container Ingress

From Disruption to Modernization: Streamlining Ingress NGINX to Avi Transition with Avi Conversion Tool (ACT)

The Kubernetes Project announced in November 2025 that the open-source Ingress NGINX controller is being retired, an announcement that immediately impacted platform engineering teams globally. As the deprecation deadline is this month (March 2026), crucial support, security patches, and critical bug fixes will cease suddenly.

The deadline is rapidly creating understandable anxiety among platform teams as they urgently seek a supported, viable alternative. This imminent migration, however, can be viewed as a strategic opportunity to reduce existing technical debt and adopt a modern Kubernetes solution that supports Gateway API out of the box as well as existing ingress APIs .

To achieve an architectural upgrade with VMware Avi Load Balancer (Avi), we are thrilled to introduce the latest Avi Conversion Tool (ACT) to automate the migration from Ingress NGINX to Avi, streamlining the transition to modern Kubernetes solution. Avi supports Kubernetes workloads including VMware Kubernetes Service (VKS), details are covered in this blog.

Why Does This Matter?

The transition from the original Kubernetes Ingress API to the Avi Kubernetes solution that supports Gateway API is a critical industry shift. The core problem with the outdated Ingress API was its inability to go beyond the most basic HTTP routing capabilities. To implement necessary enterprise functions like detailed rewrites, rate limiting, traffic splitting, or unique health checks, users were forced to rely heavily on non-standard, custom Ingress NGINX annotations. This resulted in widespread “annotation sprawl,” which made configurations brittle, overly dependent on a specific vendor, and exceptionally challenging to manage, audit, and troubleshoot.

The industry has addressed these shortcomings with the Gateway API, designed for standardization and expressiveness. Key advantages of the Gateway API include:

  • Role-Oriented Architecture: It enforces a clear separation of concerns, distinguishing between infrastructure management (handled by Platform Operators using GatewayClass/Gateway) and application routing (managed by Developers via HTTPRoute). This allows for native Kubernetes RBAC to govern specific resources.
  • Built-in Advanced Routing: Complex features like header matching, traffic weighting, and routing across different namespaces are core features of the API standard, eliminating the need for complex, messy annotations.

Future-Proofing: It natively supports L4 and L7 protocols (including HTTP, gRPC, TCP, and UDP), ensuring the infrastructure is prepared for the next generation of containerized applications.

The Enterprise Upgrade: Avi + VKS on VCF

For customers looking for an alternative, migrating to Avi isn’t just a tactical move; it’s a massive architectural upgrade and a step forward in visibility, security, and scale.

Avi elevates Kubernetes with enterprise-grade L4-L7 load balancing, a robust Web Application Firewall (WAF), and granular, per-transaction visibility. This deep analytics capability reduces guesswork when application performance suffers, allowing Avi to precisely pinpoint the source of latency, even down to the individual pod.

Avi seamlessly integrates with VMware Kubernetes Service (VKS) deployed on VMware Cloud Foundation (VCF), serving as the native ingress and load-balancing provider for VKS. This minimizes the need to bolt on a third-party proxy afterthought, providing a unified, centrally managed control plane. The data plane proxies also elastically scale to meet the needs of your growing Kubernetes clusters.

Automating the Transition: The ACT

The main obstacle to moving past NGINX is not selecting an alternative platform, but the overwhelming difficulty of manually converting countless intricate ingress applications. This manual translation process is prone to human errors, which can result in broken routing configurations and crippling production downtime. To smooth out this disruptive change, Avi just released the ACT.

The ACT fundamentally de-risks the migration process by automating the heavy lifting. Instead of reverse-engineering legacy manifests, the tool does the work for you:

  • Intelligent Parsing: ACT analyzes your existing Ingress NGINX configurations, intelligently reading through those notorious legacy annotations.
  • Automated Translation: It maps those legacy rules and translates them directly into standardized, modern Gateway API manifests and Avi-specific Custom Resource Definitions (CRDs).
  • Validation and Confidence: The tool doesn’t just spit out new YAML; it generates a comprehensive status report. This report acts as an audit trail, flagging exactly what was converted successfully and highlighting any highly customized edge cases that might need a quick manual review before deployment.

See the Conversion Tool in Action

We recorded a demo to show you exactly how the ACT parses complex ingress NGINX manifests and generates production-ready Gateway API resources in seconds. As you will see in the demo, the tool ingests existing YAML configuration files and annotations to create functional equivalents specifically formatted for AKO. By using this automated process, users can seamlessly provision virtual services, health monitors, and pools that are managed as part of a dynamic operator lifecycle within the Avi controller.

Ingress NGINX Replacement: 6 Key Questions to Ask 

With the impending migration deadline, you are likely evaluating several alternative migration paths. The following are a few key considerations to guide your decision-making to meet the sophisticated demands of enterprises running production Kubernetes at scale:

  1. Some vendors claim “zero-config drop-in”. Is this actually possible?
    No. Emulation of proxies is unreliable due to variations in how complex environments, edge cases, timeouts, and TLS are handled. The ACT automates the transition, mapping legacy configs cleanly to Avi’s software-defined architecture instead of relying on fragile emulation.

  2. Does emulating legacy annotations create technical debt?
    Using a new proxy to emulate a retired proxy’s annotations is architecturally sub-optimal. Avi offers a clean break with a one-time conversion, allowing you to move beyond legacy systems and use modern, scalable Avi configurations.

  3. I am worried about the long migration cycle and uncertainty?
    Vendors’ “drop-in” solutions exploit migration fears. Avi reduces this concern with an automated conversion tool that reduces the timeline from months of manual work to minutes, removing uncertainty.

  4. Can a simple proxy swap accurately translate complex WAF rules?
    No. A basic drop-in replacement is insufficient and poses significant security risks. The conversion tool is necessary to accurately map complex ModSecurity rules to Avi’s robust Web Application Firewall, ensuring security continuity.

  5. Is the “drop-in” approach really free? Are there any hidden costs?
    Unforeseen edge cases cause costly production failures. Avi prevents these through clean, upfront conversion and centralized visibility, ensuring predictable operational expenses and avoiding emergency troubleshooting.

  6. Are we just applying a band-aid or actually modernizing?
    Emulation is a temporary fix; Avi is the key to genuine, sustainable modernization. More than a migration tool, Avi upgrades your NGINX setup to an enterprise-level platform with centralized management and deep analytics. This shift guarantees superior performance, scalability, and security.

ACT Now

The retirement of Ingress NGINX doesn’t have to mean weeks of stressful, manual YAML translation for your platform team. By leveraging the ACT, you can confidently automate the transition, secure your container workloads with an enterprise-class proxy, and future-proof your architecture with the Gateway API.

Resources

Related Articles