Learning GitOps - FluxCD - Managing Helm Charts

#Introduction

In episode 7 you used Kustomize to merge and transform manifests. Now it's Helm's turn — another way, and often a more practical one, to package applications. Flux runs Helm entirely from inside the cluster through the Helm Controller, so you don't need to install Helm on your laptop.

We'll learn about HelmRepository as the chart source, HelmRelease as the release container, values management, the release lifecycle, and dependencies.

#Adding a HelmRepository

Before a chart can be installed, Flux needs to know where the chart comes from. The object is called HelmRepository. Public repo examples are Bitnami and ingress-nginx:

apiVersion: source.toolkit.fluxcd.io/v1
kind: HelmRepository
metadata:
  name: bitnami
  namespace: flux-system
spec:
  interval: 1h
  url: https://charts.bitnami.com/bitnami

Create it via the CLI:

flux create source helm bitnami \
  --url=https://charts.bitnami.com/bitnami \
  --interval=1h

#Private Repos

Private repos (ChartMuseum, Artifactory, Harbor) require authentication:

flux create secret helm auth-helm \
  --username=arman \
  --password=$HELM_PASSWORD
 
flux create source helm internal \
  --url=https://helm.internal.acme.com \
  --secret-ref=auth-helm

#OCI Registry

Beyond HTTP, HelmRepository also supports OCI — charts packaged as images in a registry like Harbor, ECR, or GHCR. Just set type: oci and the registry URL:

apiVersion: source.toolkit.fluxcd.io/v1
kind: HelmRepository
metadata:
  name: ghcr
  namespace: flux-system
spec:
  type: oci
  interval: 10m
  url: oci://ghcr.io/arman

#Creating a HelmRelease

HelmRelease is a Helm Controller CRD. It references a chart from a HelmRepository and determines the release configuration:

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: redis
  namespace: databases
spec:
  interval: 5m
  chart:
    spec:
      chart: redis
      version: "20.x"
      sourceRef:
        kind: HelmRepository
        name: bitnami
  values:
    architecture: standalone
    auth.enabled: true

Via the CLI:

flux create helmrelease redis \
  --source=HelmRepository/bitnami \
  --chart=redis \
  --chart-version="20.x" \
  --target-namespace=databases

Things to note:

• chart.spec.chart — the chart name in the repository.
• chart.spec.version — a semver constraint. "20.x" means all version 20 releases.
• spec.interval — how often Flux checks for a new chart version.
• spec.values — values that override the chart defaults.

Charts are always installed into the same namespace as the HelmRelease, unless you set spec.targetNamespace. To release a chart into another namespace, include a service account so the Helm Controller has permission.

#Managing Values

There are two main ways to provide values: inline in spec.values, or pulled from a ConfigMap or Secret via spec.valuesFrom.

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: redis
  namespace: databases
spec:
  chart:
    spec:
      chart: redis
      version: "20.x"
      sourceRef:
        kind: HelmRepository
        name: bitnami
  values:
    architecture: standalone
  valuesFrom:
    - kind: ConfigMap
      name: redis-values
      valuesKey: common.yaml
    - kind: Secret
      name: redis-secret-values
      valuesKey: secrets.yaml

Override order (the last one wins):

1. Default values inside the chart (values.yaml).
2. spec.values on the HelmRelease.
3. valuesFrom in order of appearance in the list.

#Release Lifecycle

The Helm Controller manages install, upgrade, and rollback automatically. Every time the chart or source changes, Flux performs an upgrade:

• If the release doesn't exist yet, it installs.
• If it exists and the chart or values changed, it upgrades.
• If the upgrade fails, Flux rolls back to the previous version by default.

flux get helmreleases
flux reconcile helmrelease redis
kubectl describe helmrelease redis -n databases

#Hooks and Tests

Helm charts with pre-upgrade, post-install, or test jobs keep working because Flux fully supports Helm hooks. Enable tests so Flux executes test jobs during upgrades:

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: redis
  namespace: databases
spec:
  interval: 5m
  test:
    enable: true
  chart:
    spec:
      chart: redis
      version: "20.x"
      sourceRef:
        kind: HelmRepository
        name: bitnami

#Install, Uninstall, Atomic

• install.createNamespace: true — Helm creates the namespace automatically on install.
• upgrade.force: true — force upgrade, recreating immutable resources.
• upgrade.atomic: true — if the upgrade fails, the entire release is rolled back automatically.
• uninstall.disableHooks and uninstall.keepHistory — control the behavior when a HelmRelease is deleted.

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: redis
  namespace: databases
spec:
  install:
    createNamespace: true
    remediation:
      retries: 3
  upgrade:
    atomic: true
    remediation:
      retries: 5
  rollback:
    enable: true
  interval: 5m
  chart:
    spec:
      chart: redis
      version: "20.x"
      sourceRef:
        kind: HelmRepository
        name: bitnami

#Dependencies and Ordering

There are two layers of dependencies to understand: between charts, and between Kustomizations or HelmReleases.

• Chart dependency — a chart that references sub-charts (e.g. nginx as the ingress for an application) is handled by Helm itself; Flux only needs to make sure its HelmRepository is available.
• Kustomization dependency — the deploy order at the Flux level uses dependsOn between Kustomizations or between HelmReleases:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: apps
  namespace: flux-system
spec:
  dependsOn:
    - name: databases
  path: ./apps
  prune: true
  sourceRef:
    kind: GitRepository
    name: fleet

With this, the apps Kustomization only runs after databases finishes and all its releases are reported healthy. Orchestration details like health checks and circular dependency prevention are covered fully in episode 10.

#Closing

Helm is now part of your GitOps flow:

• HelmRepository provides charts from public repos, private repos, or OCI registries.
• HelmRelease determines the chart, version, namespace, and values of a release.
• Values can be inline or sourced from a ConfigMap or Secret with a clear override order.
• Install, upgrade, rollback, hooks, tests, and atomic behavior are all configured declaratively.
• Dependencies between releases are controlled through dependsOn.

Next we'll dive into source management: advanced Git references, HelmRepository and OCIRepository, bucket storage, and GPG and Cosign signature verification. See you!