When you’re deploying any type of workload into Kubernetes, whether it’s a full application stack, one Kubernetes Manifest, or an entire Helm Chart, you need a method in which you can deploy the workload in an efficient and repeatable fashion.

When actually installing Linkerd itself, you still need that efficient method.

In this blog post, you’ll learn how to configure Linkerd with one of the popular GitOps Controllers, ArgoCD.

Prerequisites

For the purposes of this blog post if you’re planning on following along in a hands-on fashion, you should have:

1. A Kubernetes cluster. The cluster can be a local Kubernetes cluster like Minikube or Kind, or it can be a production-ready cluster.

What Is GitOps

When you’re deploying any workload which includes:

• Helm Charts
• Kustomize files
• Raw Kubernetes Manifests

You need a way to automatically deploy the workloads in a repeatable and efficient fashion. GitOps gives you the ability view Git repos where the workloads exist and deploy them in an automated fashion.

When deploying a workload, GitOps will look at the source control repo where the code exists and deploy it. Then, if there are any changes to that code, the GitOps Controller will see those changes and automatically deploy the new changes based on an interval/time that you set up.

GitOps, in more ways than one, is Configuration Management for Kubernetes Resources. If you’re familiar with Chef, Ansible, or Puppet, GitOps is doing the same thing from a technical perspective. The difference is it’s deploying Kubernetes Resources and not configurations for servers or services.

It can also be looked at as Continuous Delivery (not to be confused with Continuous Deployment) due to its nature of automatically deploying workloads once a source control repository is updated.

What Is ArgoCD

When you’re working with GitOps, you have a few options in terms of Controller choices. One of the most popular GitOps Controllers is ArgoCD.

When thinking about a specific GitOps Controller, think about Kubernetes Controllers in general. The entire point of a Kubernetes Controller is to confirm that the current state is the desired state. For example, the Replica Controller will confirm that the desired amount of Pods running is what’s running. If the current state of the Pod replica count does not match the desired state, the desired state will be implemented if possible.

The same goes for a GitOps Controller like ArgoCD. Its job is to confirm that the current state is the desired state. The desired state is what exists in a Git repo and the current state is what’s actively deployed on the Kubernetes cluster. The goal is to get the current state to match the desired state.

ArgoCD is open-source, a CNCF Graduated project, and a very well-used GitOps Controller in production environments.

Deploying ArgoCD

Now that you know the theory behind ArgoCD and why you’d want to use it to deploy workloads like Linkerd, let’s learn how to deploy ArgoCD.

First, you’ll need to install the ArgoCD CLI. There’s an installation method for every Operating System, whether it’s a Linux distro, macOS, or Windows.

For example, below is the method using Homebrew (the macOS package manager) to install the ArgoCD CLI

brew install argocd

You can find more installation options here: https://argo-cd.readthedocs.io/en/stable/cli_installation/

Next, create a Kubernetes Namespace for the ArgoCD Resources to exist in.

kubectl create namespace argocd

When deploying ArgoCD, you have two options:

1. Standard no HA deployment.
2. An HA deployment

If you choose to go with the HA deployment, you must have at least three (3) Kubernetes Worker Nodes. The reason why is that ArgoCD uses Redis and Redis expects a three-node cluster for HA.

Below is the HA method of installing via kubectl.

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/ha/install.yaml

If you’re on a smaller cluster or a local cluster like Minikube or Kind, you can use the below deployment via kubectl.

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Once deployed, you will see several Kubernetes Resources get created.

After a few minutes, you should see all of the Resources running in the ArgoCD Namespace.

kubectl get all -n argocd

Now that the resources are deployed, you’ll need to access the instance of ArgoCD. Before that, you’ll need the ArgoCD initial password. The password exists in a Kubernetes Secret.

kubectl get secret -n argocd argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

Once you’ve received the password, you can log into the UI and access the dashboard.

kubectl port-forward -n argocd service/argocd-server :80

Access the URL from the port forward command and you’ll see the ArgoCD dashboard.

The username is admin and the password is what you retrieved from the Kubernetes Secret above.

To deploy workloads with ArgoCD, you have two options:

1. The UI
2. The CLI

The CLI is typically a better option as you can automate the process and you don’t have to click around a UI to get the job done.

When deploying workloads via the ArgoCD CLI, you’ll have to log into ArgoCD.

The username is admin and the password is the same password as the UI.

argocd login 127.0.0.1:argocd_port_here

Now that you’re logged into ArgoCD, let’s learn how to deploy Linkerd with ArgoCD.

Deploying Linkerd with ArgoCD

When you’re deploying a workload to ArgoCD, it doesn’t matter what the workload is as long as it’s in a Kubernetes Manifest.

It’s the same with deploying a Service Mesh like Linkerd.

When deploying a workload with the ArgoCD CLI, you’ll use the app create command which contains the following flags:

• Repo: Where the code exists.
• Path: The path to the code (Helm Chart, raw k8s Manifest, etc.).
• Destination: The destination Kubernetes cluster (local or an external cluster).
• Namespace: The Namespace that you want the workload deploy to.

For the purposes of this deployment, you’ll use the Linkerd Helm Chart. Helm is a great way to deploy Manifests in production as it gives you the ability to not only version what’s deployed, but to deploy workloads as a full stack vs raw Kubernetes Manifests.

First, create a new Namespace for the Linkerd k8s Resources to exist in.

kubectl create namespace linkerd

Next, deploy the Helm Chart for the Linkerd Custom Resource Definitions (CRD). Notice the Git repo and path.

argocd app create linkerdcrd --repo https://github.com/linkerd/linkerd2.git --path charts/linkerd-crds --dest-server https://kubernetes.default.svc --dest-namespace linkerd

Once deployed, you’ll see the workload now exists in the ArgoCD dashboard.

After syncing, you can see the full workload.

Now that the CRD’s are deployed, you can deploy the second Helm Chart for the Linkerd Control Plane/installation itself. It’s the same Git repo, just a different path.

The biggest difference you’ll see with this deployment compared to the CRD deployment is there are a few parameters. Linkerd requires the certs and keys to be present for mTLS when deploying with Helm.

With Helm Charts, you would use the --set-file flag to specify the certs and keys. With ArgoCD, you use the --parameter flag.

If you don’t already have certs and keys, you can learn how to generate them in the Deploying Linkerd In The Cloud blog post under the first section, Generating Certificates.

Once the certs/keys are generated, run the following ArgoCD CLI command and run it from the directory where the certs/keys exist.

argocd app create linkerdcp --repo https://github.com/linkerd/linkerd2.git --path charts/linkerd-control-plane --dest-server https://kubernetes.default.svc --parameter identityTrustAnchorsPEM=ca.crt --parameter identity.issuer.tls.crtPEM=issuer.crt --parameter identity.issuer.tls.keyPEM=issuer.key --dest-namespace linkerd

Once deployed, you’ll now see that the Linkerd Control Plane exists.

Linkerd is now officially managed by ArgoCD.