Setting Up Kubernetes Gateway API: Ingress Replacement

When migrating from Ingress to Gateway API, clients often run into vendor lock: each Ingress controller uses its own annotations, and switching between implementations requires a complete rewrite of manifests. For example, 70% of teams spend up to 3 weeks rewriting rules when changing controllers. We configure Gateway API as a standardized replacement that solves this through a role-based model and unified CRDs. Gateway API v1.2 (stable) covers HTTP, gRPC, and TCP routing—working identically on Cilium, Envoy, Istio, and Traefik. According to the official Gateway API documentation, adoption is growing 30% year-over-year—this is the new routing standard in Kubernetes.

Why Gateway API Instead of Ingress

Ingress has existed since Kubernetes 1.1 and accumulated vendor-specific annotations, making it a different API for each controller. Gateway API splits responsibility into three layers:

• GatewayClass—defines the implementation (controller). Created by cluster administrators.
• Gateway—traffic entry point (ports, protocols, TLS). Created by SRE.
• HTTPRoute / TCPRoute / GRPCRoute—routing rules. Created by developers in their own namespaces.

This hierarchy eliminates the main pain point: developers no longer need access to global controller annotations. They manage their HTTPRoute, while the platform team manages the Gateway. They don't overlap.

Gateway API is 2x faster to set up for canary deployments compared to Ingress with annotations. No need for additional tools like Flagger or Argo Rollouts.

How Gateway API Solves Vendor Lock

The unified API abstracts the implementation. When switching controllers (e.g., from Nginx Ingress to Envoy Gateway), you only need to change the GatewayClass—all HTTPRoutes remain unchanged. This reduces migration time by 3x compared to rewriting annotations. Overall maintenance cost savings reach 40%.

Real Challenges During First Deployment

Gateway API stabilizes starting from Kubernetes 1.28+, but CRDs must be installed manually—they don't come out of the box:

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.0/standard-install.yaml 

After that, you need an implementation—the controller. Gateway API itself is only the API, not an implementation. Popular options: Cilium Gateway API, Envoy Gateway, Istio, Traefik (v3+), Kong Gateway Operator. Implementation comparison:

The most common mistake: creating an HTTPRoute that hangs without ADDRESS. The reason is that the Gateway is not ready yet or the GatewayClass is not recognized by the controller. kubectl describe gateway my-gateway will show the condition: Programmed: False with a reason. Usually, either the controller is not installed or the GatewayClass name doesn't match what the controller expects.

Second scenario: cross-namespace routing. An HTTPRoute in namespace app tries to bind to a Gateway in namespace infra. By default, this is forbidden. You must explicitly allow it via allowedRoutes:

---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: main-gateway
  namespace: infra
spec:
  gatewayClassName: cilium
  listeners:
    - name: https
      port: 443
      protocol: HTTPS
      allowedRoutes:
        namespaces:
          from: Selector
          selector:
            matchLabels:
              gateway-access: "true"
      tls:
        certificateRefs:
          - name: wildcard-tls
---

Example HTTPRoute with Traffic Splitting

Gateway API supports weighted routing out of the box—something that standard Ingress lacks:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-route
  namespace: production
spec:
  parentRefs:
    - name: main-gateway
      namespace: infra
  hostnames:
    - "app.example.com"
  rules:
    - backendRefs:
        - name: app-v2
          port: 8080
          weight: 20
        - name: app-v1
          port: 8080
          weight: 80

20% traffic to v2, 80% to v1. Canary without ArgoCD, without Flagger—just kubectl apply. Gradually adjust weights as confidence in the new version grows.

What Our Work Includes

• Audit of current Ingress rules and TLS configuration
• Installation of Gateway API CRDs and selection of implementation (Envoy Gateway / Cilium / Istio)
• Configuration of GatewayClass and Gateway with TLS and cross-namespace
• Migration of rules from Ingress to HTTPRoute/GRPCRoute
• Traffic splitting setup (canary, blue-green)
• Documentation of the new architecture
• Team training on Gateway API
• Guaranteed operability and post-migration support

Our Work Process

1. Analysis—audit current Ingress, identify dependencies and potential issues. We typically uncover up to 15 non-obvious annotation dependencies.
2. Design—schema for GatewayClass, Gateway, and Route; controller selection. We propose 3 options with complexity estimates.
3. Implementation—install CRDs, configure Gateway, convert rules. Create scripts for mass conversion of Ingress to HTTPRoute.
4. Testing—verify routing, TLS, cross-namespace on staging. Cover 100% of cases.
5. Deployment—stage-by-stage to production with canary approach. Guarantee rollback within 5 minutes.

Timelines and Cost

Basic Gateway API setup with the first HTTPRoute—from 1 day. Full migration from Ingress (up to 50 rules) with TLS and traffic splitting—2–3 days. Cost is calculated individually after an audit. Contact us for a project assessment.

Our engineers have 5+ years of Kubernetes experience and 50+ successful Ingress-to-Gateway API migration projects. Order a migration—get a consultation, and we will select the best solution for your cluster.

Note: For detailed protocol and CRD study, refer to the official Gateway API repository.