The recent announcement regarding the deprecation of the `HelmRelease` API in Flux v2 is a significant shift for teams heavily invested in that workflow. While the deprecation schedule allows for a transition period, understanding the migration path and its technical implications is critical for platform stability.
The primary directive is to migrate from the `HelmRelease` custom resource to the standardized `HelmChart` and `HelmRelease` APIs defined in the `source.toolkit.fluxcd.io` and `helm.toolkit.fluxcd.io` groups. This aligns Flux with the Carvel and Helm SDK patterns, consolidating the API surface. In practice, this means decomposing your existing `HelmRelease` manifest into separate `HelmRepository`/`OCIRepository` (Source) and `HelmRelease` (Helm) resources.
For example, a legacy `HelmRelease` referencing a chart from a repository:
```yaml
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
name: my-app
namespace: default
spec:
chart:
spec:
chart: my-chart
sourceRef:
kind: HelmRepository
name: my-repo
interval: 5m
interval: 10m
values: {...}
```
Becomes two distinct objects:
```yaml
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: HelmRepository
metadata:
name: my-repo
namespace: default
spec:
interval: 5m
url: https://charts.my-company.com
---
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
name: my-app
namespace: default
spec:
chart:
spec:
chart: my-chart
sourceRef:
kind: HelmRepository
name: my-repo
namespace: default
interval: 10m
values: {...}
```
The key changes are the externalization of the source definition and the explicit namespace in the `sourceRef`. The `flux migrate helmrelease` command is provided to automate this transformation, but a careful review of the generated manifests is advised, especially for complex use cases involving custom values files or dependencies.
This move simplifies the controller logic and paves the way for more unified GitOps practices. However, it introduces operational overhead during the transition. Teams should audit their fleet of `HelmRelease` objects, plan a namespace-by-namespace migration, and validate the new resource topology in a pre-production environment. The deprecation timeline is bound to the Flux v2 API versions, so monitoring the release notes for final removal dates is essential.
—J
—J
Okay, so just to make sure I've got this right... the main change is splitting one file into two, a source file and a release file? That example is helpful. Does the migration tool handle this split automatically, or do we need to go and manually rewrite all our helm release files? That sounds like a lot of work for a bigger setup.