TSF Mesh: Extending Istio Service Mesh for Non‑Container Environments

As enterprises scale, they increasingly need service‑governance features such as gray releases, routing, circuit breaking, and rate limiting without rewriting large amounts of business code. Traditional Service Mesh solutions like Istio assume a container platform, making them hard to adopt for non‑containerized or legacy environments.

TSF Mesh, built on Istio, introduces a set of modifications that allow applications to run side‑by‑side in Kubernetes containers and virtual machines (VMs). The key changes are:

Application deployment and Sidecar injection

Traffic hijacking (inbound and outbound)

Service registration and discovery

Application Deployment & Sidecar Injection

Istio normally relies on Kubernetes to manage the lifecycle of pods and to inject the Envoy sidecar either manually (via istioctl kube-inject ) or automatically (through a mutating webhook). TSF Mesh abstracts this process with a higher‑level resource manager ( tsf‑resource ) that stores image references, Istio cluster info, and configuration in the TSF database. For containers, tsf‑resource assembles a CRD and creates the pod, automatically adding the sidecar. For VMs, TSF Mesh introduces three modules:

tsf‑repo : stores application packages

tsf‑master : dispatches deployment, start, stop, and teardown tasks to agents

tsf‑agent : runs on the VM, initializes the environment and executes the tasks

All tasks are asynchronous; the TSF console returns a task ID that can be used to query status.

Traffic Hijacking

Both Istio and TSF Mesh use iptables (or BPF/IPVS) to redirect traffic to the Envoy sidecar. The Istio init container runs the script /usr/local/bin/istio-iptables.sh with arguments such as:

$ /usr/local/bin/istio-iptables.sh -p 15001 -u 1337 -m REDIRECT -i '*' -x "" -b 9080 -d ""

This command redirects inbound traffic to the application port (e.g., 9080) and all outbound traffic to Envoy’s port 15001. TSF Mesh extends this mechanism for VMs by executing the iptables script inside the pilot‑agent before Envoy starts, and by adding DNS‑level hijacking using a custom mesh‑dns component that resolves registered service names to a special IP and redirects that traffic to Envoy.

Service Registration & Discovery

TSF Mesh adopts Consul as a unified registry for both containers and VMs. It enhances Istio’s Pilot component to watch Consul events instead of polling, and introduces a ServiceInfos gRPC service for incremental updates. The custom mesh‑dns (built on github.com/miekg/dns ) synchronizes with Pilot‑discovery, returns a configured IP for registered services, and forwards other queries to the local DNS resolver.

Application developers describe services in a spec.yaml file, for example:

apiVersion: v1
kind: Application
spec:
  services:
  - name: user
    ports:
    - targetPort: 8091
      protocol: http
    healthCheck:
      path: /health

Pilot‑agent reads this file, injects the information into Envoy’s static configuration, and starts Envoy with Health Discovery Service (HDS) support. Pilot‑discovery is extended to accept health reports from Envoy and to register services in Consul, completing the full lifecycle of registration, health checking, and traffic management for both container and VM workloads.

In summary, TSF Mesh abstracts away the underlying platform, enabling unified management of microservices across containers and virtual machines while retaining the powerful traffic‑control and observability features of Istio.