Getty Images
Testing automated Kubernetes deployments, a GitOps benefit
GitOps and GitOps tooling may be your answer to the tricky, taxing problem that is testing Kubernetes environments. Explore why, how and what's necessary to perform GitOps testing.
When you think about Kubernetes deployments, the first thing that typically comes to mind is: How can I automate this? In a world filled with automation and DevOps-centric tooling, it's a cumbersome process for developers to manually deploy an application to Kubernetes.
For a software engineering team to remove the manual footprint from its Kubernetes deployments, it should adopt GitOps. Let's see how testers can use GitOps to test their Kubernetes environments.
What is GitOps?
In its most basic form, GitOps is like configuration management. Configuration management was originally designed to have multiple servers connect to a main server to retrieve configuration information, such as how to install an application or a service like SQL Server that runs a script for some automation. The ultimate goal was to ensure that the services always had the same configuration running and the configurations were exactly what the engineer expected.
GitOps is a way to automatically deploy and define exactly what developers want to run in Kubernetes. It could be anything from Kubernetes deployments to services or any other workload that you choose to run on a Kubernetes cluster.
The main server -- like in configuration management -- is a Git-based source control system. As such, this means that the code in, for example, a GitHub account, is the source of truth for what a team should deploy to Kubernetes. Kubernetes is then set up to have an interval checker that looks at GitHub every, say, five minutes, and confirms that what's running on Kubernetes is what's in source control. If it's not, Kubernetes attempts to retrieve the code configurations from source control.
At a high level, developers can use GitOps to ensure that Kubernetes runs applications, services and/or deployments exactly how the dev team expects them to run.
GitOps tooling
When it comes to tools that engineers can use for testing their automated deployments on Kubernetes, there's no shortage of vendor or open source options to set up a GitOps environment. Three popular options include:
- Flux CD
- Argo CD
- Weave GitOps
Developers just starting with GitOps tend to choose Flux CD. Flux CD is a GitOps operator and runs as a deployment application on a Kubernetes cluster. The project is used to synchronize manifest files from a Git-based source control system -- like GitHub -- to ensure what's running on the Kubernetes cluster is what's in the GitOps manifests. Flux CD ensures that the Kubernetes cluster runs the proper applications from Git by watching the Kubernetes manifests to see if any changes occur. If a change occurs, Flux CD deploys the new changes to the Kubernetes cluster.
Argo CD is a continuous delivery and deployment tool specifically set up for GitOps. This controller is declarative by nature, which means it describes what the deployments are doing, not how they're doing it. Within the tool itself, Argo CD also has synchronization abilities to ensure that the Kubernetes cluster runs the specific applications and Kubernetes manifests declared in source control. The tool is like Flux CD with its synchronization features, but Argo CD has better functionality with its multi-cluster deployment management. Argo CD also has a UI that developers can use to manage the deployments.
Weave has a free, open source option called GitOps Core as well as a paid version called GitOps Enterprise. Similar to Argo CD, Weave GitOps Core is an open source continuous delivery tool used to deploy Kubernetes applications. The enterprise version provides a management console/UI, collaboration with teams and extra security features.
Get started with GitOps testing
Before teams start GitOps testing, they'll need the following four components:
- a Kubernetes cluster
- a source control system
- a GitHub account
- an application to deploy
First, the team will need a Kubernetes cluster. Testers can use GitOps on any type of Kubernetes cluster, such as AKS in Azure or EKS in AWS. If the team is running Kubernetes on premises or managing the master and worker nodes itself, testers can use GitOps with that, too. If a running Kubernetes cluster has an available resource to deploy one of the aforementioned GitOps tools/platforms, it will also work.
After the Kubernetes cluster is up and running, testers will then need to set up a Git-based source control system. The source control system is where the team will store Kubernetes manifests for deployments, services, ingress and so on. Testers looking to get started with a free Git-based source control system should consider GitHub.
Next, the team will need to decide which GitOps system it wants to use. For example, if it chooses Flux CD, team members will need to go through the setup configuration to deploy the tool to the Kubernetes cluster. Once the tool is deployed to Kubernetes, it will constantly check the Git-based source control system to confirm the Kubernetes manifest configurations.
When the Kubernetes cluster, source control and GitOps tool are configured, someone on the team will need to create a Kubernetes manifest. The Kubernetes manifest can be for any application. Also, the Kubernetes website provides an Nginx example.
After all of this is configured, a team's testers can perform GitOps tests to ensure that the Kubernetes manifests in source control deploy and synchronize properly to a Kubernetes cluster.
