Hello folks and welcome! Today we’re going to talk about GitOps and how it relates to the Linkerd service mesh. GitOps is a buzzy topic, and that’s in no small part because it can have a really positive impact on teams working with Kubernetes. Teams that have established effective GitOps pipelines can programmatically deploy and configure fleets of clusters, all built with the same specification. For those running Kubernetes at scale, GitOps allows for automatic cluster or environment recovery, configuration drift detection, and easily trackable configuration changes over time.
By the end of this article, you will be able to use Flux to bootstrap a cluster with Linkerd and deploy an application to it.
I won’t offer a comprehensive definition here but we can start with something simple.
GitOps is a way of deploying things to Kubernetes that involves storing all your Kubernetes artifacts in one or more git repositories and regularly syncing your cluster’s state with that repository. You can find more comprehensive definitions here and here.
Yes! If you’re relatively new to Linkerd, it’s pretty normal to do your installs via the Linkerd CLI. It does a good job of automatically generating the basic installation and even has easy options to make your environment failure tolerant via the –ha switch.
Unfortunately, or fortunately, depending on your perspective, GitOps doesn’t involve running a bunch of bash scripts, so you can’t run Linkerd CLI commands directly. The good news is that Linkerd has a ton of install options, including the default linkerd install, which outputs a YAML manifest that you can save right to your git repository. Linkerd also supports and maintains its own Helm charts, which can be used with GitOps tools like Flux and ArgoCD directly.
Flux v2 is a GitOps tool from Weaveworks that recently became an incubating CNCF project and is rapidly maturing towards a GA release. It works by integrating directly with the Kubernetes API via Custom Resource Definitions. Flux ships with a CLI tool to handle interacting with it and exporting YAML manifests that you can apply directly to Kubernetes.
By following along here! We’re going to get started with a brand new Kubernetes cluster from our friends over at Civo, but you can use any Kubernetes cluster.
We’re using Civo to host our Kubernetes cluster.
Once that’s done, we’ll jump right into how we use the Flux CLI to get flux installed and get our new cluster configured to use our git repo.
Install Flux on your cluster:
The Flux check commands will ensure your new cluster is ready to run Flux, install the Flux pods, and validate that your install is healthy.
With the Flux install out of the way, we need to set up Flux to work with our git repository.
Throughout this demo, I will use the flux CLI to work with the cluster and configure our GitOps resources. At any point, you can modify the Flux CLI commands I’m using to export instead of YAML files that can be applied to your Kubernetes cluster.
Configure your git repo:
The command will output text telling you that it has successfully pulled the repository.
Now that we’ve got our cluster healthy, we need to deploy our application platform. I call it the runtime environment. The runtime we’re deploying today consists of three applications, Linkerd, the Linkerd dashboard, and Flagger. You can find the details of the manifest file here.
One notable thing about the install is that for Linkerd, the Linkerd dashboard, and Flux to install correctly, we need to ensure that they’re deployed in sequence. Flux can wait on one item to finish installing before the next item starts. We do that using Health Checks and the dependsOn condition. You can read more about how that works here.
To get the runtime deployed on our new cluster, we will pull down the GitOps repo and pass the manifest off to our Kubernetes cluster. Flux will see the new Kustomize objects getting created and will go about ensuring they are on our cluster and are installed correctly.
Deploy the runtime:
Once all the Kustomization objects show `true` under the `READY` column our runtime environment has been properly installed and configured. We’ve now successfully deployed Linkerd with Flux. In the next section we’ll go a step further and install an application and have Linkerd add the app to our mesh by injecting the linkerd proxy.
You have two main avenues for instructing Linkerd to inject a proxy into your application. You can annotate the namespace or annotate the object manifests. You can see how we’re annotating the podinfo application here. By putting the annotation on the namespace, all the pods we create will automatically get injected with the Linkerd proxy.
Once again you can use watch commands to check on the state of your cluster.
With that Podinfo is successfully deployed. You can use the Linkerd viz commands to check on the traffic or connect to the Linkerd dashboard to see the current state of your cluster.
Thanks for reading along, folks! Today we went over GitOps and Flux and how to use Flux with Linkerd. Linkerd’s flexible install mechanism allows it to be used directly via the CLI and integrates seamlessly with a more mature GitOps style workflow. When using Flux, you can easily build and deploy a common Kubernetes runtime that includes Linkerd to all your clusters. Additionally, we saw how straightforward it is to install Linkerd on a new Kubernetes cluster with Flux’s health checks and dependency chaining. And finally, we configured our applications to automatically inject the Linkerd proxy when deployed to the cluster.