Does Linkerd mesh with GitOps? Flux around and find out

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.

GitOps and Linkerd

What is GitOps?

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.

Can I use GitOps with Linkerd?

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.

What the Flux?

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.

So how do I use Flux, GitOps, and Linkerd?

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.

Deploying a Cluster

We’re using Civo to host our Kubernetes cluster.

# Create a cluster
civo kubernetes create gitops_dev -n 3 -s g3.k3s.small --region NYC1 -w
# Grab the config
## This will merge it into your .kube/config file
civo kubernetes config gitops_dev -sym

Install Flux

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:

# Install the flux cli
curl -s https://toolkit.fluxcd.io/install.sh | sudo bash

# Check that you can in fact install flux
flux check --pre

# Install flux
flux install

# Check flux installed correctly
flux check

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:

flux create source git gitops --url https://github.com/BuoyantIO/gitops_examples --branch main

The command will output text telling you that it has successfully pulled the repository.

Set up the Cluster Runtime Environment

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:

git clone https://github.com/BuoyantIO/gitops_examples

cd gitops_examples

kubectl apply -f flux/runtime/manifests/dev_cluster.yaml

# You can follow along with the flux runtime install with the following commands
# To watch deployed pods
watch kubectl get pods -A
# To watch the customization objects
watch kubectl get kustomizations -A

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.

Deploy an Application

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.

Deploy podinfo:

# from the gitops repo we were in before run the following command
kubectl apply -f flux/apps/manifests/podinfo.yaml

Once again you can use watch commands to check on the state of your cluster.

# To watch deployed pods
watch kubectl get pods -n podinfo
# To watch the customization objects
watch kubectl get kustomizations -A

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.

Summary

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.

Similar posts

Jan 11, 2021 | Risha Mars

In this article we’re going to show you how to accomplish a basic Kubernetes observability task: getting “golden metrics” (or “golden signals”) from the applications running on your Kubernetes cluster. We’ll do this without changing any code or doing any configuration by installing Linkerd, an open …


Dec 23, 2020 | Zahari Dichev

Applying L4 network policies with a service mesh In this tutorial, you’ll learn how to run Linkerd and Cilium together and how to use Cilium to apply L3 and L4 network policies to a cluster running Linkerd. Linkerd is an ultralight, open source service mesh. Cilium is an open source CNI layer for …


Oct 21, 2020 | Kevin Leimkuhler

SLOs are a lot easier with a service mesh in hand In this tutorial, you’ll learn how to easily create service health SLOs on Kubernetes with Prometheus, an open source time-series database, and Linkerd, an open source ultralight service mesh. You’ll see how using a service mesh can solve one of the …