Cross-cluster HelmRelease promotion with Flux HelmRelease dependsOn

Flux's helm-controller reconciles HelmRelease objects by fetching the chart through a source, rendering values, and running helm upgrade --install with atomic and drift-detection semantics. In a multi-cluster setup you define a HelmRelease per cluster with a cluster-specific values overlay, and you chain them with spec.dependsOn so the canary cluster must reach Ready before the production cluster starts. Internally the controller sets status.conditions to Ready only after the Helm release and any spec.test hooks succeed, and it emits events that Alert/Notification controllers can route to Slack or PagerDuty.

Use this pattern when a single chart (for example ingress-nginx, cert-manager, or an internal service mesh) must roll out consistently across regions. Production teams stage by cluster tier: dev, staging, then prod, using separate HelmRelease CRs in directories clusters/dev, clusters/staging, clusters/prod that all point to the same HelmRepository. Version pinning via spec.chart.spec.version prevents an upstream chart bump from silently hitting prod.

Security considerations include the chart's ability to create cluster-scoped resources; scope the helm-controller SA with RBAC and enable spec.install.crds=CreateReplace only when necessary, since CRD replacement can break running workloads. Performance is sensitive to spec.interval and spec.timeout: too short a timeout causes spurious failures on slow clusters, too long delays rollback. A common pitfall is drift correction fighting an operator that mutates the release; set spec.driftDetection to the appropriate mode and document exemptions. Always enable spec.upgrade.remediation.retries to bound rollback loops.

> System.Execute()

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: ingress-nginx-prod-us
  namespace: flux-system
spec:
  interval: 10m
  timeout: 5m
  chart:
    spec:
      chart: ingress-nginx
      version: "4.11.3"
      sourceRef:
        kind: HelmRepository
        name: ingress-nginx
        namespace: flux-system
  install:
    crds: CreateReplace
  upgrade:
    remediation:
      retries: 3
    crds: CreateReplace
  driftDetection:
    mode: enabled
  dependsOn:
    - name: ingress-nginx-staging
  valuesFrom:
    - kind: ConfigMap
      name: ingress-values-prod-us

> Architecture & Security Context

Verified for Valters IT Hub. When deploying this configuration in a production homelab or enterprise environment, ensure that you monitor system resources and implement strict access controls. Administrator privileges are required.

ID: VALTERSIT-62CB5B5F4CF7