Table of contents
NSM v1.0.0 is released via a set of example use cases.
NSM v1.0.0 has been successfully integration tested with Kubernetes versions:
Changes since version v0.2.0
v1.0.0 major themes include:
- Markdown Driven Testing
- Topology Aware Scale from Zero
- Latency Reduction
Network Service Mesh intrinsically can support vWires that carry different payload types. Currently supported are:
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
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.
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:
- 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
Table of contents