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 :
Sample Applicationcard and select
Bookinfo Applicationfrom the list.
1linkerd inject ./sample/bookinfo.yaml | kubectl apply -f -
This will give you the if the Linkerd injection was successful or not.
1linkerd stat deploy
You will see the following services running in your cluster
1kubectl get svc2 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE3 details ClusterIP 10.96.115.62 <none> 9080/TCP 13m4 kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 7h56m5 productpage ClusterIP 10.109.31.20 <none> 9080/TCP 13m6 ratings ClusterIP 10.101.57.168 <none> 9080/TCP 13m7 reviews ClusterIP 10.105.52.139 <none> 9080/TCP 13m
You can access the producpage by port-forwarding
1kubectl port-forward svc/productpage 9080:9080
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.
1kubectl apply -f ./sample/service.yaml
There are two new services created
1kubectl get svc2 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE3 details ClusterIP 10.96.115.62 <none> 9080/TCP 35m4 kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 8h5 productpage ClusterIP 10.109.31.20 <none> 9080/TCP 35m6 ratings ClusterIP 10.101.57.168 <none> 9080/TCP 35m7 reviews ClusterIP 10.105.52.139 <none> 9080/TCP 35m8 reviews-v2 ClusterIP 10.106.174.219 <none> 9080/TCP 7s9 reviews-v3 ClusterIP 10.96.125.224 <none> 9080/TCP 7s
Now, let's apply traffic-split CRD from SMI :
1apiVersion: split.smi-spec.io/v1alpha12kind: TrafficSplit3metadata:4 name: reviews-split5spec:6 service: reviews7 backends:8 - service: reviews-v19 weight: 500m10 - service: reviews-v211 weight: 500m
This tells Linkerd’s control plane that whenever there are requests to the reviews service, to split them across the
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.
1kubectl delete trafficsplit/reviews-split2kubectl delete -f ./sample/service.yaml
Meshery Dashboardby clicking on the
trash iconin the
sample applicationcard on the linkerd adapters' page.