A Practical Guide to Operating Kubernetes the GitOps Way
Take a look at how Git and its version control capabilities can benefit you within your DevOps pipeline.
Join the DZone community and get the full member experience.Join For Free
What is GitOps?
“GitOps” is the term we use to describe the way we rely on developer tooling to drive operations. It is an operating model for cloud-native applications such as Kubernetes that enables continuous delivery through automated deployment, monitoring, and management by using Git as the “single source of truth.”
Why Do We Love GitOps?
We love GitOps because it delivers core cloud-native benefits such as agility, reliability, and speed. A GitOps pipeline enables developers to speed up development and to safely and securely make changes to complex applications. It also gives developers the freedom and flexibility to choose the tools that they are familiar with and that work best in their dev environments. Developers can work with either open source and closed source tools, whatever they prefer.
Aside from the freedom it offers, both enterprise and startup development teams can implement a GitOps approach for more stability and reliability over a typical CI/CD pipeline.
One of the improvements a GitOps deployment pipeline provides over a traditional CI/CD pipeline is a clear separation of common security concerns. With a traditional CI/CD pipeline, developers often need to share the API credentials of their Kubernetes cluster with their CI tooling. With GitOps, this is no longer the case, making it a more secure way of delivering updates to your cluster.
There are four key principles of GitOps that drive its implementation:
1. The Entire System Is Described Declaratively.
Kubernetes is just one example of many modern cloud-native tools that are “declarative” and that can be treated as code. Declarative means that configuration is guaranteed by a set of facts instead of by a set of instructions. With your application’s declarations versioned in Git, you have a single source of truth. Your apps can then be easily deployed and rolled back to and from Kubernetes. And even more importantly, when disaster strikes, your cluster’s infrastructure can also be dependably and quickly reproduced.
#2. The Canonical Desired System State Is Versioned in Git.
With the declaration of your system stored in a version control system, and serving as your canonical source of truth, you have a single place from which everything is derived and driven. This trivializes rollbacks, where you can use
git revert to go back to your previous application state. With Git’s excellent security guarantees, you can also use your SSH key to sign commits that enforce strong security guarantees about the authorship and provenance of your code.
3. Approved Changes to The Desired State Are Automatically Applied to The System.
Once you have the declared state kept in Git, the next step is to allow any changes to that state to be automatically applied to your system. What's significant about this is that you don't need cluster credentials to make a change to your system. With GitOps, there is a segregated environment that the state definition lives outside of. This allows you to separate what you do and how you're going to do it.
4. Software Agents Ensure Correctness and Alert on Divergence.
Once the state of your system is declared and kept under version control, software agents can inform you whenever reality doesn’t match your expectations. The use of agents also ensures that your entire system is self-healing. And by self-healing, we don’t just mean when nodes or pods fail—those are handled by Kubernetes—but in a broader sense, like in the case of human error. In this case, software agents act as the feedback and control loop for your operations.
What Happens when You Adopt GitOps?
Introducing GitOps into your organization means:
- Any developer that uses Git can start deploying new features to Kubernetes.
- The same workflows are maintained across development and operations.
- All changes can be triggered, stored, validated and audited in Git.
- Ops changes can be made by pull request including rollbacks.
- Ops changes can be observed and monitored.
Since all of your developers are already living in Git, incorporating GitOps into your organization is simple. Having everything in one place means that your operations team can also use the same workflow to make infrastructure changes by creating issues, and reviewing pull requests. GitOps allows you to roll back any kind of change made in your cluster. In addition to this, you also get built-in observability, which enables your teams to have more autonomy to make changes.
Download our Practical Guide to GitOps and start operating Kubernetes the GitOps way. This guide walks you through principles, benefits and what to expect when you start adopting the GitOps methodologies. Also included in the guide is an in-depth hands-on tutorial that shows how to build an end-to-end CI/CD pipeline and deploy changes to Kubernetes using GitOps best practices.
Opinions expressed by DZone contributors are their own.