
The destination component of the control plane looks for changes in configuration of linkerd (actualized as Kubernetes Custom Resource Definitions) and afterward pushes the right config for
proxies to follow. As opposed to presenting its own configuration format for traffic splitting, Linkerd follows the SMI spec, which plans to give a brought together, summed up setup model for service meshes (simply like ingress, CRI, and so on in Kubernetes).
We will be deploying istio's bookinfo application for this part of the demo
Use meshery to deploy the bookinfo application :
default in the Namespace field.Sample Application card and select Bookinfo Application from the list.OR...
This will give you the if the Linkerd injection was successful or not.
You will see the following services running in your cluster
You can access the producpage by port-forwarding
Checking localhost:9080 would show you a product page, with a list of reviews on the right. Those reviews are being loaded from the reviews service which is backed by the 3 reviews pods. The requests to the reviews service are randomly sent to one of the 3 review pods, as they represent different versions of this service.
The three different versions provide different output:
We will have reviews service only split traffic between v1 and v2 of the application.
In Linkerd’s approach to traffic splitting, services are used as the core primitives. Hence we need to create two new services corresponding to v1 & v2 pods.
There are two new services created
Now, let's apply traffic-split CRD from SMI :
This tells Linkerd’s control plane that whenever there are requests to the reviews service, to split them across the reviews-v1 and reviews-v2 based on the weights provided.
If we now go back to our product page, we can only see the reviews with orange or no stars appear on each refresh.
Meshery Dashboard by clicking on the trash icon in the sample application card on the linkerd adapters' page.