Sophroid

Sophroid is a home brewed xDS control plane for the WMF service mesh, written in Go. It acts as the dynamic configuration server for Envoy proxies running as sidecars in Kubernetes pods. It offers a single point service interface for the service mesh managing service-to-service communication over gRPC.

In introducing a control plane to the service mesh, our goal is to eventually bypass the load balancers internally between applications, utilizing them exclusively in edge-to-service interface requests.

Currently, Envoys in production are configured statically through a Kubernetes ConfigMap. We'd like to eventually replace the static configuration with a dynamic resource pointing Envoys to Sophroid, and through which Envoys in production can subscribe to discovery resources (currently cluster & listener (CDS, LDS), but eventually also route and endpoint (RDS, EDS) resources from an xDS server.

Deployment

Sophroid is deployed as a Kubernetes service via the sophroid helm chart. As of April 2026, It is deployed in the aux-k8s cluster and pooled in eqiad only as active/passive service. It is directly behind LVS.

Configuration pipeline

Resources (clusters & listeners as of Jun 2026) are configured through puppet onto the deployment host and then mounted onto Sophroid through a ConfigMap. Sophroid reads the ConfigMap containing the service catalog, cluster and listener definitions passing resources through a go template to generate envoy configuration. The templated configuration is read through Sophroids config processor to generate a cached snapshot of resources which envoys can request at startup and subscribe to through an xDS service serving resources through grpc.

Future work

Data flow & format

As of currently, Sophroid reads configuration resources from puppet by way of ConfigMap written directly onto the deployment host. We'd like to eventually replace the puppet provisioned resources and read directly from etcd.

In doing so, we would need to define a data format to be read from etcd and consider possible opportunities to learn from existing patterns at WMF (e.g, conftool-data statically describes an object in etcd, which is modified by tooling to reflect dynamic state).

On the control plane side, we'd want to update the data flow to reflect the new data format, consider what happens when we read the current data in etcd at startup time, and what’s triggered when the etcd watcher notices a change.

Managing multiple envoy configurations

Sophroid is currently processing and managing a single envoy config. We'd also like to consider what managing multiple envoys configurations might look like.

Failure modes

TODO: brainstorm real-world situations we want the combined Envoy-Sophroid system to be resilient to, and plan out how we’ll prepare for those situations