GitOps Toolkit Roadmap and the road to Flux v2

Announcements Ecosystem
1

We are very happy to announce that we finalised the plans for the GitOps Toolkit and thus the road to Flux v2. We are especially pleased as we got great feedback and contributions from a wide range of people.

As you all know Flux v1 is a monolithic do-it-all operator, and the GitOps Toolkit separates the functionality into specialized controllers. Flux v2 will be a curated configuration of the GitOps Toolkit which you can simply consume using the tk command. Limiting the use of features and/or adding extensions on top of Flux has never been this easy.

You can review the roadmap in greater detail here. The big blocks we want to land are:

  • Feature parity with Flux v1 in read-only mode (80% completed). Once we’re done we will be able to ask people to transition over.
  • Image update capabilities (design in progress). This constitutes the biggest block of work still.
  • Helm Operator v2 (50% done).

We will move Flux v1 into maintenance mode now (no new features will be added). Once above work items are done, we will still support Flux v1 for 6 months - this will be a transition period for everyone to update their deployments.

1600Ă—1057 220 KB

If you immediately want to get started and check things out, that’s great. You can find more information here:

We believe we are building something extraordinary here - we will need your help to do it! We want the GitOps Toolkit to be a set of components that fit the bill for all GitOps needs. One example for how the components are meant to be reusable is Flagger: the team is looking at using the Toolkit’s notification-controller.

Here are some ways how you can help:

Please talk to us if you have any questions or feedback.

2 Likes
2

Cross-posted from https://www.weave.works/blog/flux-v2-september-update

The Road to Flux v2 - September update

This is the first blog post in a series which accompanies the development of the GitOps Toolkit on the road to delivering Flux v2 and more. We want to highlight what has been happening in development in the past weeks, who has contributed and what you can look forward to. And if you are curious, how to try it out for yourself.

It has been three weeks since the Flux community announced their plans for Flux v2 that has been rebuilt from scratch and based on top of the new GitOps Toolkit. If you haven’t heard the news yet, here’s what we are planning on doing:

  1. The GitOps functionality in Flux and Helm Operator is now delivered by individual components, to enable and support far more use-cases and to simplify development.
  2. Everything is driven by Custom Resources for more control and better observability.
  3. We built the GitOps Toolkit from the ground up incorporating the most requested features:
  • Support for multiple source Git repositories
  • Operational insight through health checks, events and alerts
  • Multi-tenancy capabilities, such as applying each source repository with its own set of permissions

In April this year we started with early experimentation for building a proof-of-concept, which was first shown at the GitOps Days virtual event in May, followed by a request-for-comments period and roadmap discussions in June. Since then the Flux community has come a long way.

Our highlight in this episode: the road to Helm Operator v2

Since the announcement, the team has made great strides, especially in the area of Helm: around 90% of all the work related to building the “Helm Operator v2” is done. The Helm Controller now has support for values from Secret and ConfigMap resources, and support for strategies for handling different kinds of failure. Its API package is also available as an independent Go Module. Failure handling is a big one. It means that you can extensively configure how to automatically remediate an installation, test, or upgrade failure. This includes actions that should be performed to remediate (rollback or uninstall), the number of retries, and even if the release has failed and retries have expired, you can debug the issue more easily. In addition, it is possible to ignore test failures if necessary (as opposed to remediate after a failed “helm test”).

Also the API to support Helm releases, based on source API, has been discussed and designed. In particular, providing values from sources and support for Helm charts from Git. So what’s left for Helm Controller to be on par with today’s Helm Operator? Only implementing support for referring to an alternative chart values file. And of course lots of testing. Before we tell the world they can transition to Helm Operator v2, we need to hear from current users and integrate their feedback.

If you are using Helm Operator right now, it would be fantastic if you could test the Helm Controller: simply check out https://toolkit.fluxcd.io/guides/helmreleases/ and give us feedback on how the journey went for you (find contact info at the bottom of this blog post).

GOTK_Progress_blog_post_1.png
GOTK_Progress_blog_post_1.png1800Ă—2048 151 KB

In other news

Here’s a recap of what happened in the project overall in the past three weeks:

  • Support for HelmChart artifacts built from GitRepository sources.
  • Various bug fixes, e.g. Notification Controller: fix to the Prometheus scraping endpoint.
  • We were approached by members of the Grafana Tanka project who decided to call their binary “tk” so we decided to go with “gotk” from now on.
  • In the future we will also be able to enable ARM support; one blocker for this is that Flux shelled out to the kustomize binary, which has been fixed now.
  • Mozilla SOPS decryption support is coming!

More projects starting to look at using go-git-providers: eksctl, libgitops, and through libgitops: ignite, crdconv, cluster-api-provider-existinginfra and wksctl.

Since Flux become a CNCF Sandbox project about a year ago, we formally started the process to review the project with the CNCF - the PR is worth a read if you are interested in where the project stands as a whole and what happened in the last year. The amount of care and contributions our large community of users and contributors has shown is somewhat mind-boggling. We are certainly very pleased with what we have achieved.

Development-wise the focus for the next few weeks is going to be:

  • Figuring out the final form of Flux v2
  • The next big milestone: Bringing the image automation on par with Flux v1
  • Increasing general test coverage

If you want to help us shape the future of any of these, please reach out - we would love to hear from you.

Special thanks to our contributors - here’s what they landed:

  • Martin H Berwanger improved the gotk install script and automated the upgrades of controller component dependencies in the Toollkit.
  • Sean Eagan contributed the conditional remediation on failed actions to the helm-controller.
  • Philip Laine implemented notifications for Github commits.
  • We also had many folks jump into conceptional work in our Github Discussions:
    • Shane Sveller is looking into non-curl-bash installation methods
    • Moshe Immerman had a look at the image update automation design
    • Sean Eagan has been working on various parts of the Helm controller planning. Calle Petterson, Jonas Arneberg and Steve Hipwell as well.
    • Daniel Morgan in SOPS support and Philip Laine in e2e testing, exposing image fields in kustomization resources and a possible Job controller.

There is still lots where you can help shape the future of the GitOps Toolkit. Some of the important discussions are:

We are looking forward to working with you.

