Flux – announcement

Blog: Announcing Flux 2.7 GA

Tue, 30 Sep 2025 06:00:00 +0000

We are thrilled to announce the release of Flux v2.7.0! In this post, we highlight some of the new features and improvements included in this release.

Highlights

Flux v2.7 marks the General Availability (GA) of the image update automation features and comes with new APIs ExternalArtifact and ArtifactGenerator for advanced source composition and decomposition patterns.

In this release, we have also introduced several new features to the Flux controllers, including watching for changes in ConfigMaps and Secrets references, extended readiness evaluation of dependencies with CEL expressions, and support for OpenTelemetry tracing for Flux Kustomization and HelmRelease reconciliation.

In ecosystem news, there is a new release of Flux Operator that comes with in-cluster image update automation features, that can be used for GitLess GitOps workflows.

General availability of Image Update Automation

This release marks the General Availability (GA) of Flux Image Automation APIs and controllers. The image-reflector-controller and image-automation-controller work together to update Kubernetes manifests in Git repositories when new container images are available in container registries.

The following APIs have been promoted to stable v1:

The ImagePolicy API now supports the .spec.suspend field to pause and resume the policy evaluation.

The ImageUpdateAutomation API gains support for Git sparse checkout. To enable this optimization, the image-automation-controller can be configured with the --feature-gates=GitSparseCheckout=true flag.

In addition, the image-automation-controller can now be configured to use Kubernetes Workload Identity for authenticating with AzureDevOps repositories.

Breaking changes:

The image-reflector-controller autologin flags which were deprecated since 2023 are now removed. Users should set ImageRepository.spec.provider to the appropriate cloud provider for their container registry.
The ImageUpdateAutomation commit template fields .Updated and .Changed.ImageResult which were deprecated since 2024 are now removed. Users should migrate to:
- .Changed.FileChanges for detailed change tracking
- .Changed.Objects for object-level changes
- .Changed.Changes for a flat list of changes

Watching for changes in ConfigMaps and Secrets

Starting with Flux v2.7, the kustomize-controller, helm-controller and notification-controller gain support for reacting to changes in ConfigMaps and Secrets references.

The following references are now watched for changes:

Kustomization.spec.postBuild.substituteFrom
Kustomization.spec.decryption.secretRef
Kustomization.spec.kubeConfig.secretRef
Kustomization.spec.kubeConfig.configMapRef
HelmRelease.spec.valuesFrom
HelmRelease.spec.kubeConfig.secretRef
HelmRelease.spec.kubeConfig.configMapRef
Receiver.spec.secretRef

When a referenced ConfigMap or Secret changes, the controller will immediately trigger a reconciliation if the referenced object is labelled with reconcile.fluxcd.io/watch: Enabled.

To enable the watching of all referenced objects without the need to label them, the controllers can be configured with the --watch-configs-label-selector=owner!=helm flag.

Workload Identity Authentication for Remote Clusters

Starting with Flux v2.7, you can configure workload identity at the object level in the Kustomization and HelmRelease resources to authenticate with cloud providers when running Flux in the hub-and-spoke model.

This feature allows cluster admins to use cloud identities on the hub cluster to configure Flux authentication to spoke clusters, without the need to create and manage static kubeconfig Secrets.

For more details on how to configure secret-less authentication to remote clusters, please refer to the following guides:

Object-level Workload Identity

In Flux v2.7, we have completed the integration of Kubernetes Workload Identity at the object level for all Flux APIs that support authentication with cloud providers.

This includes the following resources:

Bucket.spec.serviceAccountName for authenticating with AWS S3, Azure Blob Storage and Google Cloud Storage.
GitRepository.spec.serviceAccountName for authenticating with Azure DevOps.
OCIRepository.spec.serviceAccountName for authenticating with AWS ECR, Azure Container Registry and Google Artifact Registry.
ImageRepository.spec.serviceAccountName for authenticating with AWS ECR, Azure Container Registry and Google Artifact Registry.
Kustomization.spec.decryption.serviceAccountName for authenticating with AWS KMS, Azure Key Vault and Google KMS.
Kustomization.spec.kubeConfig.configMapRef.name for authenticating with remote clusters on AWS EKS, Azure AKS and Google GKE.
HelmRelease.spec.kubeConfig.configMapRef.name for authenticating with remote clusters on AWS EKS, Azure AKS and Google GKE.
Provider.spec.serviceAccountName for authenticating with Azure DevOps, Azure Event Hub and Google Pub/Sub.

For more details on how to configure object-level workload identity for Flux, see the following docs:

OpenTelemetry Tracing

Starting with Flux v2.7, users can enable OpenTelemetry tracing for Flux reconciliations by configuring a Provider of type otel:

apiVersion: notification.toolkit.fluxcd.io/v1beta3
kind: Provider
metadata:
 name: jaeger
 namespace: flux-system
spec:
 type: otel
 address: http://jaeger-collector.jaeger:4318/v1/traces

The notification-controller converts Flux events into OTEL spans with proper trace relationships based on the Flux object hierarchy. Source objects (GitRepository, HelmChart, OCIRepository, Bucket) create root spans, while Kustomization and HelmRelease objects create child spans within the same trace. Each span includes event metadata as attributes and uses the alert name and namespace as the service identifier.

For more details on how to configure OpenTelemetry tracing for Flux, please refer to the notification-controller documentation.

Controller Improvements

The GitRepository API gains support for mTLS in GitHub App authentication.
The Kustomization API now supports CEL expressions for extended readiness evaluation of dependencies.
The Kustomization API gains a new field .spec.ignoreMissingComponents for ignoring missing Kustomize components in the source.
The kustomize-controller now supports global SOPS decryption for Age keys, allowing centralized management of decryption keys.
The kustomize-controller can be configured to cancel ongoing health checks when a new source revision is detected with the --feature-gates=CancelHealthCheckOnNewRevision=true flag.
The HelmRelease API now supports CEL expressions for extended readiness evaluation of dependencies.
The HelmRelease API gains a new strategy called RetryOnFailure for better handling of release failures.
The Provider API now supports setting proxy via spec.proxySecretRef and mTLS via spec.certSecretRef.
The Provider API has been extended with support for Zulip and OpenTelemetry tracing.

CLI Improvements

The flux bootstrap and flux install commands now support the --components-extra=source-watcher flag to enable the new source-watcher component.
A new flux migrate command has been added to migrate Flux resources stored in Kubernetes etcd to their latest API version.
The flux debug command gains a new --show-history flag to display the reconciliation history of Flux objects.
The flux diff command now handles the kustomize.toolkit.fluxcd.io/force: Enabled annotation.
The flux create hr command gains a new --storage-namespace flag for changing the namespace of Helm storage objects.
New commands were added for ImagePolicy resources:
- flux reconcile image policy
- flux suspend image policy
- flux resume image policy
New commands were added for ArtifactGenerator resources:
- flux get artifact generator
- flux export artifact generator
- flux tree artifact generator
- flux events --for ArtifactGenerator/<name>

Artifact Generators

Flux v2.7 comes with a new component that can be enabled at bootstrap time with the --components-extra=source-watcher flag.

The source-watcher controller implements the ArtifactGenerator API which allows Flux users to:

Compose multiple Flux sources (GitRepository, OCIRepository, Bucket) into a single deployable artifact
Decompose monorepos into multiple independent artifacts with separate deployment lifecycles
Optimize reconciliation by only triggering updates when specific paths change
Structure complex deployments from distributed sources maintained by different teams

Multiple Source Composition

The ArtifactGenerator can be used to combine multiple sources into a single deployable artifact, for example, you can combine upstream Helm charts from OCI registries with your organization’s custom values and configuration overrides stored in Git:

apiVersion: source.extensions.fluxcd.io/v1beta1
kind: ArtifactGenerator
metadata:
 name: podinfo
 namespace: apps
spec:
 sources:
 - alias: chart
 kind: OCIRepository
 name: podinfo-chart
 - alias: repo
 kind: GitRepository
 name: podinfo-values
 artifacts:
 - name: podinfo-composite
 originRevision: "@chart"
 copy:
 - from: "@chart/"
 to: "@artifact/"
 - from: "@repo/charts/podinfo/values.yaml"
 to: "@artifact/podinfo/values.yaml"
 strategy: Overwrite
 - from: "@repo/charts/podinfo/values-prod.yaml"
 to: "@artifact/podinfo/values.yaml"
 strategy: Merge
---
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
 name: podinfo
 namespace: apps
spec:
 interval: 15m
 releaseName: podinfo
 chartRef:
 kind: ExternalArtifact
 name: podinfo-composite

Monorepo Decomposition

The ArtifactGenerator can be used to decompose a monorepo into multiple independent artifacts with separate deployment lifecycles. For example:

apiVersion: source.extensions.fluxcd.io/v1beta1
kind: ArtifactGenerator
metadata:
 name: app-decomposer
 namespace: apps
spec:
 sources:
 - alias: git
 kind: GitRepository
 name: monorepo
 artifacts:
 - name: frontend
 originRevision: "@git"
 copy:
 - from: "@git/deploy/frontend/**"
 to: "@artifact/"
 - name: backend
 originRevision: "@git"
 copy:
 - from: "@git/deploy/backend/**"
 to: "@artifact/"
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
 name: frontend-service
 namespace: apps
spec:
 interval: 15m
 prune: true
 sourceRef:
 kind: ExternalArtifact
 name: frontend
 path: ./
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
 name: backend-service
 namespace: apps
spec:
 interval: 15m
 prune: true
 sourceRef:
 kind: ExternalArtifact
 name: backend
 path: ./

Each service gets its own ExternalArtifact with an independent revision. Changes to deploy/backend/ only trigger the reconciliation of the backend-service Kustomization, leaving other services untouched.

For more details on how to use the ArtifactGenerator API, please refer to the source-watcher documentation.

Supported Versions

Flux v2.4 has reached end-of-life and is no longer supported.

Flux v2.7 supports the following Kubernetes versions:

Distribution	Versions
Kubernetes	1.32, 1.33, 1.34
OpenShift	4.19

Enterprise support Note that the CNCF Flux project offers support only for the latest three minor versions of Kubernetes. Backwards compatibility with older versions of Kubernetes and OpenShift is offered by vendors such as ControlPlane that provide enterprise support for Flux.

Upgrade Procedure

Note that in Flux v2.7, the following APIs have reached end-of-life and have been removed from the CRDs:

source.toolkit.fluxcd.io/v1beta1
kustomize.toolkit.fluxcd.io/v1beta1
helm.toolkit.fluxcd.io/v2beta1
image.toolkit.fluxcd.io/v1beta1
notification.toolkit.fluxcd.io/v1beta1

Before upgrading to Flux v2.7, make sure to migrate all your resources to the stable APIs using the flux migrate command.

Upgrade Procedure for Flux v2.7+

We have published a dedicated step-by-step upgrade guide, please follow the instructions from Upgrade Procedure for Flux v2.7+.

Over and out

If you have any questions or simply just like what you read and want to get involved, here are a few good ways to reach us:

Join our upcoming dev meetings.
Talk to us in the #flux channel on CNCF Slack.
Join the planning discussions.
Follow Flux on Twitter, or join the Flux LinkedIn group.

Blog: FluxCon NA 2025

Thu, 05 Jun 2025 12:00:00 +0000

This year at KubeCon NA in Atlanta, we’ll be hosting the first-ever FluxCon! We’re so excited to have a space specifically for Flux end-users to share their stories. FluxCon will be taking place on November 10th, 2025.

We’ve added a number of new features to Flux and continue to stabilize API’s for a stable, scalable lifetime. FluxCon is a great way to learn about new use-cases, hear about Flux at scale, and connect with other Flux practitioners.

Call for Papers

Are you using Flux in your org? We’d love to hear your story. You can submit your talk proposal before June 30th, 2025.

New Use-Cases

Flux is used in retail stores, massive datacenters, trains, cell-towers, satellites, tractors, and so many more places. Practitioners choose Flux because it’s performant, flexible, and secure. Over the years, we’ve heard so many use-cases for Flux’s uniquely extensible continuous delivery API’s.

This year we’re advocating for Gitless GitOps, experimenting with AI-assisted GitOps, and showing object-level identity for external API’s. The ecosystem of projects innovating around Flux is also healthy. The Headlamp project builds UI tools for Flux users, and there are a number of vendors offering SaaS and support for Flux in their products. We can’t wait to hear what people are doing next at FluxCon.

Connect with the Community

The most important part of the Flux project is our community. Yes, our software is beautiful, and simple, and incredibly principled, but we build Flux purely for the love of our community of practitioners. We created GitOps to change the way we work, and meeting each other and sharing our stories is the only way to do so.

