Meshery Adapter for Network Service Mesh

Service Mesh Adapter Status Latest Supported Mesh Version
Network Service Mesh Adapter stable v0.2.1

Lifecycle management of Meshery Adapter for Network Service Mesh

The Meshery Adapter for Network Service Mesh can install v0.2.1 of Network Service Mesh. A number of sample applications can be installed using the Meshery Adapter for Network Service Mesh.

Lifecycle management of sample applications

The (Meshery Adapter for Network Service Mesh) includes a handful of sample applications. These applications represent different network services orchestrated by Network Service Mesh. Use Meshery to deploy any of these sample applications:

1. Hello NSM Application

Watch this presentation to see the Hello NSM Application in-action:

See on YouTube: Adopting Network Service Mesh with Meshery

2. VPP-ICMP Application

A simple example that connects a vpp based Pod to a Network Service using memif.

The simplest possible case for Network Service Mesh is to have is connecting a Client via a vWire to another Pod that is providing a Network Service. Network Service Mesh allows flexibility in the choice of mechanisms used to provide that vWire to a workload.

The icmp responder example does this with kernel interfaces. The vpp-icmp-responder provides and consumes the same ‘icmp-responder’ Network Service, but has Client’s and Endpoint’s that use a memif high speed memory interfaces to achieve performance unavailable via kernel interfaces.

vpp-icmp-responder-example

Working process

This will install two Deployments:

Name Description
vpp-icmp-responder-nsc The Clients (four replicas)
vpp-icmp-responder-nse The Endpoints (two replicas)

And cause each Client to get a vWire connecting it to one of the Endpoints. Network Service Mesh handles the Network Service Discovery and Routing, as well as the vWire ‘Connection Handling’ for setting all of this up.

vpp-icmp-responder-example-2

In order to make this case more interesting, Endpoint1 and Endpoint2 are deployed on two separate Nodes using PodAntiAffinity, so that the Network Service Mesh has to demonstrate the ability to string vWires between Clients and Endpoints on the same Node and Clients and Endpoints on different Nodes.

Verification

First verify that the vpp-icmp-responder example Pods are all up and running:

kubectl get pods | grep vpp-icmp-responder

To see the vpp-icmp-responder example in action, you can run:

curl -s https://raw.githubusercontent.com/networkservicemesh/networkservicemesh/master/scripts/nsc_ping_all.sh | bash

3. ICMP Responder

The simplest possible case for Network Service Mesh is to have is connecting a Client via a vWire to another Pod that is providing a Network Service. We call this case the ‘icmp-responder’ example, because it allows the client to ping the IP address of the Endpoint over the vWire.

icmp-responder-example

Outcomes

This will install two Deployments:

Name Description
icmp-responder-nsc The Clients, four replicas
icmp-responder-nse The Endpoints, two replicas

And cause each Client to get a vWire connecting it to one of the Endpoints. Network Service Mesh handles the Network Service Discovery and Routing, as well as the vWire ‘Connection Handling’ for setting all of this up.

icmp-responder-example-2

In order to make this case more interesting, Endpoint1 and Endpoint2 are deployed on two separate Nodes using PodAntiAffinity, so that the Network Service Mesh has to demonstrate the ability to string vWires between Clients and Endpoints on the same Node and Clients and Endpoints on different Nodes.

Verification

  1. Verify that the icmp-responder example Pods are all up and running:
kubectl get pods | grep icmp-responder
  1. To see the icmp-responder example in action, you may run:
curl -s https://raw.githubusercontent.com/networkservicemesh/networkservicemesh/master/scripts/nsc_ping_all.sh | bash

Suggested Topics