How Service Mesh Discovers Services: ASM Config Push & Selective Discovery

Background and Motivation

Alibaba Cloud Service Mesh (ASM) is the first fully managed, Istio‑compatible service mesh on Alibaba Cloud. Its control plane runs on the cloud while the data plane (Sidecars) runs inside user Kubernetes clusters. By decoupling control‑plane lifecycle from the clusters, ASM improves flexibility and scalability.

Service Mesh Basics

A service mesh uses the Sidecar pattern to simplify service governance. The control plane (Istiod) translates high‑level resources such as VirtualService and DestinationRule into concrete Envoy configurations and pushes them to each Sidecar’s cluster list.

In Envoy, a cluster represents a set of upstream hosts. Even without any user configuration, Envoy automatically discovers services in the Kubernetes cluster and populates clusters for them.

Experiment Setup

We deployed ASM on an ACK cluster, created two namespaces ( default and test), and enabled automatic Sidecar injection only for default. The default namespace therefore contains “mesh‑in” services, while test hosts “mesh‑out” services.

Deployed the following services: sleep (a simple curl container) in

default

httpbin

in default (optional) bookinfo in test Commands used:

kubectl apply -f sleep.yaml

kubectl apply -f bookinfo.yaml -n test

Viewing Sidecar Cluster Configuration

ASM provides a tool asmctl (compatible with istioctl) to inspect Sidecar configs. Example command:

$ asmctl proxy-config cluster sleep-557747455f-g4lcs

The output lists clusters for services both inside and outside the mesh, such as productpage.test.svc.cluster.local even though bookinfo has no Sidecar.

Why Mesh‑Out Services Appear

Istio does not perform its own service discovery. It relies on the underlying platform (Kubernetes, Consul, etc.) to populate a service registry, which is then translated into Envoy clusters. Consequently, every Pod IP in the cluster is recorded, regardless of Sidecar injection.

VirtualService Example

A VirtualService can rewrite a URI and route traffic to a mesh‑out service:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  namespace: test
  name: test-vs
spec:
  hosts:
  - productpage.test.svc.cluster.local
  http:
  - match:
    - uri:
        prefix: /test/
    rewrite:
      uri: /
    route:
    - destination:
        host: productpage.test.svc.cluster.local
        port:
          number: 9080

After applying, a request to /test/productpage is correctly rewritten and reaches the productpage service.

Implications

The distinction between “mesh‑in” and “mesh‑out” is solely based on Sidecar injection; the control plane still watches all services in the cluster. In large clusters with only a few mesh‑enabled workloads, this creates unnecessary load on the control plane and excessive configuration pushes to Sidecars.

Optimization: Selective Service Discovery

Istio 1.10+ introduced a “discovery selector” to limit which namespaces the control plane watches. ASM offers the same feature via its console.

Steps to enable selective discovery:

Label the mesh‑in namespace, e.g. kubectl label namespace default in-mesh=yes.

In the ASM console, navigate to “Configuration Push Optimization → Selective Service Discovery”.

Add a label selector matching the label added above.

After applying the selector, the control plane stops watching services in other namespaces, reducing its workload.

Result After Optimization

Running the same asmctl proxy-config cluster command for the sleep Sidecar now shows a trimmed list containing only clusters relevant to the default namespace (e.g., httpbin, sleep, Kubernetes API). The previously listed bookinfo clusters disappear.

Conclusion

Service mesh does not implement its own discovery; it mirrors the platform’s service registry. While this simplifies integration, it can overload the control plane in mixed‑usage clusters. Enabling selective service discovery narrows the watch scope, cuts down configuration push traffic, and improves overall mesh performance.