CNCF-sponsored service Mesh Linkerd provides a lot of needed features in nowadays microservices architectures.

If you are reading this, probably, you are already aware of the challenges that come with a microservices architecture. It could be because you are reading about those or even because you are challenging them right now in your own skin.
One of the most common challenges is network and communication. With the eclosion of many components that need communication and the ephemeral approach of the cloud-native developments, many new features are a need when in the past were just a nice-to-have.
Concepts like service registry and service discovery, service authentication, dynamic routing policies, and circuit breaker patterns are no longer things that all the cool companies are doing but something basic to master the new microservice architecture as part of a cloud-native architecture platform, and here is where the Service Mesh project is increasing its popularity as a solution for most of this challenges and providing these features that are needed.
If you remember, a long time ago, I already cover that topic to introduce Istio as one of the options that we have:

But this project created by Google and IBM is not the only option that you have to provide those capabilities. As part of the Cloud Native Computing Foundation (CNCF), the Linkerd project provides similar features.
How to install Linkerd
To start using Linkerd, the first thing that we need to do is to install the software and to do that. We need to do two installations, one on the Kubernetes server and another on the host.
To install on the host, you need to go to the releases page and download the edition for your OS and install it.
I am using a Windows-based system in my sample, so I use chocolatey to install the client. After doing so, I can see the version of the CLI typing the following command:
linkerd version
And you will get an output that will say something similar to this:
PS C:\WINDOWS\system32> linkerd.exe version Client version: stable-2.8.1 Server version: unavailable
Now we need to do the installation on the Kubernetes server, and to do so, we use the following command:
linkerd install | kubectl apply -f -
And you will get an output similar to this one:
PS C:\WINDOWS\system32> linkerd install | kubectl apply -f - namespace/linkerd created clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-identity created clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-identity created serviceaccount/linkerd-identity created clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-controller created clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-controller created serviceaccount/linkerd-controller created clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-destination created clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-destination created serviceaccount/linkerd-destination created role.rbac.authorization.k8s.io/linkerd-heartbeat created rolebinding.rbac.authorization.k8s.io/linkerd-heartbeat created serviceaccount/linkerd-heartbeat created role.rbac.authorization.k8s.io/linkerd-web created rolebinding.rbac.authorization.k8s.io/linkerd-web created clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-web-check created clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-web-check created clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-web-admin created serviceaccount/linkerd-web created customresourcedefinition.apiextensions.k8s.io/serviceprofiles.linkerd.io created customresourcedefinition.apiextensions.k8s.io/trafficsplits.split.smi-spec.io created clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-prometheus created clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-prometheus created serviceaccount/linkerd-prometheus created clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-proxy-injector created clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-proxy-injector created serviceaccount/linkerd-proxy-injector created secret/linkerd-proxy-injector-tls created mutatingwebhookconfiguration.admissionregistration.k8s.io/linkerd-proxy-injector-webhook-config created clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-sp-validator created clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-sp-validator created serviceaccount/linkerd-sp-validator created secret/linkerd-sp-validator-tls created validatingwebhookconfiguration.admissionregistration.k8s.io/linkerd-sp-validator-webhook-config created clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-tap created clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-tap-admin created clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-tap created clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-tap-auth-delegator created serviceaccount/linkerd-tap created rolebinding.rbac.authorization.k8s.io/linkerd-linkerd-tap-auth-reader created secret/linkerd-tap-tls created apiservice.apiregistration.k8s.io/v1alpha1.tap.linkerd.io created podsecuritypolicy.policy/linkerd-linkerd-control-plane created role.rbac.authorization.k8s.io/linkerd-psp created rolebinding.rbac.authorization.k8s.io/linkerd-psp created configmap/linkerd-config created secret/linkerd-identity-issuer created service/linkerd-identity created deployment.apps/linkerd-identity created service/linkerd-controller-api created deployment.apps/linkerd-controller created service/linkerd-dst created deployment.apps/linkerd-destination created cronjob.batch/linkerd-heartbeat created service/linkerd-web created deployment.apps/linkerd-web created configmap/linkerd-prometheus-config created service/linkerd-prometheus created deployment.apps/linkerd-prometheus created deployment.apps/linkerd-proxy-injector created service/linkerd-proxy-injector created service/linkerd-sp-validator created deployment.apps/linkerd-sp-validator created service/linkerd-tap created deployment.apps/linkerd-tap created configmap/linkerd-config-addons created serviceaccount/linkerd-grafana created configmap/linkerd-grafana-config created service/linkerd-grafana created deployment.apps/linkerd-grafana created
Now we can check that the installation has been done properly using the command:
linkerd check
And if everything has been done properly, you will get an output like this one:
PS C:\WINDOWS\system32> linkerd check kubernetes-api -------------- √ can initialize the client √ can query the Kubernetes API
kubernetes-version ------------------ √ is running the minimum Kubernetes API version √ is running the minimum kubectl version
linkerd-existence ----------------- √ 'linkerd-config' config map exists √ heartbeat ServiceAccount exist √ control plane replica sets are ready √ no unschedulable pods √ controller pod is running √ can initialize the client √ can query the control plane API
linkerd-config -------------- √ control plane Namespace exists √ control plane ClusterRoles exist √ control plane ClusterRoleBindings exist √ control plane ServiceAccounts exist √ control plane CustomResourceDefinitions exist √ control plane MutatingWebhookConfigurations exist √ control plane ValidatingWebhookConfigurations exist √ control plane PodSecurityPolicies exist
linkerd-identity ---------------- √ certificate config is valid √ trust anchors are using supported crypto algorithm √ trust anchors are within their validity period √ trust anchors are valid for at least 60 days √ issuer cert is using supported crypto algorithm √ issuer cert is within its validity period √ issuer cert is valid for at least 60 days √ issuer cert is issued by the trust anchor
Then we can see the dashboard from Linkerd using the following command:
linkerd dashboard

