Service Meshes Available


Traffic Splitting using SMI and Linkerd

How Linkerd handles traffic splitting

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).

Deploying sample application

We will be deploying istio's bookinfo application for this part of the demo

Use meshery to deploy the bookinfo application :

  • In Meshery, navigate to the Linkerd adapter's management page from the left nav menu.
  • On the Linkerd adapter's management page, please enter default in the Namespace field.
  • Then, click the (+) icon on the Sample Application card and select Bookinfo Application from 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 svc
3 details ClusterIP <none> 9080/TCP 13m
4 kubernetes ClusterIP <none> 443/TCP 7h56m
5 productpage ClusterIP <none> 9080/TCP 13m
6 ratings ClusterIP <none> 9080/TCP 13m
7 reviews ClusterIP <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:

  • v1 with No stars
  • v2 with Orange stars
  • v3 with Black stars

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 svc
3 details ClusterIP <none> 9080/TCP 35m
4 kubernetes ClusterIP <none> 443/TCP 8h
5 productpage ClusterIP <none> 9080/TCP 35m
6 ratings ClusterIP <none> 9080/TCP 35m
7 reviews ClusterIP <none> 9080/TCP 35m
8 reviews-v2 ClusterIP <none> 9080/TCP 7s
9 reviews-v3 ClusterIP <none> 9080/TCP 7s

Now, let's apply traffic-split CRD from SMI :

2kind: TrafficSplit
4 name: reviews-split
6 service: reviews
7 backends:
8 - service: reviews-v1
9 weight: 500m
10 - service: reviews-v2
11 weight: 500m

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.


1kubectl delete trafficsplit/reviews-split
2kubectl delete -f ./sample/service.yaml
  • Remove the bookinfo application from the Meshery Dashboard by clicking on the trash icon in the sample application card on the linkerd adapters' page.


Getting Started

Layer5, the cloud native management company

An empowerer of engineers, Layer5 helps you extract more value from your infrastructure. Creator and maintainer of cloud native standards. Maker of Meshery, the cloud native manager.