Skip to content

CONCEPT Cited by 1 source

Bundled GitOps dependency anti-pattern

Definition

Bundling a GitOps controller (e.g. FluxCD, ArgoCD) as a hidden internal dependency of a Kubernetes Operator or similar vendor-shipped platform component is a structural anti-pattern. The vendor gets faster feature velocity (the GitOps tool's reconcile-from-Git mechanics are free to the operator) but the customer pays three costs:

  1. Ecosystem divergence — the operator doesn't look like other operators (which don't ship a GitOps controller inside them); customers don't know how to inspect, configure, or debug it via the idioms they've learned for the rest of their stack.
  2. Dependency conflict — customers who already run the same GitOps controller for their own manifests get two competing installations in the same cluster, with version skew and CRD ownership ambiguity.
  3. Release-cadence coupling — the vendor's operator releases become gated on the bundled tool's release cycle, and every bundled-tool CVE becomes the vendor's responsibility to patch and re-release.

Canonical wiki instance

Redpanda's customer-facing Redpanda Operator bundled FluxCD as an internal dependency — Flux was used to wrap Redpanda's Helm chart and drive lifecycle management. The operator shipped faster, but Redpanda disclosed the anti-pattern verbatim:

"While bundling FluxCD made initial development easy, we found that customers were confused — bundling made our initial version of the customer-facing operator quite different from others in the Kubernetes ecosystem. Additionally, some customers were already using FluxCD, which conflicted with our bundled version. Lastly, having FluxCD and the Helm chart as dependencies made it challenging to combine both operators so our cloud team could easily manage our cloud deployments."

(Source: sources/2025-05-06-redpanda-a-guide-to-redpanda-on-kubernetes)

Fix shipped across three operator branches:

  • v2.3.x — FluxCD made optional via spec.chartRef.useFlux property.
  • v2.4.x (Jan 2025) — FluxCD disabled by default; toggle preserved for opt-in.
  • v25.1.x — FluxCD removed entirely, along with the operator's dependency on the standalone Redpanda Broker Helm chart. Paved the path for the [[patterns/unified-operator-for- cloud-and-self-managed|unified operator]] across Cloud and Self-Managed.

Why the anti-pattern is tempting

The vendor gets a shortcut. GitOps controllers provide a battle-tested reconcile-from-Git primitive for declaratively managing Kubernetes resources. If the operator needs "keep this Helm chart applied with these values" as a primitive, bundling Flux's HelmRelease CRD is a fast way to get there. The cost appears later, when customers notice the divergence.

When a GitOps dep is not an anti-pattern

  • Optional dep — the operator works without the GitOps tool but can integrate with it when present. ArgoCD-aware controllers that expose hooks for sync-waves are fine.
  • External dep, customer-installed — the operator requires a GitOps controller but the customer installs it separately with their chosen version. Like requiring cert-manager.
  • Vendor whose only product is the GitOps substrate — Weaveworks Flagger-on-Flux, Argo Rollouts-on-Argo. Bundling is expected when the vendor is the GitOps tool.
Last updated · 470 distilled / 1,213 read