Here is how you can get involved:

3

Cross-posted from The Road to Flux v2 - October update

The Road to Flux v2 - October update

The Flux community has set itself very ambitious goals for version 2 and as it’s a multi-month project we strive to inform you of what’s landed every month, including new possibilities that are available for integration and where you can get involved. Read last month’s update here.

Let’s recap what happened in September. There has been quite a lot.

Flux v1 is in maintenance mode

As already mentioned in the announcement of our Flux v2 and GitOps Toolkit plans, Flux v1 (and Helm Operator) are in maintenance mode and have been for a while. This means we are focusing all of our attention on v2 and we’ll only be working on Flux and Helm Operator v1 for critical updates and fixes. If you have important PRs that you want to land or if you are considering helping out with v1 maintenance, please talk to us. We want to make this transition work for everyone.

GitOps Toolkit about to reach a big milestone: 0.1.0

We have been working on the GitOps Toolkit for about six months and we have largely reached feature parity with Flux v1 (in read-only mode) and Helm Operator v1. The 0.1.0 milestone will mean that the APIs will be promoted to beta and that we will want more widespread testing and experimentation of Flux for those two sets of use-cases. Going forward, changes to the API will be accompanied by a conversion mechanism. With the v0.1 release the API becomes more stable but while in beta phase there are no guarantees about backwards compatibility between beta releases. We will also be working on migration paths and guides.

You can expect the release in the next couple of days and we would welcome any feedback you might have. Check out the “Get Started” guide (including others) on https://toolkit.fluxcd.io/.

This is a great achievement, so thanks a lot Bianca Cheng Costanzo, Daniel Holbach, Dinos Kousidis, Erik Hollensbe, Hidde Beydals, Ihor Dvoretskyi, Kevin McDermott, Leigh Capili, Lucas Käldström, Manuel Morejón, Martin H Berwanger, Michael Bridgen, Michael Cristina, Mike Beaumont, Philip Laine, Sara El-Zayat, Scott Rigby, Sean Eagan, Simon Howe, Stefan Prodan and Yiannis Triantafyllopoulos for your help thus far!

go-git-providers adding new maintainers and Gitlab support

Another Flux project that has seen new maintainers pick up the work is go-git-providers. Mike Beaumont, Simon Howe, Dinos Kousidis, Yiannis Triantafyllopoulos and Sara El-Zayat all work for Weaveworks and they stepped in to pick up where Lucas Käldström left off.

Dinos says:

“The project offers a common interface to run operations on different git providers. It defines an abstraction and mapping on repositories, organizations, and teams so that projects don’t have to combine provider specific ones (go-github, go-gitlab, etc.). We just released 0.0.3 which adds the gitlab provider alongside the github one that was added by Lucas. A BitBucket provider is also being discussed .”

In other news

The list of improvements and new features is long, so check out the links below to find out more:

The list goes on. We are particularly pleased with the thoughtfulness and tone of our growing community that is spec’ing out future features and integrations over in our Github Discussions section. There are many great things to come and we will showcase some of the work in our next episode.

We also created the /fluxcd/community repository. This is in response to a number of discussions which happened recently where we realised we want to better express our project-level governance and community docs - expect more discussion about this in future meetings, on Slack and elsewhere. If you would like to participate in this effort, talk to Daniel Holbach and Scott Rigby (or anyone else in the project really).

Get involved

If you like what you have read and would like to get involved, here’s how:

We are looking forward to working with you.

4

Cross-posted from The Road to Flux v2 - November update

The Road to Flux v2 - November update

Before we get started, what is GitOps?

If you are new to the community and GitOps, you might want to check out our GitOps manifesto or the official GitOps FAQ.

If you want to see the latest demo of GitOps Toolkit in action, check out this video:

The road to Flux v2

The Flux community has set itself very ambitious goals for version 2 and as it’s a multi-month project, 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 last month’s update here.

Let’s recap what happened in October - there have been many changes.

Flux v2 - what’s in a name?

In the past few weeks, we have found ourselves talking and explaining our plans for the future of the Flux project a lot more, and the received feedback was that the naming of the project was difficult to get used to, so here’s what we have decided to use in terms of naming:

  • Flux v2 now lives in the fluxcd/flux2 repository
  • the CLI was renamed to “flux”
  • the system namespace is called “flux-system”
  • And the website https://fluxcd.io will see consolidation in the next few days too.

The term GitOps Toolkit is a SDK for building Kubernetes controllers that can interact with Flux to extend its functionality.

This was the first decision made using the new Governance process (:arrow_down:more on this below).

Flux v1 is in maintenance mode

This means we

  • are focusing most of our attention on Flux v2
  • will only be working on Flux (and the Helm Operator v1) for critical updates and bug fixes

Flux is still being maintained and supported, it will just take a little bit longer to get around to addressing issues and PRs. Critical bug fixes have our priority. Read more about what this means.

(The same goes for Helm Operator v1.)

Flux v2 reaches 0.2.0

With 0.2.0 we are celebrating a big milestone. Two out of three of our big areas of workare done:

Regarding image updates, the design that replaces Flux v1’s image updates has been implemented. Here are instructions for installing and using it.

Since the last minor release we also added many more features. These are a few of our favourites:

  • Remote cluster targeting e.g. cluster-api support (we will add docs for this, but for now refer to the docs in the kustomize and helm controller repos)
  • Improvements to the handling of SemVer ranges (pre-releases are now excluded from e.g. 1.0.x ranges)
  • Added support for downloading dependency charts for Helm charts from GitRepository and Bucket sources
  • Picking the last version for ambiguous SemVer matches for GitRepository tag references, and charts from GitRepository sources (based on the timestamp metadata available in the source systems)

We also wrote a migration guide, so if you are curious and want to test Flux v2 in a Dev environment, please have a look at https://github.com/fluxcd/flux… and give us feedback. (A migration guide for Helm Operator will be published soon as well.)

The Flux project is growing up: our focus on governance and community

:mega: We’re happy to announce that we now have an official document to define the governance process for the Flux CNCF project and community.

