Traffic Splitting using SMI and Linkerd

Learn how to split traffic between different versions of your services using SMI and Linkerd.

image1

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 :

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

OR…

  • Download the ./sample/bookinfo.yaml
  • Inject linkerd into the sample application.
linkerd inject ./sample/bookinfo.yaml | kubectl apply -f -

This will give you the if the Linkerd injection was successful or not.

linkerd stat deploy

You will see the following services running in your cluster

kubectl get svc
    NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
    details       ClusterIP   10.96.115.62    <none>        9080/TCP   13m
    kubernetes    ClusterIP   10.96.0.1       <none>        443/TCP    7h56m
    productpage   ClusterIP   10.109.31.20    <none>        9080/TCP   13m
    ratings       ClusterIP   10.101.57.168   <none>        9080/TCP   13m
    reviews       ClusterIP   10.105.52.139   <none>        9080/TCP   13m

You can access the producpage by port-forwarding

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

kubectl apply -f ./sample/service.yaml

There are two new services created

kubectl get svc
    NAME          TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
    details       ClusterIP   10.96.115.62     <none>        9080/TCP   35m
    kubernetes    ClusterIP   10.96.0.1        <none>        443/TCP    8h
    productpage   ClusterIP   10.109.31.20     <none>        9080/TCP   35m
    ratings       ClusterIP   10.101.57.168    <none>        9080/TCP   35m
    reviews       ClusterIP   10.105.52.139    <none>        9080/TCP   35m
    reviews-v2    ClusterIP   10.106.174.219   <none>        9080/TCP   7s
    reviews-v3    ClusterIP   10.96.125.224    <none>        9080/TCP   7s

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

apiVersion: split.smi-spec.io/v1alpha1
kind: TrafficSplit
metadata:
  name: reviews-split
spec:
  service: reviews
  backends:
    - service: reviews-v1
      weight: 500m
    - service: reviews-v2
      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.

Cleanup

kubectl delete trafficsplit/reviews-split
kubectl 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.

Quiz