You can expect to meet other users, talk directly with Flux maintainers (represented by multiple companies), and hear more about how we’re moving GitOps forward.

Please consider this a warm invitation to come join us at FluxCon this November. We’ll see you there!

Blog: Announcing Flux 2.6 GA

Thu, 29 May 2025 12:00:00 +0000

We are thrilled to announce the release of Flux v2.6.0! In this post, we will highlight some of the new features and improvements included in this release.

Highlights

Flux v2.6 marks the General Availability (GA) of the Flux Open Container Initiative (OCI) Artifacts features. The OCI artifacts support was first introduced in 2022, and since then we’ve been evolving Flux towards a Gitless GitOps model. In this model, the Flux controllers are fully decoupled from Git, relying solely on container registries as the source of truth for the desired state of Kubernetes clusters.

In the last couple of years, the OCI feature-set has matured, and we’ve seen major financial institutions and enterprises adopting Flux and OCI as their preferred way of managing production deployments. To see it in action, you can check the reference architecture guide made by ControlPlane on how highly regulated industries can securely implement Gitless GitOps with Flux and OCI.

In this release, we have also introduced several new features to the Flux controllers, including digest pinning in image automation, object-level workload identity for container registries and KMS services authentication, and various improvements to notifications.

In ecosystem news, there is a new release of Flux Operator that comes with a Model Context Protocol (MCP) implementation for allowing AI assistants to interact with Flux. For more details on the Flux MCP Server, see the AI-Assisted GitOps blog post.

General availability of Flux OCI Artifacts

This release marks the General Availability (GA) of Flux OCIRepository API, which allows storing the desired state of Kubernetes clusters in OCI container registries.

The OCIRepository v1 API comes with new features including:

Support for Object-Level Workload Identity, which allows Flux to use different cloud identities for accessing container registries on multi-tenant clusters.
Caching of registry credentials for cloud providers, which allows Flux to reuse the OIDC tokens for subsequent requests to the same registry, reducing the number of authentication requests.

The OCIRepository v1 API is backward compatible with the previous v1beta2 API, users can upgrade by changing the apiVersion in the YAML files that contain OCIRepository definitions from source.toolkit.fluxcd.io/v1beta2 to source.toolkit.fluxcd.io/v1.

The Flux CLI commands for working with OCI artifacts have been promoted to stable:

flux build artifact
flux push artifact
flux pull artifact
flux tag artifact
flux diff artifact
flux list artifacts

The Flux custom media types used for OCI artifacts produced by the Flux CLI are now stable:

config media type application/vnd.cncf.flux.config.v1+json
content media type application/vnd.cncf.flux.content.v1.tar+gzip

Breaking changes

Prior to v2.6.0, the OCIRepository and ImageRepository APIs allowed the spec.provider field to be set to a value that did not necessarily match the repository URL. In these cases the controllers would simply ignore the spec.provider, not configuring OIDC authentication for the repository.

For example, the repository public.ecr.aws/aws-controllers-k8s never matched Flux’s regular expression for the aws provider, but the controller would still allow the spec.provider to be set to aws in this case and would simply ignore it. This specific configuration would work correctly because this particular repository is public and does not require authentication.

Similarly, a private repository that did not match any of Flux’s validations for the three container registry providers (aws, azure, gcp) would also work with the spec.provider set to one of these values, as long as it was also configured with one of the spec.secretRef or spec.serviceAccountName fields for using image pull secrets. In these cases, the controller would simply ignore the spec.provider and use the image pull secret instead.

Starting with v2.6.0, Flux is fixing this behavior. The repository URL must now match the provider set in spec.provider, otherwise the controller will reject the configuration and return an error. For automatic OIDC authentication, the spec.provider must be set to one of the three container registry providers (aws, azure, gcp). For public repositories or authentication using image pull secrets, the spec.provider must not be set, or set to generic. These configuration instructions were explicit in the Flux docs since many releases, but are only now in v2.6.0 being strictly enforced by the controllers.

Image Automation Digest Pinning

In Flux v2.6, the image automation has been enhanced to support digest pinning for container images. This feature allows users to configure the ImagePolicy to track the latest digest of a container image, and the ImageUpdateAutomation to update the manifests in the Git repository with the new digest.

The ImagePolicy can now be configured to select the latest image digest with .spec.digestReflectionPolicy set to Always. Once a policy is set to track the latest digest, the manifests in the Git repository will be updated with digest references in the format <registry>/<name>:<tag>@<digest>.

A new marker has been introduced to allow setting the digest in custom resources where repository, tag and digest are separate values:

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
 name: my-app
 namespace: apps
spec:
 values:
 image:
 repository: docker.io/my-org/my-app # {"$imagepolicy": "flux-system:my-app:name"}
 tag: latest  # {"$imagepolicy": "flux-system:my-app:tag"}
 digest: sha256:ec0119... # {"$imagepolicy": "flux-system:my-app:digest"}

For more details on how to configure image automation digest pinning, see the following guide.

Object-level Workload Identity

Starting with Flux v2.6, you can configure workload identity at the object level in the Kustomization API for SOPS decryption with KMS services, and in the OCIRepository and ImageRepository APIs for accessing container registries.

This feature allows cluster admins to use different cloud identities on multi-tenant clusters. Instead of relying on static Secrets that require manual rotation, you can now assign cloud identities per tenant by leveraging Kubernetes Workload Identity.

To use this feature, cluster admins have to enable the feature gate ObjectLevelWorkloadIdentity which is opt-in from Flux v2.6.

For more details on how to configure object-level workload identity for Flux, see the following docs:

GitHub App Authentication

In Flux v2.6, we have completed the integration of GitHub App authentication for Git repositories. This feature was introduced in Flux v2.5, and it is now fully supported across all Flux APIs.

The GitHub App authentication tokens are now cached by the Flux controllers and reused for subsequent requests for the duration of the token lifetime.

The notification-controller has also been updated to support GitHub App authentication when updating Git commit statuses and for triggering GitHub Actions workflows.

Notifications Improvements

Starting with Flux v2.6, users can customize the Git commit status identifier in the notifications sent to Git providers by using Common Expression Language (CEL) expressions.

apiVersion: notification.toolkit.fluxcd.io/v1beta3
kind: Provider
metadata:
 name: github-status
 namespace: flux-system
spec:
 type: github
 address: https://github.com/my-gh-org/my-gh-repo
 secretRef:
 name: github-app-auth
 commitStatusExpr: "(event.involvedObject.kind + '/' + event.involvedObject.name + '/' + event.metadata.clusterName)"

Customizing the commit status ID is particularly useful when using a monorepo for a fleet of Kubernetes clusters, as it allows you to differentiate the commit statuses for each cluster.

Other improvements include:

The notification-controller can now use Azure Workload Identity when sending notifications to Azure Event Hub.
The github and githubdispatch providers now support authenticating with a GitHub App.

Controller Improvements

The GitRepository v1 API now supports sparse checkout by setting a list of directories in the .spec.sparseCheckout field. This allows for optimizing the amount of data fetched from the Git repository.
The GitRepository v1 API gains supports mTLS authentication for HTTPS Git repositories.
The Kustomization v1 API now supports the value WaitForTermination for the .spec.deletionPolicy field. This instructs the controller to wait for the deletion of all resources managed by the Kustomization before allowing the Kustomization itself to be deleted.
The helm-controller v1.3.0 comes with a new feature gate called DisableChartDigestTracking, which allows disabling appending the digest of OCI Helm charts to the chart version. This is useful for charts that do not follow Helm’s recommendation of using the app version instead of the chart version as a label in the manifests.

Supported Versions

Flux v2.3 has reached end-of-life and is no longer supported.

Flux v2.6 supports the following Kubernetes versions:

Distribution	Versions
Kubernetes	1.31, 1.32, 1.33
OpenShift	4.18

Enterprise support Note that the CNCF Flux project offers support only for the latest three minor versions of Kubernetes. Backwards compatibility with older versions of Kubernetes and OpenShift is offered by vendors such as ControlPlane that provide enterprise support for Flux.

Over and out

If you have any questions or simply just like what you read and want to get involved, here are a few good ways to reach us:

Join our upcoming dev meetings.
Talk to us in the #flux channel on CNCF Slack.
Join the planning discussions.
Follow Flux on Twitter, or join the Flux LinkedIn group.

Blog: Announcing Flux 2.5 GA

Thu, 20 Feb 2025 12:00:00 +0000

We are thrilled to announce the release of Flux v2.5.0! In this post, we will highlight some of the new features and improvements included in this release.

Highlights

Flux v2.5 marks a significant milestone in the project’s evolution, we have integrated Common Expression Language (CEL) with the Flux controllers to enable long-awaited features such as custom health checks and webhook receiver filters. Moreover, we have added support for GitHub App authentication, custom event metadata for notifications and Flux CLI helpers for troubleshooting Flux resources.

In ecosystem news, the Flux Operator v0.14 release brings one of the most requested features: deploy app code and/or config changes made in a GitHub Pull Request or GitLab Merge Request to an ephemeral environment for testing and validation.

The Flux Operator has the ability to create, update and delete application instances on-demand based on the ResourceSet definitions and Pull/Merge Requests state.

For more details on how to use the ephemeral environments feature, see the following guides:

Health Checks for Custom Resources

In this release, we have extended the Flux Kustomization API with support for defining custom health checks using Common Expression Language (CEL). The health checks are used to verify the readiness of the resources managed by Flux and are a key feature for ensuring that the desired state of the cluster is achieved.

While Flux performs a series of built-in health checks for Kubernetes core resources, the new feature allows users to teach Flux how to check the health of Kubernetes custom resources. This is particularly useful for custom resources that do not subscribe to the Kubernetes API conventions or for resources that require additional logic to determine if they reached the desired state.

A common use case for custom health checks is to verify the status of Cluster objects reconciled by the Cluster API controllers. When Flux is used to manage a fleet of Kubernetes clusters, the health checks can be used to ensure that the clusters are ready before deploying cluster addons and applications.

Example of a Kustomization with a custom health check for Cluster API:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
 name: prod-clusters
 namespace: infra
spec:
 interval: 30m
 retryInterval: 5m
 prune: true
 sourceRef:
 kind: GitRepository
 name: fleet
 path: "./production"
 timeout: 15m
 wait: true
 healthCheckExprs:
 - apiVersion: cluster.x-k8s.io/v1beta1
 kind: Cluster
 failed: "status.conditions.filter(e, e.type == 'Ready').all(e, e.status == 'False')"
 current: "status.conditions.filter(e, e.type == 'Ready').all(e, e.status == 'True')"

The above example configures Flux to wait for all the Cluster objects to reach the Ready state before proceeding with the reconciliation of other Kustomizations that have a dependsOn relationship defined for the prod-clusters.

We have published a health check library that contains CEL expressions for popular custom resources. The library is community-maintained, and we encourage users to contribute new health checks.

Other kustomize-controller improvements include:

Fine-grained control of garbage collection with .spec.deletionPolicy.
SOPS support for decryption of Kubernetes secrets generated by Kustomize components.

GitHub App Authentication for Git Repositories

Starting with Flux v2.5, you can configure source-controller and image-automation-controller to authenticate against GitHub repositories using a GitHub App installation.

Instead of relying on personal access tokens or SSH keys that require manual rotation, you can now configure Flux to authenticate against GitHub repositories using an identity that is not tied to a specific user account.

We have added a new command to the Flux CLI that can be used to create the Kubernetes Secret required for the GitHub App authentication.

flux create secret githubapp github-auth \
 --app-id=1 \
 --app-installation-id=2 \
 --app-private-key=~/private-key.pem

The Kubernetes Secret generated by the above command can be referenced in a GitRepository and ImageUpdateAutomation with .spec.secretRef.name.

For more details on how to configure the GitHub App authentication, see the GitRepository API documentation.

Custom event metadata for notifications

Starting with Flux v2.5, users can enrich the metadata of the events sent by the notification-controller by adding annotations on the Flux Kustomization and HelmRelease resources. The metadata is included in the notifications sent to the configured providers, such as Slack, Microsoft Teams, etc., and can be used to provide additional context about a particular application or environment.

One highly requested feature was the ability to include the image tag in the notifications send when Flux image automation updates the container image tag in HelmRelease values.

Example of a HelmRelease with custom event metadata containing the image tag:

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
 name: my-app
 namespace: apps
 annotations:
 event.toolkit.fluxcd.io/image: docker.io/org/my-app:1.0.0 # {"$imagepolicy": "apps:my-app"}
spec:
 chart:
 spec:
 chart: my-app
 sourceRef:
 kind: HelmRepository
 name: podinfo
 values:
 image:
 tag: 1.0.0 # {"$imagepolicy": "apps:my-app:tag"}

