Improve prose: active voice, conciseness, remove clichés

- Replace passive voice with active constructions
- Trim wordiness throughout
- Remove "not just about" and "more than X—it's Y" patterns
- Replace em dashes with parentheses

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Author: dirien

content/blog/ingress-nginx-to-gateway-api-kgateway/index.md

@@ -18,19 +18,19 @@ social:
     linkedin:
 ---
 
-The upcoming retirement of **ingress-nginx** in early 2026 presents infrastructure teams with a deadline, but also a rare opportunity to rethink traffic management. For years, the standard approach involved stringing together annotations to force a controller to behave. The Gateway API offers a cleaner, standardized alternative. This post investigates the practical reality of this migration and explores why **kgateway** emerges as a robust solution for the future.
+The upcoming retirement of **ingress-nginx** in early 2026 gives infrastructure teams both a deadline and an opportunity to rethink traffic management. For years, the standard approach involved stringing together annotations to force a controller to behave. The Gateway API offers a cleaner, standardized alternative. This post investigates the practical reality of this migration and explores why **kgateway** emerges as a robust solution for the future.
 
 <!--more-->
 
-With **ingress-nginx** entering its sunset phase in early 2026, the Kubernetes community faces a decision point. While the controller served as the default standard for a decade, its architecture now struggles to meet modern requirements. The transition to the Gateway API represents more than a forced migration; it offers a chance to adopt a standard designed for the complexity of contemporary traffic patterns.
+With **ingress-nginx** entering its sunset phase in early 2026, the Kubernetes community faces a decision point. While the controller served as the default standard for a decade, its architecture now struggles to meet modern requirements. The transition to the Gateway API offers a chance to adopt a standard designed for contemporary traffic patterns.
 
 The Ingress API relied heavily on controller-specific annotations, creating a fragmented ecosystem where configurations were rarely portable. The Gateway API addresses this by establishing a standardized, expressive approach that behaves consistently across implementations. A technical evaluation of the available options points to **kgateway** as a particularly strong candidate for production workloads.
 
 ## Why ingress-nginx is retiring
 
 The Kubernetes SIG Network and Security Response Committee was direct in its [announcement regarding the project's future](https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/). After March 2026, **ingress-nginx** will cease to receive releases, bug fixes, or security patches. The repositories will become read-only, leaving existing deployments functional but unmaintained.
 
-This decision stems from both resource constraints and technical debt. The project relied on a very small group of maintainers working primarily in their spare time. Furthermore, features that once provided flexibility, such as "snippets" for arbitrary NGINX configuration injection, are now recognized as significant security liabilities. With no viable path to modernization within the existing codebase, retirement became the necessary conclusion.
+This decision stems from both resource constraints and technical debt. The project relied on a very small group of maintainers working primarily in their spare time. Furthermore, features that once provided flexibility, such as "snippets" for arbitrary NGINX configuration injection, now pose significant security liabilities. With no path to modernize the codebase, retirement was inevitable.
 
 It is worth noting that the Ingress API itself remains supported. The retirement affects only the **ingress-nginx** controller. NGINX as a web server continues unchanged. However, clusters relying on this specific controller must prepare for a transition.
 
@@ -42,9 +42,9 @@ kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-ngin
 
 ## Understanding the Gateway API
 
-The Gateway API represents a fundamental shift in traffic management concepts. While some elements may look familiar to those used to Ingress, the underlying philosophy addresses the "baggage" that the previous standard accumulated.
+The Gateway API represents a fundamental shift in traffic management concepts. Some elements will look familiar to Ingress users, but the underlying philosophy addresses the "baggage" that the previous standard accumulated.
 
-The core improvement lies in expressiveness. Advanced routing requirements—header matching, weighted traffic splitting, and traffic policies—are now native parts of the specification. This eliminates the need for the non-portable annotations that plagued the Ingress ecosystem.
+The core improvement lies in expressiveness. Advanced routing requirements (header matching, weighted traffic splitting, and traffic policies) are now native parts of the specification. This eliminates the need for the non-portable annotations that plagued the Ingress ecosystem.
 
 The API also introduces a role-oriented structure that mirrors actual organizational workflows.
 
@@ -129,13 +129,13 @@ spec:
       kind: Service
 ```
 
-This mechanism allows platform teams to strictly control which namespaces are authorized to attach to shared gateways.
+This mechanism allows platform teams to strictly control which namespaces can attach to shared gateways.
 
 ## Evaluating Gateway API implementations
 
 Several implementations have emerged to support the new standard, each with a distinct philosophy.
 
-**NGINX Gateway Fabric** leverages NGINX as the data plane, offering continuity for teams already deep in the F5 ecosystem. It provides impressive throughput and integrates with enterprise security tools, making it a logical choice for existing NGINX shops.
+**NGINX Gateway Fabric** leverages NGINX as the data plane, offering continuity for teams in the F5 ecosystem. It provides impressive throughput and integrates with enterprise security tools, making it a logical choice for existing NGINX shops.
 
 **Traefik** focuses on simplicity. As a single binary with no external dependencies, it aligns well with environments that prioritize developer experience and rapid iteration. Its declarative configuration is particularly friendly to GitOps workflows.
 
@@ -161,23 +161,23 @@ Several implementations have emerged to support the new standard, each with a di
 * **Envoy Gateway** works for those valuing community governance and strict standards adherence.
 * **kgateway** is the choice for enterprise scale, native AI gateway needs, and Istio integration.
 
-For this exploration, **kgateway** was selected due to its proven track record and its native handling of both traditional microservices and AI traffic.
+This exploration uses **kgateway** for its proven track record and native handling of both traditional microservices and AI traffic.
 
 ## Migrating from Ingress to Gateway API
 
-The [official migration guide](https://gateway-api.sigs.k8s.io/guides/getting-started/migrating-from-ingress/) outlines the transition process. It is less about a direct translation and more about restructuring intent.
+The [official migration guide](https://gateway-api.sigs.k8s.io/guides/getting-started/migrating-from-ingress/) outlines the transition process. It's less translation, more restructuring.
 
 The process typically involves:
 
 1. **Defining a Gateway resource:** Unlike Ingress, listeners must be explicitly defined. This provides granular control over ports and protocols.
-1. **Creating HTTPRoute resources:** These replace Ingress routing rules. Complex Ingress resources can be split into multiple HTTPRoutes for better management.
+1. **Creating HTTPRoute resources:** These replace Ingress routing rules. You can split complex Ingress resources into multiple HTTPRoutes for better management.
 1. **Configuring filters:** Annotations for headers or redirects are replaced by standardized filters within the HTTPRoute spec.
 
 The **[ingress2gateway](https://github.com/kubernetes-sigs/ingress2gateway)** tool can automate much of the initial conversion, providing a baseline of resources to review and refine.
 
 ### Migration planning
 
-A successful migration requires scoping the effort:
+Scope the migration effort first:
 
 **1. Assessment**
 Identify the volume and complexity of existing resources.
@@ -198,7 +198,7 @@ Keeping the original Ingress manifests ensures that traffic can be quickly rever
 
 ## Why kgateway stands out
 
-**kgateway** distinguishes itself through its maturity and architectural decisions. Having started as Gloo Gateway in 2018, it has undergone years of hardening in production environments.
+**kgateway** distinguishes itself through its maturity and architectural decisions. Having started as Gloo Gateway in 2018, it has hardened through years of production use.
 
 Its control plane uses the krt framework, originally developed for Istio. This allows it to track dependencies precisely and recalculate only the parts of the configuration that have changed. In large clusters where pods churn constantly, this incremental approach prevents the control plane from becoming a bottleneck, enabling it to [handle over 10,000 routes](https://kgateway.dev/blog/design-kgateway-for-scalability/) efficiently.
 
@@ -466,15 +466,15 @@ For organizations that cannot immediately migrate to the Gateway API, there is a
 
 This fork is not about adding new features. Chainguard is explicit that they are maintaining stability, not continuing development. Their commitment includes keeping dependencies updated, addressing CVEs on a best-efforts basis, and providing commercial container images with low vulnerability counts and SLAs. FIPS-compliant versions are also available for regulated environments.
 
-The [chainguard-forks/ingress-nginx](https://github.com/chainguard-forks/ingress-nginx) repository on GitHub provides the maintained codebase. For teams running `ingress-nginx` in production, this fork offers a viable bridge while evaluating the Gateway API or other alternatives. However, this should be viewed as buying time rather than a permanent solution. The architectural limitations of the Ingress API remain, and the eventual move to a more expressive standard like the Gateway API is still the recommended path forward.
+The [chainguard-forks/ingress-nginx](https://github.com/chainguard-forks/ingress-nginx) repository on GitHub provides the maintained codebase. For teams running `ingress-nginx` in production, this fork offers a viable bridge while evaluating the Gateway API or other alternatives. However, this buys time rather than solving the problem permanently. The architectural limitations of the Ingress API remain, and the eventual move to a more expressive standard like the Gateway API is still the recommended path forward.
 
 ## Looking ahead
 
 The retirement of **ingress-nginx** marks the end of an era and the beginning of a more structured approach to Kubernetes networking. The Gateway API offers a robust framework that reflects how teams actually build and secure applications today.
 
 While March 2026 provides a comfortable runway, early planning prevents rushed decisions. Setting up a test environment with **kgateway** to validate the new API constructs is a prudent next step.
 
-The shift to the Gateway API is not just about keeping the lights on; it is about building a networking foundation ready for the next decade of infrastructure challenges.
+Moving to the Gateway API means building a networking foundation ready for the next decade of infrastructure challenges.
 
 {{< get-started >}}