:sparkling_heart: A lot of care was taken to ensure this reflected the spirit of the Flux community, the priority of users, and intent to broaden contributorship. We also connected with maintainers of other CNCF projects to learn what works well for them and what they may have done differently in terms of governance. With over 100 comments, the maintainers discussed and collaborated on this over a period of several weeks until finally reaching a happy consensus. If you want to see everything that went into this effort, it’s all discoverable in this pull request.

:clap: This is a major step forward for the Flux community: it will enable a broader contribution base as there is now a defined process for becoming more involved, and is a step toward CNCF project incubation and eventual graduation.

:construction: This comes with one notable change for Flux contributors: Developer Certificate of Origin (DCO) commit signoff will be required for all new code contributions in the fluxcd GitHub org repos. It’s easy to implement - for details, see our contributors guide.

:speech_balloon: Defining clear rules for governance and participation demonstrates how Flux has matured in the past four years since its inception: born out of a specific need to automate deployments at Weaveworks it quickly proved useful and moved on to be voted along with Helm as one of the few Cloud Native projects into the ADOPT category of the CNCF User Survey. With hundreds of contributors and an ever-growing number of organizations picking up Flux, it was time to agree on governance rules and further democratize the project.

Philip Laine joins notification-controller maintainers

notification-controller is the event forwarder and notification dispatcher for the GitOps Toolkit controllers (read the specification here).

For a few weeks now, Philip Laine has been helping out with the project and agreed to take on leadership for it too. Here’s a quick message from Philip:

Philip_Laine_.png

I am a DevOps engineer at a company called Xenit where I mostly work with Kubernetes and related tooling, where Flux is the obvious choice for CD. My first contribution to the notification controller was the GitHub provider. The provider allows the notification controller to update the status of a commit, when an event linked to that commit occurs. This will hopefully allow for deployment feedback that is closer to the code. I am currently looking at bringing to light use cases other than sending messages to Slack. These use cases could for example be triggering other actions inside the cluster when a specific event occurs. Getting involved has been very easy as community meetings and other communication is public. The community and maintainers have been great so far.

In our last Flux Dev meeting Philip also presented his work on the Flux v2 Terraform provider. Reach out to him if you have feedback or want to help. We’re super happy the Flux project is growing like this!

Upcoming events

The Flux community is already going out of their way to make sure people learn about what we’re building together. You might want to add these to your hearing/viewing list:

If you prefer live action, here are some upcoming events:

GitOps Days EMEA

GitOps Days EMEA 2020 is a 2-day online event on November 12-13, 2020 .

Day 1 will cover introductions to GitOps, the business value of GitOps, and use cases.

Day 2 we’ll nerd out and dive into more technical aspects, including workshops for:

  • Getting Started with GitOps
  • Flux v2 and the Future of Flux
  • Helm Operator and Helm Controller Migration

In other news

In recent weeks, we added Prometheus instrumentation for all the toolkit controllers. There is a new Grafana dashboard available that gives you an overview of the cluster reconciliation. The new dashboard displays the readiness status of each kustomization, helm release, git and helm repository along with stats about the duration of each reconciliation run. Here are the docs on how to install the monitoring stack: Installation | Flux

GOTK_cluster_stats.png
GOTK_cluster_stats.png3294Ă—2870 232 KB

