---
title: "Scaling GitOps: The \"pull\" architecture for global fleets"
description: "Red Hat conducted a performance and scale test of the argocd-agent pull architecture for GitOps, using 42 physical machines, 500 spoke clusters, and software including OpenShift 4.21 and OpenShift GitOps 1.20. The pull model decentralizes reconciliation to lightweight agents on each managed cluster, which pull configurations from a central hub, improving security by eliminating inbound administrative ports and reducing cross-cluster network traffic by up to 80%. In the bootstrap scenario, generating and syncing 31,200 applications across 480 clusters completed in 13 minutes 3 seconds, while the sync-to-commit scenario, which includes a polling delay, took 13 minutes. The test revealed bottlenecks including Kubernetes API limits on the hub, informer processing slowdowns causing watch restarts, event writer retry issues under load, and ApplicationSet controller RAM consumption. The team also deleted all 31,200 applications in 4 minutes 53 seconds using cascading deletion, and the insights are informing future OpenShift GitOps releases."
---

# Scaling GitOps: The "pull" architecture for global fleets

[Red Hat](https://yomu.fyi/company/red-hat) · Jann Fischer, Pradeep Surisetty, Sho Weimer, Jan Hutař, Alex Krzos, Mike Ng · Sep 24, 2026

**Type:** Benchmark

## Summary

Red Hat conducted a performance and scale test of the argocd-agent pull architecture for GitOps, using 42 physical machines, 500 spoke clusters, and software including OpenShift 4.21 and OpenShift GitOps 1.20. The pull model decentralizes reconciliation to lightweight agents on each managed cluster, which pull configurations from a central hub, improving security by eliminating inbound administrative ports and reducing cross-cluster network traffic by up to 80%. In the bootstrap scenario, generating and syncing 31,200 applications across 480 clusters completed in 13 minutes 3 seconds, while the sync-to-commit scenario, which includes a polling delay, took 13 minutes. The test revealed bottlenecks including Kubernetes API limits on the hub, informer processing slowdowns causing watch restarts, event writer retry issues under load, and ApplicationSet controller RAM consumption. The team also deleted all 31,200 applications in 4 minutes 53 seconds using cascading deletion, and the insights are informing future OpenShift GitOps releases.

## Context

Traditional push-based GitOps requires the hub to hold high-level credentials for every cluster and creates bottlenecks as the hub observes all resources. The pull model with Argo CD Agent decentralizes reconciliation to agents on each spoke cluster, improving security and network efficiency.

## Approach / What changed

Deploy a lightweight Argo CD Agent on each managed cluster that pulls configuration from a central hub. The hub generates ApplicationSets and Applications, and agents reconcile locally. Testing used 500 spoke clusters with up to 31,200 applications and 3.12 million resources across two scenarios: bootstrap and sync-to-commit.

## Takeaways

- The pull architecture reduced cross-cluster network traffic by up to 80% compared to the traditional push model.
- Bootstrap sync of 31,200 applications across 480 clusters completed in 13 minutes 3 seconds; sync-to-commit took 13 minutes.
- The Kubernetes API and etcd on the hub became the primary rate-limiting factor at scale, requiring QPS limits to avoid overwhelming the API.

## FAQ

### What is the main difference between push and pull GitOps?

In push GitOps, a central hub pushes configurations to spoke clusters, requiring high-level credentials for each spoke. In pull GitOps, a lightweight agent on each spoke pulls configurations from the hub, improving security and reducing network traffic.

### How many clusters and resources were tested?

The test used up to 480 spoke clusters with 31,200 applications and 3.12 million resources. The environment included 42 physical machines and 500 virtual machine clusters.

### What were the main bottlenecks found?

The main bottlenecks were Kubernetes API limits on the hub, informer processing slowdowns causing watch restarts, event writer retry issues under load, and ApplicationSet controller RAM consumption.

**Tags:** [Argo CD](https://yomu.fyi/topic/argocd), [GitOps](https://yomu.fyi/topic/gitops), [Kubernetes](https://yomu.fyi/topic/kubernetes), [Performance](https://yomu.fyi/topic/performance), [Scalability](https://yomu.fyi/topic/scalability)

- Source: [Red Hat](https://developers.redhat.com/articles/2026/09/24/scaling-gitops-pull-architecture-global-fleets)
- Source URL: https://developers.redhat.com/articles/2026/09/24/scaling-gitops-pull-architecture-global-fleets
- Ingested by Yomu: 2026-09-24T15:00:10.389Z

[Read original post](https://developers.redhat.com/articles/2026/09/24/scaling-gitops-pull-architecture-global-fleets)