When the image automation updates the my-app HelmRelease with a new image tag e.g. 1.0.1, the notification sent after the Helm release upgrade will include image: docker.io/org/my-app:1.0.1 in message body.

For more details on how to configure custom event metadata, see the Alert API documentation.

Other notifications improvements include:

The notification-controller is now capable of updating Git commit statuses from events about Kustomizations that consume OCIRepositories.
The Receiver API now supports filtering the declared resources that match a given Common Expression Language (CEL) expression.

CLI Improvements

To help users troubleshoot Flux, we’ve added a new flux debug command the following subcommands:

flux debug kustomization --show-vars used to inspect the final variables values by merging the Flux Kustomization inline vars with the vars coming from Kubernetes ConfigMaps/Secrets.
flux debug helmrelease --show-values used to inspect the final Helm values by merging the HelmRelease inline values with the values coming from Kubernetes ConfigMaps/Secrets.

Note that these commands will print sensitive information if Kubernetes Secrets are referenced in the Flux Kustomization or HelmRelease resources.

Other CLI improvements include:

A new command was added, flux create secret githubapp that can be used to generate a Kubernetes Secret for GitHub App authentication.
The flux create source git command now supports the --provider=github flag to configure GitHub App authentication for Git repositories.

Supported Versions

Flux v2.2 has reached end-of-life and is no longer supported.

Flux v2.5 supports the following Kubernetes versions:

Distribution	Versions
Kubernetes	1.30, 1.31, 1.32
OpenShift	4.17

Enterprise support

Note that the CNCF Flux project offers support only for the latest three minor versions of Kubernetes.

Backwards compatibility with older versions of Kubernetes and OpenShift is offered by vendors such as ControlPlane that provide enterprise support for Flux.

Over and out

If you have any questions, or simply just like what you read and want to get involved, here are a few good ways to reach us:

Join our upcoming dev meetings.
Join the Flux mailing list and let us know what you need help with.
Talk to us in the #flux channel on CNCF Slack.
Join the planning discussions.
Follow Flux on Twitter, or join the Flux LinkedIn group.

Blog: Announcing Flux 2.4 GA

Mon, 30 Sep 2024 12:00:00 +0000

We are thrilled to announce the release of Flux v2.4.0! In this post, we will highlight some of the new features and improvements included in this release.

General availability of Flux S3-compatible Source API

This release marks the General Availability (GA) of Flux Bucket API which allows storing the desired state of Kubernetes clusters in S3-compatible storage services such as Amazon S3, Azure Blob Storage, Google Cloud Storage, Alibaba Cloud, MinIO, and others.

The Bucket v1 API comes with new features including: proxy support, mTLS and custom STS configuration for AWS S3 and MinIO LDAP authentication.

New fields in the source.toollkit.fluxcd.io/v1 API:

.spec.proxySecretRef allows configuring HTTP/S Proxy authentication for the S3-compatible storage service.
.spec.certSecretRef allows custom TLS client certificate and CA for secure communication with the S3-compatible storage service.
.spec.sts allows custom STS configuration for AWS S3 and MinIO LDAP authentication.

For more details, please see the Bucket documentation.

To upgrade, make sure the new CRDs and controllers are deployed, and then change the manifests in Git:

Set apiVersion: source.toolkit.fluxcd.io/v1 in the YAML files that contain Bucket definitions.
Commit, push and reconcile the API version changes.

Bumping the APIs version in manifests can be done gradually. It is advised to not delay this procedure as the deprecated versions will be removed after 6 months.

Azure DevOps OIDC Authentication

Starting with Flux v2.4, you can configure source-controller and image-automation-controller to authenticate against Azure DevOps repositories using AKS Workload Identity.

Instead of using Azure personal access tokens or SSH keys that require manual rotation, you can now use OIDC tokens to authenticate against Azure DevOps repositories by leveraging Kubernetes Workload Identity.

For more details on how to configure the Azure DevOps OIDC authentication, see the GitRepository API documentation.

Controller Improvements

The OCIRepository v1beta2 API gains support for proxy configuration thus allowing dedicated HTTP/S Proxy authentication on multi-tenant Kubernetes clusters.
The HelmRelease v2 API gains support for disabling JSON schema validation of the Helm release values during installation and upgrade. And allows adopting existing Kubernetes resources during Helm release installation.
The notification-controller allows transitioning the Microsoft Teams alerting from the deprecated Office 365 connector to MS Workflows and the Adaptive Card format.
The Flux Kustomization and HelmRelease APIs now support defining dependencies between resources managed by different controller shards.

CLI Improvements

A new command was added, flux create secret proxy that can be used to generate a Kubernetes Secret for HTTP/S Proxy authentication referenced by Bucket, GitRepository and OCIRepository.
The flux create source git command now supports the --provider=azure flag to configure OIDC authentication for Azure DevOps repositories.
The flux diff kustomization command now supports the --recursive flag to recursively diff encountered Kustomizations.
On Windows, the Flux CLI can now be installed using the WinGet tool by running winget install -e --id FluxCD.Flux.

Supported Versions

Flux v2.1 has reached end-of-life and is no longer supported.

Flux v2.4 supports the following Kubernetes versions:

Distribution	Versions
Kubernetes	1.29, 1.30, 1.31
OpenShift	4.16

Enterprise support

Note that the CNCF Flux project offers support only for the latest three minor versions of Kubernetes.

Backwards compatibility with older versions of Kubernetes and OpenShift is offered by vendors such as ControlPlane that provide enterprise support for Flux.

Flux Operator and OpenShift Compatibility

Flux can be installed on Red Hat OpenShift cluster directly from OperatorHub or by using the Flux Operator Helm chart.

The Flux Operator is an open-source project developed by ControlPlane that offers an alternative to the Flux Bootstrap procedure, it removes the operational burden of managing Flux across fleets of clusters by fully automating the installation, configuration, and upgrade of the Flux controllers based on a declarative API.

The operator simplifies the configuration of Flux multi-tenancy lockdown, sharding, horizontal and vertical scaling, persistent storage, and allows fine-tuning the Flux controllers with Kustomize patches. The operator streamlines the transition from Git as the delivery mechanism for the cluster desired state to OCI artifacts and S3-compatible storage.

After installing the Flux Operator on OpenShift, you can deploy the Flux controllers using the FluxInstance custom resource e.g.:

apiVersion: fluxcd.controlplane.io/v1
kind: FluxInstance
metadata:
 name: flux
spec:
 distribution:
 version: "2.x"
 registry: "ghcr.io/fluxcd"
 artifact: "oci://ghcr.io/controlplaneio-fluxcd/flux-operator-manifests:latest"
 components:
 - source-controller
 - kustomize-controller
 - helm-controller
 - notification-controller
 - image-reflector-controller
 - image-automation-controller
 cluster:
 type: openshift
 multitenant: true
 networkPolicy: true
 domain: "cluster.local"
 sharding:
 shards: [ "shard1", "shard2" ]
 sync:
 kind: OCIRepository
 url: "oci://ghcr.io/my-org/my-fleet-manifests"
 ref: "latest"
 path: "clusters/my-cluster"
 pullSecret: "flux-system"

For more details on how to use configure Flux using the operator, please see the Flux Operator documentation.

Over and out

If you have any questions, or simply just like what you read and want to get involved, here are a few good ways to reach us:

Join our upcoming dev meetings.
Join the Flux mailing list and let us know what you need help with.
Talk to us in the #flux channel on CNCF Slack.
Join the planning discussions.
Follow Flux on Twitter, or join the Flux LinkedIn group.

Blog: Announcing Flux 2.3 GA

Mon, 13 May 2024 12:00:00 +0000

We are thrilled to announce the release of Flux v2.3.0! In this post, we will highlight some of the new features and improvements included in this release.

General availability of Flux Helm features and APIs

This release marks a significant milestone for the Flux project, after almost four years of development, the helm-controller and the Helm related APIs have reached general availability.

The following Kubernetes CRDs have been promoted to GA:

HelmRelease - helm.toolkit.fluxcd.io/v2
HelmChart - source.toolkit.fluxcd.io/v1
HelmRepository - source.toolkit.fluxcd.io/v1

The Helm features and APIs have been battle-tested by the community in production and are now considered stable. Future changes to the Helm APIs will be made in a backwards compatible manner, and we will continue to support and maintain them for the foreseeable future.

Enhanced Helm OCI support

The HelmRelease v2 API comes with a new field .spec.chartRef that adds support for referencing OCIRepository and HelmChart objects in a HelmRelease. When using .spec.chartRef instead of .spec.chart, the controller allows the reuse of a Helm chart version across multiple HelmRelease resources.

Starting with this version, the recommended way of referencing Helm charts stored in container registries is through OCIRepository.

Using OCIRepository objects instead of HelmRepository improves the controller’s performance and simplifies the debugging process. The OCIRepository provides more flexibility in managing Helm charts, as it allows targeting a Helm chart version by tag, semver or OCI digest pinning. If a chart version gets overwritten in the container registry, the controller will detect the change in the upstream OCI digest and reconcile the HelmRelease resources accordingly.

Example of a HelmRelease referencing an OCIRepository:

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
 name: metrics-server
spec:
 interval: 10m
 chartRef:
 kind: OCIRepository
 name: metrics-server
 driftDetection:
 mode: enabled
 values:
 apiService:
 create: true
---
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: OCIRepository
metadata:
 name: metrics-server
spec:
 interval: 12h
 layerSelector:
 mediaType: "application/vnd.cncf.helm.chart.content.v1.tar+gzip"
 operation: copy
 url: oci://docker.io/bitnamicharts/metrics-server
 ref:
 semver: ">=7.0.0"

Improved observability of Helm releases

By popular demand, the helm-controller now emits Kubernetes events annotated with the Helm chart appVersion in addition to the version info. When configuring alerts for Helm releases, the appVersion is now available as a field in the alert metadata and is displayed in the notification messages. The appVersion field is also included in the HelmRelease status, and in the gotk_resource_info Prometheus metrics.

When using an OCIRepository as the HelmRelease chart source, the controller will also include the OCI digest of the Helm chart artifact in the Kubernetes events and the HelmRelease status.

Benchmark results

To measure the real world impact of the helm-controller GA, we have set up benchmarks that measure Mean Time To Production (MTTP). The MTTP benchmark measures the time it takes for Flux to deploy application changes into production. Below are the results of the benchmark that ran on a GitHub hosted runner (Ubuntu, 16 cores):

Objects	Type	Flux component	Duration	Max Memory
100	HelmChart	source-controller	25s	40Mi
100	HelmRelease	helm-controller	28s	190Mi
500	HelmChart	source-controller	45s	68Mi
500	HelmRelease	helm-controller	2m45s	250Mi
1000	HelmChart	source-controller	1m30s	110Mi
1000	HelmRelease	helm-controller	8m1s	490Mi

Compared to Flux v2.2, in this version the memory consumption of the helm-controller has improved a lot, especially when the cluster has hundreds of CRDs registered. In Flux v2.2, helm-controller on Kubernetes v1.28 runs out of memory with only 100 CRDs registered. Whereas, in Flux v2.3 on Kubernetes v1.29, it can handle 500+ CRDs without issues. Given these results, it is recommended to upgrade the Kubernetes control plane to v1.29 and Flux to v2.3.

Image update automation improvements

The ImageUpdateAutomation API has been promoted to v1beta2 and the image-automation-controller has been refactored to enhance the reconciliation process.

The v1beta2 API comes with a new template model that can be used to customize the commit message when the controller updates the image references in the Git repository. The commit template supports old and new values for the changes made to the files containing the policy markers. In addition, the commit message is included in the Kubernetes events emitted by the controller, offering better visibility into the automation process.

The ImageUpdateAutomation API now supports selecting ImagePolicies using label selectors in the new field .spec.policySelector.

Migration to v1beta2 template model

To migrate to the v1beta2 API, update the apiVersion field in the ImageUpdateAutomation resources to image.toolkit.fluxcd.io/v1beta2, and modify the messageTemplate to use the Changed template data.

Example template:

apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImageUpdateAutomation
metadata:
 name: <automation-name>
spec:
 git:
 commit:
 messageTemplate: |-
 Automated image update

 Changes:
 {{ range .Changed.Changes -}}
 - {{ .OldValue }} -> {{ .NewValue }}
 {{ end -}}

 Files:
 {{ range $filename, $_ := .Changed.FileChanges -}}
 - {{ $filename }}
 {{ end -}}

Example generated commit message:

Automated image update

Changes:
- docker.io/nginx:1.25.4 -> docker.io/nginx:1.25.5
- docker.io/org/app:1.0.0 -> docker.io/org/app:1.0.1

Files:
- apps/my-app/deployment.yaml

For more examples and details, see the ImageUpdateAutomation documentation.

