It’s time to install the control plane onto your OpenShift cluster. We will install the control plane in a dedicated linkerd project where it can easily be removed. Let's get started by logging in (needs admin rights to create the respective RBAC settings):

oc policy add-role-to-user cluster-admin developer && oc policy add-role-to-user admin developer && oc login -u developer -p developer

OK, ready to install Linkerd's control plane? Here we go:

oc new-project linkerd && linkerd install | sed -e '/kind: Namespace/,+3d' | oc apply -f -

Above generates a bunch of Kubernetes resources and pipes it to oc which then applies it to your OpenShift cluster.

Let's wait until everything is up and running, which may take a minute or so. An easy way to do that is the following (hint: use CTRL+C to stop the watch command to updating you once you see all pods in the Running status):

watch oc get po -l linkerd.io/control-plane-ns=linkerd

Once all the pods started are ready, it is possible to also view the Linkerd2 server's version:

linkerd version

At this point you'd normally use linkerd dashboard. Because this tutorial is running in Katacoda, we need to do a little extra work. Run:

oc expose svc

You've not added any services to the mesh yet, so the dashboard won’t have much to display beyond the status of the service mesh itself. Let's run something!

Finally, it’s time to install a demo application and add it to the service mesh.

Fetch the demo, add Linkerd2 to it and apply it to your cluster using the following commands:

wget https://raw.githubusercontent.com/runconduit/conduit-examples/master/emojivoto/emojivoto.yml

cat emojivoto.yml | linkerd inject - > linkerd-emojivoto.yml

cat linkerd-emojivoto.yml | oc apply -f -

These commands download the Kubernetes config for an example gRPC application where users can vote for their favorite emoji, then runs the config through linkerd inject. The config has the Linkerd2 data plane proxies injected as sidecar containers in the demo's pods and kubectl takes care of applying this configuration to your cluster.

As with linkerd install, in this command, the Linkerd2 CLI is simply doing text transformations, with kubectl doing the heavy lifting of actually applying config to the Kubernetes cluster.

The pattern of injecting Linkerd2's configuration in this matter is convenient because you can introduce additional filters into the pipeline, or run the commands separately and inspect the output of each one.

Take a look at what's actually happening by running a diff on the before and after (hint: press q to exit the git diff view):

git diff --no-index -- emojivoto.yml linkerd-emojivoto.yml

At this point, you should have an application running on your Kubernetes cluster, and (unbeknownst to it!) also added to the Linkerd2 service mesh.

If you glance at the Linkerd2 dashboard, you should see all the HTTP/2 and HTTP/1-speaking services in the demo app show up in the list of deployments that have been added to the Linkerd2 mesh.

View the demo app by querying the URL like so:

oc expose svc

Finally, let’s take a look back at our dashboard. You should be able to browse all the services that are running as part of the application to view:

• Success rates
• Request rates
• Latency distribution percentiles
• Upstream and downstream dependencies

As well as various other bits of information about live traffic. Neat, huh?

Views available in the dashboard:

SERVICE MESH

Displays continuous health metrics of the control plane itself, as well as high-level health metrics of deployments in the data plane.

DEPLOYMENTS

Lists all deployments by requests, success rate, and latency.

Of course, the dashboard isn’t the only way to inspect what’s happening in the Linkerd2 service mesh. The CLI provides several interesting and powerful commands that you should experiment with, including linkerd stat and linkerd tap.

To view details per deployment, run:

linkerd -n emojivoto stat deployments

To see a live pipeline of requests for your application, run:

linkerd -n emojivoto tap deploy voting