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:

• Payloads
• Wireguard
• SRIOV
• Markdown Driven Testing
• Topology Aware Scale from Zero
• Latency Reduction
• Refactoring

Payloads

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

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

SRIOV

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.

Refactoring

Simplification

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

NetworkService

Used to Request, Close, or Monitor vWire Connections between a Client and and Endpoint providing the requested Network Service

Registry

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.

Multi-repo

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

api

Just the NSM apis

sdk

Platform independent sdk

sdk-*

Platform dependent sdks

cmd-*

Commands. Each cmd-* repo has exactly one docker container with one command.

deployment-k8s

Documentation for how to try various NSM examples in k8s

integration-tests

Integration tests compiled from the markdown documentation in deployment-k8s

integration-k8s-*

Runs of the integration tests in various environments