How TSF Mesh Extends Istio to Support Non‑Container Environments

Background

Enterprises need service‑governance features (gray‑release, routing, circuit‑breaking, rate‑limiting) but cannot refactor large code bases or adopt container platforms. Traditional service‑mesh solutions such as Istio depend on Kubernetes, limiting their use in VM‑based or non‑container environments.

TSF Mesh Overview

TSF Mesh extends Istio to support both container and virtual‑machine workloads and to interoperate with Spring Cloud services. The main extensions are:

Application deployment & sidecar injection

Traffic hijacking for VM instances

Platform‑agnostic service registration & discovery

Application Deployment and Sidecar Injection

Istio normally relies on Kubernetes and injects the Envoy sidecar via istioctl kube-inject or a mutable webhook. TSF Mesh introduces a higher‑level module tsf‑resource that stores Istio cluster information, image URLs and startup parameters in a TSF database.

For container workloads, tsf‑resource reads the stored data, builds a Kubernetes CRD and creates the POD; the sidecar is injected automatically with parameters supplied from the control console.

For VM workloads, TSF Mesh adds three components: tsf‑repo: package repository that stores application binaries and dependencies. tsf‑master: master node that dispatches deployment, start, stop and teardown tasks to agents. tsf‑agent: runs on each VM, prepares the environment and executes the tasks. Tasks are asynchronous; the UI returns a task ID that can be queried for status.

Traffic Hijacking

Istio uses an init container istio‑init that runs /usr/local/bin/istio-iptables.sh to redirect inbound and outbound traffic to the Envoy sidecar. TSF Mesh keeps the iptables approach but must solve two VM‑specific problems:

Executing the iptables script inside the VM.

Hijacking only the traffic of the target application, not the whole VM network.

Inbound hijacking follows the original Istio behavior. For outbound traffic, TSF Mesh adds a custom mesh‑dns module that synchronizes service entries from pilot‑discovery to a local DNS cache. Requests for registered services resolve to a special IP; an iptables rule redirects that IP to Envoy. DNS port 53 is also intercepted so that queries are routed through mesh‑dns.

Service Registration and Discovery

Istio relies on the underlying platform (e.g., Kubernetes) for service registration and uses Pilot to discover services via xDS. TSF Mesh adopts Consul as a platform‑agnostic registry for both containers and VMs. The Pilot‑discovery component is extended with:

A gRPC ServiceInfos service that streams registry changes.

Consul watch‑based change detection instead of periodic polling.

Incremental synchronization of service data.

During deployment, users provide a spec.yaml that describes each service (name, ports, health‑check path). The pilot‑agent reads this file, injects the information into Envoy’s static configuration and starts Envoy. Envoy’s Health Discovery Service (HDS) periodically checks the health endpoint and reports status back to pilot‑discovery, which registers the service in Consul via a new RegisterService API and reports health via ReportHealthCheckInfo.

Key Technical Artifacts

initContainers:
  - args:
    - -p
    - "15001"
    - -u
    - "1337"
    - -m
    - REDIRECT
    - -i
    - '*'
    - -x
    - ""
    - -b
    - 9080,
    image: istio/istio-release-proxy_init:1.0.1
    securityContext:
      capabilities:
        add:
        - NET_ADMIN
    ...

FROM ubuntu:xenial
RUN apt-get update && apt-get install -y \
    iproute2 \
    iptables \
    && rm -rf /var/lib/apt/lists/*
ADD istio-iptables.sh /usr/local/bin/
ENTRYPOINT ["/usr/local/bin/istio-iptables.sh"]

Conclusion

By extending Istio with higher‑level control modules, TSF Mesh provides unified service‑mesh management for container and non‑container workloads without requiring a specific underlying platform. It enables full lifecycle management, data‑driven operations, monitoring and service‑governance for enterprises adopting cloud‑native architectures.

References

https://www.servicemesher.com/

https://cloud.tencent.com/product/tsf-mesh

https://www.servicemesher.com/blog/istio-pilot-service-registry-code-analysis/