Kubernetes & GitOps

What is GitOps

Git Versioning is the only source of truth in the GitOps concept. Everything must happen on Git, where it is automatically versioned and can be collaborated on, deployed, rolled back, and more.

Version control is used for everything in GitOps, from development to deployment.

Git versions and stores not only your core application code, but also your tests, infrastructure setup, images, deployment processes, release pipelines, and everything else relevant to the application.

Git thus becomes the shared, centralized repository where everything exists. The configuration and deployment processes that create and manage your environments are byproducts of code modifications, and this code exists alongside your application code and is treated in the same manner.

Having everything regarded as code and triggered from Git makes life much easier for developers and allows them to execute things that were previously reserved for operations teams.

Unlike the traditional approach, which separates Dev and Ops teams (those who develop the code and check-in their code versions on Git, and those who need to run the applications in production environments), GitOps allows developers to "build it" and "run it," all while focusing on the code and their familiar processes and repositories.

GitOps in Kubernetes

GitOps in Kubernetes relies around one critical principle that must be understood:

Kubernetes is a declarative system.

And, more than any other CI/CD tool (Jenkins, for example), Kubernetes and its declarative properties are what are now making GitOps practical in real time and at scale.

Because Kubernetes is a declarative system, it has a final vision of what the ideal cluster setup should look like and is constantly attempting to match it with the present situation. It constantly monitors and compares the system's present state to its desired stated state, and works automatically to ensure that the system is managed to retain its optimal required configuration.

Because developers identify the "end state" of the system they want to see, Kubernetes' declarative characteristic allows all configuration files to be version-controlled via Git.

Standardizing on Git processes makes it much easier to manage the entire system and, if necessary, recover/roll back to prior versions. Because both apps and infrastructure are fundamentally code, they can be versioned with IDs and timestamps and audited for modifications.

GitOps Best Practices in Kubernetes:

1. When feasible, use Kubernetes Operators.

Best practices suggest that existing Operators be used whenever possible rather than ad hoc, manual scripting. This is largely due to the difficulty of maintaining stateful applications or other complicated services in Kubernetes, which necessitates a great deal of knowledge gained via experience.

Custom Resource Definitions (CRDs) used by Kubernetes Operators are far more efficient than in-house alternatives. Using approved operators created by the community or trustworthy suppliers guarantees that you standardise on the finest tools for the job while also benefiting from the contributor's experience with the specific service you're deploying.

For example, instead of re-scripting the entire configuration and deployment procedure from scratch, utilizing an existing Operator to deploy a relational database on your Kubernetes cluster may be a better strategy.

2. Using Branches instead of repositories

While having numerous repositories has advantages (clear ownership, etc.), this architecture becomes overly difficult as you go up. Furthermore, because each team effectively has different repositories for development, staging, and production, getting a solid overview of the system as a whole is difficult.

When each team is exclusively concerned with a single service, personnel who are familiar with the entire platform become scarce.

Reducing the number of repositories benefits developers greatly because it not only saves time but also makes the duties of sharing code, debugging, and providing feedback much easier.

The best GitOps practice is to have one repository per team, and when more repositories are required, use branches instead. Of course, there is no one-size-fits-all solution for the number of repositories, but it is beneficial to provide each team its own repository so that development is not hampered. Using branches at the same time will help you avoid repository bloat.

3. Push over Pull

Gitops relies on pull requests to publish new code.

A pull request is similar to an application that you submit to have your changes moved through the workflow, and it is usually accompanied by a large amount of supporting information.

This additional information about why the changes were made and who made them makes debugging and troubleshooting much easier.

For the reasons stated above, it is best practice to avoid pushing anything directly to masters unless absolutely required and instead rely on Pull requests. Furthermore, push requests expose your cluster credentials over the network unnecessarily, whereas pull requests cause Kubernetes Operators to deploy fresh images from within the cluster. The Operator also monitors configuration settings for changes and initiates "convergence" when it detects one.

4. Automation, automation, automation

When it comes to GitOps and jobs that must be performed "exactly" the same way, keeping the "human element" out of the picture is best practise. A hands-off approach is essential here, and every operation must be handled by a script that has already been checked for problems. Git webhooks are used to do this, and they are triggered in response to application updates that have passed the screening procedure.

5. GitOps plus Observability

By monitoring the system and the state of your clusters and applications for anomalies and tying this data to Git trigger processes — such as in the case of a failure, bottleneck, or other incidents — you can automate response to Production issues and accelerate recovery, as well as auto-rollback if necessary.

Conclusion

Finally, GitOps bridges the gap between your repositories and your actual environment, allowing you to use version control to manage not only your application code, but also your environment and processes. GitOps enables developers to manage the operations of their code as well, allowing them to be self-sufficient and "operation agnostic."

Summarize

I discovered GitOps a few years ago and immediately fell in love with it. We began working with it because many of our clients choose to utilize it. We looked at how GitOps works with Kubernetes today.

That's all for today. 👋

Thank you for reading to the end!

Career tip! I'm not sure how you do it, but please 😅 click the Green Follow Button on the top right side.

If you found my article useful, please SHARE it with your colleagues and CLAP (up to 50!), follow me on Medium, and connect with me on LinkedIn to remain up to speed on my new articles. 🤩