Signatures verification with Notation

The Flux source-controller now supports verifying the authenticity of OCI artifacts signed with Notation (CNCF Notary project).

To enable Notation signature verification, please see the following documentation:

In addition, the Flux CLI now supports generating Kubernetes secrets with Notation trust policies, using the flux create secret notation command.

Big thanks to Microsoft for contributing to the development of this feature!

Terraform provider improvements

The Flux Terraform provider has undergone a major refactoring and now supports air-gapped bootstrap, drift detection and correction for Flux components, and the ability to upgrade and restore the Flux controllers in-cluster. Starting with this release, the provider is fully compatible with OpenTofu.

The provider documentation has been updated with examples and detailed usage instructions.

New maintainer

We are very happy to announce that Steven Wade has joined the Flux project as a maintainer of the Terraform provider. Steven has been a long-time contributor to the Flux project and we are excited to have him on board!

Controllers improvements

The Flux Kustomization API gains two optional fields .spec.namePrefix and .spec.nameSuffix that can be used to specify a prefix and suffix to be added to the names of all managed resources.
The kustomize-controller now supports the --feature-gates=StrictPostBuildSubstitutions=true flag, when enabled the post-build substitutions will fail if a variable without a default value is declared in files but is missing from the input vars.
The notification-controller Receiver API has been extended to support CDEvents.
The OCIRepository API has been extended with support for semver filtering.
The HelmChart API v1 comes with a new optional field .spec.ignoreMissingValuesFiles.

CLI improvements

The bootstrap capabilities have been extended to support Oracle VBS repositories.
The bootstrap procedure for Azure DevOps repositories has been update with support for SSH RSA SHA-2 keys.
The flux bootstrap command gains a new flag --ssh-hostkey-algos that can be used to specify the host key algorithms to be used for SSH connections.
The flux bootstrap and flux install commands now support the --registry-creds flag that can be used for generating an image pull secret for container images stored in private registries.
A new command was added, flux envsubst that can be used to replicate the behavior of the Flux Kustomization post-build substitutions.
The flux create source oci command now supports the --verify-subject and --verify-issuer for cosign keyless verification.
New commands were added for managing HelmChart objects: flux create|delete|export source chart.

Breaking changes and deprecations

Deprecated fields have been removed from the HelmRelease v2 API:

.spec.chart.spec.valuesFile replaced by .spec.chart.spec.valuesFiles
.spec.postRenderers.kustomize.patchesJson6902 replaced by .spec.postRenderers.kustomize.patches
.spec.postRenderers.kustomize.patchesStrategicMerge replaced by .spec.postRenderers.kustomize.patches
.status.lastAppliedRevision replaced by .status.history.chartVersion

The following APIs have been deprecated and will be removed in a future release:

HelmRelease v2beta2 and v2beta1
HelmChart v1beta2 and v1beta1
HelmRepository v1beta2 and v1beta1
ImageUpdateAutomation v1beta1

Supported versions

Flux v2.0 has reached end-of-life and is no longer supported.

Flux v2.3 supports the following Kubernetes versions:

Distribution	Versions
Kubernetes	1.28, 1.29, 1.30
OpenShift	4.15

Flux v2.3 is the first release end-to-end tested on OpenShift. Big thanks to Replicated for sponsoring the Flux project with on-demand OpenShift clusters. For more information on how to bootstrap Flux on OpenShift, see the OpenShift installation guide.

Enterprise support

Note that the CNCF Flux project offers support only for the latest three minor versions of Kubernetes.

Backwards compatibility with older versions of Kubernetes and OpenShift is offered by vendors such as ControlPlane that provide enterprise support for Flux.

Installing or upgrading Flux

To install Flux, take a look at our installation and get started guides.

To upgrade Flux from v2.x to v2.3.0, either rerun flux bootstrap or use the Flux GitHub Action.

To upgrade the APIs in the manifests stored in Git:

Before upgrading, ensure that the HelmRelease v2beta2 YAML manifests are not using deprecated fields. Search for valuesFile and replace it with valuesFiles, replace patchesJson6902 and patchesStrategicMerge with patches.
Commit and push the changes to the Git repository, then wait for Flux to reconcile the changes.
Upgrade the controllers and CRDs on the cluster using Flux v2.3 release.
Update the apiVersion field of the HelmRelease resources to helm.toolkit.fluxcd.io/v2.
Update the apiVersion field of the HelmRepository resources to source.toolkit.fluxcd.io/v1.
Update the apiVersion field of the ImageUpdateAutomation resources to image.toolkit.fluxcd.io/v1beta2.
Commit and push the changes to the Git repository.

Bumping the APIs version in manifests can be done gradually. It is advised to not delay this procedure as the deprecated versions will be removed after 6 months.

What’s next for Flux?

The next milestone for the Flux project is v2.4, which is planned for Q3 2024 and will focus on the image automation APIs and S3-compatible storage APIs. For more details on the upcoming features and improvements, see the Flux project roadmap.

After the introduction of OCI Artifacts in 2022, we had a recurring ask from users about improving the UX of running Flux fully decoupled from Git. In response, we made a proposal for a flux bootstrap oci command and a new Terraform/OpenTofu provider that relies on container registries as the unified data storage for the desired state of Kubernetes clusters. The RFC can be found at fluxcd/flux2#4749 and we welcome feedback from the community.

Over and out

If you have any questions, or simply just like what you read and want to get involved, here are a few good ways to reach us:

Join our upcoming dev meetings.
Join the Flux mailing list and let us know what you need help with.
Talk to us in the #flux channel on CNCF Slack.
Join the planning discussions.
Follow Flux on Twitter, or join the Flux LinkedIn group.

Blog: Flux project gains New Corporate Support and Ecosystem in 2024

Tue, 19 Mar 2024 08:00:00 +0000

The CNCF graduated Flux project is proud to announce that it will receive enhanced support from dedicated companies in 2024. These organizations are committed to the ongoing maintenance and development of Flux GitOps tools. At KubeCon EU 2024 in Paris, the Flux project has keynote highlights, sessions, and a booth.

Vendors and clouds are stepping up contributions

Major vendors are ramping up their ecosystem involvement in Flux moving forward. GitLab announced its continued support for Flux and working with partners. In early 2023, GitLab integrated Flux with its agent for Kubernetes offering as the recommended GitOps solution.

Similarly, Flux continues to be the GitOps engine for cloud vendors such as Microsoft and AWS. Lachie Evenson at Microsoft affirms that “Flux is the engine that powers several GitOps experiences on Azure as well as in our customer’s environments’ and that Microsoft is committed to upstream contributions.

Flux is the engine that powers several GitOps experiences on Azure as well as in our customer’s environments. We will continue to invest in Flux through upstream contributions for the long-term health and support of the project, and downstream partnerships to help customers

Lachie Evenson, Principal PDM Manager – Cloud Native Ecosystem, Microsoft

Both Azure and AWS use Flux to streamline Kubernetes cluster and application management, adopting GitOps principles for enhanced automation, security, and reliability in cloud-native application deployments for Azure Arc Kubernetes and EKS-Anywhere.

New Enterprise adopters: Silva project, Cisco, Tchibo, and more

Flux’s significant benefits show in its widespread adoption by large-scale enterprises across various sectors, including telecommunications and financial services. The new Sylva project showcases the critical role of Flux for its complex telecom cloud native environments. Sylva streamlines the management of Kubernetes workload clusters, specifically designed to deploy Containerized Network Functions (CNF) provided by both external CNF vendors and telecom operators’ in-house services. As Orange VP of Software Engineering affirms, Flux’s security, modularity, resilience, and community all contribute to how it is the GitOps framework of choice.

We are really happy to observe new big tech shops bringing their support to Flux. It should give to everyone the confidence to keep committing and investing. The level of quality and security, and the modularity of Flux have been prime reasons for our decision to use it two years ago to automate the deployment and lifecycle management of network functions. Our Linux Foundation Sylva-based cloud native infrastructure relies on the strength and resilience of the Flux community. Flux’s technology and community make it the GitOps framework in our Telco networks.

Philippe Ensarguet, VP Software Engineering, Orange

Other long-time Flux adopters who have added themselves to the public list recently include Cisco and German retailer, Tchibo.

New Support and Ecosystem: Hirings and Value-Add Extensions

While several ecosystem companies are coordinating to step up as maintainers, contributors, and supporters of Flux, ControlPlane was first to hire Stefan Prodan (Flux project maintainer and architect as well as Flagger creator) and Soulé Ba (core maintainer) to continue their contributions. As ControlPlane CEO, Andrew Martin, has reinforced their commitment to help maintain the project, which is part of their offering of an enterprise-grade distribution of Flux, including support services for critical system.

ControlPlane is delighted to continue supporting the Flux project for all users, and to provide organisations utilising Flux with access to a hardened, FIPS-compliant, enterprise-grade distribution of Flux.

Andrew Martin, CEO, ControlPlane

In addition, companies such as Aviator, OpsMX, OpsWorks Group, OSO and Teracloud began providing support for Flux among their offerings.

At KubeCon EU 2024 in Paris, these and other companies in the ecosystem will meet at a Birds of a Feather meeting to kick off further commitments to add value to Flux’s extensibility and ecosystem reach.

Cloud Native Computing Foundation Exemplar Project

At this juncture, the Flux project is a strong graduated project within the Cloud Native Computing Foundation with continued recognition from CNCF CTO, Chris Aniszczyk, who states how Flux exemplifies the strength and resilience of the community. Flux reached General Availability in December 2023 and blew through its second security audit with the CNCF with no CVEs. The project’s published benchmarks results demonstrate why cloud vendors and enterprises alike have been trusting Flux with their needs for scale.

I am glad to see the continued support across the open source cloud native community for Flux. I encourage other organizations to get involved as there’s never a bad time to contribute to an open source project you depend on. Also, this is a great example of the strength and resilience of our community and we look forward to Flux’s continued evolution and growth.

Chris Aniszczyk, CTO, CNCF

If you’re at KubeCon in Paris this week, visit the Flux project booth and the many sessions, including Stefan’s maintainer talk on the Flux roadmap at the event.

Blog: Announcing Flux 2.2 GA

Tue, 12 Dec 2023 15:00:00 +0000

We are thrilled to announce the release of Flux v2.2.0! In this post, we will highlight some of the new features and improvements included in this release, with the primary theme being the many changes made to the helm-controller.

This new release will also be demoed by Priyanka “Pinky” Ravi and Max Werner on Monday, December 18. To attend this demo and ask any questions, you can register here.

Important things first: API changes

This release is accompanied by a series of (backwards compatible) API changes and introductions. Please refer to the release notes for a comprehensive list, and make sure to read them before updating your Flux installation.

Enhanced `HelmRelease` reconciliation model

The reconciliation model of the helm-controller has been rewritten to be able to better determine the state a Helm release is in, to then decide what Helm action should be performed to reach the desired state.

Effectively, this means that the controller is now capable of continuing where it left off, and to run Helm tests as soon as they are enabled without a Helm upgrade having to take place first.

In addition, it now takes note of releases while they are happening, instead of making observations afterward. Ensuring that when performing a rollback remediation, the version we revert to is always exactly the same as the one previously released by the controller. In cases where it is uncertain about state, it will always decide to (reattempt to) perform a Helm upgrade.

This also allows it with certainty to only count release attempts that did cause a mutation to the Helm storage as failures towards retry attempts, improving continuity due to it retrying instantly instead of remediating first.

Improved observability of Helm releases

An additional thing the enhanced reconciliation model allowed us to work on is making improvements to how we report state back to you, as a user.

The improvements range from the introduction of Reconciling and Stalled Condition types to become kstatus compatible, to an enriched overview of Helm releases up to the previous successful release in the Status, and more informative Kubernetes Event and Condition messages.

Events:
 Type Reason Age From Message
 ---- ------ ---- ---- -------
 Normal HelmChartCreated 25s helm-controller Created HelmChart/demo/demo-podinfo with SourceRef 'HelmRepository/demo/podinfo'
 Normal InstallSucceeded 20s helm-controller Helm install succeeded for release demo/podinfo.v1 with chart podinfo@6.5.3
 Normal TestSucceeded 12s helm-controller Helm test succeeded for release demo/podinfo.v1 with chart podinfo@6.5.3: 3 test hooks completed successfully

For more details around these changes, refer to the Status section in the HelmRelease v2beta2 specification.

Recovery from `pending-*` Helm release state

A much-reported issue was the helm-controller being unable to recover from another operation (install/upgrade/rollback) is in progress errors, which could occur when the controller Pod was forcefully killed. From this release on, the controller will recover from such errors by unlocking the Helm release from a pending-* to a failed state, and retrying it with a Helm upgrade.

Helm Release drift detection and correction

