**** 🚧 IF YOU’ER SEEING THIS 🚧 ****
*** 🚦 THIS IS A POLITE NOTICE THAT THIS ARTICLE IS A WORK-IN-PROGRESS 🚥 ****
The article is currently being tweaked, drafted and is not yet complete. I’m sharing it early to document my process, so feel free to take a look at the current progress. I expect to finalize the content in my next commit
THANKS FOR READING 🧐!
DO ENJOY YOURSELF IN THE PROCESS 😇!
************
Introducktion
The other day, I shared a concern in a WhatsApp group comprised of some super advanced DevOps Engineers as well as aspiring Linux Administrators. There I was, pouring my heart out around the topic of Service Mesh, (Istio, and Linkerd). How all these subjects were all intertwined and downright confusing. In the course of the debate, I’d later realised I would have to throw in a bit of Deployment Strategies just to fully grasp their concepts.
I am glad I started the debate in the whatsapp group, because as thirsty as I was for knowledge, my cry did not fall on deaf ears. Some of the greatest minds in DevOps weighed in on their thoughts and opinion on that matter. We had a healthy debate going on.
Then Matt Saunders, an esteemed member of the WhatsApp group, who is also one of the founders and organisers of the London DevOps meetup group, He’s also a well known author of many DevOps Articles, just like my favourite about Docker Bake, outright suggested that I stick with Linkerd for now.
Matt, in his own words, advised that I would be complicating things should I wish to attempt to study everything all at once. He also debated that not all seasoned Engineers are fond of Istio. so I could learn the ropes by starting with Linkerd till I get the hang of it.
He further suggested that I use various versions of my WebApps to depict the actual release metamorphosis, while demonstrating the evolution from legacy “brownfield” deployments, changing-over to the modern “greenfield” release.
His advice was brilliant. Served as a beacon of hope. The light in the dark tunnel, and honestly, a refreshing icy pool dip, in the middle of a hot Sahara desert. I am truly grateful for his suggestion and the clarity it provided.
But in a true DevOps style, suggestions are useless if you don’t act on them. Which has given birth to this article. This series documents my journey in implementing various deployment strategies using Linkerd.
Canary Deployment in Kubernetes
To kick things off, we are diving straight into Canary Deployments. This strategy allows us to shift a small portion of traffic to a new version of an application, minimizing risk before a full-scale rollout.
My Architecture and honourable mentions
As usual, no prices for guesses but the entire infrastructure would be run and tested in MiniKube. However, should I deviate from it, or also test my theory in another enviroment, other infrasture that I work with and their explanations can be found here - My Set Up
If you need a refresher on the foundational concepts before we jump into the commands, I highly recommend checking out these resources:
So let’s get to it
Step 1 : Install Linkerd in MiniKube
- Download the Linkerd CLI
First, install the Linkerd command-line tool onto your local machine.
curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/install | sh
Use code with caution.
Add the linkerd binary to your system’s path:
export PATH=$PATH:$HOME/.linkerd2/bin
Use code with caution.
- Verify Your Minikube ClusterMake sure your Minikube cluster is running and properly configured for Linkerd by performing a pre-check:
#start minikube
minikube start
#test Linkerd
linkerd check --pre
Use code with caution.
- Install the Control Plane
Install the Custom Resource Definitions (CRDs) and the Linkerd control plane onto your active Kubernetes context:
linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -
Use code with caution.
- Validate the InstallationConfirm that all Linkerd control plane pods are spinning up correctly:
linkerd check
Use code with caution.