In recent years, working as a consultant in the technology field, I’ve observed how companies have increasingly adopted multi-cluster strategies using Kubernetes and OpenShift. These strategies generally aim to distribute workloads across clusters for reasons such as team segmentation or to enhance system resilience and availability.
To support this approach, delivery automation and pipeline standardization have become essential to ensure consistency, auditability, and scalability — while also providing operational control and efficiency.
In this article, I show how Red Hat Advanced Cluster Management for Kubernetes (RHACM) enables a Hub-and-Spoke GitOps architecture integrated with Argo CD.
The practical foundation for this article is the GitOps Pull Model repository, which provides a simplified implementation of the proposed model.
But… What is GitOps?
GitOps is a declarative approach to infrastructure and application management that relies on Git as the single source of truth and leverages continuous automation to apply changes. Instead of executing manual commands or scripts directly against clusters, the desired state of the environment is versioned in a Git repository, and automated tools, like Argo CD, are responsible for reconciling that state with the actual environment.
This strategy brings several key benefits:
Auditability and traceability: Every change is recorded as a Git commit, enabling full visibility and review history.
Reproducibility and consistency: Environments can be rebuilt from the repository, minimizing drift and human error.
Security and control: By separating change approval (via Git) from change application (via automation), access to clusters can be tightly controlled.
Speed and scalability: Applications and configurations can be propagated efficiently and safely across multiple clusters.
GitOps extends familiar software development concepts — such as pull requests, CI/CD, and versioning — into the realm of infrastructure operations, unifying delivery processes with modern DevOps practices.
What is a Hub-and-Spoke Architecture?
In environments with only a few Kubernetes clusters, it’s common for each cluster to have its own Argo CD instance, directly managed by the development team or even a dedicated DevOps team. However, this approach becomes difficult to scale in dynamic environments where clusters are frequently provisioned and decommissioned.
To address this challenge, the Hub-and-Spoke model offers a well-established architectural pattern in distributed systems, where a central component (the Hub) coordinates or manages multiple peripheral components (the Spokes). In Kubernetes or OpenShift environments, this pattern proves especially useful for centrally managing a large number of clusters.
In a GitOps and multi-cluster management context, the architecture can be described as follows:
Hub: A central cluster, often running management tools like Red Hat Advanced Cluster Management (RHACM), responsible for registering, inspecting, and applying policies to the Spoke clusters.
Spokes: Managed clusters that operate independently but are governed by configurations or policies originating from the Hub. Each Spoke typically runs its own GitOps agent (e.g., Argo CD) and pulls its desired state from a shared Git repository.
The RHACM GitOps - Pull Model
Implementing a Hub-and-Spoke architecture can require significant effort from DevOps teams. To simplify this process, Red Hat Advanced Cluster Management (RHACM) provides built-in mechanisms that streamline the deployment of this model.
RHACM includes controllers that process Argo CD ApplicationSets and distribute the resulting Applications to managed clusters that match predefined Placement criteria. Notably, the Hub cluster does not execute or reconcile these applications itself. Instead, it delegates this responsibility to the target managed clusters.
The diagram below illustrates how this delegation and synchronization flow works in practice:
Once the Argo CD Applications are applied to the managed clusters, they begin reporting their status back to the Hub cluster.
For more details on this capability, refer to the official documentation:
Red Hat Advanced Cluster Management — GitOps Integration Guide
Bridging Theory and Practice
The GitOps Pull Model repository presents a simplified implementation of the GitOps Hub-and-Spoke architecture, where each Spoke cluster operates independently and pulls from a shared Git repository. Although intentionally minimalistic, the project effectively demonstrates the core principles of GitOps in multi-cluster environments — with a key role played by Red Hat Advanced Cluster Management (RHACM).
The Role of RHACM
RHACM acts as the control plane for the Hub cluster, automating and orchestrating the following tasks:
Automated installation of the OpenShift GitOps Operator: RHACM applies policies that ensure all clusters have the necessary operator installed, enabling the provisioning of Argo CD instances.
Declarative Argo CD configuration on the Hub cluster: A dedicated policy configures the Argo CD instance on the Hub, centralizing control and initial setup.
Provisioning Argo CD on managed clusters: RHACM applies policies that deploy and configure Argo CD on each Spoke, so each cluster operates its own independent GitOps instance.
Selective artifact distribution via Placements: Through the use of
Placements, RHACM informs its Argo CD instance which clusters must receive the configurations, based on labels assigned to the managed clusters. This allows centralized governance with flexible scope.
This architecture balances centralized governance and visibility (via the Hub) with decentralized execution (via the Spokes), enhancing security, scalability, and standardization across clusters.
Benefits of the Pull Model in Multi-Cluster Environments
Adopting a GitOps approach based on the pull model, especially within a Hub-and-Spoke architecture, unlocks several strategic and operational advantages. This choice directly promotes:
Enhanced Security
Communication flows from the managed clusters to the Git repository, removing the need for direct Hub access and significantly reducing the attack surface of the overall system.Operational Autonomy for Spokes
Each managed cluster runs its own Argo CD instance and applies its own manifests, enabling independent operation with local control and greater agility in managing workloads.Horizontal Scalability
Adding new clusters does not impact the Hub’s performance, as each Spoke synchronizes independently and asynchronously, allowing the architecture to scale linearly and efficiently.Native Auditability and Traceability
With all configurations version-controlled in Git, changes can be tracked accurately, history is preserved, and rollbacks are safe and straightforward to execute.Seamless Integration with DevSecOps Practices
Centralizing the desired state in Git supports automated validations, pull request-based code reviews, and CI/CD pipelines that are decoupled from runtime environments.Elimination of Single Points of Failure
Since each Spoke manages its own sync operations, a failure in the Hub does not affect the Spokes, which continue operating based on the last known Git state — improving overall system resilience.
Conclusion
The GitOps Pull Model, provided by RHACM, offers a powerful foundation for scalable, secure, and autonomous Kubernetes and OpenShift operations. By adopting this approach, organizations can reduce operational complexity and improve governance across distributed environments.
Credits and References
This article was written to provide theoretical background for the GitOps Pull Model Repository:
… which showcases a working example of a multi-cluster GitOps architecture using Red Hat Advanced Cluster Management (RHACM).
Both the conceptual and practical aspects are based on the following reference:
Top comments (2)
this was kinda awesome to read imo - always makes me wonder if there’s a real sweet spot between central control and letting clusters do their own thing
Some comments may only be visible to logged-in visitors. Sign in to view all comments.