Around April we launched cluster state drift detection and correction for Helm releases as an experimental feature. At that time, it could only be enabled using a controller global feature flag, making it impractical to use at scale due to the wide variability in charts and unpredictability of the effects on some Helm charts.

For charts with lifecycle hooks, or cluster resources like Horizontal/Vertical Pod Autoscalers for which controllers may write updates back into their own spec, those updates would always be considered as drift by the helm-controller unless the resource would be ignored in full.

To address the above pain points, Helm drift detection can now be enabled on the HelmRelease itself, while also allowing you to ignore specific fields using JSON Pointers:

spec:
 driftDetection:
 mode: enabled
 ignore:
 - paths: ["/spec/replicas"]
 target:
 kind: Deployment

Using these settings, any drift detected will now be corrected by recreating and patching the Kubernetes objects (instead of doing a Helm upgrade) while changes to the .spec.replicas fields for Deployments will be ignored.

For more information, refer to the drift detection section in the HelmRelease v2beta2 specifiation.

Forcing and retrying Helm releases

Another much-reported issue was the impractical steps one had to take to recover from “retries exhausted” errors. To instruct the helm-controller to retry installing or upgrading a Helm release when it is out of retries, you can now either:

Instruct it to reset the failure counts, allowing it to retry the number of times as configured in the remediation strategy
```
flux reconcile helmrelease <release> --reset
```
Instruct it to force a one-off Helm install or upgrade
```
flux reconcile helmrelease <release> --force
```

For in-depth explanations about these new command options, refer to the “resetting remediation retries” and “forcing a release” sections in the HelmRelease v2beta2 specification.

Benchmark results

To measure the real world impact of the helm-controller overhaul, we have set up benchmarks that measure Mean Time To Production (MTTP). The MTTP benchmark measures the time it takes for Flux to deploy application changes into production. Below are the results of the benchmark that ran on a GitHub hosted runner (Ubuntu, 16 cores):

Objects	Type	Flux component	Duration	Max Memory
100	OCIRepository	source-controller	25s	38Mi
100	Kustomization	kustomize-controller	27s	32Mi
100	HelmChart	source-controller	25s	40Mi
100	HelmRelease	helm-controller	31s	140Mi
500	OCIRepository	source-controller	45s	65Mi
500	Kustomization	kustomize-controller	2m2s	72Mi
500	HelmChart	source-controller	45s	68Mi
500	HelmRelease	helm-controller	2m55s	350Mi
1000	OCIRepository	source-controller	1m30s	67Mi
1000	Kustomization	kustomize-controller	4m15s	112Mi
1000	HelmChart	source-controller	1m30s	110Mi
1000	HelmRelease	helm-controller	8m2s	620Mi

The benchmark uses a single application ( podinfo) for all tests with intervals set to 60m. The results may change when deploying Flux objects with a different configuration.

For more information about the benchmark setup and how you can run them on your machine, check out the fluxcd/flux-benchmark repository.

Breaking changes to Kustomizations

All Flux components have been updated from Kustomize v5.0.3 to v5.3.0.

You should be aware that this update comes with a breaking change in Kustomize, as components are now applied after generators. If you use Kustomize components or .spec.components in Kustomizations along with generators, then please make necessary changes before upgrading to avoid any undesirable behavior. For more information, see the relevant Kustomize issue.

Other notable changes

flux install and flux bootstrap now have guardrails to protect users from destructive operations.
Gitea support has been added to flux bootstrap. To bootstrap Flux onto a cluster using Gitea as the Git provider, run flux bootstrap gitea --repository <repo> --owner <owner>.
The OIDC issuer and identity subject can now be verified for images signed using Cosign. Refer to the HelmChart and OCIRepository specifications for more information.
Prefix based file filtering support has been added to the Bucket API for generic, aws and gcp providers.
Support for insecure (non-TLS HTTP) container registries has been added to the ImageRepository and HelmRepository APIs.
The Flux alerting capabilities have been extended with NATS and Bitbucket Server & Data Center support.

Installing or upgrading Flux

To install Flux, take a look at our installation and get started guides.

To upgrade Flux from v2.x to v2.2.0, either rerun flux bootstrap or use the Flux GitHub Action.

To upgrade the APIs, make sure the new Custom Resource Definitions and controllers are deployed, and then change the manifests in Git:

Set apiVersion: helm.toolkit.fluxcd.io/v2beta2 in the YAML files that contain HelmRelease definitions.
Set apiVersion: notification.toolkit.fluxcd.io/v1beta3 in the YAML files that contain Alert and Provider definitions.
Commit, push and reconcile the API version changes.

Bumping the APIs version in manifests can be done gradually. It is advised to not delay this procedure as the deprecated versions will be removed after 6 months.

Over and out

If you have any questions, or simply just like what you read and want to get involved. Here are a few good ways to reach us:

Join our upcoming dev meetings.
Join the Flux mailing list and let us know what you need help with.
Talk to us in the #flux channel on CNCF Slack.
Join the planning discussions.
Follow Flux on Twitter, or join the Flux LinkedIn group.

Blog: Second Flux Security Audit has concluded

Thu, 09 Nov 2023 00:00:00 +0000

Precisely 2 years after performing our first security Audit, we had the chance to put Flux through a second audit this year, again facilitated by the CNCF and the Open Source Technology Improvement Fund. Trail of Bits partnered with us this time to make Flux even more secure. Flux passed the “General Availability” milestone earlier this year and the focus was on the features shipped in the Flux GA release.

The Flux maintainers and community are very grateful for the work put into this by everyone and the opportunity to grow and improve as a project. Thanks to Trail of Bits, notably Maciej Domański, Sam Alws, Sam Greenup and Jeff Braswell, who have always been extremely responsive during the process.

No new CVEs

Good news first: No new CVEs have been published for Flux in response to this second audit. Trail of Bits highlight that they found Flux was “well structured and generally written defensively” and the “audit uncovered only low- and informational-severity findings”, 10 in total. 8 of the discovered issues have been fixed as of publication of this announcement. From the remaining two issues to be fixed, one is in the process of being resolved and for the other one we have decided to accept the very low risk due to reasons mentioned in the report.

The assessment was kicked off with a list of 23 questions to be answered, circling around potential data leaks, security documentation, access control or denial of service vulnerabilities. Since the focus was on the GA components, the following parts of Flux have been put under scrutiny:

source-controller
kustomize-controller
notification-controller
Flux CLI
The pkg library, and git/gogit/fs in particular

Details on the discovered issues

You will find the full report here. The following table shows all the findings together with links to the pull requests fixing them:

Issue	Severity	Fix
1: SetExpiration does not set the expiration for the given key	low	source-controller#1185
2: Inappropriate string trimming function	informational	notification-controller#590
3: Go’s default HTTP client uses a shared value that can be modified by other components	low	flux2#4182
4: Unhandled error value	informational	flux2#4181
5: Potential implicit memory aliasing in for loops	informational	source-controller#1257, notification-controller#627, flux2#4329
6: Directories created via os.MkdirAll are not checked for permissions	informational	n/a
7: Directories and files created with overly lenient permissions	informational	pkg#663, pkg#681, source-controller#1276, kustomize-controller#1005, flux2#4380
8: No restriction on minimum SSH RSA public key bit size	informational	flux2#4177
9: Flux macOS release binary susceptible to dylib injection	low	in progress
10: Path traversal in SecureJoin implementation	undetermined	pkg#650, go-git/go-billy#31, go-git/go-billy#34

In addition to the pull requests linked above we also enabled security and quality CI checks through CodeQL via flux2#4121 to prevent any avoidable regressions.

Conclusion and next steps

From our perspective as Flux maintainers, 2 years feel like a lifetime. We added lots of new features and fixed even more bugs in that timeframe. That’s why we are particularly grateful that CNCF and OSTIF gave us the opportunity to let a team of security experts assess Flux another time. We are proud of having been able to learn from the first assessment and kept on making Flux more and more secure over these past 2 years, leading to only low- and informational-severity security findings within the GA components of Flux.

Our next milestone is the general availability of Flux’s Helm features and the subsequent general availability of the remaining Flux components. If you are interested in contributing to this, we are very much looking forward to working with you. We welcome contributions in helping resolve issues of the road, additional comments on our security posture and also welcome contributions in the form of extending our fuzzing infrastructure. Finally, if you have any additional security feedback, please come and talk to us.

Again we would like to thank the Cloud Native Computing Foundation for sponsoring the audit, the Open Source Technology Improvement Fund for the coordination and Trail of Bits for the careful review and advice during the audit period.

We are happy and proud to be part of this community!

Blog: Announcing Flux 2.1 GA

Mon, 04 Sep 2023 00:00:00 +0000

New releases

We are happy to announce the latest GA releases for Flux and Flagger.

Flux v2.1.0

This new release comes with lots of new features, fixes, restructured documentation and performance improvements. Everyone is encouraged to upgrade for the best experience.

The Flux APIs were extended with new opt-in features in a backwards-compatible manner.

The Flux Git capabilities have been improved with support for Git push options, Git refspec, Gerrit, HTTP/S and SOCKS5 proxies.

In case you missed it, Flux reached General Availability in June. You can read the announcement here.

You can now check the end-of-life(EOL) dates and support information for different Flux versions at https://endoflife.date/flux.

Features

The GitRepository API has a new field .spec.proxySecretRef that is used for specifying proxy configuration to use for all remote Git operations related to the particular object.
The.spec.verify.mode field of the GitRepository API now accepts one of the following values HEAD, Tag, TagAndHEAD. These values are used to specify how the Git tags and commits are verified.
The server-side apply behaviour in the kustomize-controller has been extended with two extra policies: IfNotPresent and Ignore. These policies are specified with the kustomize.toolkit.fluxcd.io/ssa annotation on the resource manifest. The IfNotPresent policy is useful to have Flux create an object that will later be managed by another controller.
Support for sending notifications to DataDog.
The ImageUpdateAutomation API has two new optional fields - .spec.git.push.refspec and .spec.git.push.options for to specify a refspec and push options that will be used when pushing commits upstream.

Fixes and improvements

Here is a short list of features and improvements in this release:

A new flag --concurrent-ssa has been introduced in the kustomize-controller to set the number of concurrent server-side operations that will be performed by the controller per object. This increases speed when reconciling Kustomization with a considerable amount of objects.
Performance improvement when loading helm repositories with large indexes (up to 80% memory reduction).
The load distribution has been improved when reconciling Flux objects in parallel to reduce CPU and memory spikes.
The Installation and Monitoring sections of the Flux documentation have been restructured to make navigation and locating guides easier. We are always open to receiving feedback on how we can improve the documentation.

Deprecation

All APIs that accept TLS data have been modified to support Kubernetes TLS style secrets. The keys caFile, certFile and keyFile have been deprecated. For more details about the TLS changes please see the Kubernetes TLS Secrets section.
⚠️ Breaking changes: This release comes with breaking changes to the Flux monitoring stack (Prom+Grafana). The stack now leverages the kube-state-metrics Custom Resource State metrics to report some Flux resource metrics. This will allow users to extend the Flux metrics with custom metadata. The monitoring configuration in the fluxcd/flux2 repository is now deprecated and will be removed in a future release. The new monitoring configuration is located at fluxcd/flux2-monitoring-example. Please see the new monitoring guide https://fluxcd.io/flux/monitoring for more information.

Upgrade

To upgrade Flux from v0.x to v2.1.0 please follow the Flux GA upgrade procedure.

To Upgrade Flux from v2.0.x to v2.1.0 either by rerunning bootstrap or by using the Flux GitHub Action.

You can take a look at the changelog for the full list of changes.

❣️Big thanks to all the Flux contributors who helped us with this release!

Flux Grafana Dashboards

The Flux monitoring stack comes with two dashboards for easy visualization of Flux controllers and resource metrics. You can follow this link to learn how to set it up.

Flagger v1.33.0

This release fixes bugs related to the Canary lifecycle. The confirm-traffic-increase webhook is no longer called if the Canary is in the WaitingPromotion phase. Furthermore, a bug which caused downtime when initializing the Canary deployment has been fixed. Also, a bug in the request-duration metric for Traefik which assumed the result to be in milliseconds instead of seconds has been addressed.

The loadtester now also supports running kubectl commands.

Please see the changelog for the full changes.

Community News

This section highlights additions to our community - new contributors, project members, maintainers or adopters.

New adopters

We are very pleased to announce that the following adopters of Flux have come forward and added themselves to our website:

Zeit Online: a German-language platform for demanding online journalism and reader discussions with level.
Sonatype: a developer-friendly full-spectrum software supply chain management platform helps organizations and software developers.
Prophesee: a company using sensor design and AI algorithms to develop computer vision systems.
Infolegale: a legal information platform to monitor company solvency.
Eco Vadis: a collaborative platform that allows companies to assess the environmental and social performance of their suppliers.