You can also check out the new [monitoring guide](https://toolkit.fluxcd.io/guides/monitoring/) which explains how to set up the monitoring stack. It covers the reconciliation metrics as well now.

Scott Rigby and Daniel Holbach joined as maintainers of the /website and /community repositories. In the upcoming weeks both will help out with the new website and start formalising some of the community plans, e.g. contributor happiness and communications. If you’d like to help out with any of these projects, have questions or concerns, please talk to us on Slack! :smiling_face_with_three_hearts:

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.

5

Cross-posted from December Update | Flux

December Update

2020-12-01 5 minute read

Before we get started, what is GitOps?

If you are new to the community and GitOps, you might want to check out the GitOps manifesto or the official GitOps FAQ.

The Road to Flux v2

The Flux community has set itself very ambitious goals for version 2 and as it’s a multi-month project, 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 last month’s update here.

Let’s recap what happened in November - there have been many changes.

Newest Flux v2 release: 0.4.0

The highlight is multi-tenancy support: you can now create tenants with the Flux CLI and restrict access to cluster resources with good old Kubernetes RBAC. Other notable changes: source operations for Git and Helm repositories, Helm charts and Buckets can now be suspended/resumed via Flux CLI or Git. This allows you to freeze the cluster reconciliation to the last fetched revision during an incident or on “No Release Fridays”. We’ve also fixed a couple of helm-controller issues and made available a CLI command to inspect the Helm charts status.

To get you started with setting up Flux and managing multi-tenant environments, an example repository and guide has been published on: GitHub - fluxcd/flux2-multi-tenancy: Manage multi-tenant clusters with Flux.

Guides for Helm users

If you have been using the Helm Operator in the past, you should be able to easily upgrade to the Helm Controller (Flux v2). Check out this guide and please give us feedback - we’d love to hear from you:

If you are interested in an example which describes how you can keep e.g. two clusters updated with minimal duplication, check out this repository - it uses Flux v2, Helm and Kustomize:

Aurel Canciu joins Flux v2 maintainers

Aurel Canciu has been putting quite a bit of work into Flux projects in the past weeks. We are very pleased to see his contributions across the project. Let’s hear a few words from Aurel himself:

As an avid promoter of the GitOps set of principles, I was very excited about the new Flux toolkit as a user, so naturally I decided to get involved and contribute to the best of my abilities and time availability. I am happy to now be part of an excellent team of maintainers and help move forward with this promising project.

Aurel Canciu

First milestone of fluxcd.io redesign landed

Ever since Flux moved into the CNCF Sandbox, we had a website for it which Luc Perkins created. For a while we have been thinking about how to best make use of the domain. We came up with a three-stage plan:

  1. Move to new them, point to Flux 2 resources
  2. Add a blog
  3. Subsume current docs and toolkit subdomains under fluxcd.io

Thanks to Hidde Beydals’s tireless work we were able to complete stage 1 and 2. Below is what it currently looks like:

New fluxcd.io homepage
New fluxcd.io homepage1702Ă—1359 251 KB

If you want to help out with the next steps, please reach out.

Fantastic demo on Flux v2

We are very pleased Viktor Farcic from Codefresh took Flux v2 for a second spin and reviewed it in his demo. If you haven’t seen Flux v2 in action yet and want to know what the big deal is about check this out:

Flux v1 is in maintenance mode

This means we

  • are focusing most of our attention on Flux v2
  • will only be working on Flux (and the Helm Operator v1) for critical updates and bug fixes

Flux is still being maintained and supported, it will just take a little bit longer to get around to addressing issues and PRs. Critical bug fixes have our priority. Read more about what this means.

(The same goes for Helm Operator v1.)

The Flux Community team

The Flux community identified work that falls into the categories of contributor experience, advocacy and communications, community management as integral to its success long ago. While this has been an implicit focus of the team for a while, we want to build out the team, open it up and formalise processes.

If you are generally interested in helping out with this effort, let us know. For now we started some social media channels for Flux and want to inform the wider community about what’s happening.

We started a Flux LinkedIn group and Flux Twitter. We will put more effort into building out the Flux community. If you are keen to help in a non-coding fashion, we’re looking forward to hearing from you.

In other news

The Flux community is growing and we are in the middle of a quite a few big discussions:

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 meeting on Dec 3
  • Talk to us in the #flux channel on CNCF Slack
  • Join the planning discussions
  • And if you are completely new to Flux v2, 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.

6

Cross-posted from January 2021 Update | Flux

January 2021 Update

Before we get started, what is GitOps?

If you are new to the community and GitOps, you might want to check out the GitOps manifesto or the official GitOps FAQ.

The Road to Flux v2

The Flux community has set itself very ambitious goals for version 2 and as it’s a multi-month project, 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 last month’s update here.

Let’s recap what happened in December - there have been many changes.

Flagger moves under Flux CD

Flagger
Flagger2216Ă—710 32.3 KB

Flagger extends Flux functionality with progressive delivery strategies like Canary Releases, A/B Testing and Blue/Green and it was specifically designed for GitOps style delivery.

Since the inception of the GitOps Toolkit, it’s clear that fluxcd/ will become more of a family of GitOps related projects. The Flagger maintainers are looking forward to making use of the toolkit components and simplifying Flagger this way. Consolidating the code-bases and thinking in terms of a “Flux Family of Projects” and writing up the roadmap accordingly should benefit both communities as a whole.

The two Flagger maintainers (Stefan Prodan and Takeshi Yoneda) are very happy to see this happening. Thanks also to Weaveworks for agreeing to transfer Flagger and its copyright to fluxcd org (and thus, CNCF).

Review the upcoming roadmap for Flagger - it now includes GitOps Toolkit integration.

Please help us steer this project forward!

Thanks also to everyone who contributed to the latest two releases:

  • Flagger 1.6.0:
    • Add support for A/B testing using Gloo Edge HTTP headers based routing
  • Flagger 1.5.0:
    • Flagger can be installed on multi-arch Kubernetes clusters (Linux AMD64/ARM64/ARM).
    • The multi-arch image is available on GitHub Container Registry at ghcr.io/fluxcd/flagger.

Newest Flux v2 release: 0.5

:rocket: :gift: We’ve released Flux2 v0.5, this is the last release for 2020.

Besides bug fixes and performance improvements, it comes with many new features. The highlights are:

  • Alpha support for automated image updates to Git (thanks to Michael Bridgen - read more in the next paragraph)
  • Support for Azure DevOps and the Git v2 protocol (thanks to Philip Laine - more below)
  • Support for overriding container images in kustomize-controller (thanks to Somtochi Onyekwere)
  • “flux bootstrap” and install commands can now be used on Windows OS without WSL (thanks to Hidde Beydals)
  • flux can now be installed on Arch Linux using AUR packages ( flux-bin or flux-git for the latest release) (thanks to Aurel Canciu)

Automated Image Updates

Automated Image Updates Guide (alpha release)

Flux v2 now includes two controllers for automating image updates – one of the controllers is for scanning container image repositories, and the other updates and commits changes to YAML config, when there are new images to deploy.

These are the Flux v2 version of Flux’s automation, but work a little differently. The guide linked above explains how to set it up. Be aware that this is an alpha release for the image update automation controllers.

Azure DevOps repository support

Flux has not been able to support Azure DevOps repositories up until the 0.5 release. This was due to the git library go-git used by source-controller not supporting specific git capabilities required by Azure Devops. The same requirements do not exist in the other major git providers, which is why this was not caught during the initial development of source-controller.

This resulted in Flux v1 users who used Azure DevOps that were now not able to migrate to Flux v2. The initial attempt at a solution was to implement the missing capabilities in the existing library, which turned into its own epic. Instead the solution was to introduce a secondary git library libgit2 as it implements the required git capabilities. It turned out that libgit2 has its own limitations as it does not currently support shallow cloning, a feature that speeds up the git polling especially in very large git repositories. The compromise is to allow the user to choose which git library to use. The majority of users will be fine with the default original git library, while the Azure DevOps users will have to specify to use libgit2 in their GitRepository resources.

Follow the generic git server guide for further instructions in how to use Flux with Azure DevOps.

Upcoming events

In this session, Scott will go through the business value as well as the technical value for users + demo these benefits especially if you use Helm 3 with Flux 2.

In other news

The Flux community is growing and we are in the middle of a quite a few big discussions:

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.

7

Cross-posted from February 2021 Update | Flux

Before we get started, what is GitOps?

If you are new to the community and GitOps, you might want to check out some general resources. We like the GitOps manifesto or the official GitOps FAQ written by folks at Weaveworks.

The Road to Flux v2

The Flux community has set itself very ambitious goals for version 2 and as it’s a multi-month project, 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 last month’s update here.

Let’s recap what happened in January - there have been many changes.

Flux2 v0.7 is here

The Flux2 team is very pleased to bring you the 0.7 release series. Most importantly these new features have been added:

  • The GitOps Toolkit controllers come with dedicated service accounts and RBAC (this is a breaking change for those of you who used the default SA to bind to IAM Roles).
  • All the controller images are now multi-arch (AMD64, ARM64, ARM 32bit), the --arch flag is no longer used when installing Flux.
  • You can now set a retry interval for Kustomization reconciliation failures.
  • In a multi-tenancy setup, health checking and garbage collection are now run using the tenant’s service account.
  • The Helm storage namespace can be configured inside the HelmRelease spec, this is particularly useful when targeting remote clusters.
  • The image update automation can be triggered using DockerHub, Quay, Nexus, GCR, GHCR, Harbor and generic CI webhooks.
  • The image update policy now supports alphabetical sorting (Build IDs, CalVer, RFC3339 timestamps) and regex filters.
  • The image automation controllers can now be run on ARM devices with 1GiB RAM including RaspberryPI 32bit.
  • Flux bootstrap comes with support for GitLab sub-groups and project tokens.

If you have been watching our roadmap document, you might have noticed that we hit the 80% mark of automated image updates milestone. This means we are getting closer and closer to feature parity with Flux v1 overall.

Some bits are still on our to-do list, but soon we are going to start working on a migration guide for this particular feature and subsequently make a big push in terms of testing and asking for feedback before we ask everyone to cut over to Flux2. This will be a longer process for sure - we are just detailing our next steps here, so you’re aware of what’s coming next.

fluxcd.io website updates

In the last months’ summaries we talked about our plans of revamping our fluxcd.io website. Originally it was mostly just spiffy placeholder page which pointed to more Flux resources. Since then we landed a new design, made its focus Flux2, now we have added two pages which should hopefully help new users and aspiring contributors learn about their options getting help and joining the team

Please let us know if there’s anything missing or you’d like to help with the site or docs.

Speaking of support, long-time Flux contributor Kingdon Barrett joined Weaveworks as OSS Support Engineer and will take on a more active role in the Flux community. Here’s what he has to say

“I have been in the Flux community for some time, though it seems like only a short while since I first heard about Flux and started getting to know the helpful folks at Weaveworks. Happy to now be taking a more active part in the Flux community through my new role as the Open Source Support Engineer, I am glad to meet everyone and thanks for the welcoming atmosphere! I am here to support the community during the transition from Flux v1 into the new supported series, for all GitOps practitioners.”

Needless to say: we’re very excited to have Kingdon with us!

The Flagger move is happening

Avid readers of our blog might be wondering why we’re reporting this again. It’s because the move of Flagger is still happening. Moving the Github repository and Docker images was just the first, and very obvious, step.

There are other resources though which are important for its community. Slack for instance. If you haven’t, please join the #flagger channel on the CNCF Slack - this is the new home for Flagger discussions.

Its website and documentation will be integrated into fluxcd.io at some point. We also want to update the scope and description of the Flux family of projects to encompass Flagger’s Progressive Delivery capabilities. Another important piece is the Flagger logo.

Bianca Cheng Costanzo has been working with the Flux community on a proposal for a new flagger logo - it would be great if you could leave your feedback and let us know how you feel about it.

Flagger v1.6 is here

We are very happy to announce the v1.6 release of Flagger. This release includes:

  • Support for A/B testing using Gloo Edge HTTP headers based routing.
  • Extended support for Istio’s HTTPMatchRequest and VirtualService delegation.
  • Support for Kubernetes anti-affinity rules.

Note that starting with Flagger v1.6, the minimum supported version of Kubernetes is v1.16.0.

Repository cleanup

Just a heads-up: we have been cleaning up some of our example repositories. As there are v1 and v2 versions of these under the Flux organisation, we decided to archive the v1 versions and point to the corresponding new versions. These are in particular:

Both come with better documentation, diagrams and more features. So a triple-win for everyone. Be sure to check them out!

Upcoming events

It’s important to us 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. In the next days we have these events coming up for you:

8 Feb 2021 - Fluxv2 Image Update Automation Sneak Peak with Leigh Capili

On the road to feature parity with Flux v1, Image Update Automation is a big milestone for Flux v2. The hard at work Flux team has recently released this feature as alpha. During this session, Leigh Capili, DX Engineer at Weaveworks, will walk us through & demo configuring container image scanning and deployment rollouts with Flux v2.

For a container image you can configure Flux to:

  • scan the container registry and fetch the image tags
  • select the latest tag based on a semver range
  • replace the tag in Kubernetes manifests (YAML format)
  • checkout a branch, commit and push the changes to the remote Git repository
  • apply the changes in-cluster and rollout the container image

For production environments, this feature allows you to automatically deploy application patches (CVEs and bug fixes), and keep a record of all deployments in Git history. For staging environments, this feature allows you to deploy the latest pre-release of an application, without having to manually edit its deployment manifests in Git.

18 Feb 2021 - Who wants Cookies? … and GitOps and Runtime Security ( at KubeSec Enterprise Online )

There is so much to think about with regard to cluster runtime security and your configuration pipeline. A good recipe helps you reduce the things you need to think about.

You will learn how to use quality OSS ingredients like Flux and Falco to serve a secure platform of gitops goodness the whole team will enjoy! You can rest easy in your gitops kitchen knowing no horrible geese (exploits, vulnerabilities etc) will burn your cookies.

This talk will be given by

  • Dan “POP” Papandrea, Director of Open Source Community and Ecosystem at Sysdig and
  • Leigh Capili, Developer Experience Engineer at Weaveworks

Check out our talks section for more upcoming and links to recordings of past talks.

Get involved and join us

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.

8

Cross-posted from March 2021 Update | Flux

Before we get started, what is GitOps?

If you are new to the community and GitOps, you might want to check out some general resources. We like the GitOps manifesto or the official GitOps FAQ written by folks at Weaveworks.

The Road to Flux v2

The Flux community has set itself very ambitious goals for version 2 and as it’s a multi-month project, 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 last month’s update here: February 2021 Update.

Let’s recap what happened in February - there have been many changes.

Feature Parity - what is this?

If you have been following Slack and other resources you will have heard that in the past Flux v2 releases we reached the “feature parity” milestone, but what does that mean?

When we embarked on this journey to rewrite Flux from scratch, we set out three big blocks of work:

  1. support for Flux operations in read-only mode
  2. Helm v3 support
  3. Image update functionality

Once all of this was realised in Flux v2, we would have feature parity between v1 and v2. After around 10 months of development, we have achieved this.

So what’s left to do? This does not mean Flux v2 is GA just yet. We are in the process of finalising all APIs, updating our documentation and generally consolidating everything. You can find more details on our roadmap here: Flux Roadmap | Flux

This means that we will spend some more time on stabilisation and we need your help testing. Flux v2 is only a couple of weeks away and it will be helpful to start your migration journey early. Refer to this discussion and our upcoming workshop.

Flux v2 is now up at 0.9

Last month saw two big releases of Flux v2.

0.8 included these highlights:

  • Support for Helm post-renderer and Kustomize patches ( helm-controller )
  • Self-signed certs support for Git over HTTPS ( source-controller )
  • In-line Kustomize Strategic Merge and JSON 6902 patches ( kustomize-controller )
  • Basic templating with bash-style variable substitutions ( kustomize-controller )
  • Prevent objects like volumes from being garbage collected with labels ( kustomize-controller )
  • Filter events from alerting based on regular expressions ( notification-controller )
  • Support numerical ordering in image policies ( image-reflector-controller )
  • Support for Azure DevOps and other Git v2 providers ( image-automation-controller )
  • Install Flux on tainted Kubernetes nodes and other bootstrap improvements (CLI)
  • Uninstall Flux by handling finalizers and preserving all the deployed workloads (CLI)

Hot on its heels 0.9 was released and included these new features:

  • flux is now available for Apple Silicon (CLI)
  • The manifests are embedded in the flux binary allowing air-gapped installations (CLI)
  • Support for recreating Kubernetes objects (e.g. Jobs) when immutable fields are changed in Git ( kustomize-controller )
  • Fix alert regex filtering ( notification-controller )
  • Improved status reporting for Git push errors ( image-automation-controller )

:boom: This version comes with breaking changes to Helm users due to upstream changes in Helm v3.5.2. Charts not versioned using strict semver can no longer be deployed using Flux due to this. When using charts from Git, make sure that the version field is set to a valid semver in Chart.yaml.

:rocket: The migration guides from Flux v1 to v2 can be found here Migrate to Flux v2 · fluxcd/flux2 · Discussion #413 · GitHub.

Thanks a lot to everyone who contributed to these releases! :sparkling_heart:

Upcoming events

It’s important to us 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. In the next days we have these events coming up for you:

8 Mar 2021 - Migrating from Flux v1 to Flux v2 with Leigh Capili

Welcome to a GitOps Days Community Special!

Get ahead of the game and migrate to Flux v2! With Flux v1 in maintenance mode we want to ensure you’re ready for the transition to Flux v2.

In this session, Leigh Capili, DX Engineer at Weaveworks, will demo the Flux guide on how to Migrate from Flux v1 (Migrate from Flux v1 to v2 | Flux), including boostrapping a cluster with Flux 1 and how to move it over to Flux v2.

If we don’t get to everything in this session, we will have subsequent sessions to cover this topic again. Join us we’ll see how far we get!

Resources:

:round_pushpin: Flux v2 Documentation: https://toolkit.fluxcd.io/

:round_pushpin: Flux v2 Guide Migrate from Flux v1: Migrate from Flux v1 to v2 | Flux

:round_pushpin: Flux v2 roadmap: Flux Roadmap | Flux

Check out Community | Flux for more upcoming and links to recordings of past talks.

In other news

CNCF : Flux is still in the process of getting promoted to Incubation status within the CNCF. This always takes a while. So far we cleared Due Diligence during which our production users were interviewed, and the two-week public comment period went successfully as well.

Website : The Flux Community team has put some more love into our website https://fluxcd.io/, if you would like to join the team, have ideas on how to make it better or would like to join the Comms team, please reach out to @dholbach or @staceypotter on Slack.

Flagger : The discussions around having a new logo for Flagger have concluded; below is the winner. Thanks a lot Bianca Cheng Costanzo for working on this! Thanks also everyone else for updating the diagrams, website and CNCF Landscape.

Flagger logo

Meeting times : the Flux team holds weekly, public meetings. To make these accessible to everyone we offer an “early” and a “late” meeting to make sure everyone can attend. Due to changes in the team we approved the request to move the times a little, so we are currently following this schedule:

  • “early” meeting: Uneven weeks: Wed, 10:00 UTC
  • “late” meeting: Even weeks: Thu, 15:00 UTC

Find all the information about meetings here: Community | Flux

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.

9

Crossposted from April 2021 update | Flux

Before we get started, what is GitOps?

If you are new to the community and GitOps, you might want to check out some general resources. We like GitOps manifesto or the official GitOps FAQ written by folks at Weaveworks.

The Road to Flux v2

The Flux community has set itself very ambitious goals for version 2 and as it’s a multi-month project, 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 last month’s update here.

Let’s recap what happened in April - there have been many changes.

We made huge strides moving Flux 2 forward. The end i.e. calling Flux 2 a GA release is slowly getting in sight and we have a huge list of contributors from all around the world to thank for this!

First we released Flux2 0.9.1 which came with improvements to the notification system. The kustomize-controller and helm-controller are now performing retries with exponential backoff when fetching artifacts. This prevents spamming events and alerts when source-controller becomes unavailable for a short period of time (e.g. upgrades, pod rescheduling, leader election changes, etc).

Much bigger and more substantial was the release of 0.10 , which saw these changes:

  • We added new commands to improve troubleshooting: flux logs , flux get source all , flux get images all (CLI)
  • The logs command supports streaming and advanced filtering: e.g. flux logs -f --level=error --kind=helmrelease --namespace=prod (CLI)
  • Push image updates to a different branch for manual approvals through pull requests ( image-automation-controller )
  • Commit message customisations: list updated images and manifests ( image-automation-controller )
  • Restrict image automation to a path relative to the Git repo root ( image-automation-controller )
  • Trigger image updates to Git using Azure Container Registry webhooks ( notification-controller )
  • Support for sending alerts to Google Chat ( notification-controller )
  • Flux Terraform Provider has been promoted from experimental to beta (terraform-provider-flux)

Hot on the heels of this was 0.11.0 and v0.1.1 of the Terraform module. :notebook_with_decorative_cover: Highlights:

  • Default leader election configuration has been improved to prevent the controllers from crashing when the Kubernetes API rate limits requests. This will be most notable to Azure users where the issue was observed a lot.
  • In case the new defaults are not sufficient, the configuration can now be tweaked using flag arguments as well.
  • flux create secret git and flux create source git now support supplying a private key from a file using --private-key-file .
  • The helm-controller will now emit collected logs on release failures in the status conditions and as an event, this should make it much easier to debug wait timeout errors.
  • SOPS in the kustomize-controller has been updated to v3.7.0, support for the newly added age encryption format is planned. :hourglass_flowing_sand:
  • All controllers do now record the suspend status of resources in a gotk_suspend_status Prometheus gauge metric.

:rocket: Check out the guide on how to automate image updates to Git Automate image updates to Git | Flux.

Next up we will triage image-* issues and mark upcoming changes for v1alpha2. The proposal for v1alpha2 is under discussion at Image APIs v1alpha2 (-> v1beta1) · fluxcd/flux2 · Discussion #1124 · GitHub.

As the go-git team made some strides of their own, we can finally bootstrap GitHub/GitLab on-prem with self-signed certs :tada:. They also fixed clones of git sub-modules, so we should be able to unblock Flux 1 users who use sub-modules instead of Kustomize remote git repositories.

Flux is a CNCF Incubation project

Flux in Incubation
Flux in Incubation1500Ă—500 39 KB

You will likely have seen the news elsewhere already, but Flux was promoted from CNCF Sandbox to CNCF Incubation. This is a huge step for the validation of our work, direction, end-user uptake and maturity of our project. Many of us worked hard to make this possible. It’s not just folks who write the code or documentation, but also everyone who gives talks, works with organisations to implement Flux and GitOps, does training, writes books, and countless other things. It was beautiful how the Technical Oversight Committee and SIG App Delivery at CNCF all acknowledged this and made it a special point to talk to some companies who use Flux in production.

Here is a bit of a press round-up if you want to read more about the history, the move itself and what it means:

Flagger v1.7.0 is out

This release comes with support for manually approving the traffic weight increase. Starting with this version, Flagger can be used with Linkerd v2.10 and its new Viz addon, please see the updated guide. Thanks to the Linkerd team for contributing to Flagger.

Upcoming events

It’s important to us 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. In the next days we have these events coming up for you:

5 Apr 2021 - Flux v2 on Azure with Leigh Capili

With Flux v2 we are building extensible and intuitive tools for implementing GitOps to fit your team’s needs. Flux 2 integrates well with existing cloud services you may already be using whether it’s for source control, secrets-management, or your Kubernetes clusters themselves.

Join Leigh Capili, DX Engineer at Weaveworks, for a live-demo of Flux on Azure. Let’s take Microsoft’s cloud offerings for a spin.

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

:rotating_light::exclamation: Notifications & Alerts :warning:
When operating a cluster, different teams may wish to receive notifications about the status of their GitOps pipelines. For example, the on-call team would receive alerts about reconciliation failures in the cluster, while the dev team may wish to be alerted when a new version of an app was deployed and if the deployment is healthy.

:arrows_counterclockwise: Webhook Receivers :repeat:
The GitOps toolkit controllers are by design pull-based. In order to notify the controllers about changes in Git or Helm repositories, you can setup webhooks and trigger a cluster reconciliation every time a source changes. Using webhook receivers, you can build push-based GitOps pipelines that react to external events.

Join Alison Dowdney, Developer Experience Engineer at Weaveworks and CNCF Ambassador, as she walks through how to define a provider and an alert, git commit status, expose the webhook receiver, define a git repository and receiver.

29 Apr 2021 - Doing GitOps for multicloud resource management using Crossplane and Flux2 (at Conf42: Cloud Native 2021)

Leonardo Murillo - CTO @ Qwinix

How would you like for resources to be automatically created across any clouds of your choosing by simply pushing a manifest to a repository? In this talk we’ll see hands on how to do multi cloud management following the GitOps operating model by leveraging Flux2 and Crossplane!

A continuous delivery world without pipelines, with automatic reconciliation of resources eliminating all drift in configuration, everything versioned and everything declarative! That is what GitOps is all about . What if only you could follow this same operating model for all your cloud resources, across any public cloud?\

In this talk you’ll learn how to do precisely that! We will be using Flux2 and Crossplane, and you will see hands on how, using these two CNCF projects, you can manage your entire multicloud architecture using Kubernetes as your control plane while following the GitOps principles.

You will learn to:

  • Install Flux2
  • Using Flux2, install Crossplane in your cluster
  • Configure AWS and GCP providers for Crossplane
  • Deploy resources across both clouds with nothing but a push to the repo
    This talk is all about code! A couple of slides in the deck to give a brief intro of GitOps and the two projects we’ll be using, and then it’s all live code!

09-10 Jun 2021 - GitOps Days 2021

The team behind GitOps Days is still busy putting the event together, and the Call for Papers is still open. So if you have something you’d like to talk about, head to the website and submit your talk!

Check out Community | Flux for more upcoming and links to recordings of past talks.

In other news

:computer: The Flux Community is looking for folks who are interested in helping out with the website. We are working on subsuming all our docs on https://fluxcd.io, moving to the Hugo Docsy theme. If you know your way around fixing up CSS and/or want to help make docs and the website more cohesive and inviting, please talk to @dholbach or @alisondy on Slack.

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.

10

Cross-posted from May 2021 update | Flux

Before we get started, what is GitOps?

If you are new to the community and GitOps, you might want to check out some general resources. We like “What is GitOps?" or “The Official GitOps FAQ” written by folks at Weaveworks.

The Road to Flux v2

The Flux community has set itself very ambitious goals for version 2 and as it’s a multi-month project, 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 last month’s update here: April 2021 update | Flux.

Let’s recap what happened in April - there has been so much happening!

It’s the one-year anniversary of Flux v2

Incredible, but true. The first experimentation around Flux v2 started about a year ago. It was only meant to be a proof of concept to illustrate that a set of small and targeted controllers could replace all of Flux eventually. We celebrate how far we have come: Flux v2 is closer to GA, and already solves more problems than v1. It’s far more flexible, ships more features and is easier to navigate and debug. What’s even more important is that our community has grown considerably since then. We have more maintainers from more organisations on board, more documentation and are looking forward to having you on the team as well!

Thanks a lot to everyone who contributed so Flux v2 so far!

We added many long-requested features

0.12 had the following highlights:

  • New bootstrap git command for pairing Flux with any Git platform (CLI)
  • Improvements to GitHub and GitLab bootstrap including self-signed certs (CLI)
  • Support for Git submodules (source-controller)
  • GPG signing of image update commits (image-automation-controller)
  • Fixes to commit templates and new branch push (image-automation-controller)
  • Extend SOPS with support for age encryption format (kustomize-controller)
  • Support for sending alerts to Sentry and Webex (notification-controller)
  • Alerts deduplication and events rate limiting (notification-controller)
  • A container image with kubectl and flux is available on DockerHub and GitHub

The Flux v2 CLI and the GitOps Toolkit controllers are now CII Best Practices certified.

Checkout the new bootstrap procedure.

0.13 comes with breaking changes to image automation and has the following highlights:

  • The image automation APIs have been promoted to v1alpha2 . Users are encouraged to test this image automation beta candidate, and give feedback before we move these APIs to beta (after which there will be no further breaking API changes)
  • Allow pre-bootstrap customisation of Flux components (CLI)
  • Improved efficiency of Bucket downloads by including .sourceignore rules during bucket item downloads (source-controller)
  • New command to list all Flux resources flux get all --all-namespaces (CLI)
  • Support for CRDs upgrade policies (helm-controller)
  • Support for SSH keys with a passphrase (source-controller)
  • Send alerts to HTTPS servers with self-signed certs (notification-controller)
  • The HelmChart ValueFile field has been deprecated in favour of ValuesFiles (source-controller)
  • Support for decrypting Kubernetes Secrets generated with SOPS and Kustomize secretGenerator (kustomize-controller)

Please follow the upgrade procedure for image automation.

Checkout the new bootstrap customisation feature.

The Image automation guide has been updated to the new APIs, and also includes a reference to a new GitHub Actions use case guide, for automatic pull request creation with Flux and GitHub Actions. This guide is for you, if you want Flux updates to go to a staging branch, where they can be reviewed and approved before going to production.

Flagger v1.8.0

Until now Flagger was compatible with Linkerd which implements the Service Mesh Interface (SMI) v1alpha1 . Starting with v1.8.0, Flagger extends the SMI support for the v1alpha2 and v1alpha3 APIs. This means Flagger can be used to automate canary releases with progressive traffic shifting for Open Service Mesh , NGINX Service Mesh , Consul Connect , and any other service mesh conforming to SMI.

More features have been included in v1.8.0 release, please see the changelog.

If you want to get hands-on experience with GitOps (Flux v2) and Progressive Delivery (Flagger), check out Stefan’s blog post: A GitOps recipe for Progressive Delivery with Istio.

Upcoming events

It’s important to us 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. In the next days we have these events coming up for you:

It’s KubeCon EU 2021 and because we are now an incubating project Flux will have a booth at the project pavilion for the first time! Stop by the booth to chat with us and check out our booth schedule of talks with various users, contributors, and maintainers.

The Flux maintainers will be speaking during the conference as well:

  • 03 May 2021 - GitOpsCon EU 2021 - KubeCon Day 0 co-located event organized by the GitOps Working Group. Co-hosted by Scott Rigby, Weaveworks and Chris Short, Red Hat. You must be registered to attend

GitOps Con Europe (#GitOpsCon) is designed to foster collaboration, discussion and knowledge sharing on GitOps. This event is aimed at audiences that are new to GitOps as well as those currently using GitOps within their organization. Get connected with others that are passionate about GitOps. Learn from practitioners about pitfalls to avoid, hurdles to jump, and how to adopt GitOps in your cloud native environment.

Helm, the Package manager for Kubernetes. Flux, the GitOps continuous delivery solution for Kubernetes. Both can be used independently, but are more powerful together. Scott Rigby, Helm and Flux maintainer — and Kingdon Barrett, OSS engineer — will share the benefits of Helm and GitOps for developers, with live demos showcasing the extra awesomeness of Flux v2 and Helm together. This talk is for Helm users who have either never used Flux, or Flux v1 users looking forward to new features in Flux v2.

Flux is a tool for keeping Kubernetes clusters in sync with sources of configuration (like Git repositories) and automating updates to the configuration when there is new code to deploy. In this presentation, we will look at how Flux can be used in multi-tenant environments to simplify the day to day work of developers and Kubernetes cluster operators.

Still a bit further down the line, but this will definitely be worth your time: an entire two-day conference about the newest developments in the GitOps world with Keynotes from Justin Cormack (CTO, Docker), Katie Gamanji (Ecosystem Advocate, CNCF), and Lei “Harry” Zhang (Staff Engineer at Alibaba Cloud).

Check out Community | Flux for more upcoming events and links to recordings of past talks.

In other news

Our website has grown

Since the start of Flux v2 we wanted to make good documentation front and center of what we do. For a while now we published all the guides and API docs at toolkit.fluxcd.io. For a time now we knew that this was confusing, so we started the work on moving everything to https://fluxcd.io.

We are very pleased to announce that we succeeded in moving the docs and now offer community information, our blog and many other useful bits on the website, everything is searchable and we look forward to adding more.

The team who has been working on this is looking for help, so if you have a knack for fixing typos, improve grammar, add short guides or work on graphics or make the layout more user-friendly, please talk to us in the #flux Slack channel and/or send a pull request to fluxcd/website.

Looking forward to growing the team! :sparkling_heart:

Alison Dowdney joins the maintainer team

Alison has been part of the Flux project for quite a while now. Not only did she present Flux at meetups, fix bugs and add documentation in the last months. She also helped out with the website and has a long background in working with communities in the Kubernetes space. Recently she took on the role of chair in k8s SIG Contributor Experience as well!

Alison

We feel very fortunate to have Alison on board!

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.