GitOps as an Evolution of Kubernetes

VANCOUVER, British Columbia — Many people talk about GitOps and Kubernetes, but when Brendan Burns, a Microsoft Corporate Vice President, a Distinguished Engineer at Microsoft Azure, and, oh yeah, co-founder of Kubernetes, talks, I listen. Burns spoke at The Linux Foundation’s GitOpsCon about how GitOps is an evolutionary step for Kubernetes.

How? Burns started by explaining how it’s deeply rooted in the development of continuous integration, deployment, and delivery. What really motivated him to help create Kubernetes was, “When we were starting out, we tried to put together reliable deployments. They worked on this using the DevOps tools of the time with a mixture of Puppet, Chef, Salt, and Ansible — and Bash obviously — it worked about 85% of the time. And then you’d massage it, and it eventually would work maybe 95% of the time:  However, the journey was often fraught with difficulties and uncertainties, which birthed the idea of Kubernetes.

Kubernetes’ inception was essentially a response to the arduous and unreliable nature of the deployment process. It was a fusion of the DevOps challenges and the innovative strides Docker made in the container revolution. Docker’s focus on hermetically sealing and packaging applications was a vital prerequisite to reimagining how deployments could be executed. Over the past decade, this approach has transformed into the standard modus operandi within the tech community.

Advent of GitOps

But the tech world has now moved a step further with the advent of GitOps. It’s no longer aimed at redefining the deployment process itself. It is no longer just about leading into the deployment that Kubernetes orchestrates but the entire journey — from sourcing configurations to deploying them into the world where Kubernetes can utilize them.

GitHub, with its declarative configuration, now plays a pivotal role in ensuring reliable delivery and contributes to the ongoing evolution of the community. “While it’s universally accepted now,” said Burns, “the idea was a subject of contention at the time.” Scripting was rampant. Notably, the CI/CD pipeline, even when described in YAML, was an imperative program execution. Burns thinks GitOps, with its inherent declarative nature, is a welcome reinforcement to the Kubernetes ecosystem.

Moreover, empowering people to do more was another central theme of our initial thought process. The goal was to alleviate the burdens that plagued developers daily. This, in essence, is the journey of the community — from its inception rooted in deployment and continuous delivery to the present day, where GitOps reigns, offering a more reliable, declarative, and user-empowering approach to managing deployments.

It does this in several ways:

1. Separation of Concerns: With Kubernetes and GitOps, teams can be compartmentalized, focusing on specific tasks and responsibilities. This clean delineation can help avoid confusion, improve efficiency, and make it clear where one team’s responsibilities end, and another begins.
2. Multiple Personas: In modern software development, there are many personas involved, such as developers, platform engineers, and security teams. Each has a specific role and responsibilities, and all need to work together in the same environment.
3. GitOps as a Solution: GitOps can help manage this complex environment. It allows each persona to manage a Git repository, rather than needing to directly interact with the cluster. This can reduce the risks associated with one group having too much control and can make it easier for teams to work together. It essentially allows for a clearer division of labor and less risk of overlap or conflict.
4. Automated Updates: GitOps can also facilitate automatic updates. Tools such as Dependabot can monitor repositories and propose updates when necessary. This process reduces the time and effort required to stay up to date, increasing efficiency and reducing the risk of falling behind on important updates.
5. Security and Compliance: GitOps also supports better security and compliance. Through a well-managed Git repository, it can ensure that every change is tracked and auditable, which is important for meeting compliance requirements.

The GitOps workflow and its intersection between platform engineering and the developer is particularly significant for programmers who prefer not to be bogged down by the intricacies of deploying their code into Kubernetes. Irrespective of their preferred programming language — be it Java, Python, Dotnet, Rust, or Go — they simply want to push their code, generate a container image, and have it deployed immediately. GitOps enables them to do this.

Scalability

Burns continued, the beauty of GitOps lies in its scalability. Developers need not be overly concerned with the number of clusters in their organization or their specific locations. The shift from a push model of pipelines to a GitOps pull model allows a level of abstraction where the number of clusters becomes somewhat irrelevant. Developers only have to deal with a Git repository. If a new cluster emerges or an old one disappears, developers may not even notice.

The consistency of the workflows remains even when transitioning from early pre-production to staging to production in the application lifecycle. This decreases the cognitive load on developers, allowing them to concentrate more on their code rather than where it goes post-deployment.

Thus, in GitOps, the Git repository becomes the ultimate source of truth, and the platform engineering team can concentrate on initializing that Git repository, thus empowering developers to efficiently deploy their code.

Burns also reminded us that historically, the concept of “snowflakes” (One-off unique servers impossible to reconstruct if they “melted”) was a cause of concern. True, containers and orchestration eliminated this problem at the individual container level. However, we now face the issue of “snowflake clusters” — clusters of machines that are uniform internally but differ from others.

GitOps, Burns said, offers a robust solution for this issue. The shift from a push to a pull model makes GitOps relatively indifferent to the scale or number of clusters. Each cluster is configured to point to the same Git repository. When you make the Git repository initialization part of creating clusters, it automatically creates clusters that are initialized with the correct software versions.

Thus, this process ensures consistency across the platform. For example, it also eliminates the chances of forgetting to include a cluster in a pipeline that deploys a new version of security software or having to inform a development team about changes in regions. This consistency and reliability are among the main advantages of GitOps.

Interestingly, the application of GitOps is not restricted to Kubernetes but extends to public cloud resources through service operators. Users are leveraging the Kubernetes control plane to manage containerized resources and instances of a Postgres database or blob storage system. GitOps can manage resources within your cluster as well as those in the cloud, thus widening its scope and utility.

No Be-All, End-All

However, GitOps is not the be-all and end-all solution There’s a place for both CI/CD pipelines and GitOps, “It’s not a fight, but rather it’s two very complementary technologies, one that is very good at easily making the state real and one that is very good at orchestrating stages of what you want the world to look like.

Drawing parallels with robotics, which Burns worked on before he came to software, there’s a constant handoff between control and planning, one can understand the relationship between traditional CI/CD pipeline systems and GitOps. GitOps is like a controller, quickly making a state reality, but it’s not ideal for software rollouts on a global scale that requires slow, gradual deployments. This is where traditional CI/CD systems, or “planners,” come into play.

So, Burns concluded, CI/CD pipelines and GitOps each have their strengths — GitOps in bringing a specific state into reality with ease, and traditional CI systems in orchestrating stages of what the world should look like. Understanding the value of GitOps in the container context and its interplay with traditional CI systems can significantly enhance efficiency and productivity. And all, of course, will work well in a Kubernetes-orchestrated world.