If you have not already done so, use the instructions here or give us a ping and we will help to add you. Not only is it great for us to get to know and welcome you to our community. It also gives the team a big boost in morale to know where in the world Flux is used everywhere.

New Contributors

Shoutout to all our new contributors:

Thanks to all of our old and new contributors, and reach out if you’d like to become one as well.

People writing/talking about Flux

We love it when you all write about Flux and share your experience, write how-tos on integrating Flux with other pieces of software or other things. Give us a shout-out and we will link it from this section!

How to Build a Self-Service Platform on Upbound: Day 1

Our friends at Upbound wrote a great blog post on how you can use the power of Flux and Crossplane to drive control plane interactions and configure your control plane for GitOps Flows.

Canary deployment with Flagger and Istio on Devtron

Rupin Solanki describes how to leverage Flagger and Istio, to automate the canary release process, ensure seamless traffic shifting and real-time application health monitoring.

Events

It’s important to keep you up to date with events in Flux and provide simple ways to see our work in action and chat with our engineers.

Recent Events

In August here are a couple of talks we would like to highlight.

Cloud Native Islamabad - Harnessing the Power of GitOps with Flux

Flux maintainer, Stefan Prodan spoke at Cloud Native Islamabad on Harnessing the Power of GitOps with Flux. It is packed with a informed introduction to the concept of GitOps and a demo of Flux and the Weave GitOps UI! Click on the video below to watch it.

Upcoming Events

We are happy to announce that we have a number of events coming up. Tune in to learn more about Flux and GitOps best practices, get to know the team and join our community.

If you wish to speak at GitOpsCon EU, reach out to us to collaborate on proposals on a range of topics related to Kubernetes. We are happy to provide our writing expertise to your proposal and to collaborate on ideas. The CFP deadline is October 4, so kindly contact tamao@weave.works ASAP if you’re interested. The conference will take place virtually on the 5th - 6th of December.

CNCF On-Demand Webinar

Flux Maintainer, Kingdon B will be giving a talk titled How to start building a self-service infrastructure platform on Kubernetes on the 14th of September. It’s going to be packed with knowledge on how to use Backstage and GitOps. Register here.

Project meetings and Bug Scrub

Our Flux Bug Scrubs still are happening on a weekly basis and remain one of the best ways to get involved in Flux. They are a friendly and welcoming way to learn more about contributing and how Flux is organised as a project.

2023-09-05 22:00 UTC, 00:00 CEST The Flux Bug Scrub (AEST)
2023-09-06 12:00 UTC, 14:00 CEST The Flux Bug Scrub
2023-09-07 15:00 UTC, 17:00 CEST CNCF Flux Project Meeting (late)
2023-09-13 12:00 UTC, 14:00 CEST CNCF Flux Project Meeting (early)
2023-09-14 17:00 UTC, 19:00 CEST The Flux Bug Scrub
2023-09-19 22:00 UTC, 00:00 CEST The Flux Bug Scrub (AEST)

We are flexible with subjects and often go with the interests of the group or of the presenter. If you want to come and join us in either capacity, just show up or if you have questions, reach out to Kingdon B on Slack.

Flux Ecosystem

Terraform-controller

The ecosystem is buzzing with news about the licensing changes to Hashicorp’s open-source projects including Terraform. Weaveworks has released a statement on this and the impact on the tf-controller.

VS Code GitOps Extension

Significant performance upgrades and code refactoring has been introduced with VS Code GitOps Tools extension version 0.25.0. Previously cluster metadata was loaded using kubectl get commands. Now, a new javascript client is also used which permits faster loading and real-time watching of cluster resources. kubectl proxy is executed in the background for the new client. Rendering of resource treeviews has been reworked to minimise data reloading, to maintain collapsible state and to allow visualising resource errors grouped by namespaces. Timeout settings were added and bad cluster connections should no longer slow down Clusters treeview rendering.

UI refinements and bug fixes for the new client are ongoing. The most up-to-date UI features can be previewed by selecting “Install Pre-Release Version” in the VS Code Extension Browser.

Flux Fun Fact!

Did you know … 🔒 Flux is designed with security in mind: Pull vs. Push, least amount of privileges, adherence to Kubernetes security policies and tight integration with security tools and best-practices. Read more about our security considerations.

Over and out

If you like what you read and would like to get involved, here are a few good ways to do that:

Join our upcoming dev meetings.
Join the Flux mailing list and let us know what you’d like to see.
Talk to us in the #flux channel on CNCF Slack.
Join the planning discussions.
And if you are completely new to Flux, take a look at our Get Started guide and give us feedback.
Social media: Follow Flux on Twitter, join the discussion in the Flux LinkedIn group.
We are looking forward to working with you.

❤️ Your Flux maintainer, Somtochi Onyekwere, and project member, Tamao Nakahara.

Blog: Announcing Flux 2.0 GA

Thu, 20 Jul 2023 00:00:00 +0000

Flux 2.0 and General Availability!

On July 5, 2023, Flux reached a major landmark with Flux 2.0 and the general availability of its GitOps components! Flux has continued to grow during its incredible journey. Its early iteration was built at Weaveworks for their own needs and for a previous SaaS product built on Flux. Flux led to Weaveworks CEO Alexis Richardson to coin the term, GitOps, which has taken the world by storm with a CNCF Working Group, GitOpsCon, GitOps Days, and several GitOps community groups. Moreover, leaders such as Kubernetes co-creators Brendan Burns and Joe Beda have stated how GitOps is a natural evolution of Kubernetes itself.

“GitOps practices and Flux has elevated our engineering: code infra as software, eliminate human intervention, accelerate lead time for changes - without compromising security requirements.”

Tahir Raza, Staff Engineer - Cloud & Platform Engineering at Best Buy

Intending to be the best GitOps tool available, the Flux project has evolved into a mature and trustworthy software. During its evolution, Flux has accomplished several goals such as low resource consumption by adopting a microservices architecture, safe multi-tenancy through its security-first design and support for bleeding edge innovation by having first-class support for technologies like OCI and Cosign.

We are proud to see that Flux is one of the few CNCF graduated projects and the GitOps tool that companies such as Microsoft, AWS, GitLab, D2iQ,q and more trust to deliver GitOps to their customers.

“Safaricom PLC provides mobile telephony, mobile money transfer, consumer electronics, e-commerce, cloud computing, data, music streaming, and fiber optic services to the Kenyan Market predominantly and to the wider East Africa. So, Flux has been an essential part of critical areas such as deployment frequency, standardization, and security, among other GitOps capabilities that help us to be competitive. We are excited about Flux 2.0 and the project’s continued maturity.”

Winnie Gakuru, DevSecOps Engineer II at Safaricom PLC

Flux General Availability

“EKS Anywhere has been providing GitOps capabilities with Flux to our happy enterprise customers. We’ve been testing Flux 2.0 since our EKS-A v0.16.0 release and it has been solid. Flux, as a CNCF Graduated project and now with its GitOps components at GA, has been reliable and enterprise grade so that we can deliver the best experience to the customers who depend on our quality of product.”

Joey Wang, Senior Software Engineer at Amazon Web Services

What does General Availability (GA) mean for you as a Flux user:

“Flux is often my go-to technology choice for building multi-cluster and even multi-region deployment patterns. It helps me enable teams in evolving their applications from one cluster to many with consistent and repeatable config.”

Bryan Oliver, Principal Engineer at Thoughtworks

This signifies that the APIs that have achieved GA (Generally Available) status are now considered stable and can be used with confidence in production environments. They offer backward compatibility, ensuring that existing implementations will continue to function as expected. Flux encompasses various APIs, but not all of them have attained GA status yet.

The APIs that have reached GA include:

GitRepository: This API facilitates pulling configurations from Git repositories.
Kustomization: It enables the application and synchronization of Kubernetes manifests defined in Git.
Receiver API: This API triggers the reconciliation of Flux Custom Resources using webhooks.

It is important to note that these GA APIs will not undergo backwards-incompatible changes unless accompanied by a major version update and appropriate advance announcements As for the remaining Flux APIs, they will undergo further development and enhancements before being promoted to GA status at a later stage.

“GitLab picked Flux for its official GitOps integration within our GitLab agent for Kubernetes. Flux’s maturation and reliability have continued to show as we’ve tested Flux 2.0 in development. Now with Flux’s GA, we can continue to build the best user experience for our enterprise customers on solid foundations.”

Viktor Nagy, Senior Product Manager, Environments group at GitLab

Releases

“It has been a fantastic journey of rebuilding the original Flux into a microservices architecture, adding Flagger as a subproject, getting validated as a graduated project in the CNCF, and now reaching GA with Flux 2.0. I am grateful to work with great teams, maintainers, contributors, and partners, and then to see major enterprises and cloud providers relying on Flux to start or mature their Kubernetes journey. Keeping great company with users (the likes of Amazon AWS, D2iQ, Microsoft Azure, VMware, Weaveworks, GitLab, Volvo, SAP, Xenit and many more) keeps me motivated for the future innovations and growth for Flux.”

Stefan Prodan, Principal Developer Experience Engineer at Weaveworks, Flux maintainer and Flagger creator

Release Cadence: Flux will have at least three minor releases in a year following the Kubernetes release cadence. The release will happen roughly two weeks after a new Kubernetes release. The two weeks timeline can be adjusted if more time is needed for testing compatibility with the new Kubernetes version.

API Versioning: The Flux project follows the semver standard for versioning. Release candidates are marked as x.y.z-rc.a (e.g v1.0.0-rc.3) and stable releases are marked as x.y.z.

Support: Flux will support the last three minor release versions of a major release and the previous major release version for a year after its release. A newly released Flux version offers support for Kubernetes N-2 minor versions.

CVE Backport: We will backport bug fixes and security fixes to the last three minor releases as patch releases. Users are advised to run the latest patch release of a given minor release.

For more details on the release procedure, take a look at https://fluxcd.io/flux/releases.

“Xenit is proud to be contributors and maintainers of the Flux project, which is the GitOps tool of choice for enterprises and cloud providers such as Volvo, GitLab, Microsoft, and AWS. We are particularly proud to be part of Flux’s major milestones: not only graduating in the Cloud Native Computing Foundation some months ago, but now getting Flux to 2.0 and general availability. We enjoy being part of the Flux community and look forward to the next stages of this growing community.”

Simon Gottschlag, CTO at Xenit

How to get started?

Watch our CNCF webinar on Flux 2.0, which has an intro to GitOps for newcomers and Flux 2.0-specific updates for existing users.
Need extra support for Flux and Flagger? Check out the Flux support page and this August 2 webinar on Flux 2.0-specific support.

❤️ Your Flux maintainer, Somtochi Onyekwere, and project member, Tamao Nakahara.

Blog: Flux is a CNCF Graduated project

Wed, 30 Nov 2022 09:00:00 +0000

Flux has graduated

Today is a very exciting day for the Flux community! Flux is now a graduated project in the Cloud Native Computing Foundation and joining the ranks of Kubernetes, Helm, Prometheus and others in this category.

Flux History

We all worked very hard to make this happen - it is another important milestone in the Flux success story. Started in July 2016, engineers at Weaveworks built the first version of Flux to guarantee predictable deployments internally. This was way before Kubernetes had won the Cloud Native market.

In the coming years at Weaveworks, the learnings with Flux helped to establish and refine the principles of GitOps. Flux was integrated ever more closely with Kubernetes, and later on Helm and Kustomize. It also grew a community and an ecosystem. In 2018, Flagger was born, a Flux companion that made progressive delivery a natural extension of GitOps.

When Weaveworks donated Flux and Flagger to the CNCF, we already saw large-scale adoption growing and cloud vendors making the Flux suite core of their offerings to provide GitOps functionality.

This was also the point where we decided to rewrite Flux from scratch, using modern tooling such as controller-runtime and as a set of targeted controllers, which made Flux development a lot more straight-forward. In the past weeks we archived Legacy Flux and are very close to making Flux v2 GA. Watch this space for the announcement!

“We created Flux as open source from the beginning, in order to work out in the open. It was very gratifying therefore, and far from inevitable, that a loyal and mutually supportive community grew around it. Making that happen takes a lot of empathy and patience from all involved – so, thank you everyone, for carrying Flux ever further.”

– Michael Bridgen, co-creator of Flux

Flux’s home: the CNCF

Today is a great time to look back at our time in the CNCF. We wouldn’t be where we are today without the services and help of people at the CNCF. It wasn’t just the great benefits and infrastructure we enjoy as a project, but also the careful guidance and collaboration of CNCF groups such as the TOC, TAG Security / TAG Contributor Experience and all the adjacent project communities which also live at the CNCF. We also would like to thank our TOC sponsor, Matt Farina, who helped us navigate this process and encouraged us to take Flux even further!

“I feel humbled and honored to be part of the Flux & Flagger team for the past five years. With the help of our community, we have come a long way since Flux inception and the start of the GitOps movement. Today, Flux is an established continuous delivery solution for Kubernetes, trusted by organisations around the world and backed by vendors like Amazon AWS, D2iQ, Microsoft Azure, VMware, Weaveworks and others that offer Flux to their users. The Flux team is very grateful to the cloud-native community and CNCF who supported us over the years and made Flux what it is today”

– Stefan Prodan, Flux maintainer and creator of Flagger

During the Graduation process, we particularly reflected on security and governance. We threat-modelled the Flux components, which resulted in documented security best practice. We will continue to educate our user community on how to use Flux securely. Today both Flux and Flagger are 100% compliant with the CLO monitor, which is the highest score amongst graduated CNCF projects. We streamlined our security processes, and have regular conversations with security professionals from CNCF tag-security. Soon we are going to undergo a second security audit for an external validation of all the great work we have done over the last few years.

We are incredibly proud of what we have achieved and what we have given to the wider ecosystem. GitOps is close to becoming the de-facto standard. Cloud vendors offer GitOps capabilities to their customers these days, a lot of this is based on Flux as a technology and the learnings we made until today. We are extremely pleased to have this huge ecosystem built on top of and around Flux, including recent Flux UIs!

Next up: Flux going GA

The 2.0.0 release of Flux is drawing near as well!

While Flux has been production ready for quite some time, we have an extremely strict backwards compatibility policy and take major versions very seriously.

The Flux community was working on a number of concurrent projects at the same time: qualifying for Graduation, refactoring the controllers to standardise the internal APIs, stabilizing the use of APIs of e.g. Helm and Git, integrating OCI artifacts and Cosign verification fully into Flux, and more. All of these workstreams were happening at the same time. To make it clear to everyone what a GA release for Flux would look like, we’ve updated our GA roadmap. There are many important details here for those following the 2.0.0 release, but one thing that is very important to us is further stabilizing Flux and its APIs so it will be even easier for new community members to contribute and build on top of Flux!

💖 Huge thank-you

You are all rock stars! 🤩 Continued thanks to everyone of our Flux community members who have, in ways small and large, contributed to the success of Flux!

If you want to celebrate with us or are now more curious about Flux, please join us at our Flux Graduation Ask-Us-Anything sessions:

December 7, 12:00 UTC with Flux maintainers: Daniel, Max, Philip, Sanskar, Stefan, Somtochi
December 8, 18:00 UTC with Flux maintainers: Kingdon, Paulo, Somtochi, Soulé

We are looking forward to seeing you and getting to know you there!

Blog: Flagger adds Gateway API Support

Fri, 11 Mar 2022 13:30:00 +0000

The Flagger team is proud to bring you Kubernetes Gateway API support as part of the 1.19.0 release. Read here about why this is a significant development in Flagger and how you can make use of it.

What is Flagger?

Flagger is a progressive delivery tool that automates the release process for applications running on Kubernetes. It reduces the risk of introducing a new software version in production by gradually shifting traffic to the new version while measuring metrics and running conformance tests.

Flagger was designed to give developers confidence in automating production releases using delivery techniques such as:

Canary release (progressive traffic shifting)
A/B Testing (HTTP headers and cookies traffic routing)
Blue/Green (traffic switching and mirroring)

What is the Gateway API?

The announcement blog post defines its design principles as

Expressiveness - In addition to HTTP host/path matching and TLS, Gateway API can express capabilities like HTTP header manipulation, traffic weighting & mirroring, TCP/UDP routing, and other capabilities that were only possible in Ingress through custom annotations.

Role-oriented design - The API resource model reflects the separation of responsibilities that is common in routing and Kubernetes service networking.

Extensibility - The resources allow arbitrary configuration attachment at various layers within the API. This makes granular customization possible at the most appropriate places.

Flexible conformance - The Gateway API defines varying conformance levels - core (mandatory support), extended (portable if supported), and custom (no portability guarantee), known together as flexible conformance. This promotes a highly portable core API (like Ingress) that still gives flexibility for Gateway controller implementers.

Gateway API exposes a more general API than Ingress for proxying and you can use it for more protocols than just HTTP (although most implementations support just HTTP for now). It models more infrastructure components to provide better deployment and management options. There are three core components to the Gateway API:

GatewayClass: This lets us define which controller implementation we want to use.
Gateway: A Gateway resource is attached to a GatewayClass and has a 1:1 relationship with the actual load balancing infra. It lets us define a set of listeners, through which we can specify which Route resources to evaluate for routing, amongst other things.
HTTPRoute: This is a Route resource that is specific for HTTP requests. It defines routing rules such as filters, path and header matches, etc. and which services should the request be forwarded to.

How does this work in Flagger?

Flagger makes use of the fact that HTTPRoute allows users to define a weight related to each reference to a service inside a routing rule. These weights are used to determine which service should receive a request. For example, if we want to send 10% of our traffic to another service, we can define a HTTPRoute like:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
 name: foo-route
spec:
 parentRefs:
 - name: example-gateway
 hostnames:
 - "foo.example.com"
 rules:
 - matches:
 - path:
 type: PathPrefix
 value: /login
 backendRefs:
 - name: foo-primary
 port: 8080
 weight: 90
 - name: foo-canary
 port: 8080
 weight: 10

This sends 10% of all requests coming to foo.example.com/login to the new service and the other 90% requests go to the stable service. You can read more about traffic splitting in Gateway API here.

Flagger fully automates the creation of HTTPRoutes with the appropriate header matches, path matches, etc and attaches the primary and canary service to the HTTPRoute. During the canary analysis, the weights related to both the services are adjusted accordingly.

If you want to get started right away, have a look at our tutorial, which shows you how to use Contour’s Gateway API implementation and Flagger to automate canary deployments. It won’t take long to follow, but will convey how powerful this integration is.

Flagger works with all implementations

With added support for Gateway API, Flagger now works with all implementations, which means that as of today these are natively supported: Contour, Emissary-Ingress, Google Kubernetes Engine, HAProxy Ingress, HashiCorp Consul, Istio, Kong and Traefik.

The Flagger team has successfully tested Contour and Istio using the v1beta2 Gateway API. Starting with Flagger v1.19, the Gateway API is part of our end-to-end test suite using the Contour implementation.

How metrics work

The Gateway API defines a common interface for traffic management, which saves us from doing anything vendor specific. But the metrics related to the traffic, still are specific to the Ingress/Service Mesh you’re using. Flagger lets you define a custom resource MetricTemplate, which runs queries against your metrics provider and calculates stats like error rate, latency, etc. For example, if you’re using Istio with Gateway API, the below MetricTemplate would calculate the error rate using Prometheus as a provider during a canary analysis:

apiVersion: flagger.app/v1beta1
kind: MetricTemplate
metadata:
 name: error-rate
 namespace: istio-system
spec:
 provider:
 type: prometheus
 address: http://prometheus.istio-system:9090
 query: |
 100 - sum(
 rate(
 istio_requests_total{
 reporter="source",
 destination_workload_namespace="{{ namespace }}",
 destination_workload=~"{{ target }}",
 response_code!~"5.*"
 }[{{ interval }}]
 )
 )
 /
 sum(
 rate(
 istio_requests_total{
 reporter="source",
 destination_workload_namespace="{{ namespace }}",
 destination_workload=~"{{ target }}"
 }[{{ interval }}]
 )
 ) * 100

Similarly the below MetricTemplate allows Flagger to compute the latency when using any Envoy based Ingress/Service Mesh:

apiVersion: flagger.app/v1beta1
kind: MetricTemplate
metadata:
 name: latency
 namespace: flagger-system
spec:
 provider:
 type: prometheus
 address: http://flagger-prometheus:9090
 query: |
 histogram_quantile(0.99,
 sum(
 rate(
 envoy_cluster_upstream_rq_time_bucket{
 envoy_cluster_name=~"{{ namespace }}_{{ target }}-canary_[0-9a-zA-Z-]+",
 }[{{ interval }}]
 )
 ) by (le)
 ) / 1000

Conclusion

The Gateway API is in alpha. As of 2022-03-11 its GitHub README says

The latest supported version is v1alpha2 as released by the v0.4.0 release of this project. This version of the API is expected to graduate to beta in the future with relatively minimal changes.

We as the Flux project will update the integration once the API becomes beta/stable.

Thanks a lot Sanskar Jaiswal for working on the implementation!

We are excited to bring this feature to you and we love feedback! Please let us know if you have feedback, questions or how you are going to use this!

Blog: Flux Security Audit has concluded

Wed, 10 Nov 2021 12:30:00 +0000

As Flux is an Incubation project within the Cloud Native Computing Foundation, we were graciously granted a sponsored audit. The primary aim was to assess Flux’s fundamental security posture and to identify next steps in its security story. The audit was commissioned by the CNCF, and facilitated by OSTIF (the Open Source Technology Improvement Fund). ADA Logics was quickly brought into the picture, and spent a month on the audit.

The Flux maintainers and community are very grateful for the work put into this by everyone and the opportunity to grow and improve as a project.

Our first CVE in Flux

Let’s start with what will likely interest you as a Flux user. The engagement uncovered a privilege escalation vulnerability in Flux that could enable users to gain cluster admin privileges. The issue has been fixed and is assigned CVE 2021-41254, and the full disclosure advisory is available at the following link:

CVE-2021-41254: Privilege escalation to cluster admin on multi-tenant Flux.

Description:

Users that can create Kubernetes Secrets, Service Accounts and Flux Kustomization objects, could execute commands inside the kustomize-controller container by embedding a shell script in a Kubernetes Secret. This can be used to run kubectl commands under the Service Account of kustomize-controller, thus allowing an authenticated Kubernetes user to gain cluster admin privileges.

Impact:

Multi-tenant environments where non-admin users have permissions to create Flux Kustomization objects are affected by this issue.

Fix:

This vulnerability was fixed in kustomize-controller v0.15.0 (included in Flux v0.18.0) released on 2021-10-08. Starting with v0.15, the kustomize-controller no longer executes shell commands on the container OS and the kubectl binary has been removed from the container image.

Audit report with full details

We are thankful for the great attention to detail by the team at ADA Logics. The whole report can be found here. To benefit from the analysis in all its detail, we created a project board in GitHub. If you take a look at it closely, you will see that we have fixed some of the most immediate issues already.

Broadly speaking, the issues fall into three categories:

Enabling Fuzzing for the Flux project
Documentation issues
Concrete issues discovered in the Flux code

Flux coming to OSS-Fuzz

The team at ADA Logics didn’t stop at reviewing Flux code. We were pleasantly surprised to receive actual PRs by the team, who set down and helped us integrate with the OSS-Fuzz project. Some of this work still needs to be integrated into all of the Flux controllers, but we are very pleased that a start has been made! OSS-Fuzz is a service for running fuzzers continuously on important open source projects, and the goal is to use sophisticated dynamic analysis to uncover security and reliability issues. There are already numerous other CNCF projects integrated, e.g. Kubernetes, Envoy and Fluent-bit, and we’re excited to be a part of that.

Our documentation from an outside perspective

One very important piece of feedback was that our documentation is mostly geared towards end users, who need very concrete advice on how to integrate Flux into their setups. We provide lots of examples, which are helpful if you want Flux to behave the right way. What is missing to date is an architectural overview and documentation which focuses on the security-related aspects of Flux.

What transpired during the code review

The team at ADA Logics found 22 individual issues, some of which were results from the fuzzers. 1 high severity (that’s the above mentioned CVE), 3 medium severity, 13 low severity and 5 informational.

We appreciate the attention to detail by the team at ADA Logics. The issues range from dependency upgrades to oversights in the code (files which aren’t closed during an operation, unhandled errors) to misleading documentation.

Issue	Severity
1: Arbitrary command execution via command injection in the kustomize controller by way of secrets	High
2: Nil-dereference in image-automation controller	Low
3: Credentials exposed in environment variables and command line arguments	Medium
4: Use of deprecated library	Low
5: Invalid and missing testing documentation	Informational
6: Bug fixes do not always include regression tests	Informational
7: Deprecated SHA-1 is used for checksums	Low
8: Missing checksum verification	Medium
9: Inconsistent and missing logging	Low
10: Reading large files can crash flux with an out-of-memory bug	Low
11: Files are opened but never closed	Low
12: Unhandled error	Low
13: Slice bounds out of range	Low
14: Possible nil-deref in image-automation controller	Low
15: Inconsistent code-styles and potential nil-dereferences	Informational
16: Missing return statement after error	Low
17: File extension comparisons are case sensitive	Low
18: Some dependencies are outdated	Informational
19: Lack of container security options in deployed pods	Low
20: Unhandled errors from deferred file close operations	Low
21: x509 certificates are not used for Webex	Medium
22: Unnecessary conditions in the code	Informational

At the time of writing, 43% of the issues were still TODO, 21% WIP and 36% DONE.

The Road Ahead

We are very happy we were given the opportunity to work with and have our assumptions and code reviewed and tested by security experts. Early on we decided that we want to benefit from the findings as much as possible. That’s why we created a project board and added a review of it as a standing agenda item in our weekly dev meetings.

“The Flux team also created a public and easy to track dashboard showing all of the work we've done together and is a fantastic example of good issue-tracking and remediation.”

-- Derek Zimmer, President and Executive Director, OSTIF

Growing the team

If you are interested in contributing to this, we are very much looking forward to working with you. We welcome contributions in helping resolve issues of the road, additional comments on our security posture and also welcome contributions in the form of extending our fuzzing infrastructure. Finally, if you have any additional security feedback, please come and talk to us.

We are working full steam on the Flux Roadmap, just recently got more maintainers involved and continue to listen to feedback.

Again we would like to thank the Cloud Native Computing Foundation for sponsoring the audit, the Open Source Technology Improvement Fund for the coordination and ADA Logics for the careful review and advice during the audit period.

We are happy and proud to be part of this community!

Blog: Server-side reconciliation is coming

Tue, 28 Sep 2021 12:30:00 +0000

tl;dr: Server-side reconciliation will make Flux more performant, improve overall observability and going forward will allow us to add new capabilities, like being able to preview local changes to manifests without pushing to upstream.

⚠ Changes required: Due to a Kubernetes issue, we require a certain set of Kubernetes releases (starting 1.16.11 - more on this below) as a minimum. The logs, events and alerts that report Kubernetes namespaced object changes are now using the Kind/Namespace/Name format instead of Kind/Name.

We rarely do this, but this time we want to give you some advance notice of a big upcoming feature you will be pleased about. Since Kubernetes moved server-side apply to GA, we are offering you a new reconciler based on it, and graduating the API to v1beta2.

What’s happening

When does this happen?
With the release of Flux 0.18, we will move to the new reconciler. It will be released in the coming weeks. Refer to this PR for more information.
Do I have to use the new thing?
Yes. Flux will be more performant, less error-prone and from a maintenance perspective will be a lot easier for us. We understand that this new feature will require changes on your end, but we are certain you are going to like the new experience!
Will my clusters stop working?
No, but you will need to do a little preparation to make sure Flux can still apply your configurations. See below.
Note: The pre-flight checks should be able to catch issues like meeting the minimum required Kubernetes version.

Here is what you get

The new reconciler improves performance (CPU, memory, network, FD usage) and reduces the number of calls to Kubernetes API by replacing kubectl exec calls with a specialized applier written in Go.
We are able to validate and reconcile sources that contain both CRDs and CRs.
Detects and reports drift between the desired state (git, s3, etc) and cluster state reliably.
In the future: Preview of local changes to manifests without pushing to upstream (flux diff -k command TBA).
Being able to wait for all applied resources to become ready without requiring users to fill in the health checks list.
Improves the overall observability of the reconciliation process by reporting in real-time the garbage collection and health assessment actions.

This is what you need to do to prepare

Check the Kubernetes version you are running in your cluster. All the versions below fix a regression in the managed fields and field type.

Kubernetes version	Minimum required*
`v1.16`	`>= 1.16.11`
`v1.17`	`>= 1.17.7`
`v1.18`	`>= 1.18.4`
`v1.19` and later	`>= 1.19.0`

* Update 2021-10-11:

If you are using APIService objects (for example metrics-server), you will need to update to 1.18.18, 1.19.10, 1.20.6 or 1.21.0 at least. See this post for more information.

Namespaced objects must contain metadata.namespace, defaulting to the default namespace is no longer supported. This means you will need to chase down any namespaced resources in your configuration files that are left to default, and give them a namespace. Keep in mind that kustomizations are often used to assign a namespace, so even if a particular file doesn’t have a namespace in it, it may not represent a problem.

The logs, events and alerts that report Kubernetes namespaced object changes are now using the Kind/Namespace/Name format instead of Kind/Name e.g.:

Service/flux-demo/podinfo unchanged
Deployment/flux-demo/podinfo configured
HorizontalPodAutoscaler/flux-demo/podinfo deleted

Any automation or monitoring that relies on a particular format in the logs will need to be adapted. Ideally, you should try to handle both the old and new formats.

In terms of API changes, the kustomize.toolkit.fluxcd.io/v1beta2 API is backwards compatible with v1beta1. This is done automatically by the Kubernetes API server, and no preparation is required. You may wish to translate your Flux Kustomization resources, though, according to the following table.

Additions and deprecations:

Change in the new version	What you should do
Version is now `v1beta2`	Change the version: `apiVersion: kustomize.toolkit.fluxcd.io/v1beta2`
`.spec.validation` deprecated	Server-side validation is now assumed. Remove this field from `.spec.`
`.spec.patchesStrategicMerge` deprecated in favour of `.spec.patches`	Convert each entry from `.spec.patchesStrategicMerge` into an inline strategic merge patch, like this example given in the Kustomize documentation, and append to `.spec.patches.`. Note that the value in the patch field is quoted; that is, it is the YAML or JSON of the patch, stringified.
`.spec.patchesJson6902` deprecated in favour of `.spec.patches`	Convert each entry from `.spec.patchesJson6902` into an inline JSON6902 patch, and append to `.spec.patches`. Note that the value in the patch field is quoted; that is, it is the YAML or JSON of the patch, stringified.
`.status.snapshot` replaced by `.status.inventory`	`.status` is not kept in files, so you will not need to account for this.
`.spec.wait` added	When true, the controller will wait for all the reconciled resources to become ready, and ignore `.spec.healthChecks`. There is no preparation needed for this, since it’s a new feature.

Why we are doing this

When we started Flux v2, we set a goal to stop relying on third party binaries for core features. While we have successfully replaced the Git CLI shell execs with Go libraries (go-git, git2go) and C libraries (libgit2, libssh2), the kustomize CLI with Go libraries (kustomize/api, kustomize/kyaml), we still depend on the kubectl CLI for the three-way-merge apply feature. With Kubernetes “server-side apply” being promoted to GA, we can finally get rid of kubectl and drive the reconciliation using exclusively the controller-runtime Go client.

Please take a look at the PR introducing this change, as it talks at length about the issues which are solved by this.

Sneak-preview

Updated on 2021-10-08

The server-side reconciliation has been released in flux2 v0.18.0.

What’s next?

The biggest parts of the work have been done, here is what is still on our TODO list until the release:

Use the SSA manager in Flux CLI to for the flux create commands
Use the SSA manager in Flux CLI to implement flux build and flux diff commands

This is great - I want to participate in this

Please join us in the #flux channel on CNCF Slack ( get an invite here) to discuss this.

Or find out other ways of connecting (including our weekly meetings) on our Community page.

We are looking forward to having you in our community!

Blog: Flux is a CNCF Incubation project

Wed, 10 Mar 2021 06:30:00 +0000

The Flux community is proud to announce that the CNCF Technical Oversight Committee just promoted the Flux project to Incubating status! 🎉

For us as a project, this is proof not only of the wide-spread use of Flux (and Helm Operator) v1, but also of our big strides into becoming a GitOps family of projects and bringing a toolkit approach to Continuous and Progressive Delivery.

We are particularly happy about the support from our community, the project maintainers, contributors and end-users who helped us through this process. Thanks to our friends at Deutsche Telekom, Lunar, MediaMarktSaturn and Sortlist who spoke in favour of Flux and explained their GitOps implementation in user interviews with the CNCF.

As a project we have come quite far in the last 5 years. From the time when it was a Weaveworks-internal project to make simple deployments happen to a buzzing and healthy project with maintainers from various companies, hundreds of contributors and a regular release cycle. Thanks a lot to everyone who made Flux possible!

“We created Flux as an open source project because we believe that is the best environment in which to develop software. Since then I have continually been shown that trusting your users and contributors is rewarded. Although it is still a modest project, there is a loyal and growing community around Flux and the methodology it engendered, GitOps. I see the acceptance of Flux into CNCF incubation status as validation of that community as much as the software itself.”

-- Michael Bridgen, Flux co-creator

What’s next for Flux

For 10 months we have been working on the new iteration of Flux. It is based on modern tooling, very composable and we were able to add long-requested features in next to no time.

Flux as a project has been on this trajectory for a longer time already: Flux was started in 2016, the Helm Operator was added in 2018, kustomize support added in 2019. 2020 was the year in which re-started the project to turn Flux into a GitOps family of projects, where simple and focused controllers can naturally be composed. 2021 saw Flagger being moved into the Flux organization and will see the GA release of Flux v2 in the coming months.

Flux v2 getting closer to GA

We are very proud of where Flux v2 is at now, and are carefully working toward a GA release, at which point we’ll recommend that all Flux v1 users migrate to Flux v2.

Now is the perfect time to familiarise yourself with Flux v2 - the Get Started guide only takes a couple of minutes to complete. If you prefer a video, check out our resources section.

Migrating from v1 will require some work, but it will definitely be worth it: in this iteration you are going to get

Support for multiple Git repositories
Operational insight through health checks, events and alerts
Multi-tenancy capabilities
Better performance
And lots of other new features

We’ve taken our time to ensure that Flux v2 has feature parity with Flux v1, and that end users have the best experience possible migrating to Flux v2. Stay tuned for our upcoming announcement about the Flux v2 migration and support timeline.

Get started today

If you have been waiting to start your GitOps journey, today is a good time to start! Check out the following upcoming events

Video Replay: Migrating from Flux v1 to Flux v2 with Leigh Capili

22 Mar 2021 - Hands-On GitOps Patterns for Helm Users with Scott Rigby

25 Mar 2021 - CNCF On-Demand Webinar: Flux is Incubating + The Road Ahead

5 Apr 2021 - Flux v2 on Azure with Leigh Capili

19 Apr 2021 - Setting up Notifications, Alerts, & Webhook with Flux v2 by Alison Dowdney

Or dive straight into our Get Started guide to get started with the next generation of Flux today.

Flux – announcement

Blog: Announcing Flux 2.7 GA

Highlights

General availability of Image Update Automation

Watching for changes in ConfigMaps and Secrets

Workload Identity Authentication for Remote Clusters

Object-level Workload Identity

OpenTelemetry Tracing

Controller Improvements

CLI Improvements

Artifact Generators

Multiple Source Composition

Monorepo Decomposition

Supported Versions

Upgrade Procedure

Upgrade Procedure for Flux v2.7+

Over and out

Blog: FluxCon NA 2025

Call for Papers

New Use-Cases

Connect with the Community

Blog: Announcing Flux 2.6 GA

Highlights

General availability of Flux OCI Artifacts

Breaking changes

Image Automation Digest Pinning

Object-level Workload Identity

GitHub App Authentication

Notifications Improvements

Controller Improvements

Supported Versions

Over and out

Blog: Announcing Flux 2.5 GA

Highlights

Health Checks for Custom Resources

GitHub App Authentication for Git Repositories

Custom event metadata for notifications

CLI Improvements

Supported Versions

Enterprise support

Over and out

Blog: Announcing Flux 2.4 GA

General availability of Flux S3-compatible Source API

Azure DevOps OIDC Authentication

Controller Improvements

CLI Improvements

Supported Versions

Enterprise support

Flux Operator and OpenShift Compatibility

Over and out

Blog: Announcing Flux 2.3 GA

General availability of Flux Helm features and APIs

Enhanced Helm OCI support

Improved observability of Helm releases

Benchmark results

Image update automation improvements

Migration to v1beta2 template model

Signatures verification with Notation

Terraform provider improvements

New maintainer

Controllers improvements

CLI improvements

Breaking changes and deprecations

Supported versions

Enterprise support

Installing or upgrading Flux

What’s next for Flux?

Over and out

Blog: Flux project gains New Corporate Support and Ecosystem in 2024

Vendors and clouds are stepping up contributions

New Enterprise adopters: Silva project, Cisco, Tchibo, and more

New Support and Ecosystem: Hirings and Value-Add Extensions

Cloud Native Computing Foundation Exemplar Project

Blog: Announcing Flux 2.2 GA

Important things first: API changes

Enhanced HelmRelease reconciliation model

Improved observability of Helm releases

Recovery from pending-* Helm release state

Helm Release drift detection and correction

Forcing and retrying Helm releases

Enhanced `HelmRelease` reconciliation model

Recovery from `pending-*` Helm release state