Deployment of the apps
We will use the same apps that we use some time ago to deploy istio, so if you want to remember what they are doing, you need to look again at that article.
I have uploaded the code to my GitHub repository, and you can find it here: https://github.com/alexandrev/bwce-linkerd-scenario
To deploy, you need to have your docker images pushed to a docker registry, and I will use Amazon ECR as the docker repository that I am going to use.
So I need to build and push those images with the following commands:
docker build -t provider:1.0 . docker tag provider:1.0 938784100097.dkr.ecr.eu-west-2.amazonaws.com/provider-linkerd:1.0 docker push 938784100097.dkr.ecr.eu-west-2.amazonaws.com/provider-linkerd:1.0
docker build -t consumer:1.0 . docker tag consumer:1.0 938784100097.dkr.ecr.eu-west-2.amazonaws.com/consumer-linkerd:1.0 docker push 938784100097.dkr.ecr.eu-west-2.amazonaws.com/consumer-linkerd:1.0
And after that, we are going to deploy the images on the Kubernetes cluster:
kubectl apply -f .\provider.yaml
kubectl apply -f .\consumer.yaml
And now we can see those apps in the Linkerd Dashboard on the default namespace:

And now, we can reach the consumer endpoint using the following command:
kubectl port-forward pod/consumer-v1-6cd49d6487-jjm4q 6000:6000
And if we reach the endpoint, we got the expected reply from the provider.

And in the dashboard, we can see the stats of the provider:

Also, linked by default provided a Grafana dashboard where you can see more metrics you can get there using the grafana link that the dashboard has.

When you enter that, you could see something like the dashboard shown below:

Summary
With all this process, we have seen how easily we can deploy a linkerd service mesh in our Kubernetes cluster and how applications can integrate and interact with them. In the next posts, we will dive into the most advanced features that will help us in the new challenges that come with the Microservices architecture.