GitOps Repository Structures and Patterns Part 2: Operator Deployment Patterns

In this series of articles, I will introduce you to different structures and patterns that you can use to design your GitOps process. This part is about patterns in the area of operator deployments. These describe how many GitOps operators you deploy relative to Kubernetes clusters or namespaces. For an introduction into GitOps-repository patterns and structures, take a look at the [first part](/en/blog/gitops-repository-patterns-part-1-introduction "Introduction into GitOps-repository patterns and structures | Cloudogu Blog" of this series. The third part explains repository patterns, the fourth part promotion patterns and the fifth part wiring patterns. In the sixth part I show different implementations of the structures and patterns using example repositories.

"Instance per cluster" (synonym: "standalone") refers to the use of a GitOps operator with a Kubernetes cluster, see Figure 1. This pattern provides strong isolation. On the one hand, this has advantages in terms of security, since in the event of a breach, only the applications of the one instance are at risk. On the other hand, this approach scales better in terms of load and downtime. The disadvantage is the maintenance effort, since several instances have to be operated instead of one central instance. In addition, the resource requirements increase.

This contrasts with the "hub and spoke" pattern, see Figure 2, where a central GitOps operator is used for multiple Kubernetes clusters. Accordingly, the advantages and disadvantages are exactly inverted to the instance per cluster pattern: The maintenance effort is lower, but there is a single point of failure, which scales worse and is less secure.

The "instance per namespace" pattern (synonym "namespaced") is similar to "instance per cluster", but here one operator is operated per namespace instead of per cluster, see Figure 3. Using this pattern can be beneficial if a high level of isolation is desired, but the operation of separate Kubernetes clusters is out of the question. This may occur, for example, due to high on-premises costs or organizational constraints. In principle, this pattern has the same advantages as "instance per cluster". It should be noted that the isolation of Kubernetes namespaces is generally lower than for separate clusters. Also, it should be noted whether operators support subdivision into namespaces at all.

Beyond these basic patterns, there are hybrid patterns, such as those presented by Nicholas Morey in his article How many do you need? - Argo CD Architectures Explained. In his post A Comprehensive Overview of Argo CD Architectures, Dan Garfield also describes the patterns "Split Instance" and "Control Plane". From the author's experience, however, these do not (yet) play a central role.

Conclusion

With the different operator deployment patterns, there are currently three established approaches, each with their own advantages and disadvantages. Depending on your requirements, you can choose the one that suits you best.

In the following articles, repository patterns, promotion patterns, wiring patterns and real-life examples will be discussed.