K8S Envoy Gateway Series Overview: A More Modern Traffic Ingress Than Ingress

If you've worked with Kubernetes external traffic before, chances are you started with Ingress. It works, and for many scenarios it's genuinely sufficient. But once you hit more complex requirements — multiple listeners, multi-team ownership, gRPC, TCP, TLS passthrough, fine-grained traffic policies — you inevitably end up in a situation where "keep it alive with annotations" becomes the norm. The YAML starts looking like an incantation, and the people maintaining it feel like they're breaking a seal.

That's where Gateway API + Envoy Gateway comes in — it's the new kit. It doesn't make things more complicated; it cleanly separates the responsibilities that used to be tangled together, making ingress traffic, routing rules, TLS security settings, protocol types, and team ownership much easier to reason about.

What Is It, Exactly

Let's say it plainly in one sentence:

• Envoy Proxy: The data plane that actually receives traffic and forwards requests — also called a Gateway Proxy
• Envoy Gateway: The control plane that manages Envoy Proxy for you
• Gateway API: The standard interface you use in Kubernetes to declare traffic rules

Think of it this way:

• Gateway API is where you write the requirements
• Envoy Gateway is the manager who translates and delegates
• Envoy Proxy is the actual guard standing at the door

The benefit of this separation is that you don't need to hand-craft low-level Envoy config, nor do you need to memorize every private annotation from various controllers. You declare Kubernetes resources, and Envoy Gateway translates them into configuration that Envoy Proxy can actually execute.

Gateway vs Ingress: What's the Difference

The short answer: Ingress isn't obsolete, but Gateway API is better suited for medium-to-large systems that need more governance.

If your requirements are simply:

• A single website or simple API
• Basic path/host routing
• Small team

Then Ingress is still fine. But if your requirements start to include:

• One ingress serving multiple protocols
• Multiple listeners, domains, or certificates
• HTTP and gRPC coexisting
• Separating platform ingress from application route permissions
• Config that reads like a proper API, not an annotation wishlist

Then Gateway API will start to look very appealing.

Why Not Just Use Ingress

The official Gateway API goal is to address several common pain points with Ingress at scale:

• Better expressiveness: Routing, TLS, traffic policies, and protocol types are more clearly defined
• Better portability: Less reliance on controller-specific private annotations
• More natural role separation: Platform teams own ingress, app teams own routes

For example, Ingress configs often look like this:

metadata:
  annotations:
    some.ingress.controller/rewrite-target: /
    some.ingress.controller/auth-type: basic
    some.ingress.controller/ssl-redirect: "true"

Not that it doesn't work — but as requirements grow, annotations easily become mysterious YAML black magic. Gateway API pulls these needs into proper fields. It reads like "configuration," not a "wishlist."

The Layered Structure

The official concept page breaks Envoy Gateway into three layers — worth memorizing as a mental map:

• User Configuration: The Gateway API resources and Envoy Gateway extension CRDs you write
• Envoy Gateway Controller: Reads these resources, translates them into executable config
• Envoy Proxy: The data plane that actually handles live traffic

In practice, you'll spend most of your time modifying the "declarative layer," not SSH-ing into proxy instances to tweak low-level config. This is the elegance of being Kubernetes-native.

What You'll Learn in This Series

This series follows a "build it first, then go deeper" order — 10 posts including this overview:

1. Quick Start: Install Envoy Gateway and run your first HTTP request end-to-end
2. Core Concepts: Understand GatewayClass, Gateway, Listener, and Envoy Proxy
3. HTTP Routing in Practice: Deep dive into HTTPRoute — host, path, header, filter, timeout
4. TLS and Security: Set up HTTPS, understand certificateRefs, TLS termination, and TLSRoute
5. Best Practices: Key habits before going to production
6. Route Type Cheatsheet: Quickly decide between HTTPRoute, GRPCRoute, TCPRoute, and TLSRoute
7. Listener Design Guide: Multi-port, multi-hostname, multi-ingress design patterns
8. Multi-Namespace and Team Ownership: Master allowedRoutes, ReferenceGrant, and shared ingress governance
9. Status and Debugging Handbook: Read Accepted, ResolvedRefs, Programmed, and follow the shortest troubleshooting path

If you just want to feel what Envoy Gateway is like, go straight to the next post. Getting it running beats memorizing every term first — just like going to the gym, actually showing up beats watching 30 YouTube videos first.

Core Resources You'll Encounter

Beginners often stumble because they assume Gateway API only has Gateway and HTTPRoute. It's actually a whole family of resources.

GatewayClass

Defines "which Gateway implementation to use in this cluster." For Envoy Gateway, the key is getting controllerName to point to the right controller.

Gateway

Defines "what the ingress looks like." For example: which ports to open, which protocols to listen on, how TLS is attached, which routes are allowed.

Listener

Listener is one of the most important units inside a Gateway. Think of it as an outward-facing slot on the Gateway — each slot defines:

• port
• protocol
• hostname
• TLS config
• allowedRoutes

Many people think of Gateway as a black box, but what actually determines ingress behavior is each individual listener inside it.

The Route Family

• HTTPRoute: HTTP/HTTPS traffic — the most common
• GRPCRoute: gRPC traffic — can match on service/method
• TCPRoute: Raw TCP traffic — doesn't parse HTTP semantics
• TLSRoute: Routes based on TLS SNI — common for TLS passthrough

What all routes share: They don't "open the door" — they decide "how to route traffic after it enters."

Minimal Mental Model

Keep this map in your head:

GatewayClass  # Which Gateway implementation to use in this cluster
Gateway       # Which listeners this ingress opens
Listener      # A port / protocol / hostname / TLS slot
Route         # How to distribute traffic once it enters
Service       # The backend actually serving requests in the cluster
Envoy Proxy   # The data plane that ultimately handles the traffic

A minimal example looks like this:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: demo
spec:
  parentRefs:
    - name: eg
  hostnames:
    - "www.example.com"
  rules:
    - backendRefs:
        - name: backend
          port: 3000

You don't need to memorize every field now. Just understand what it's doing:

• parentRefs: Which Gateway this rule attaches to
• hostnames: Which domain should match this rule
• backendRefs: Which Service to send traffic to

At a Glance: When to Use Which Route

This decision matrix is very practical. Before writing YAML, ask yourself:

"Am I dealing with HTTP, gRPC, or raw TCP/TLS traffic?"

One-Line Summary

Envoy Gateway isn't just another term you have to memorize — it's a way to elevate Kubernetes external traffic from "good enough" to "something that resembles an engineering system."

💡 If this is your first time with this stack, don't try to learn every CRD at once. Install it, get your first request through, then revisit the concepts — the absorption rate is much faster that way.

Next Step

Next post, we get hands-on — install Envoy Gateway in your cluster and run your first Gateway + HTTPRoute: 👉 Quick Start