Skip to content

Latest commit

 

History

History

vl3-lb

README.md

vL3 Load Balancer

This example shows what is a vL3 Load Balancer (LB) and how it works.

Description

We all know and use Kubernetes Services in our work. Service is a method for exposing a network application that is running as one or more Pods in your cluster. It distributes traffic across a set of selected Pods.

To define a Kubernetes Service:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

Now you can reach the service by its name.

It turned out that we can use a similar mechanism in our vL3 networks - we can use a vL3 Load Balancer. Being on the same vL3 network, clients can behave like pods - they can communicate with each other. Using selectors, we can combine some of them to implement a service. vL3-LB will help us with this. We will call these clients that implement the service as "real servers".

So, vL3-LB has the following parameters:

NSM env Description
NSM_SELECTOR labels that group the vL3 clients we need to implement any service
NSM_PROTOCOL TCP or UDP IP protocol
NSM_PORT LB port
NSM_TARGET_PORT real server port

vL3-LB is a vL3-network client that monitors the real servers using NSM_SELECTOR. It has its own DNS name that we can use.

Example of monitoring:

NSM vL3 Diagram
Please note: The network configuration is given as an example. It can have a different number of elements.

In the current example, we want to get a finance service for processing http requests.
After calling the command $:curl finance:8080, the DNS name is converted to the IP address of the Load Balancer.
When the http request reaches the balancer, it converts the destination address to the address of the real server.

Example of the data path:

NSM vL3 Diagram
Please note: The IP addresses are given as an example, they may change from run to run.

Run

Deploy the vL3 network service, vL3-NSE, vL3-LB, finance-servers and finance-client (the last 3 are actually clients of the vL3 network) (see kustomization.yaml):

kubectl apply -k https://github.com/networkservicemesh/deployments-k8s/examples/features/vl3-lb?ref=c91be29099fab1f8376d9ff90c858efd829de35e

Wait for vL3-clients to be ready:

kubectl wait --for=condition=ready --timeout=2m pod -l type=vl3-client -n ns-vl3-lb

Send an http-request from the finance-client:

kubectl exec deployments/finance-client -n ns-vl3-lb -- curl -s finance.vl3-lb:8080 | grep "Hello! I'm finance-server"

In the response you will see the name of the real server that performed the processing. If you run the command above many times, you will see that load balancing occurs and the responses are returned by different handlers.

Cleanup

To clean up the example just follow the next command:

kubectl delete ns ns-vl3-lb