Ambient waypoints move traffic policy to the destination

A service can own its routing policy while relying on every caller's proxy to enforce it. In Istio's sidecar model, traffic shaping generally happens at the source proxy, while security policies generally apply at the destination proxy. That distributes one service's intended behaviour across many consumers. A destination change can consequently require updates to proxies elsewhere in the mesh.

The March 31 waypoint design explanation moves that work toward the destination. Ambient waypoints handle Layer 7 processing for their managed workloads, with namespace scope by default or service-account scope as another option. The destination's waypoint enforces its policies, so it needs configuration for that destination scope instead of learning every other service's configuration.

I regard Istio's operating cost as justified only when the fleet needs what the mesh provides. Reducing configuration distribution is relevant to that judgement. A policy model that keeps service-specific configuration with the service's proxy can make both ownership and diagnosis more direct.

Ambient separates transport from Layer 7 processing

The original ambient architecture introduction splits the data plane into a secure overlay and an optional Layer 7 processing layer. A per-node ztunnel supplies secure transport and identity-related functions without parsing HTTP. Envoy-based waypoint proxies provide the additional application-protocol processing where it is required.

This differs from assigning every application pod its own full-featured proxy. A waypoint runs outside the application pod and can be installed, upgraded, or scaled independently. The March article presents its revised configuration model as work following the initial 2022 preview. It remains an ambient alpha design at this date.

The separation has an ownership consequence. Shared transport machinery does not need the full set of HTTP policy rules for every tenant. Layer 7 processing can instead run in proxies associated with a namespace or service account. The original introduction identifies concerns about sharing complex Envoy processing across unconstrained tenants as one reason for that division.

Destination ownership changes configuration distribution

The March article names several problems with source-side traffic policy. Each caller's sidecar needs information about destinations. A destination update then has to reach those callers. Policy debugging is split between source and destination proxies, and clients outside the mesh may not apply source-side routing behaviour at all.

Putting policy at the destination waypoint changes that relationship. A service's incoming traffic goes through the waypoint responsible for its scope. Routing and security decisions can therefore be inspected at the same destination-oriented component. The article describes the waypoint as a gateway into its namespace or service-account scope.

This also aligns policy ownership with proxy work. A namespace's configuration primarily affects processing performed by a proxy for that namespace. In the source-side arrangement, a policy written for a service can be distributed to many callers' proxies. The source notes that Istio secures that arrangement, while arguing that the ownership attribution remains less direct.

The distinction is particularly useful for traffic splitting. A service producer can define a canary split, but a client outside the mesh has no source sidecar to enforce it. Destination-oriented processing gives the service a place to apply the policy on incoming traffic instead of depending on a policy-aware proxy at every source.

A declarative Gateway creates the waypoint

The March design uses Kubernetes Gateway resources to deploy waypoints. Its generated example has the following form.

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: namespace
spec:
  gatewayClassName: istio-waypoint
  listeners:
    - name: mesh
      port: 15008
      protocol: HBONE

Istiod watches the resource and manages the corresponding waypoint deployment. The class selects the waypoint role, while the listener identifies HBONE, the tunnelling protocol used between ambient components. This is the API shown for the March alpha. It should be read in that version context rather than replaced with fields from a later waypoint design.

The source describes terminating an incoming HBONE connection and forwarding it to an internal Envoy listener for policy enforcement. Internal listeners accept user-space connections without using the system network API. That provides a processing stage inside the proxy after tunnel termination, where workload policy can be evaluated.

The example is useful because it shows the difference between defining policy processing and embedding a proxy in the application pod. The managed Gateway establishes a separately deployed component. Its lifecycle can follow the policy-processing need without requiring the application pod itself to contain that component.

Configuration counts illustrate a narrower claim

The authors compare a small sidecar deployment with namespace-scoped waypoints and then expand the example. Their larger calculation uses two namespaces with twenty-five deployments and ten pods per deployment. Two waypoint replicas per namespace need one hundred distributed configuration units in their model, compared with twelve thousand five hundred for sidecars.

That calculation illustrates configuration fan-out under the example's assumptions. It is not a measured latency result or a universal resource-reduction percentage. The article also notes that careful use of exportTo and the Sidecar API can reduce sidecar configuration. Ambient changes the default distribution model so those particular scoping declarations are not needed for the illustrated result.

I find the reduction in required configuration knowledge more persuasive than applying the example's percentage to every cluster. A proxy serving one destination scope has a clear reason to omit unrelated routes and endpoints. The article's configuration dumps show that omission for its reviews service-account waypoint.

Consumer-owned egress policy remains unresolved work

Destination ownership is less straightforward when the destination is external and outside the operator's control. A caller may still need a timeout or resilience policy for such a service. The March article explicitly identifies routing to an egress gateway and configuring its policies as active design work.

That qualification defines the proposal's current limit. Moving producer-owned policy to a waypoint simplifies the common case described by the authors, but it does not answer every consumer-owned policy requirement. At this date, the destination-oriented alpha provides a concrete configuration model for managed workloads while egress behaviour remains under development.

The resulting diagnostic question is specific. For an incoming service policy, the destination waypoint is the component whose routes and clusters explain enforcement. For a policy on an unmanaged external destination, the article does not yet provide an equivalent completed egress design.