Insights | ape factory

Linkerd Gateway API: Ingress vs Mesh Policy Reality

Written by Team | Jul 20, 2026 9:14:59 AM

If you try to use Linkerd as a traditional edge ingress controller, your deployment will fail immediately.

Unlike Istio, Envoy Gateway, or Cilium, Linkerd does not ship with an ingress proxy controller. There is no linkerd-ingressgateway pod. There is no Linkerd-managed cloud load balancer. If you create a Gateway API Gateway resource targeting Linkerd expecting a public IP to provision, nothing happens.

Linkerd’s core philosophy is fundamental minimalism: do one thing (east-west microservice sidecar/mesh routing) with ultra-low latency and zero proxy bloat using its native Rust micro-proxy (linkerd2-proxy).

Yet, Linkerd relies heavily on the Kubernetes Gateway API (HTTPRoute, GRPCRoute) as its primary configuration model for mesh routing, retries, timeouts, and authorization policies.

If you don't understand how Linkerd separates L7 ingress proxies from in-mesh L7 policy routes, you will waste days trying to configure edge traffic on a service mesh that deliberately refuses to touch your edge.

Here is how Linkerd natively implements the Gateway API spec, how to pair it with an external ingress gateway, and how to configure L7 traffic policies without bloating your cluster.

The Architecture: Ingress vs. In-Mesh Gateway API

When using Gateway API with Linkerd, your cluster networking divides into two distinct operational layers:

  1. North-South (Ingress Gateway Domain): An external ingress controller (like Envoy Gateway or Traefik) processes public client traffic, handles TLS termination, and routes packets into the cluster.
  2. East-West (Linkerd Service Mesh Domain): Once traffic crosses the ingress boundary, Linkerd’s injected Rust proxy handles mTLS, circuit breaking, timeouts, and HTTPRoute policies pod-to-pod.

Linkerd doesn't replace your ingress proxy—it hooks directly into the pod-level data path via linkerd2-proxy to enforce Gateway API CRDs after traffic enters the cluster.

The Blueprint: Pairing Envoy Gateway with Linkerd L7 Routes

Here is the exact declarative pattern to run a production Envoy Gateway ingress layer that hands off traffic to a Linkerd-meshed microservice protected by HTTPRoute policies.

Decoupled Ingress Gateway (Envoy Gateway)

The edge gateway terminates external TLS and maps incoming paths to internal Kubernetes services:

In-Mesh Linkerd Gateway API Enforcement (Server + HTTPRoute)

Inside the payments namespace, Linkerd uses Gateway API resources combined with its policy CRDs to define service boundaries, request timeouts, and client authorization rules:

The Trap: The parentRefs Group Target Shift

If you attach a Gateway API HTTPRoute to a Gateway resource, Linkerd ignores it.

In standard ingress controllers, parentRefs points to kind: Gateway (in the gateway.networking.k8s.io group). But when configuring in-mesh policy rules for Linkerd, parentRefs must point directly to a Linkerd Server resource in the policy.linkerd.io group:

If your developers confuse these two target modes, your edge proxy will route traffic, but Linkerd will fail to enforce in-mesh timeouts, authorization policies, or retries.

The Verdict

Linkerd's refusal to ship a bloated Envoy-based ingress proxy is its greatest feature. By focusing strictly on microservice sidecar efficiency (adding under 30 MB memory and sub-millisecond overhead per pod), it lets you pick the best ingress controller for your edge while standardizing internal L7 routing on the Kubernetes Gateway API.

Use Linkerd when operational simplicity and proxy performance matter more than running a single monolithic control plane for both your edge and your mesh.

 

------


 
View full post