How a Lightweight Service Mesh Can Streamline Gray‑Release in Cloud‑Native Environments

Preface

UCloud, a B2B public‑cloud provider, follows its CTO’s view that a development team must first ensure service stability before delivering easy‑to‑use, low‑cost products. Yet, to meet fast‑evolving customer scenarios, teams must also "embrace change".

Six Software Design Principles

1. Software exists to help others.

2. Reducing maintenance cost is more important than lowering development cost.

3. Change Law: The longer software lives, the more likely some part will need to change.

4. Defect Law: The likelihood of defects is proportional to the extent of modifications.

5. Simplicity Law: Maintenance difficulty is proportional to complexity.

6. Test Law: Understanding software behavior equals the amount of testing performed.

Gray Release as a Safety Net

Because user requirements evolve, software must be modified, which inevitably introduces defects. Even extensive testing cannot guarantee complete coverage, so the final safety net is gray (canary) release: using real user behavior as the ultimate test while limiting the change scope to reduce risk and enable rapid rollback.

Why Use Service Mesh for Gray Release

Service Mesh is an infrastructure layer that handles inter‑service communication, typically deployed as a set of lightweight sidecar proxies alongside application code. Compared with an API Gateway, which sits only at the traffic entry point and requires two full system deployments for full gray release, Service Mesh provides centralized control, simplifies implementation, lowers change cost, and speeds up product releases.

Why Choose a Lightweight Service Mesh

Although Service Mesh is promising, early implementations like Istio and Conduit were immature, creating a gap between expectation and reality. To adopt Service Mesh in 2017, UCloud needed a practical solution.

Readiness for Cloud Native

UCloud does not yet use Kubernetes; its IaaS control plane already offers similar functionality.

Transitioning to Service Mesh

UCloud has many existing services that must be integrated without heavy intrusion. Traditional K8s networking (IPTables) adds complexity, so a low‑intrusion approach is required.

Implementing a Lightweight Service Mesh

Istio consists of a data plane (Envoy sidecars) and a control plane (Pilot, Mixer, Istio‑Auth). For UCloud’s internal network, Mixer and Istio‑Auth can be omitted, keeping only Pilot for traffic management.

We extracted Pilot from Istio, removed K8s dependencies, and rebuilt it to run independently. Pilot’s design allowed easy integration with an ETCD platform to fetch service and instance information. After modifying main.go to retain Pilot’s model, proxy, and proxy/envoy modules while discarding other platforms, we obtained a fully standalone Pilot that still supports the Istio DSL.

To deploy sidecars without K8s, we use Docker‑Compose to simulate pods, managing service dependencies and generating per‑node configuration files. This approach supports HTTP/1.0, HTTP/2, and gRPC via explicit proxying rather than IPTables redirection.

Configuration rules:

If a service defines an Envoy proxy port, traffic is routed through Envoy to join the Service Mesh.

If an IP address and port are configured, the service is accessed directly.

If a domain name is configured without an Envoy proxy, ETCD gRPC naming and discovery automatically locate the remote service.

Conclusion

Through a series of design refinements, UCloud built a lightweight Service Mesh that optimizes gray release, controls change scope, and maintains service stability.