Istio configures gRPC directly through xDS

A common control-plane protocol lets Istio configure a data plane other than Envoy. Its experimental proxyless gRPC integration uses the gRPC library's xDS support for discovery and selected traffic policies. Requests can travel directly between application libraries while an agent still maintains their control-plane connection.

The 28 October introduction describes support added in Istio 1.11. It includes basic discovery, selected VirtualService and DestinationRule behavior, and explicit mutual TLS. The implementation remains experimental and does not offer every capability of an Envoy sidecar.

I find this interesting because Istio's value lies partly in common configuration and workload identity. Those functions need not require Envoy to handle every request if an application library can implement the necessary protocol. The tradeoff moves some responsibilities into the application's dependency and startup model.

xDS describes configuration beyond one proxy

The gRPC global-load-balancing proposal explains the underlying direction. gRPC adopts xDS as a configuration protocol in place of its earlier look-aside balancing protocol, with capabilities added incrementally.

Its discovery flow starts with a listener resource and follows route, cluster, and endpoint configuration. These resource names originated in the proxy model, but a gRPC implementation can use their relevant information to configure its own channel and balancing behavior.

The proposal describes a bootstrap file locating the management server and identifying the client. It also describes the xds URI scheme that selects the resolver. A service address using that scheme asks gRPC to obtain configuration through xDS.

Common protocol support does not imply identical behavior across consumers. The proposal itself discusses differences between gRPC and Envoy. Istio's introduction likewise warns that a configuration can have missing or different behavior in the gRPC implementation.

Proxyless still includes an agent

Istio's agent generates bootstrap configuration describing how gRPC should reach istiod, where certificates are located, and which metadata to send. It then acts as an xDS proxy, authenticating to istiod on the application's behalf.

The agent also fetches and rotates certificates used for data-plane traffic. Removing Envoy from that traffic path does not remove the credential lifecycle or the need to establish an authenticated configuration connection.

This makes the deployment more precise than the word proxyless alone suggests. The application library handles data traffic directly, while the injected agent remains a supporting process. Resource use and failure behavior need to include both the library and the agent.

The introduction's resource comparison explicitly excludes additional gRPC resource use inside the application container. Its agent measurements therefore cannot be treated as a complete comparison of total workload cost. That limitation belongs beside any interpretation of the reported savings.

The application opts into xDS

For Go, the introduction requires gRPC 1.39.0 or newer and an import registering xDS resolvers and balancers. Client connection targets use the xds:/// scheme. TLS support also needs the specified xDS transport credentials.

Server integration requires the xDS-aware server constructor and compatible generated registration code. A server that only uses the ordinary constructor has not acquired every server-side configuration feature merely because its client knows the resolver.

The Pod selects the agent injection template with an annotation. The introduction also recommends holding application startup until the agent is ready for gRPC servers:

metadata:
  annotations:
    inject.istio.io/templates: grpc-agent
    proxy.istio.io/config: '{"holdApplicationUntilProxyStarts": true}'

This is a Pod metadata fragment for an injection-enabled deployment. It assumes the application has already made the necessary gRPC changes. An annotation cannot register the resolver or replace the server constructor inside the binary.

The credential examples also include fallback credentials for cases where istiod supplies no security configuration. That fallback is part of the connection behavior and needs to agree with the intended policy. A working resolver alone does not establish that mTLS was selected, because discovery and transport credentials enter the setup through different APIs. The introduction demonstrates enabling security on the client and server separately.

The startup dependency is real. Calling the server or creating an xDS channel before the bootstrap file and agent proxy are ready can fail. The hold setting is one documented way to coordinate those components.

Supported policy is narrower than Envoy's

DestinationRule subsets can select groups of instances by labels. Round-robin is the supported Istio load-balancing policy in this integration. The introduction distinguishes that Istio limitation from consistent hashing support already present in gRPC.

VirtualService support includes header matching and RPC path matching in the form /ServiceName/RPCName. It also supports changing the destination host or subset and weighted traffic shifting.

The introduction lists faults, retries, timeouts, mirroring, and rewrite rules as possible future work. Those should not be assumed to work because a familiar Istio resource accepts their fields.

This affects how a mixed data plane is interpreted. The same resource can describe a policy that an Envoy proxy supports while the proxyless library implements only part of it. Configuration validity and consumer support remain separate questions.

Mutual TLS must be explicit on both sides

The initial integration does not support automatic mTLS detection or permissive mode. The client uses DestinationRule ISTIO_MUTUAL, and the server uses PeerAuthentication STRICT. Other modes outside the supported choices can be treated as disabled, according to the introduction.

That limitation is more consequential than a missing balancing option. A user expecting permissive negotiation could obtain a different security posture. The configuration needs to select the supported modes explicitly.

Health checks also need attention when the xDS-enabled server requires mTLS. The introduction recommends a separate port or a health-check client that can obtain the required certificates. A plaintext probe cannot be assumed to work against the protected listener.

My judgement is that direct gRPC participation is useful where the supported policy set matches the application. It removes a data-plane hop while preserving control-plane configuration and certificate management. The cost is explicit application integration and a narrower, version-dependent set of mesh behaviors.

The concrete boundary is therefore the gRPC implementation receiving xDS, not the YAML resource alone. The agent supplies bootstrap and credentials, while the library must implement each requested traffic or security behavior for that application.