Star
This insightful blog post is brought to you by the highly skilled Kubernetes expert Michael Levan. With vast experience in cloud-native projects and a passion for fostering the tech community, Michael shares his expertise, helping engineers on their journeys. Enjoy reading!
In any production environment, ensuring that the current state is the desired state is key. If a code configuration looks one way and the environment looks another way, there are a lot of doors open for a fair amount of configuration drift.
In this blog post, you’ll learn about the best options to manage configuration drift in Kubernetes with GitOps.
What Is GitOps
GitOps can be defined as both configuration management and continuous delivery.
From a configuration management perspective, GitOps confirms that the current state of a deployed resource is the desired state. It does this by connecting to a Git-based source control system and scans the Kubernetes Manifests inside of a particular repo in an interval. For example, if you have a Kubernetes Manifest that’s a Deployment with two replicas, the GitOps Controller will continuously check the Kubernetes Manifest within the repository to confirm that the Manifest still says two replicas. If the replica count changes within the Kubernetes Manifest, the GitOps Controller will see that change and deploy the replica count change. If the Kubernetes environment has two replicas and the Manifest changes to three, the GitOps Controller will automatically get the third deployed.
From a continuous delivery perspective, taking the example from above, the third Pod is being deployed automatically for you. Much like in a continuous delivery (CD) pipeline, when you add/change code, the change gets deployed, and the GitOps Controller does the same thing.
GitOps Value Add
Manually deploying Kubernetes Manifests is a huge pain and it doesn’t scale. If you’re running a bunch of kubectl apply -f commands from your local terminal, it’s a terrible practice for a few reasons:
- No one else can run the Manifests.
- Your environment will be different from other environments.
- Your laptop isn’t shared amongst the team (I hope), so that solution won’t scale.
The next best option is using a CD pipeline. You could use a pipeline and run a bunch of kubectl apply -f commands within the pipeline. It’s a better option than running the commands on your terminal, but again, not the most efficient.
GitOps, on the other hand, is. It not only confirms that the current state is the desired state when looking at Kubernetes Manifests and your environment, but it automatically deploys the changes for you. It’s all hands which is great for the majority of teams.
Why GitOps May Not Be For You
In the previous section, there was a portion that described how continuous delivery
works in GitOps. Although this is a phenomenal implantation, like all
continuous delivery, it requires:
- Vigorous testing
- A lot of QA
- Hope
The truth is, there are a lot of environments that can’t click a button and have a resource automatically deploy because it’ll fail and require some manual intervention. It’s why the whole “deploy 10 times per day” thing sounded cool, but not everyone could achieve it. There could be many reasons from the testing process isn’t great or it’s a startup that simply cannot spend that much time testing.
In any case, the only real drawback to GitOps out of the box is the automated
deployments, which is ironically the reason why people want to use it.
GitOps Options
A GitOps Controller is like any other Kubernetes Controller. It has a reconciliation loop that gets run in an interval to confirm that the current state of the resource deployed to Kubernetes is the desired state. Many refer to this when they say Kubernetes does “self-healing”.
If you want to use a GitOps Controller, you’ll have to use a specific solution/tool.
The two most popular tools in today’s world are:
- ArgoCD
- Flux
From a conceptual perspective, they do the same thing. They’re both GitOps Controllers that give you the ability to deploy Kubernetes Manifests, Helm Charts, and Kustomize configurations. The biggest difference is that ArgoCD has gained a bit more popularity amongst engineers. It could be anything from the marketing that went behind it to subtle differences like the ArgoCD GUI vs the Flux GUI. ArgoCD also feels a bit more “enterprise-focused”, which makes it a go-to solution for many environments.
💡 A day before writing this, Weaveworks CEO (maintainers of Flux) announced that Weaveworks is shutting down. From an enterprise perspective, we know that means clients are being offloaded. From an open-source perspective, we don’t know what will happen to Flux. As per the LinkedIn post, there are still talks with CNCF about keeping Flux up and running.
Regardless of which solution you choose, even if it’s not listed in this section, just
remember that all GitOps Controllers are essentially doing the same thing. Yeah, they may have different GUIs and features, but underneath the hood, it’s all the same - confirming that the current state of an environment is the desired state of the deployed resource with reconciliation loops.
If you have any queries, don't hesitate to connect with us. Join the lively discussions and shared knowledge in our vibrant Discord Community.
