Does GitOps Provide the Key Fix for Kubernetes’ Complexity?

Let’s just say that Kubernetes remains complex and difficult. Managing Kubernetes clusters and deploying applications on Kubernetes clusters is a complex process at best and it will be a while at least before these complexity issues are solved. The environment can be especially daunting for small- and medium-sized enterprises that often do not have the resources to go cloud native.

But organizations are learning and the number of new users who will eventually gain expertise continues to gather momentum — and cloud native’s success owes much of its present and future success to GitOps. Since Alexis Richardson, founder and CEO of Weaveworks, first coined the term GitOps, the framework has steadily seen adoption as a way to support Kubernetes environments for some, and as a way to solve most of what ails Kubernetes for others.

The recently held conferences of Rejekts (the conference created to give a second chance for those great talks that did not make the KubeCon cut) and KubeCon + CloudNativeCon included a number of interesting and well-attended talks. During the day-long ArgoCon co-located event, the auditorium was packed to the hilt and the Flux project meeting was well-attended during KubeCon + CloudNativeCon. GitOps was the subject of several talks during Rejekts and KubeCon + CloudNativeCon. The excitement and optimism expressed about how GitOps can continue to support the adoption of Kubernetes was palpable.

The reduction in complexity, security-management capabilities and other benefits when working with Kubernetes clusters that GitOps offers ultimately serves as an enabler for organizations to scale when working with the clusters.

GitOps makes Kubernetes adoption scalable — developers and operators involved in the release process deliver their contribution in the form of declarative code that specifies the desired state of the overall application. This ensures the consistent configuration of the entire application stack with its hundreds of parameters and seemingly thousands of opportunities for seemingly innocent but ultimately costly mistakes, by relying on a controller that automatically reconciles the actual state of the application with the desired one,” Torsten Volk, an analyst for Enterprise Management Associates (EMA), said. “Should something go wrong, the controller can quickly roll back the application, including all of its dependencies, to its previous state. This lowers the stress and risk that typically comes with each release and at the same time it simplifies security audits by maintaining a complete history of all changes to any part of the app stack.”

The Best Best Practices

OpenGitOps — a GitOps working group under the CNCF App Delivery SIG —  is a set of open source standards, best practices and community-focused education to help organizations adopt a structured, standardized approach to implementing GitOps. It describes GitOps Principles as:

1. Declarative: A system managed by GitOps must have its desired state expressed declaratively.
2. Versioned and Immutable: Desired state is stored in a way that enforces immutability, versioning and retains a complete version history.
3. Pulled Automatically: Software agents automatically pull the desired state declarations from the source.
4. Continuously Reconciled: Software agents continuously observe actual system state and attempt to apply the desired state.

The end result is that replacing scripted application releases with declarative ones leaves it to the controller of the continuous delivery platform to establish and protect the desired state of the application stack when using GitOps, Volk said. “This approach achieves an ultimate degree of consistency as everything that is needed to deploy, run and manage the application is safely stored within a universal code repository,” Volk said. “New applications will reuse all of the generic parts of this code and can receive the same patches, updates and configuration changes across the entire organization.“

For the developer, the key benefits are clear: When working with GitOps framework, the developer does not necessarily have to master the workings of YAML files and even Jenkins nor do they have to understand all the different operations infrastructure and complex workings of Kubernetes whether it’s the node structure, namespace etc. The developer ideally, working with GitOps with such open source alternatives as Argo CD and Flux can do their work of creating applications and loading them on Git without — ideally — having to have a deep understanding of Kubernetes.

For the operations teams, GitOps can solve many of the security concerns that plague Kubernetes. With this push and pull model and structure, GitOps ops can take much of the load off of your operations teams who will almost unanimously say that Kubernetes management and security is a challenge at best.

Additionally, GitOps through policy as code and other means can be used for resource savings. It can prevent developers from inadvertently running up major cloud-use bills when working with clusters. For operations teams, GitOps can help to better manage cloud resources, by helping to prevent redundancy of unused cluster resources.

Do best practices differ between #ArgoCD and @fluxcd? Or is this list for all #GitOps best practices in general? @VMware's @ping_Unnati's great talk "Deploying with Confidence: Best Practices with Argo CD" begged this question. @rejektsio #opensource #KubeConEU #kubeconeurope pic.twitter.com/XqwFk4nwkD

— BC Gain (@bcamerongain) April 17, 2023

Again, GitOps is designed to induce simplicity into the process of developing, deploying and managing applications running in Kubernetes environments. Unnati Mishra, a working member the technical staff at VMware, explained during her talk “Deploying with Confidence: Best Practices with Argo CD”, how GitOps makes it “easy for everyone to collaborate on your project.” “You can deploy your application after testing.”

Indeed, GitOps is “quite powerful” for deploying applications on Kubernetes, Selvi Kadirvel, a platform architect and engineer at Elotl, said during her Rejekts talk “The missing piece of your GitOps pipeline.”  Organizations can further take advantage of GitOps “power” by using multi-cluster orchestrators, Kadirvel said. She said during her talk that this allows organizations to:

• Dynamically map workload to clusters.
• Track current clusters and their resource availability, to “make more intelligent business decisions.”
• Migrate workloads across fleets of clusters when applicable.

Argo CD and Flux: It’s Flamingo

👁 Image

Both Argo CD and Flux have their uses and variances, which have been previously covered. That said, Argo CD — like Flux — takes advantage of the history available in Git to make it possible to easily audit the change history or revert back to previously working versions before a breaking change was applied. However, Flux’s and Argo CD’s workflows and extensions are different.

Open source Flamingo, the Flux subsystem for Argo introduced shortly before KubeCon + CloudNativeCon, integrates Flux into Argo CD for what Weaveworks, the company behind Flamingo, said offers a “seamless” GitOps experience with Kubernetes clusters.

“Flux has superpowers like Terraform and Pulumi and CloudFormation integration.  Flamingo lets users access these Flux superpowers from Argo,”  Richardson told The New Stack. “Overall Flux is a great platform engineering tool with the potential to become a universal deployment engine.  Being able to use dev tools like Argo on top of Flux is compelling.”