Exploring GitOps environment models for Kubernetes cluster management

Author: Moha Saaid - Site Reliability Engineer at Multilogin

In Kubernetes cluster management and application development, GitOps is revolutionizing how we handle infrastructure configurations. But how do GitOps work when choosing the suitable environment model? We'll delve into three popular options: Branch per environment, Folder per environment, and Repo per environment.

Spoiler alert: There's no one-size-fits-all answer, but each offers a unique approach to maintaining a desired state and audit trail.

Branch Per Environment: Popular but Problematic

Branching by environment is a popular approach in software development, often touted for its simplicity in CI/CD pipelines. The idea is straightforward: "Promotion is a simple git merge." For instance, pull requests make moving from QA to staging easy. Sounds easy, right? Well, not so fast.

The Pitfalls

• Maintenance Hell: With multiple environments, keeping track of configuration files becomes a nightmare.

• Environment-Specific Code: Allows for commits to specific branches, leading to non-generic projects.

• CI Strain: Your Continuous Integration system has to test each branch, adding unnecessary load on cloud infrastructure.

• Merge Fails: Pull requests and merges between branches can be problematic, affecting your continuous deployment strategies.

Real-World Scenarios

In practice, things are rarely that simple. For example, if someone changes the number of replicas in the QA branch, merging it into staging could inadvertently scale your cloud-native applications incorrectly.

Folder Per Environment: A Different Approach

Setting the Stage

Instead of branches, this model uses folders within a single branch for each environment. Before diving in, you'll need to understand your application's settings, which can be categorized as follows:

• Application Version: Defined by the container tag.

• Kubernetes Settings: Includes replicas, resource limits, and other Kubernetes-specific configurations.

• Business Settings: These are settings like external URLs and UI defaults unrelated to Kubernetes but crucial for application code.

The Structure

Each environment has its folder, making it easier to manage configurations without the complexities of branching. This approach leans heavily on declarative configuration and serves as a single source of truth in version control systems.

Repo Per Environment: The Segregated Model

The Basics

In this model, you'd have separate Git repositories for different environments. For example, one for production and another for non-production environments like Dev, DA, and Staging.

The Trade-offs

While this adds an extra layer of security, it complicates promotions. You'll need to check out two Git repositories before making any changes, but it does allow for more stringent security measures on the production repository.

This model benefits infrastructure and application settings requiring different access control levels.

Conclusion

Choosing the suitable GitOps environment model depends on various factors, such as your team's workflow, the complexity of your project, and your security requirements.

While branching is widespread, it's not without its pitfalls. Folders offer a more straightforward structure, and separate repositories provide added security. The GitOps workflow you choose will ultimately depend on the specific needs of your cloud-native applications and infrastructure configurations.