Release v1.0.0

NSM v1.0.0 is released via a set of example use cases.

Kubernetes Compatibility

NSM v1.0.0 has been successfully integration tested with Kubernetes versions:

  • v1.21.1
  • v1.20.7
  • v1.19.11
  • v1.18.15
  • v1.17.11

Changes since version v0.2.0

v1.0.0 major themes include:


Network Service Mesh intrinsically can support vWires that carry different payload types. Currently supported are:

  • IP
  • Ethernet

in v0.2.0 only Ethernet was supported.


Wireguard tunnels are used in NSM v1.0.0 as the default transport type for IP payloads.


SRIOV allows a single physical NIC to be ‘shared’ as it is multiple physical NICs. NSM now support using either vfio or a kernel interface backed by SRIOV as the mechanism by which a workload is connected to a Network Service.

Markdown Driven Testing

Network Service Mesh documents its examples in deployment-k8s in Markdown. Network Service Mesh’s testing is now generated by compiling that Markdown to Go tests in integration-tests

Topology Aware Scale from Zero

When a workload requests a Network Service, the Network Service can specify topology preferences. For example the Network Service definition may define that the workload should be connected via a vWire to an Endpoint providing that Network Service on the same Node, or in the same Cluster, etc as the workload.

In the absense of a topologically appropriate Endpoint for a workload, NSM can now spawn such an Endpoint. That Endpoint will retire itself after a period of idleness in which it has not been in use.

Latency Reduction

All of the components of Network Service Mesh have gone through an aggressive reduction in their latency to reduce overall systemic latency between workload request and fulfilment of that request. This reduction also reduces the time it takes to reconverge in the event of the failure of one or more components.



NSM has been simplified such that it only has two APIs:

Used to Request, Close, or Monitor vWire Connections between a Client and and Endpoint providing the requested Network Service
Used to Register, UnRegister, and Find Network Services and the Network Service Endpoints that provide them

All sdk elements are written to provide a chain element implementing one of these APIs. Executable components are written by chaining together these chain elements in a chain of responsibility pattern.

This vastly simplifies both writing new chain elements and consuming them to create new Network Service Endpoints, Forwarders, or other Components.


Network Service Mesh has been refactored from a monorepo (networkservicemesh/networkservicemesh) into multi-repos:

Multi-Repo Image
Just the NSM apis
Platform independent sdk
Platform dependent sdks
Commands. Each cmd-* repo has exactly one docker container with one command.
Documentation for how to try various NSM examples in k8s
Integration tests compiled from the markdown documentation in deployment-k8s
Runs of the integration tests in various environments