Service Mesh in GCP with Linkerd

Linkerd is a service mesh solution that provides a transparent layer of network communication between microservices in a Kubernetes cluster. Service meshes help to address many of the challenges faced in microservice architecture, such as service discovery, traffic management, load balancing, and security. While of course a service mesh may not be needed depending on your use case this is to explore those capabilities and show you Linkerd is installed along with the dashboard showing the capabilities of this service mesh.

Linkerd provides a unified solution for network communication and service discovery within a cluster, allowing developers to focus on their application code and not the underlying network infrastructure. The use of Linkerd in Kubernetes enables consistent observability, reliability, and security for all services in the cluster, regardless of size or complexity. These security addons help secure communication between services and add an extra layer of protection against various security threats like data breaches, unauthorized access, and attacks on the network. For example, Linkerd provides features like mTLS (Mutual TLS) to secure communication between services, network-level access control, and service-level authentication.

Get some hands on in Linkerd

Getting started we are running Kubernetes 1.26

curl --proto '=https' --tlsv1.2 -sSfl https://run.linkerd.io/install | sh

Ensure that you run the following command to to add the CLI Path

export PATH=$PATH:/root/.linkerd2/bin

After that we run the following to check if the CLI is running correctly

linkerd check --pre

Since this says unavailable don’t fret this is because we have to install Linkerd Control Plane.

Now let’s get to the installation on our cluster running the following command

linkerd install --crds | kubectl apply -f -

Followed by the command listed below to break these commands down we are first installing the custom resource definitions associated with Linkerd and secondly the “kubectl is telling our cluster to install those resources into our cluster”.

If you forgot to run the command below you are reminded in the terminal

linkerd install | kubectl apply -f -

So we can see a lot going on here notable some cluster role roles defined along with service accounts, service and much more.

If you run into a hang up in this area this will reveal it as such I installed this on GKE to demonstrate extended capabilities and this took some time see the image below

Run this command to ensure that this is done installing.

linkerd check

Alternatively Linkered is available as a helm chart as well this is not the only way of installation if you’d like to explore how that compares feel free to visit this link https://linkerd.io/2.12/tasks/install-helm/

Now we will run through how Linkerd can open up visibility to a deployed application in the docs provided is the Emojivote – a standalone application using gRPC and HTTP calls to allow users to vote on their favorite emojis

curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/emojivoto.yml \
  | kubectl apply -f -

Mind you this installs the application this doesn’t activate Linkerd yet – let’s take a peak at the application by running the following command

Prior to running the next command if we run this command we can see what this application is made up of.

kubectl get pods -n emojivoto

kubectl -n emojivoto port-forward svc/web-svc 8080:80

I had to deviate from this local cluster to a GKE cluster to demonstrate the dashboard capabilities as I was unable to utilize the localhost and expose the port needed but the dash board integration piece

Like anything when I ran into some issues on a small node on GKE I had to expand the autoscaler to upscale the nodes for the workloads scheduled I also did enable Cluster Security API on GKE and got some granular data.

So we can see we have some concerns for these workloads lets investigate further on the concerns tab.

After investigating further of the vulnerability we can zoom in and find the affected deployment (if you are following along be aware of this in your cluster for this demo as this image contains underlying vulnerabilities that are actively out in the wild).

Digging into the configuration concerns we can see that some of the workloads we did deploy have additional capabilities of measuring our risk

We can also see what else is of concern for the configuration

After up-scaling my cluster was completed I’ve increased the nodes to manage the workload and now we are up and running.

Let’s skip to installing the visualization add-on to access our dashboard and explore further by running the following commands.

linkerd viz install | kubectl apply -f - # install the on-cluster metrics stack

Once this is ran we can run the following command to check our status

linkerd check

Now we are ready to run the next command to get our dashboard this will populate a port you can use to navigate

linkerd viz dashboard &

If your running this in a managed cluster such as AKS/GKE/EKS you’ll have to select a few options on the cloud shell to access this.

Since I’m on GKE I’ve selected the *Web Preview* shown below

If successful in this the dashboard should look like the following image.

So it appears our deployment doesn’t have the service meshed ensure you re-run this command if this is the issue

kubectl get -n emojivoto deploy -o yaml \
  | linkerd inject - \
  | kubectl apply -f -

This should look like this now once we click into the emojivote

Now we can see how our deployment is communicating with the visual along with measuring the success rate.

If navigate to the menu side and select Control Plane this will show a view of our cluster

On this page you can also run a Linkerd Check as shown in the image the button below will launch a UI

Going back to the dashboard let’s investigate emojivoto deployment further by selecting the hyperlinked on HTTP Metrics

We can see we have some trouble with the voting with a lowered success rate let’s open that pod up and see how the traffic flows

We can see the breakdown is the voting to web specifically for these metrics gathered if I scroll down on this page I can see my inbound connections that are affected with a even lower success rate.

It appears that this is a bottle neck is on the web portion of our service affecting the voting bot and voting pod.

Additionally I’d be remiss to summarize and say that this sums up the solution service mesh is a large field with many players notably are Linkerd and Istio and the next question is does it fit my use case? Well it’s likely your organization will consume some microservices they have to communicate with each other in that case especially at scale you’d like a few items to be checked such as mTLS. Perhaps your organization wants to process credit card information in a micro-services architecture you’ll want to protect this data in transit and this will likely be a concern on how you can observe and enforce this to ensure mTLS is enabled throughout your platform. Like any tool in the set of resources that come with the ease of use of kubernetes they all have a purpose underlying and as far as the next era service mesh will likely exponentially be a realm of investment for companies to gain visibility and encryption at scale.

Ensure if you are running this in a cloud environment you delete your resources as you’ll be surprised on costs depending on your cluster can add up every dollar counts!

Conclusion

Overall, Linkerd is a powerful tool for modern, cloud-native applications and provides a simple and effective solution for managing the network communication of microservices within a Kubernetes cluster. With its seamless integration with Kubernetes, Linkerd offers a robust, scalable, and secure service mesh solution for organizations looking to improve the reliability and performance of their applications. Service Mesh varies the creators of Linkerd run BouyantCloud as a managed service and offering should you want to explore that realm.