Flux, the Kubernetes GitOps operator, has been accepted as a Sandbox project by the Cloud Native Computing Foundation (CNCF)! Chat with the Flux team on Wednesday, August 28 about this announcement!

flux-logo-vertical@2x.png

"The future of operations is automated. When we talk about cloud native, we expect continuous delivery of applications. Manual tools and CI scripts are not enough - we need GitOps, Kubernetes and Flux. The CNCF is the right home for this new generation of software. - Alexis Richardson, Weaveworks

Why we built Flux

Flux was built to drive Weaveworks’ own deployment pipeline. It was operated by updating Kubernetes manifests and applying them, and then committing the change to git. It became clear that the central mechanism was the wrong way around: it was mechanically simpler and more effective to commit changes to git, and then apply what was in git. This was the genesis of “GitOps.”

When Weaveworks launched Weave Cloud it made sense to include Flux. Weave Cloud is a SaaS product that combines and improves upon three Weaveworks open source projects - Weave Scope, Flux, and Cortex - with the goal of maximizing Flux’s capabilities by leveraging metrics from hosted Cortex. Early fans embraced the new methodology that Flux brought:

"GitOps fundamentally changed my approach to CI/CD and Flux was what brought everything to life. Watching it evolve from the pre-1.0 days has been inspiring and I can't wait to see where the community takes it from here."   - Michelle Casbon, early user formerly at Qordoba

The Flux community expanded, the number of integrations grew, and the team worked to generalize the code to enable more integrations. Members of Weaveworks’ Engineering and Developer Experience teams - Michael Bridgen (@squaremo), Daniel Holbach (@dholbach), Stefan Prodan (@stefanprodan), and Hidde Beydals (@hiddeco) - also started the effort to move Flux into the CNCF.

What is Flux?

Flux is a tool that automatically ensures that the state of a cluster matches the config in git. It uses an operator in the cluster to trigger deployments inside Kubernetes, which means you don't need a separate Continuous Deployment tool. It monitors all relevant image repositories, detects new images, triggers deployments and updates the desired running configuration based on that (and a configurable policy).

Flux led us to the concept of GitOps in which management operations can be executed automatically by orchestrators, not manually or by scripts or CI tools. Flux, Kubernetes, Terraform and Weave Flagger are all examples of GitOps tools. They work by observing the current state of the system under management and comparing it with a description in config.

Alexis coined the term, GitOps, in 2017 and now the expression has taken off in the Kubernetes community. (Here are additional resources on GitOps and Flux for more).

flux-cd-diagram.png

The GitOps “Movement” and Key Integrations

As users started to seek out how to implement the GitOps methodology, the number of Flux users grew. The project currently has over 2500 GitHub stars, and the number of integrations is growing:

To meet the momentum and needs of users, the DX team at Weaveworks has created #GitOps in the Kubernetes Slack channel and is in the process of creating a GitOps user group. People like Kyle Rockman at Under Armour has shared what Flux and GitOps has meant to his team and presented his support to the CNCF TOC:

"At Under Armour, we realized early in our Kubernetes journey that having developers rely on kubectl as a major part of their workflow can create some sticky situations. We had all of our manifests in a single repository to share knowledge of what Kubernetes specs look like and how others at UA were using them. However, we would find that a PR would hang for a long time even though someone had applied it to the cluster, or someone would make a change and it would blow away someone else's manually-applied change. We just didn't know how the state of the cluster compared to the state in git. 

When we found Flux and applied it to our cluster, we saw the benefits almost immediately. We really liked the trimmed down mentality of "just do this one thing really really well." After using Flux, we never questioned what was in the cluster. We could just look at the master branch in the repo that Flux was tracking as the single source of truth. Flux made the single source of truth possible in git, and it was so much more clear. Flux has been super clutch! - Kyle Rockman, Under Armour

Flux in the CNCF

As the user base for Flux grew, many of them started contributing. Daniel and Michael worked to form a more open developer community around Flux by being more transparent, removing obstacles to contributing, and having more forums to discuss Flux's future. The response was immediate and today we have over 80 committers, the contributors meet regularly, and Hidde was one of them who joined Weaveworks to work on Flux full time.

The organic momentum helped the process of donating Flux to the CNCF. At the presentation, we were elated that TOC members, Michelle Noorali (Microsoft) and Xiang Li (Alibaba), volunteered to be sponsors.

"As a CNCF TOC member, I was happy to sponsor Flux as a Sandbox project. I've seen quite a bit of interest in the GitOps methodology within the CNCF community and was impressed by how Flux leverages the capabilities of Kubernetes and also plays well with other familiar tools and technologies in the ecosystem. I am looking forward to seeing Flux's journey through the next iterations in the space of cloud native application delivery."  - Michelle Noorali, CNCF

Join the Flux Community!

Chat with our team on Wednesday, August 28 about how to get started!

To try Flux, get help, and contribute: