Project post originally published on the Flux blog by Daniel Holbach

As the Flux family of projects and its communities are growing, we strive to inform you each month about what has already landed, new possibilities which are available for integration, and where you can get involved. Read our last update here.

It’s the beginning of March 2023 – let’s recap together what happened in February – it has been a lot!

News in the Flux family

Two Flux minor releases hit the streets

Last month gave us two minor releases of Flux. Here’s what you can look forward to on your next upgrade. As always: Users are encouraged to upgrade for the best experience.

v0.40: ImageRepository and ImagePolicy promote to v1beta2

Flux v0.40 brings a number of features and improvements:

To read up on the details of the above, you might want to check out these pieces of documentation:

v0.39: better security support, improved performance and observability

Flux v0.39 includes these highlights:

Features and improvements include:

Documentation

Big thanks to all the Flux contributors that helped us with this release!

Security news

We extended our Security Docs to show more examples for verifying SBOMs. Now the newly introduced SLSA Provenance Attestation feature is documented as well.

Flagger 1.29.0 brings support for template variables for analysis metrics

A canary analysis metric can reference a set of custom variables with .spec.analysis.metrics[].templateVariables. For more info see the docs. Furthermore, a bug related to Canary releases with session affinity has been fixed.

Improvements & Fixes

Flux Ecosystem

Weave GitOps

The latest release includes enhancements, improvements, bug fixes, and documentation updates to enhance Weave GitOps’ overall functionality and user experience.

Enhancements in this version include improved detection of the OSS dashboard and the addition of imagePolicy details. The get-session logs feature has also been enhanced to support pod logs, filters, and return logging sources. A new optional tooltip has been added to the Timestamp component, and the formatting of log message timestamps in the log UI has been improved.

UI enhancements in this version aim to improve the overall user experience of Weave GitOps. Access properties on undefined ImageAutomation objects can now be handled, and an issue where graph nodes hopped around has been fixed. A text search has been added to table URLs, and undefined icon types can now be handled.

The Helm reloading strategy has been fixed, and the chart spec has been updated with values.yaml to address reloading issues.

Terraform-controller

The latest release of TF-Controller, version v0.14.0, introduces several new features and many bug fixes. Notably, the release offers first-class support for Terraform Cloud with the spec.cloud field. This enhancement allows Weave GitOps Enterprise users to leverage GitOps Templates with Terraform Cloud as a backend for their Terraform resources, opening up a world of possibilities for GitOps workflows.

In addition to Terraform Cloud support, the update upgrades Flux to v0.40.0 and Terraform to v1.3.9, with bug fixes including improved AWS package documentation, and missing inventory entries.

The new release also offers multi-arch image support, customizable controller log encoding, and the option to configure Kube API QPS and Burst. The Terraform apply stage now features a parallelism option for even more customization.

Users are highly recommended to upgrade to TF-Controller v0.14.0 to take advantage of these improvements. For any feedback or questions, please reach out to the team on the GitHub repository.

Flux Subsystem for Argo

The team has recently updated Flamingo by rebasing it onto the upstream ArgoCD versions v2.3.17, v2.4.23, and 2.5.11. This update has been made in response to the recent vulnerability CVE-2023-23947, and the team strongly recommends that all users update their systems as soon as possible.

Updated Flamingo images are:

VS Code GitOps Extension

Version 0.23.0 of the vscode-gitops-tools extension was released. This version introduces a new webview for configuring GitRepositoryHelmRepositoryOCIRepositoryBucket and Kustomization resources. Extension context (right-click) file and folder actions now work with multiple open repositories in the expected way.

Pulumi Kubernetes Operator

Michel Bridgen wrote a blog post about how to combine Pulumi with Flux using the Pulumi Kubernetes Operator, which extends the reach of both Flux and Pulumi.

What you can look forward to in the next release of the operator is that – based on Paolo’s work on git-go – the operator (and Pulumi itself) will be able work with Azure DevOps.

Recent & Upcoming Events

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

Recent Events (ICYMI) 📺

We feel blessed to have such a big community of users, contributors and integrators and so many are happy to talk about their experiences. In February here are a couple of talks we would like to highlight.

Here is a list of additional videos and topics we really enjoyed – please let us know if we missed anything of interest and we will make sure to mention it in the next post!

Upcoming Events 📆

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

Flux 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.

The next dates are going to be:

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 on Slack.

We really enjoyed this demo of the k3d git server recently. It’s a local Git server that runs outside of Kubernetes, to support offline dev in a realistic but also simple way that does not depend on GitHub or other hosted services.

In other news

Gitlab adopts Flux for GitOps

We are incredibly pleased that GitLab chose to move forward with Flux for the GitOps capabilities in their project. In the past weeks, members of the GitLab team joined our Dev meetings where it became clearer what needs to happen next. This is another great recognition of the versatility and great feature set of Flux and we very much look forward to the collaboration.

Please check out the announcement on the GitLab blog, which links to all the individual discussions and development epics where you can track the progress of the integration.

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! ✍

TrueLayer: Flux2 migration: how we dropped our CPU usage by nearly 40x

Flux logo

We love hearing end-user success stories, particularly to learn how a migration went well. Surya Pandian wrote up the entire experience in the blog post and comes to this conclusion:

With our original Flux setup, we were running one pod per GitOps, and with 40 teams, that required a lot of cash and CPU. But with this setup, we run just one flux GitOps agent for an entire cluster. In total, one flux GitOps agent manages over 40 GitRepoCRDResources and 240 FluxKustomizeCRDResources.

Our migration to Flux2 has paved the way for a config-managed setup. Not only did this drastically reduce costs, but it also made Flux reconciliations faster and reduced CPU usage by almost 40x.

As the sun sets on Flux1, migrating to Flux2 may sound like a daunting task. But with the right migration plan, engineering teams can reap the benefits.

Surya Pandian

Flux + Testkube: GitOps Testing is here

Abdallah Abedraba describes how to set up Flux with Testkube in the blog post in an easy to follow step-by-step fashion. The takeaway is:

Once fully realized – using GitOps for testing of Kubernetes applications as described above provides a powerful alternative to a more traditional approach where orchestration is tied to your current CI/CD tooling and not closely aligned with the lifecycle of Kubernetes applications.

This tutorial uses Postman collections for testing an API, but you can bring your a whole suite of tests with you to Testkube.

Abdallah Abedraba

News from the Website and our Docs

Flux Adopters shout-out

We are very pleased to announce that the following adopters of Flux have come forward and added themselves to our website: B1 Systems GmbH and Wildlife Studios.

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.

More docs and website news

We are constantly improving our documentation and website – here are a couple of small things we landed recently:

Thanks a lot to these folks who contributed to docs and website: Ben Bodenmiller, Stefan Prodan, Stefan Bodenmiller, Michael Bridgen, Hidde Beydals, Sunny, Kingdon Barrett, Mac Chaffee, Ronan, Sanskar Jaiswal, zipizapclouds.

Flux Project Facts

We are very proud of what we have put together. We want to reiterate some Flux facts – they are sort of our mission statement with Flux.

  1. 🤝 Flux provides GitOps for both apps or infrastructure. Flux and Flagger deploy apps with canaries, feature flags, and A/B rollouts. Flux can also manage any Kubernetes resource. Infrastructure and workload dependency management is built-in.
  2. 🤖 Just push to Git and Flux does the rest. Flux enables application deployment (CD) and (with the help of Flagger) progressive delivery (PD) through automatic reconciliation. Flux can even push back to Git for you with automated container image updates to Git (image scanning and patching).
  3. 🔩 Flux works with your existing tools: Flux works with your Git providers (GitHub, GitLab, Bitbucket, can even use s3-compatible buckets as a source), all major container registries, fully integrates with OCI and all CI workflow providers.
  4. 🔒 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.
  5. ☸️ Flux works with any Kubernetes and all common Kubernetes tooling: Kustomize, Helm, RBAC, and policy-driven validation (OPA, Kyverno, admission controllers) so it simply falls into place.
  6. 🤹 Flux does Multi-Tenancy (and “Multi-everything”): Flux uses true Kubernetes RBAC via impersonation and supports multiple Git repositories. Multi-cluster infrastructure and apps work out of the box with Cluster API: Flux can use one Kubernetes cluster to manage apps in either the same or other clusters, spin up additional clusters themselves, and manage clusters including lifecycle and fleets.
  7. ✨ Dashboards love Flux: No matter if you use one of the Flux UIs or a hosted cloud offering from your cloud vendor, Flux has a thriving ecosystem of integrations and products built on top of it and all have great dashboards for you.
  8. 📞 Flux alerts and notifies: Flux provides health assessments, alerting to external systems and external events handling. Just “git push”, and get notified on Slack and other chat systems.
  9. 👍 Users trust Flux: Flux is a CNCF Graduated project and was categorised as “Adopt” on the CNCF CI/CD Tech Radar (alongside Helm).
  10. 💖 Flux has a lovely community that is very easy to work with! We welcome contributors of any kind. The components of Flux are on Kubernetes core controller-runtime, so anyone can contribute and its functionality can be extended very easily.

Over and out

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

We are looking forward to working with you.