webhooks Documentation

Official TypeScript developer resources and documentation for fluxcd/webhooks. Verified technical context for AI.

0 stars TypeScript TypeScript 1 file · ~60,566 tokens
RAW Doc

1. Project Overview & Quickstart (fluxcd/webhooks)

Technical Documentation: fluxcd/webhooks

ℹ️ Provenance: Multi-Tier Ingestion · CodeWiki Reference

webhooks

Agent Skills & Rules

  • Discovered 21 agent rule(s) and prompt configurations.

--- METRICS ---

2. Official Technical Reference & Guides (fluxcd/website)

File: README.md

fluxcd.io

This repo houses the assets used to build the Flux project's landing page at https://fluxcd.io.

Note: The sources for some of Flux's documentation are housed in other repositories within https://github.com/fluxcd. Documentation issues and pull requests should be made against those repos.

Project Docs Site GitHub Source
Flux https://fluxcd.io/flux https://github.com/fluxcd/website
Flagger https://fluxcd.io/flagger https://github.com/fluxcd/website

How to modify this website

The main landing page of this website can be modified in hugo.yaml.

Almost all of the content lives in the content/en/ directories. Here are some special cases.

  • ./content/en/blog contains all blog posts - make sure you update the front-matter for posts to show up correctly.
  • ./external-sources/ defines how files from other repositories are pulled in. We currently do this for Markdown files from the /fluxcd/community and /fluxcd/.github repositories. (make gen-content pulls these in.)
  • Flux CLI docs (cmd) and components docs: under ./content/en/flux but pulled in through in make gen-content as well.
  • /static/_redirects defines redirects on https://fluxcd.io. Check out https://docs.netlify.com/routing/redirects/ for the syntax definition and how to test if things work.

Running the site locally

In order to run the Flux site locally, you need to install:

  • Node.js
  • The Hugo static site generator. Make sure to install the "extended" variant of Hugo with support for the Hugo Pipes feature and to check the netlify.toml configuration file for which version of Hugo you should install.
  • jq

Once those tools are installed, fetch the assets necessary to run the site:

Then run the site in "server" mode:

cli
make serve

Navigate to http://localhost:1313 to see the site running in your browser. As you make updates to the site, the browser will immediately update to reflect those changes.

Note: Sometimes you need to clear the output of previous builds, e.g. when the structure of imported documentation has changed. If you see duplicate pages being served, run

text
git clean -fx -- content/

and then run make serve again. The duplicates will then be gone.

Publishing the site

The Flux website is published automatically by Netlify when changes are pushed to the main branch. The site does not need to be published manually.

Preview builds

When you submit a pull request to this repository, Netlify builds a "deploy preview" of your changes. You can see that preview by clicking on the Details link of the netlify/fluxcd/deploy-preview check at the bottom of the pull request page.

Local Development (docker)

Run make docker-preview and wait until the following output appears:

cli
Environment: "development"
Serving pages from memory
Web Server is available at //localhost:1313/ (bind address 0.0.0.0)
Press Ctrl+C to stop

Visit http://localhost:1313, where any changes will be visible from inside of the running container. Markdown files updated in content/ should trigger a browser refresh as they are saved.

The docker-preview target builds the theme, which takes a while and doesn't need to be repeated unless you are making changes to the theme. On subsequent runs, running make docker-serve instead will skip building the theme.

This depends on the Docker image fluxcd/website:hugo-support which should be kept updated when the website's build-time dependencies have changed; this image contains everything needed to run the docs locally.

If this doesn't work, the image may be stale. The instructions to update it are below.

Remote Development (kubernetes / okteto CLI)

This works the same as local development above, but with the Okteto CLI you do not need to run a Linux machine or virtual machine on your local development environment.

First, make sure you are permitted to deploy pods on any local or remote Kubernetes cluster. Download the Okteto CLI for Windows, Mac, or Linux.

Okteto CLI is a light-weight client-side tool that replaces Docker with a remote cluster. You can run hugo server remotely in this way; any changes to the local clone are synchronized to the cluster. The experience is basically the same as local development, (except that you won't need to install Docker.)

Instead of make docker-serve, type okteto up.

You can change the behavior in okteto.yml according to the Okteto Manifest Reference, for example adding a persistent volume can speed up the synchronization of the working directory files to the remote pod on repeated runs.

Updating the Development/preview container image

(For maintainers) Using a machine with docker and logged in with an account that has permission to push to docker.io/fluxcd/website repo, run make docker-push.

The dependencies of docker-push are explained below. If the above worked then you are done, and should not need to read any further. Rebuilding hugo takes a long time and should be avoided when the version hasn't changed or it isn't needed; run make docker-push-support instead to skip building hugo.

Update the docker-support image tag whenever build-time (or "serve"-time) dependencies have changed.

How is the Development container made?

These targets as explained below are run in the appropriate order as dependencies of make docker-push.

  • TODO: add a system/integration test for website that verifies any changes have not broken make docker-serve, for example by adding new dependencies without mentioning them in the ./Dockerfile.

Flux-specific Dependencies

The Flux website has some build-time dependencies including Python3, PyYAML, rsync, grep, nodejs, npm, curl, jq, (and potentially others that may be added in the future.) Flux-specific dependencies are prepared in an image that gets tagged as docker.io/fluxcd/website:hugo-support.

This image is built from the Dockerfile in ./; run make docker-build-support to rebuild it locally, (or run as make docker-push-support to build and also push.)

`gohugoio/hugo`

The Flux website also depends on a specific version of Hugo, which unfortunately does not provide docker images for each version. So we build it from source, with the HUGO_BUILD_TAGS=extended build arg enabled.

Run make docker-push-hugo to build and also push this image target.

This will run make hugo to get a shallow clone of the gohugoio/hugo repository at the right HUGO_VERSION and make docker-build-hugo to build a hugo container base image. (This target compiles golibsass which is very large, and may take a while.)

These are all the dependencies of make docker-push.

File: CODE_OF_CONDUCT.md

Code of Conduct

The Flux project follows the CNCF Code of Conduct.

File: CONTRIBUTING.md

Contributing

Flux is Apache 2.0 licensed and
accepts contributions via GitHub pull requests. This document outlines
some of the conventions on to make it easier to get your contribution
accepted.

We gratefully welcome improvements to issues and documentation as well as to
code.

Certificate of Origin

By contributing to this project you agree to the Developer Certificate of
Origin (DCO). This document was created by the Linux Kernel community and is a
simple statement that you, as a contributor, have the legal right to make the
contribution.

We require all commits to be signed. By signing off with your signature, you
certify that you wrote the patch or otherwise have the right to contribute the
material by the rules of the DCO:

Signed-off-by: Jane Doe <[email protected]>

The signature must contain your real name
(sorry, no pseudonyms or anonymous contributions)
If your user.name and user.email are configured in your Git config,
you can sign your commit automatically with git commit -s.

Format of the Commit Message

For this repository we prefer the following rules for good commit messages:

  • Limit the subject to 50 characters and write as the continuation
    of the sentence "If applied, this commit will ..."
  • Explain what and why in the body, if more than a trivial change;
    wrap it at 72 characters.

The following article
has some more helpful advice on documenting your work.

Communications

For realtime communications we use Slack: To join the conversation, simply
join the CNCF Slack workspace and use the
#flux-dev channel.

To discuss ideas and specifications we use GitHub
Discussions.

For announcements we use a mailing list as well. Simply subscribe to
flux-dev on cncf.io
to join the conversation (there you can also add calendar invites
to your Google calendar for our Flux
meeting).

File: hugo.yaml

baseURL: /
title: Flux
enableRobotsTXT: true
enableEmoji: true

Language configuration

defaultContentLanguage: en
defaultContentLanguageInSubdir: false
enableMissingTranslationPlaceholders: true

Provide .LastMod values

enableGitInfo: true

module:
proxy: direct
hugoVersion:
extended: true
imports:
- path: github.com/google/docsy
disable: false
mounts:
# The following entry is the one we actually need, to be able to
# refer to it in our own assets/scss files.
- source: assets/scss
target: assets/scss/docsy
# Unfortunately that means we need to redefine all of Docsy's
# module mounts here...
# https://github.com/google/docsy/commit/215f68033bbc7bddf8dbec2bbabf8749d1998a17 (lines 24f)
#
# I hope this use-case will be simplified one day.
- source: content
target: content
- source: static
target: static
- source: layouts
target: layouts
- source: data
target: data
- source: assets
target: assets
- source: i18n
target: i18n
- source: archetypes
target: archetypes
- source: node_modules/bootstrap
target: assets/vendor/bootstrap
- source: node_modules/@fortawesome/fontawesome-free
target: assets/vendor/Font-Awesome
- source: node_modules/@fortawesome/fontawesome-free/webfonts
target: static/webfonts
- path: github.com/google/docsy/dependencies
disable: false
- path: github.com/mfg92/hugo-shortcode-gallery
disable: false
mounts:
- source: content/en
target: content

Markup settings

Ref: https://gohugo.io/getting-started/configuration-markup#goldmark

markup:
goldmark:
renderer:
unsafe: true
highlight:
# See a complete list of available styles at https://xyproto.github.io/splash/docs/all.html
style: friendly
parser:
autoHeadingID: true
autoHeadingIDType: github

languages:
en:
params:
languageName: English
languageCode: en
time_format_default: 2006-01-02
time_format_blog: 2006-01-02

permalinks:
blog: /:section/:year/:month/:slug/

outputFormats:
SearchIndex:
baseName: index
mediaType: application/json
isPlainText: true
notAlternative: true

outputs:
home: [HTML, SearchIndex]
page: [HTML]

params:
copyright: The Flux authors
github_repo: https://github.com/fluxcd/website
github_branch: main
github_project_repo: https://github.com/fluxcd/flux2
slack: https://cloud-native.slack.com/messages/flux
support: /support
images: [img/flux-social.png]

Enable Algolia DocSearch

algolia_docsearch: true
offlineSearch: false
version_menu: "Versions"
version: "2.3"
archived_version: false
version_menu_pagelinks: true
url_latest_version: https://fluxcd.io/flux/
versions:
- version: "v2.10"
url: https://fluxcd.io
- version: "v2.9"
url: https://v2-9.docs.fluxcd.io
- version: "v2.8"
url: https://v2-8.docs.fluxcd.io
logos:
navbar: flux-horizontal-white.png
hero: flux-horizontal-color.png
footer: flux-stacked-white.png
cncf: cncf-color.png
ui:
# Enable to show the side bar menu in its compact state.
sidebar_menu_compact: true
sidebar_menu_foldable: true
sidebar_menu_truncate: 1000
# Set to true to disable breadcrumb navigation.
breadcrumb_disable: false
# Set to true to hide the sidebar search box (the top nav search box will still be displayed if search is enabled)
sidebar_search_disable: true
# Set to false if you don't want to display a logo (/assets/icons/logo.svg) in the top nav bar
navbar_logo: true
# Set to true to disable the About link in the site footer
footer_about_disable: false
readingtime:
enable: false
markmap:
enable: true
links:
# End user relevant links. These will show up on left side of footer and in the community page if you have one.
user:
- name: Twitter
url: https://twitter.com/fluxcd
icon: fab fa-twitter
desc: Follow us on Twitter to get the latest news!
- name: LinkedIn
url: https://linkedin.com/groups/8985374
icon: fab fa-linkedin
desc: Join the Flux Community group on LinkedIn!
- name: RSS Feed
url: /blog/index.xml
icon: fa fa-rss
desc: Subscribe to the RSS feed of our blog!
- name: Support
url: /support
icon: fas fa-comments
desc: Subscribe to the RSS feed of our blog!
# Developer relevant links. These will show up on right side of footer and in the community page if you have one.
developer:
- name: Flux project on GitHub
url: https://github.com/fluxcd
icon: fab fa-github
desc: Development takes place here!
- name: Slack
url: https://cloud-native.slack.com/messages/flux
icon: fab fa-slack
desc: Chat with other project developers
- name: Developer mailing list
url: https://lists.cncf.io/g/cncf-flux-dev
icon: fa fa-envelope
desc: Discuss development issues around the project
- name: Flux YouTube channel
url: https://youtube.com/@fluxcd
icon: fab fa-youtube
desc: Watch videos about Using Flux and Flux Development

menus:
main:

  • name: Documentation
    url: /flux
    weight: 10
  • name: Code of Conduct
    parent: Project
    url: https://github.com/fluxcd/community/blob/main/CODE_OF_CONDUCT.md
    weight: 1
  • name: Resources
    parent: Project
    url: /resources
    weight: 5
  • name: Support
    parent: Project
    url: /support
    weight: 10
  • name: Community
    parent: Project
    url: /community
    weight: 20
  • name: Contributing
    parent: Project
    url: /contributing
    weight: 30
  • name: Governance
    parent: Project
    url: /governance
    weight: 40
  • name: Roadmap
    parent: Project
    url: /roadmap
    weight: 50
  • name: Privacy
    parent: Project
    url: /privacy
    weight: 60
  • name: Security
    parent: Project
    url: /security
    weight: 70
  • name: Branding
    parent: Project
    url: https://github.com/cncf/artwork/blob/master/examples/graduated.md#flux-logos
    weight: 9999
  • name: Adopters
    url: /adopters
    weight: 80
  • name: Ecosystem
    url: /ecosystem
    weight: 90
  • name: Flagger
    url: https://flagger.app
    weight: 100
  • identifier: Project
    name: Project
    weight: 110

File: okteto.yml

name: hugo
image: fluxcd/website:hugo-support
workdir: /site

command: ["bash", "--login"]

command:

  • sh
  • -c
  • make serve
    autocreate: true
    forward:
  • 1313:1313
    persistentVolume:
    enabled: false

File: package.json

{
"devDependencies": {
"autoprefixer": "^10.4.20",
"postcss": "^8.4.49",
"postcss-cli": "^11.0.0"
}
}

File: requirements.txt

icalendar
pathlib
pygithub
python-dateutil>=2.8.1
pytz
pyYaml
recurring-ical-events
urllib3

File: runtime.txt

3.12

File: content/en/privacy.md

title: Privacy type: page

Privacy Policy

The Linux Foundation’s core purpose is to foster an ecosystem that supports the collaborative and public
development of free and open source software projects (each, a "Project").

This website tracks visits using Netlify server-side analytics. Because site activity is tracked anonymously
without storing cookies, and visits are never correlated with personally identifying information, the Flux website is fully compliant with CCPA, with the
EU ePrivacy directive, and with EU GDPR.

To learn about the general CNCF privacy policy, read the
Privacy Policy page
on the Linux Foundation website.

File: content/en/roadmap.md

title: "Flux Roadmap" linkTitle: "Roadmap" weight: 90 type: page

Flux Roadmap

{{% alert color="info" title="Production readiness" %}}
The Flux latest beta and stable APIs
(including their reconcilers) are well tested and safe to use in production environments.
The beta APIs will be replaced in time with stable versions.

To learn more about Flux supported versions and release cadence,
please see the Flux release process.
{{% /alert %}}

Milestones

The Flux project roadmap is divided into milestones representing minor releases,
each with a set of goals and tasks. The milestones marked as provisional are
subject to change based on the project's priorities and the community's feedback.

Please note that the Flux maintainers prioritize fixes to defects affecting GA APIs
and security issues over new features. Depending on the volume of incoming issues and
the complexity of the fixes, the roadmap may be adjusted and new features
may be postponed to the next milestone.

v2.8 (Q1 2026)

Status: Completed - Flux v2.8 GA

The primary goal of this milestone is to add support for Helm v4 to helm-controller,
and to reduce the mean time to recovery (MTTR) for app deployments.

v2.9 (Q2 2026)

Status: Completed - Flux v2.9 GA

The primary goal of this milestone is to add support for Flux CLI plugins,
extend Flux server-side apply with field ignore rules and enhance the secrets
decryption.

v2.10 (mid Q4 2026)

Status: Completed - Flux v2.10 GA

The primary goals of this milestone are making a generally available release for
the Flux Alerting APIs and integrating Flux with SPIFFE.

v2.11 (Q1 2027)

Status: Provisional

The primary goals of this milestone are wrapping up the work for
RFC-0011 and RFC-0014, as well as reviewing and implementing the
proposed RFC Advanced Dependency Management.

Requests for comments

The RFC process
provides a consistent and controlled path for substantial changes to enter Flux.

To keep track of the Flux project's current direction and future plans, please see the following RFCs:

  • RFC-0001 Memorandum on the authorization model
  • RFC-0002 Flux OCI support for Helm
  • RFC-0003 Flux OCI support for Kubernetes manifests
  • RFC-0004 Block insecure HTTP connections across Flux
  • RFC-0005 Artifact Revision format and introduction of Digest
  • RFC-0006 Flux CDEvents Receiver
  • RFC-0007 Passwordless authentication for Git repositories
  • RFC-0008 Custom Event Metadata from Annotations
  • RFC-0009 Custom Health Checks for Kustomization using Common Expression Language(CEL)
  • RFC-0010 Multi-Tenant Workload Identity
  • RFC-0011 OpenTelemetry Tracing
  • RFC-0012 External Artifact API
  • RFC-0013 Flux CLI Plugin System
  • RFC-0014 Advanced Support for Short-Lived Cryptographic Material
  • RFC-XXXX Advanced Dependency Management

File: content/en/adopters/_index.md

title: Flux Adopters
type: adopters
The Flux community is immensely proud to have grown a lot over all the years. On this page you can see a selection of organisations who self-identified as using any of the Flux projects in production.

Thanks a lot for your trust, support and being part of our community!

Flux Adopters

Organisations below all are using the Flux family of projects in production.

We are happy and proud to have you all as part of our community! :sparkling_heart:

To join this list, please follow these instructions.

File: content/en/blog/2021-01-06-january-update.md

author: dholbach date: 2021-01-06 12:30:00+00:00 title: January 2021 Update tags: [monthly-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 the `fluxcd` organization

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.

File: content/en/blog/2021-02-01-february-update.md

author: dholbach date: 2021-02-01 08:30:00+00:00 title: February 2021 Update tags: [monthly-update]

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

File: content/en/blog/2021-03-31-april-update.md

author: dholbach date: 2021-03-31 08:30:00+00:00 title: April 2021 update url: /blog/2021/03/april-2021-update/ tags: [monthly-update]

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.

🚀 Check out the guide on how to automate image updates to Git.

Next up we will triage image-* issues and mark upcoming changes for
v1alpha2. The proposal for v1alpha2 is under discussion at https://github.com/fluxcd/flux2/discussions/1124.

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

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

🚨❗️ Notifications & Alerts ⚠️
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.

🔄 Webhook Receivers 🔁
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 our calendar section for more upcoming
and links to recordings of past talks.

In other news

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

File: content/en/blog/2021-06-28-bug-scrub-announce.md

author: kingdonb date: 2021-06-28 08:30:00+00:00 title: Flux Bug Scrub Announce tags: [event] url: /blog/2021/06/flux-bug-scrub-announce/

What is the Flux Bug Scrub

In the past months we have had many folks reach out to us and ask where
they could get involved, make their first steps in the Flux community
and give back in a way.

We started looking around and got inspired by a concept from SIG Node
(who in turn were inspired by SIG CLI) over in the Kubernetes community.
For us, a great way to get started, is to learn more about Flux
through direct experience, when e.g. trying to reproduce issues reported by
other Flux users, and the general business of chopping wood and
carrying water. The Flux Bug Scrub is born.

Here is how it works

Show up at the appointed time, if you can. The first Bug Scrub is

  • June 30 12:00 UTC, 8:00AM ET.
  • Meet at #flux on the CNCF Slack,

we will provide a Zoom link closer to the event time.

We will have one or more contributors with triage access in attendance,
and attempt to review each issue in the target group. (The targets will
vary by week, or by event date, as this will be a recurring event on
some TBD schedule.) A key goal is to figure out if a given issue can be
reproduced, and report our findings. Some issues don't provide enough
info to get us all the way to reproduction, so we may ask more questions
and wait for the submitter to respond.

If someone present wants to volunteer to follow up an issue, we will
make an assignment then. If all we can do is read the thread once and
confirm that labels are still correct, (or fix them up when they were
not) then it will be providing a valuable service to Flux maintainers
and the community at large. A process will be demonstrated to avoid
backtracking from week to week and maximize coverage. This is not a race
to close the issues, but if an issue has received no reply and it looks
like the submitter has lost interest, it could be closed.

Here's what you need

  • A web browser
  • a GitHub account
  • the Google Drive spreadsheet app
  • a user on the CNCF Slack
  • have the Zoom app installed and up to date

before you arrive, and bring your burning desire to get to know more
about Flux through reviewing open issues and PRs in the queue.

We are performing a service for the Flux project by reviewing open
issues and pull requests, applying labels, checking status, and closing
issues wherever it looks appropriate. If we have enough attendees, we
may use a breakout room.

Attending the Zoom meeting, though not required for participating
contributors, means you get to commiserate with other Flux community
members in real time over issues in the queue. We will not likely be
able to dwell on any individual issue for much longer than 2-5 minutes
to keep the pace of progress moving at our event. Our artifacts for
coordination will be published where everyone can see them (GitHub
issues, milestones, Drive spreadsheet, public Slack conversations), and
we will help shape and inform the roadmap of Flux for future development
efforts.

Not every issue will get a response from us but we will try to hit every
issue with an Emoji in our spreadsheet, to signal what state we found it
in, whether it can be moved ahead, and if it needs attention or is
blocked somehow. These notes will carry forward to the next Bug Scrub
event, insofar as any issues we visit are still open next time.

We are very much looking forward to seeing you there! 🎈

File: content/en/blog/2021-09-29-server-side-reconciliation-is-coming.md

author: dholbach date: 2021-09-28 12:30:00+00:00 title: Server-side reconciliation is coming The next Flux release will bring you a new reconciler based on Kubernetes "Server-Side Apply". It will make Flux more performant, observable, less error-prone and provide a generally more delightful experience. This post informs you of the changes you need to take to be able to upgrade. url: /blog/2021/09/server-side-reconciliation-is-coming/ tags: [announcement]

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

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

File: content/en/blog/2021-10-01-october-update.md

author: dholbach date: 2021-10-01 8:30:00+00:00 title: October 2021 update url: /blog/2021/10/october-2021-update/ tags: [monthly-update]

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 last month's update
here.

Let's recap what happened in September - there has been so much
happening!

Flux Project Facts

We are very proud of what we put together, here 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, and all CI workflow providers.
  4. ☸️ 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.
  5. 🤹 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.
  6. 📞 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    .
  7. 👍 Users trust Flux: Flux is a CNCF Incubating project
    and was categorised as "Adopt" on the CNCF CI/CD Tech
    Radar
    (alongside Helm).
  8. 💖 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.

This section has made it onto the landing page of
https://fluxcd.io now - let us know how you like it!

News in the Flux family

Server-side reconciliation is coming

We are going to land a big feature with lots of improvements for
everyone very soon. 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.6.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.

Read our detailed release
announcement
with instructions on how to prepare for this change.

Better transport and crypto support for libgit2

The next release of Flux is coming soon and will include an improvement
to the libgit2 Git implementation. The source-controller and
image-automation-controller both use this
library (in combination with others
like go-git) to perform cloning and/or push
operations on remote Git repositories.

Unfortunately, due to libgit2 depending on various other C libraries
for transport and crypto, using the OS packages has proven to not always
provide a reliable setup, especially not one that supports a wide range
of key formats. As we want our users to be able to use modern private
and/or host key formats like ECDSA* and ED25519, we now build the library
ourselves while linking against the correct libraries (OpenSSL and LibSSH2)
which should solve most issues around private keys. Support for a wider
range of host keys is still pending, but will eventually become available
as well, once libgit >=1.2 can properly be used in Go.

This will also prepare us for changing the build to static, which will allow
us to enable fuzzing for more controllers.

Check out the in-flight
PR
for more information if you are curious. Thanks a lot Chanwit Kaekwasi, Hidde
Beydals and Sunny for your work on this!

Flagger 1.14 has landed

We have released Flagger v1.14.0. This release comes with bug fixes to
Istio load balancer settings and in-line PromQL. Starting with this
version, the canary analysis can be extended with metrics targeting
InfluxDB, Dynatrace, and Google Cloud Monitoring (Stackdriver).

Thanks to Somtochi Onyekwere for integrating Flagger with InfluxDB &
Stackdriver and for all the bug fixes.

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.

Flux at GitOpsCon and KubeCon

One of the really big themes at KubeCon this time is GitOps. Because of
this, KubeCon organisers have put together GitOpsCon as well, as a
dedicated Day 0 event. Below we are going to list our favourites Flux
related sessions - for an up-to-date list of everything take a look at
the "schedule" of our Flux KubeCon
mini-site. (All times are
Pacific Time.)

Meet the Maintainer

There will be three Flux Project Office Hours where you can meet our
maintainers:

GitOpsCon

Our friends from the GitOps working group have put together a fantastic
event - here are some talks you should watch out for on October 12:

KubeCon talks on the main event and our booth

Take a look at our Flux KubeCon
mini-site. This is where
you can connect with us for all the Flux related talks at the event.
During KubeCon hours we will be at our virtual and in-person booth in
the CNCF Project Pavillion - drop by for a chat, for short talks from
engineers and users. It'll be a great way to get involved with our
community and have all your questions answered.

GitOps One-Stop Shop Event

So KubeCon will be lots of fun and give you lots of great Flux content,
but only a week afterwards we have a real treat coming up for you.

If you want to learn more about how big vendors have built their GitOps
offerings on top of Flux, sign up at
https://gitopsdays.com and learn
from Amazon, D2IQ, Microsoft, VMware and Weaveworks why they chose Flux
and which cool services and products they have got to offer. See you
there on October 20th!

Flux Bug Scrub

During KubeCon, Flux's weekly Bug Scrub will be postponed unless another
volunteer wants to run one! Kingdon, who hosts Bug Scrub each week, is
going in person to Los Angeles to present: how to deploy Jenkins
declaratively with Helm Controller,
and other fun things.

Throughout KubeCon, look for Flux maintainers at media events and giving
talks in the Flux booth, (TBD: or at least, virtually talking in the
booth! Maybe due to social distancing rules.)

As for Bug Scrub, I foresee that cancellation or postponement of the
weekly event is likely while KubeCon is going on in person, ... but if
there are volunteers at the usual time, and enough interested people who
want to perform the bug scrub activity get together, they will be put to
work! There will always be plenty of bugs to scrub for the foreseeable
future.

This week, and every other week, find Bug Scrub with a link to the Zoom
invite beneath the fold
alongside other scheduled Flux developer team events.

One more thing

Martin Hickey (Helm maintainer), and Scott Rigby (Helm and Flux
maintainer) present a feature showcase and demos of both Helm and Flux,
reasons for the overwhelming community use of Helm for application
packaging and deployment on k8s, and how Helm is extended by Flux for
teams moving to GitOps.

🔹 Helm - https://helm.sh/ helps
you manage Kubernetes applications --- Helm Charts helps you define,
install, and upgrade even the most complex Kubernetes application.

🔹The GitOps Toolkit
is the set of APIs and controllers that make up the runtime for Flux.
The APIs comprise Kubernetes custom resources, which can be created
and updated by a cluster user, or by other automation tooling.

🔹The Helm Controller
built on Kubernetes controller runtime and is part of the GitOps
Toolkit -- allows one to declaratively manage Helm chart releases with
Kubernetes manifests.

📍 Date: Tuesday, October 5th @ 10 am PST to 11 am
PST
(1:00 pm EST - 2:00 pm EST)

In other news

News from the Website and our Docs

Our website https://fluxcd.io is the central place for news and docs
regarding Flux and we put quite some effort into making it ever more useful
and interesting. If you have feedback or would like to help out, reach out
alisondy, dholbach or scottrigby on Slack.

In the past month we made large parts of the site more easily maintainable.
Juozas Gaigalas simplified the styling and beautified the looks of the site
in many places as well - thanks for your work on it!

We are pleased to see that the number of contributors to the docs is slowly
growing. Many small improvements to make the content more readable and
correct. Go team!

Apart from that we were able to add more adopters and
integrations. Please add yourself if you haven't already.

What to watch out next for: Alison Dowdney is working on restructuring the
documentation to make it even easier to find things. Reach out to her, if you
want to help out or have observations you would like to share.

People writing about Flux

We have two sets of articles we would like to share. (Please reach out to
us if you find others show-casing Flux projects.)

Manage your Kubernetes clusters with Flux 2

Cyril Becker wrote a very nice introductory article over at
https://medium.com/alterway/manage-your-kubernetes-clusters-with-flux2-82dd1cfe2a6a.
If you are entirely new to the concept of GitOps and want to learn more
and follow a how-to, check the article out.

GitOps - Part 1+2

Girish Goudar, Cloud & DevOps Architect at EY wrote a set of two articles to
explain GitOps using Flux.

In the first article https://www.linkedin.com/pulse/gitops-part-1-girish-goudar-1c/
you will learn how to deploy apps using Helm and Kustomizations.

The second article https://www.linkedin.com/pulse/gitops-part-2-girish-goudar/
focuses on securing apps using Mozilla SOPS.

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.

File: content/en/blog/2022-02-22-security-fuzzing.md

author: dholbach date: 2022-02-22 8:30:00+00:00 title: 'Security: More confidence through Fuzzing' url: /blog/2022/02/security-more-confidence-through-fuzzing/ tags: [security]

Next up in our blog series about Flux Security is how we implemented
fuzzing in Flux and its controllers and how that makes things safer for
you.

Wikipedia explains Fuzzing
like so:

Fuzzing or fuzz testing is an automated software testing
technique that involves providing invalid, unexpected, or random data
as inputs to a computer program. The program is then monitored for
exceptions such as crashes, failing built-in code assertions, or
potential memory leaks. Typically, fuzzers are used to test programs
that take structured inputs. This structure is specified, e.g., in a
file format or protocol and distinguishes valid from invalid input. An
effective fuzzer generates semi-valid inputs that are "valid enough"
in that they are not directly rejected by the parser, but do create
unexpected behaviors deeper in the program and are "invalid enough"
to expose corner cases that have not been properly dealt with.

We already have quite a good coverage of unit and end-to-end tests
across the controllers. Adding fuzzing to the mix will further extend
the scope of tests to scenarios and payloads not previously covered.
Together with the fuzzing that's already being done within the
Kubernetes repositories, e.g. kubernetes, client-go and
apimachinery we feel ever more confident in our code.

We are happy to share that since the 0.27 release of Flux all Flux
controllers and libraries are now tested by Google's continuous
fuzzing for open source software.

How we got here

When we announced the results of the security
audit
back in November, we already shared that the team at ADA
Logics had helped put together an initial
implementation of Fuzzing for some of the Flux controllers. In this
first inception three issues were already found (1x slice
out-of-bounds, 2x nil-dereference), and immediately fixed.
Naturally we were very interested in merging the fuzzing integration.

In order for us to fully land the fuzzers, we needed to make some
architectural changes to the build process, especially for the
controllers that rely on C bindings to libgit2, such as
source-controller and image-automation-controller, which are now
statically built. In addition to that, we extended the scope of the
fuzzers considerably. If you take a look at the related pull request
for
notification-controller
you get a good idea of what this all entailed, e.g. fuzzing for all
notifiers.

Fuzzers are now run for every commit which lands in the Flux controllers
and libraries.

Thanks again ADA Logics for contributing and to everyone else who helped
integrate this! We are also very grateful to Google and
OpenSSF who provide and maintain the required
infrastructure.

What's next

As Go will see built-in Fuzz support in 1.18, we were very interested
in structuring everything closely to the new format, so that the
transition from dvyukov/go-fuzz
(which is currently being used) goes smoothly. (We can recommend Jay
Conrod's blog
post
about the Internals of Go's new fuzzing system, if you are curious!)

The move of Flux to go native fuzzing is being tracked in this
issue. We
also hope to add new fuzzers soon, so if you want to contribute there:
come and find us on Slack! It's an easy way to get to know and extend
the Flux codebase.

This is just one more measure we are taking to keep you more secure.

Talk to us

We love feedback, questions and ideas, so please let us know your
personal use-cases today. Ask us if you have any questions and please

See you around!

File: content/en/blog/2022-03-09-pod-security-standard-restricted.md

author: dholbach date: 2022-03-09 12:30:00+00:00 title: 'Security: Using Pod Security Standard "restricted"' url: /blog/2022/03/security-pod-security-standard-restricted/ tags: [security]

Next up in our blog series about Flux
Security is how we moved
to Pod Security Standard "restricted", all the background info you need
to know and how that makes things safer for you.

Since version 0.26 of
Flux
we are applying

[..] the restricted pod security
standard
to all controllers. In practice this means:

  • all Linux capabilities were dropped
  • the root filesystem was set to read-only
  • the seccomp profile was set to the runtime default
  • run as non-root was enabled
  • the filesystem group was set to 1337
  • the user and group ID was set to 65534

Flux also enables the Seccomp runtime default across all controllers.
Why is this important? Well, the default seccomp profile blocks key
system calls that can be used maliciously, for example to break out of
the container isolation. The recently disclosed kernel vulnerability
CVE-2022-0185
is a good example of that.

Pod Security Standards definition

Kubernetes defined three policies in its Pod Security Standards. They
range from

  • Privileged: This does not place any restrictions on the workload
    at all. The idea being that this can be used for system- and
    infrastructure-level workloads which are managed by privileged and
    trusted users only.
  • Baseline: This policy comes with some restrictions. It aims to
    guard against known privilege escalations while still making it
    easy to adopt and use it by keeping a certain level of
    compatibility with most workloads.
  • Restricted: Inheriting all the restrictions from Baseline, it
    enforces additional limitations, thus follows hardening best
    practices by increasing the isolation levels the workload is
    exposed to.

We are very pleased that all Flux controllers were moved to
Restricted, as that offers the highest level of security for you.

We recommend checking out the Upstream Kubernetes documentation on Pod
Security
Standards
as it gives a generally good overview of all the security features
enabled. In addition to that you can see which restrictions were added
as part of which Kubernetes release, meaning that with every Kubernetes
release, you will benefit from new Upstream Kubernetes security
improvements automatically.

{{% note %}}
As of v1.24 Kubernetes still runs all workloads with seccomp in
unconfined mode, in other words, disabled. On the other hand, Docker
has seccomp enabled by default for years now.

There are discussions to change the Kubernetes default on v1.25, and have all
workloads set to RuntimeDefault unless opted-out. This would be based on
SeccompDefault feature
gate
being enabled from that version onwards.
{{% /note %}}

{{% note %}}
If you are an OpenShift user, you might run into this
issue
(related upstream
report).
The work-around right now is to remove the seccomp profile as
described in these instructions.
{{% /note %}}

`seccomp` and `RuntimeDefault`

Seccomp is short for "Secure Computing". It refers to a facility in the
Linux kernel which can limit the number of system calls available to a
given process. Right now there are around 300+ system calls available,
e.g. read to read from a file descriptor or chmod to change the
permissions of a file. The more syscalls you block, the more secure your
application, as a rogue process will only be able to do what you
specified.

In its first inception seccomp was introduced into Linux in 2005, to
Docker in version 1.10 (Feb 2016) and to Kubernetes in version 1.3 (Jul
2016). So while the technology has been around for a while and you could
handcraft your own seccomp profiles, the challenge has always been
striking the right balance: if you are too generous in your filter, it
won't guard against malware effectively -- if you are too strict, your
application might not work.

All container runtimes come with a default seccomp profile. Docker
Desktop for
example
blocks around 44 system calls. In Kubernetes you can enable the seccomp
profile RuntimeDefault for your pod like so:

yaml
spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault

All Flux controllers have this implemented as well now!

By adopting both changes, we further restrict the permissions that Flux
requires in order to operate. This, alongside other changes we are working
on, translate in a decreased attack surface which may reduce the impact of
eventual CVEs that may surface in our code base - or our supply chain.

Further reading

If you would like to understand the concepts in this blog post better,
you might want to check out these blog posts (in addition to the docs
referred to above):

Talk to us

We love feedback, questions and ideas, so please let us know your
personal use-cases today. Ask us if you have any questions and please

See you around!

File: content/en/blog/2022-04-13-contributing-to-flux.md

author: dholbach
date: 2022-04-13 14:30:00+00:00
title: 'Contributing to Flux'
"It takes a village" - that's true for the Flux community as well. And there are countless ways to join the team and help out. In this post we list a lot of them. Some very small, so you can definitely do your part and join Team Flux as well!
url: /blog/2022/04/contributing-to-flux/

📈 Our Community is growing

We are very pleased to see that our community is growing, whichever
metric you apply. Number of members in Slack or mailing list, newly
added adopters or projects in our
ecosystem - all numbers are going up. Even the length
of our monthly updates is growing
every month.

As many asked in the past months how to get involved in the Flux
community, let's walk you through some steps to join Team Flux!

Update: Earlier versions of this post referred to the pre-KubeCon
Bug Bash. Unfortunately we had to cancel our participation.

First things first

The first thing to do is get in touch with us! The communication
section on our
website lists all the ways, but let's drill into them in more detail.

  1. A good way to reach us and talk to us in real-time is on CNCF Slack.
    Get an invite here, then
    proceed to the #flux channel.

  2. We have public meetings on a weekly basis to talk about upcoming
    work and direction of the project. They are open to anyone and we
    very much want to welcome you to drop by, say Hi and introduce
    yourself. Here are the
    instructions    .

  3. To generally stay up to date, you also might want to check out our
    blog    , our Twitter and/or
    Flux group on LinkedIn.

Please say Hi, let us know what you are interested in and how we can
help you get started. From hereon it depends on what you would like to
do. Let's take a look at different ways to get involved.

Interacting with GitHub

All code for the Flux project is available under the fluxcd
organisation in GitHub. So if
you are interested in contributing to Flux, it is a good idea to learn
how things are organised and potentially get involved with responding to
GitHub issues.

The Bug Scrub

For 9 months now, Kingdon Barrett has been organising the Flux Bug
Scrub:

For us, a great way to get started, is to learn more about Flux through
direct experience, when e.g. trying to reproduce issues reported by
other Flux users, and the general business of chopping wood and carrying
water.

Each week we will have one or more contributors with triage access in
attendance, and attempt to review each issue in the target group. (The
targets will vary by week, or by event date.) A key goal is to figure
out if a given issue can be reproduced, and report our findings. Some
issues don't provide enough info to get us all the way to reproduction,
so we may ask more questions and wait for the submitter to respond.

The great thing about this is: we run this on a weekly basis, so every
week you have the opportunity to learn from experienced Flux maintainers
in a friendly setting, so all you need to do is check our
calendar and turn up.

The Bug Bash

Unfortunately we will not be participating in the Bug Bash this KubeCon!

Despite earlier announcements claiming we would do this, we felt we
could not do this well enough. If you were looking forward to this,
we are sorry - but you know what: we still have the weekly Bug Scrub! Your
weekly one-on-one mentoring to learn the ropes of working on Flux!

Participating in Flux Development

If you are interested in Flux development, great! We are always looking
for new people to get started. Come and talk to us on Slack and in our
meetings as suggested above - that makes collaboration usually a lot
easier.

All of Flux Development is happening in the open, the priorities for the
next releases are documented
publicly
and we continuously tag issues as "good first
issues"
if you are looking for suggestions.

Our contributor docs will
likely be helpful as well!

If you are interested in Security, you might have seen how much we have
done to improve security lately. We are very
interested in doing more - and are always open to new ideas!

Meeting in person

As stated above KubeCon / CloudNativeCon Europe 2022 is just around the
corner. It is going to happen in Valencia, Spain 16 - 20 May and we will
have many Flux maintainers and contributors at our booth and presenting
talks and be available to talk to in other events. This is your chance
to meet, have a chat and get to know the team.

There will be a separate announcement, but here already is a short
summary of what to look forward to.

Monday, 16 May

13:00 - 17:00 (Room 2H - Event Center): Flux Project Meeting: We will
kick off the Flux get-togethers and festivities with an in-person
meeting for all Flux users, contributors, maintainers and generally
interested folks. This will be an opportunity to get to know each other,
have a chat, see what people's interests are and to potentially start
contributing. (Sign up
here.)
Contact people on the ground are: Somtochi Onyekwere and Scott Rigby.

Tuesday 17 May - [GitOpsCon](https://events.linuxfoundation.org/gitopscon-europe/program/schedule/)

Lots and lots of talks about GitOps in general and Flux in particular,
here's a short selection of what to look forward to:

Wednesday 18 May - Friday May 20 - [KubeCon](https://kccnceu2022.sched.com/?iframe=no)

Over these three days we are going to be at the Flux booth (both
virtually and on the ground), so come over for a chat. We are planning
loads of talks, demos and ample time to have a chat, get to know
everyone, ask questions and have great new ideas together!

On top of that, here is a list of talks, workshops and sessions during
those days:

If you can't make it to KubeCon in person, we've got you covered as
well. In addition to all of this, we are going to have a virtual booth
with talks - will announce the schedule very soon.

Putting Flux to the Test

If you have already gathered some experience with Flux, you should be in
a great position to help us further and move the project forward a lot.
The term "Testing" might sound a bit dull to you, but there's a lot that
falls into this category, which is super important to us. You could for
example:

  • verify bugs and make minimal test cases to help fix those issues
  • refine and expand on the existing unit and end-to-end tests
  • try Flux in new environments and figure out if it works, and if not,
    what it would take to make it work

As you can gather by now already - we'd love to join this effort!

Flux Advocacy

We all love GitOps and we have heard from many who use Flux that they
integrated it into their machinery and afterwards "forgot about it"
since it was "just doing its job". That's how we like it.

Still it is important to let people know and educate communities around
you. So if you like blogging or giving talks, let us know and we can
help promote your work, or collaborate on events or content.

Help answering questions

We receive questions and requests from our user base on Slack, also in
Github Discussions
and other places like e.g. Reddit as well. If you enjoy helping people,
come and join the team. We are a friendly bunch and it can be quite
satisfying to know you just helped somebody fix an issue, and
potentially provided an onramp for them to join the community.

As part of this effort, we are always looking at improving our
documentation, FAQ and how-tos. So making some of the learnt knowledge
more generally available is of great use as well.

Flux Documentation and Website

https://fluxcd.io for many is the
first impression of the project and documentation and blog posts the
next interactions. We really want to make the project shine there, so if
you have a knack for writing and/or organising content, come and talk to
us. Web wizards are very welcome too! 💖

If you check out some of our last monthly update posts, you will get an
idea of what we have been up to and how important it is to us.

Sorry, got no time - but still want to support

If you don't have time for any of the above, that is entirely fine and
understandable.

One good way how you can still help out, is by adding yourself to the
Flux Adopters page, if your
organisation is using it. We love hearing from folks using Flux
projects. Contributors really love seeing where their software is being
used and it gives our community a good idea of how wide-spread adoption
really is.

The same goes for the Flux Ecosystem
page. If you integrate with
Flux, we want to hear from you!

⭐ And please star us on
GitHub as well!

Conclusion

You might have heard the saying "It takes a village" before, and it is
the same for Team Flux. The success of our project depends on many
different people with many different skills. We love meeting you, we
love helping you get started - just reach out and we are looking forward
to meet you!

Talk to us

We love feedback, questions and ideas, so please let us know your
personal use-cases today. Ask us if you have any questions and please

See you around!

File: content/en/blog/2022-05-04-april-update.md

author: dholbach date: 2022-05-03 8:30:00+00:00 title: April 2022 update url: /blog/2022/05/april-2022-update/ tags: [monthly-update]

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 May 2022 - let's recap together what happened in
April - it has been a lot!

Update: Earlier versions of this post referred to the pre-KubeCon
Bug Bash. Unfortunately we had to cancel our participation.

News in the Flux family

Latest Flux release series is 0.29

This is the latest and greatest, but before we get into the list of
great features and improvements, let's take a look at the breaking
changes beforehand:

  • From this release on, the RUNTIME_NAMESPACE environment variable is
    no longer taken into account to configure the advertised HTTP/S
    address of the storage. Instead, variable
    substitution
    must be used, as described in the changelog entry
    for
    v0.5.2.
  • Use of file-based KubeConfig options are now permanently disabled
    (e.g. TLSClientConfig.CAFile, TLSClientConfig.KeyFile,
    TLSClientConfig.CertFile and BearerTokenFile). The drive behind
    the change was to discourage insecure practices of mounting
    Kubernetes tokens inside the controller's container file system.
  • Use of TLSClientConfig.Insecure in KubeConfig file is disabled by
    default, but can be enabled at controller level with the flag
    --insecure-kubeconfig-tls.
  • Use of ExecProvider in KubeConfig file is now disabled by default,
    but can be enabled at controller level with the flag
    --insecure-kubeconfig-exec.

With that out of the way, here are the highlights of the release:

Notification Improvements

A new notification is now emitted to identify recovery from failures. It
is triggered when a failed reconciliation is followed by a successful
one.

In-memory cache for HelmRepository

An opt-in in-memory cache for HelmRepository that addresses issues where
the index file is loaded and unmarshalled in concurrent reconciliation
resulting in a heavy memory footprint. It can be configured using the
flags: --helm-cache-max-size, --helm-cache-ttl,
--helm-cache-purge-interval.

Configurable retention of Source Artifacts

Garbage Collection is enabled by default, and now its retention options
are configurable with the flags: --artifact-retention-ttl (default:
60s) and --artifact-retention-records (default: 2). They define the
minimum time to live and the maximum amount of artifacts to survive a
collection.

Configurable Key Exchange Algorithms for SSH connections

Using the flag --ssh-kex-algos. Note this applies to the go-git
gitImplementation or the libgit2 gitImplementation but only when Managed
Transport is being used.

Configurable Exponential Back-off retry settings

With the new flags: --min-retry-delay (default: 750ms) and
--max-retry-delay (default: 15min). Previously the defaults were set to
5ms and 1000s, which in some cases impaired the controller's ability to
self-heal (e.g. retrying failing SSH connections).

Experimental managed transport for libgit2 Git implementation

Now has self-healing capabilities, to recover from failure when
long-running connections become stale.

SOPS refactored and optimized

Including various improvements and extended code coverage. Age
identities are now imported once and reused multiple times, optimizing
CPU and memory usage between decryption operations.

Helm chart directory loader improvements

Introduction of a secure directory loader which improves the handling of
Helm charts paths.

For a more detailed list of changes in the series, please refer to the
change logs of
0.29.0,
0.29.1,
0.29.2,
0.29.3,
0.29.4,
and
0.29.5.

Flagger 1.20.0

This release comes with improvements to the AppMesh, Contour and Istio
integrations.

Improvements

  • AppMesh: Add annotation to enable Envoy access logs
    #1156
  • Contour: Update the httproxy API and enable RetryOn
    #1164
  • Istio: Add destination port when port discovery and delegation are
    true
    #1145
  • Metrics: Add canary analysis result as Prometheus metrics
    #1148

Fixes

  • Fix canary rollback behaviour
    #1171
  • Shorten the metric analysis cycle after confirm promotion gate is
    open
    #1139
  • Fix unit of time in the Istio Grafana dashboard
    #1162
  • Fix the service toggle condition in the podinfo helm chart
    #1146

Flux Ecosystem

Flux Subsystem for Argo

In the latest release, we have added checkboxes to enable Flux Subsystem
in the Argo CD UI. We also have a tutorial to use TF-controller with
Flux Subsystem for
Argo.
With this you have an alternative option to Crossplane to manage
infrastructure.

Terraform-controller

We have released TF-controller v0.9.4 which is a bug-fix release. We
also added cloud cost estimation to our road map. Please feel free
to give us feedback on how you would like this feature to be:

Weave GitOps

Weave GitOps is a powerful, open source extension to Flux, which
provides insights into your deployments, and makes continuous delivery
with GitOps easier to adopt and scale across your teams. You can easily
install alongside an existing Flux setup, adding (or removing) Weave
GitOps as a standard Helm resource.

The v0.8.0 release
brings multi-namespace querying so you can see objects from across your
cluster in the Web UI, several UI enhancements and bug fixes, as well as
supporting the Source v1beta2 API - this breaking change means we now
require Flux v0.29.0 or later.

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
April here are a couple of talks we would like to highlight:

Managing Thousands of Clusters and Their Workloads with Max Jonas Werner
D2iQ uses Flux to automatically enable this experience in its products. Join Max for this hands-on session on multi-cluster management using GitOps.

CNCF on-demand webinar: Flux for Helm Users with Scott Rigby
Scott Rigby, Flux & Helm Maintainer, takes you on a tour of Flux’s Helm Controller, shares the additional benefits Flux adds to Helm and then walks through a live demo of how to manage helm releases using Flux.

Women In GitOps Panel
We celebrated international women’s day, GitOps Style. This event gathered female role models who innovate, challenge and embrace the world of GitOps. Inspirational women who have achieved great success within the sector and will share stories of their journey and explore the question why is it important to “Get on GitOps.”

Securing GitOps Debug Access with Flux, Pinniped, Dex, & GitHub with Leigh Capili
In this live demo, Leigh will show how the incredibly flexible, open-source combo of Flux, Pinniped, and Dex can empower a team to leave a traceable solution during a production incident. He explores effective team debugging habits with Kubernetes and git.

Security: The Value of SBOMs with Dan Luhring (Anchore)
During this session, Dan Luhring, OSS Engineering Manager at Anchore, dives into SBOMs - what they are, why you need them, some common use cases and how to get your pipeline ready for SBOM generation and verification using the Flux SBOM as an example.

OpenSource 101: WTF is GitOps & Why Should You Care? with Priyanka Ravi
Pinky shares from personal experience why GitOps has been an essential part of achieving a best-in-class delivery and platform team, gives a brief overview of definitions, CNCF-based principles, and Flux’s capabilities: multi-tenancy, multi-cluster, (multi-everything!), for apps and infra, and more.

From Zero to GitOps Heroes with Mae Large, Russ Parmer, & Priyanka Ravi
During this session Mae, Pinky, & Riss share key learnings from their early days of assessing GitOps as an idea and methodology to how it evolved into the de facto automated software change process in less than 1 year.

Upcoming Events 📆

We are happy to announce that we have a number of events coming up in
May - 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.

KubeCon / CloudNativeCon Europe 2022 coming up

As every other project in the Cloud Natice space, we are very busy
preparing everything for KubeCon / CloudNativeCon Europe
2022,
which is going to be 16-20 May 2022 in Valencia, Spain (and virtual of
course!).

We will post a separate announcement as soon as everything is confirmed,
but we already want to inform you about what's likely to happen, so you
can plan accordingly or collaborate with us!

The Bug Bash

Unfortunately we will not be participating in the Bug Bash this KubeCon!

Despite earlier announcements claiming we would do this, we felt we
could not do this well enough. If you were looking forward to this,
we are sorry - but you know what: we still have the weekly Bug Scrub! Your
weekly one-on-one mentoring to learn the ropes of working on Flux!

Monday, 16 May

13:00 - 17:00 (Room 2H - Event Center): Flux Project Meeting: We will
kick off the Flux get-togethers and festivities with an in-person
meeting for all Flux users, contributors, maintainers and generally
interested folks. This will be an opportunity to get to know each other,
have a chat, see what people's interests are and to potentially start
contributing. (Sign up
here.)
Contact people on the ground are: Scott Rigby, Somtochi Onyekwere and
Stefan Prodan.

Join Flux Maintainers Stefan Prodan, Somtochi Onyekwere & Scott Rigby
for this Flux Project Meeting in-person at KubeCon EU on Monday, May
16 from 1pm - 5pm CEST

Click here to register
(here)
for the Flux Project Meeting. Please note that you must be a KubeCon +
CloudNativeCon Europe
(here)
registrant in order to attend this meeting.

Details Flux Project Meeting Monday, May 16, 13:00 - 17:00 CEST Room
2H | Event Center

Space is limited Please note: we will not have any live streaming,
recordings, or any virtual component available for this meeting.

Tuesday 17 May - [GitOpsCon](https://events.linuxfoundation.org/gitopscon-europe/program/schedule/)

Lots and lots of talks about GitOps in general and Flux in particular,
here's a short selection of what to look forward to:

Wednesday 18 May - Friday May 20 - [KubeCon](https://kccnceu2022.sched.com/?iframe=no)

Over these three days we are going to be at the Flux booth (both
virtually and on the ground), so come over for a chat. We are planning
loads of talks, demos and ample time to have a chat, get to know
everyone, ask questions and have great new ideas together!

On top of that, here is a list of talks, workshops and sessions during
those days:

Please note: all of the above might be subject to change. Please
double-check the schedule beforehand. Please reach out to Vanessa
Abankwah or Daniel Holbach on Slack if you have questions or would like
to participate in any of the above.

We very much look forward to seeing you there!

GitOps Days 2022

GitOps Days 2022 is a free 2-day online event on June 8-9, 2022.

This is THE event for your GitOps journey! Getting started? Taking
GitOps to the next level? We'll cover all of the steps for your success!

The event will run from 9:00 am PT to ~3:00 pm PT each day as a free
online event.

✨✨ Register
now to
reserve your spot to receive updates to the schedule and speakers. ✨✨

Join the conversation! Chat with the speakers and other attendees!
Invite yourself at
https://slack.weave.works
and hang out with us at
#gitopsdays

What to expect?

  • Talks and tutorials on how to get started with Kubernetes and GitOps
  • Talks from Flux users about their use cases
  • How to do GitOps securely
  • Platforms that offer GitOps: Microsoft Arc Kubernetes, AWS Anywhere,
    Weave GitOps, D2iQ Kubernetes Platform, and more! all using Flux!
  • Flux in the CNCF and the GitOps Ecosystem
  • Flux support and Integrations: Flux + Helm, Terraform, HashiCorp Vault,
    Jenkins, OpenShift, Visual Studio Code, and much much more!
  • Technical deep dives with Flux maintainers
  • Music from DJ Desired State 🎶

In other news

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

Manage Kubernetes Secrets for Flux with HashiCorp Vault

Rosemary Wang from HashiCorp wrote a great blog post about how to
manage Kubernetes Secrets for Flux with HashiCorp Vault. The how-to
is nicely written with a lot of detail and will take you through the steps
to configure the Secrets Store CSI driver with HashiCorp Vault to securely
inject secrets into Flux or other GitOps tools on Kubernetes.

We are looking forward to more collaboration together!

Full GitOps Tutorial: Getting started with Flux

{{< youtube 5u45lXmhgxA >}}

This video is great for everyone who gets started, but also everyone who enjoys a story well-told.

In this video, Anais Urlichs covers

  • What is GitOps and how does Flux work
  • Flux installation
  • Managing Helm Charts with Flux
  • Managing Kubernetes Manifests with Flux
  • Setting up alerts with Flux

Anais also sat down wrote this all up in blog-post from.

How To Apply GitOps To Everything Using Crossplane And Flux

{{< youtube dunU2ABitMA >}}

Viktor Farcic has done it again - check out this great video where he
shows how to leverage the extensibility of Crossplane and Flux features
to apply GitOps not only to applications running in Kubernetes but to
everything (infrastructure, services, applications running anywhere, etc.)

Encrypted gitops secrets with flux and age

Major Hayden wrote a nice article about how to get encrypted gitops secrets
with flux and age
right.

Here you will learn how to store encrypted kubernetes secrets safely in
your GitOps repository with easy-to-use age encryption. 🔐

Basic authentication with Traefik on kubernetes

Another post from Major Hayden! This time about Basic authentication
with Traefik on kubernetes.

It's nicely detailed and will take you through all the steps to
keep prying eyes away from your sites behind Traefik with basic authentication. 🛃

Automated Canary Deployments with Rancher Fleet and Flagger

{{< youtube 2x5q89YLdc0 >}}

In this video, Lukonde Mwila will demonstrate how to execute automated
canary deployments with Rancher Fleet and Flagger.

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:
Stackspin,
Maersk and
Rungway.

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.

  • If you always wanted to join Team Flux and weren't quite sure how,
    please read our blog post Contributing to
    Flux
    and say Hi on Slack!
  • Many mobile UI fixes!
  • Add flux-subsystem-argo/flamingo
    and weaveworks/vscode-gitops-tools
    to the Flux Ecosystem page.
  • New videos under Flux Resources! 😍
  • Various docs fixes.
  • And here is a big one: we moved all docs from https://flagger.app into
    https://fluxcd.io/flagger - this is part of a bigger move to subsume all
    of our documentation and web-presence into one place, so we won't
    have to maintain too many pieces of infrastructure.
    This has been on our to-do list since Flux became a CNCF
    Incubating project. Now that we are going for Graduation, we
    finally got around to doing it.

Thanks a lot to these folks who contributed to docs and website: Ihor
Sychevskyi, Kingdon Barrett, Stefan Prodan, Endre Czirbesz, Maarten de
Waard and Patrick Rodies.

In particular we would like to thank Ihor Sychevskyi who recently took
on fixing small UI glitches all over the place - especially on mobile
the site should work a lot better now!

Flux Project Facts

We are very proud of what we put together, here 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, 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. 📞 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    .
  8. 👍 Users trust Flux: Flux is a CNCF Incubating project
    and was categorised as "Adopt" on the CNCF CI/CD Tech
    Radar
    (alongside Helm).
  9. 💖 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.

File: content/en/blog/2022-05-10-may-2022-security-announcement.md

author: 'dholbach & pjbgf' date: 2022-05-10 8:30:00+00:00 title: May 2022 Security Announcement url: /blog/2022/05/may-2022-security-announcement/ tags: [security]

tl;dr

The Flux Team has found three security vulnerabilities in
Flux, and we strongly advise you to upgrade your clusters as soon as you
can.

| CVE | Advisory | Severity | Affected versions
| --- | --- | --- | --- | ---
| CVE-2022-24817 | Improper kubeconfig validation allows arbitrary code execution | Critical | < 0.29.0 >= v0.1.0
| CVE-2022-24877 | Improper path handling in Kustomization files allows path traversal | Critical | < v0.29.0
| CVE-2022-24878 | Improper path handling in Kustomization files allows for denial of service | High | < v0.29.0 >= v0.19.0

Breaking changes to be aware of in the upgrade process:
0.29,
0.28,
0.27,
0.26,
0.24 - 0.21.

If you cannot immediately update or are hard pressed for time and need a
work-around for now, please see the CVE advisories linked above for more
information.

Some Background

Last week the Flux Security Team disclosed three new vulnerabilities
which affect v0.28 and older versions, and have a greater impact in
multi-tenancy deployments.

The reason why the impact is greater in multi-tenancy deployments is due
to the way that Flux/GitOps works. Flux tends to operate like a cluster
admin, having permissions to apply any changes to a cluster, regardless
of their scope - at namespace or cluster levels. Users having access to
a source repository, or simply having access to create/alter Flux
objects within a cluster can instruct Flux to apply such changes, which
in single tenancy effectively means that such users have cluster admin
permissions to the target clusters. The caveat being that using Flux you
can add additional security controls between the user and the target
cluster, for example, before each change is merged into a repository
Pull Requests must be created requiring peer reviews. The Open GitOps
community started defining and codifying this further - have a look at
this blog post if
you want to know more.

In multi-tenant environments, users with similar permissions can only
affect part of a cluster, or an isolated cluster in a group of clusters.
Therefore, if a user can gain escalated privileges (or deny service) at a Flux
level, it will have an impact way larger than on single-tenant clusters, as
the users can impact more than just themselves.

At time of writing, we are unaware of any public exploits in the wild,
and therefore have no reason to believe such vulnerabilities have been
actively exploited.

The advisories in detail

[CVE-2022-24817](https://github.com/fluxcd/flux2/security/advisories/GHSA-vvmq-fwmg-2gjc) - Kubeconfig Validation

At the beginning of the Flux2's journey we implemented a feature to apply
state to remote clusters. It enables users to have a management cluster
in which Flux is installed, which then applies changes to other
clusters, making it ideal for some multi-tenancy scenarios in which high
isolation across tenants is needed.

The connection between the management cluster and the target clusters is
done by referencing a Kubernetes secret containing a kubeconfig, which is set at the spec.KubeConfig field in
either Kustomization or HelmRelease objects.

One interesting thing about kubeconfigs is that they are quite
extensible. You can for example define an executable which will then be
automatically called by kubectl every time it requires a new on-demand
access token. An example of this in action is
aws-iam-authenticator,
which enables AWS users to authenticate against AWS and then use the
returning JWT tokens to access their EKS clusters. Once the token expires,
the process happens again. All that is managed by kubectl behind the scenes
without user intervention.

The problem here is that first, the use of executables in kubeconfigs
was enabled by default. Meaning that a malicious tenant would be able to
craft a malicious kubeconfig which could lead to privilege escalation
within the cluster.

As a solution, we decided to disable this feature by default. It can
still be enabled at a cluster level via a new flag
--insecure-kubeconfig-exec being sent to the controller binary.

For cluster admins considering this feature, we also recommend the use
of AppArmor and SELinux profiles to enforce at Kernel level what
binaries could be executed.

[CVE-2022-24877](https://github.com/fluxcd/flux2/security/advisories/GHSA-j77r-2fxf-5jrw) - Kustomization Path Traversal

Flux allows users to lean on Kustomize features to make their lives
easier as they go on about declaring the state of their clusters. Some
of those features could result in sensitive data from the pod filesystem
to be exposed into the target cluster, which could lead to a malicious
tenant being privy to anything sensitive that may exist in the
controller's filesystem or attached volumes (e.g. token).

The mitigation for the path traversal was to create stronger bounds,
enforcing that all kustomize operations happen within such bounds or
result in error.

[CVE-2022-24878](https://github.com/fluxcd/flux2/security/advisories/GHSA-7pwf-jg34-hxwp) - Kustomization Denial of Service

Whilst working on the mitigation of the previous CVE, we have noticed
that in some scenarios a specially crafted kustomization.yaml could lead
to the kustomize-controller to enter into an endless loop, and finally
crash.

For single-tenant clusters, this would mean that an user may make a mistake and
the controller stops working, potentially resulting in future
reconciliations not being applied. For multi-tenant clusters, depending on the
deployment model, a tenant could cause a disruption to affect not only
itself but also the other tenants and potentially even the management
cluster.

The solution mitigating this vulnerability was to further improve our
validation and ensure that such scenarios are not processed in the first
place.

Inspecting your Flux system version

To check if your system is currently vulnerable, run flux version --context=my-cluster
with the --context set to the cluster you want to inspect. This will
report the current Flux binary and controller versions.

Vulnerable Flux system

To find out if your system could be vulnerable, simply find out the
version of Flux. Here it's important to check you are running all of
these:

  • flux < v0.29.0
  • helm-controller < v0.19.0
  • kustomize-controller < v0.24.0.

You can do this like so:

cli
$ flux version
flux: v0.22.1
helm-controller: v0.12.2
kustomize-controller: v0.17.0
notification-controller: v0.18.1
source-controller: v0.17.2

Updating your vulnerable system

:collision: If you find the controllers versioned within the range
mentioned above, follow the upgrade procedure for your system. For
flux bootstrap, this can be done by running the command again with
the same arguments as used during install.

:warning: Please note that if you are upgrading from below one of the
versions in the following list, there are breaking changes and, pre-
and/or post-upgrade notes you need to take into account:
0.29,
0.28,
0.27,
0.26,
0.24 - 0.21.

Up-to-date Flux system

An up to date Flux system should at least have versions listed below:

  • flux >= v0.29.0
  • helm-controller >= v0.19.0
  • kustomize-controller >= v0.24.0

So in practice the output could look like this:

cli
$ flux version
flux version
flux: v0.30.2
helm-controller: v0.21.0
kustomize-controller: v0.25.0
notification-controller: v0.23.5
source-controller: v0.24.4

We encourage all users to keep Flux up-to-date. We offer a GitHub Action with which you can automate the Flux upgrades in a GitOps manner, without having to connect from CI to the cluster's API, as Flux is capable of upgrading itself from Git.

Flux Security more generally speaking

It is no secret that the Flux community has been investing in security
for a long time. Early on the Flux journey we re-architectured the
codebase to avoid shelling out to binaries to decrease the likelihood of
code execution vulnerabilities. The story about our Git integration we
wrote down here.

As Security is such a central pillar of Flux, we are keen to write
about it and tell you how you can benefit from all
the individual features and improvements we worked on, e.g. SBOMs,
CI Checks, Branch Protection, restricted pod security standard and
more. Since the beginning we worked hard to ensure that we ship code
that does what it needs to do, even when that means having to rewrite
parts of upstream dependencies.

When we had our first security audit last
year, the results were quite
reassuring as most of the findings were quite small, with the exception
of a RCE in
kustomize-controller,
which speaks to the security improvements we have been investing on, and
how they are resulting in better development practices.

Another recommendation from the auditors was to implement and follow a
stricter and more elaborate RFC process, which is what we
did. They
also recommended we get in touch with other security teams or auditors
for getting feedback on a refined and more general multi-tenancy
proposal - which we also did as mentioned below.

What's next for Flux

The way we shaped the Flux Roadmap for GA was

  1. Feature party with Flux Legacy
  2. Stable APIs (this was after the controller refactoring which
    consolidated functionality in
    fluxcd/pkg)
  3. Straightforward multi-tenancy implementation
  4. GA release

Here is the status
quo regarding
multi-tenancy:

Flux2 supports multi-tenancy, and users have been using it in
production for some time
now.

The documentation around the subject covers a bootstrap
example
to help users kick start their multi-tenancy deployments. And also how
to implement control plane isolation with the
multi-tenancy-lockdown.

What's next

In summary, the documentation needs expanding to better inform users
around the security risks of multi-tenancy and the recommended
deployment models for their specific isolation/security requirements.

There are proposed changes that would further improve Flux in
multi-tenancy environments, by for example enabling tenants to share
resources amongst themselves. Such changes must be progressed once the
security impact of such changes have been assessed.

To help us get this right, we are engaging with the CNCF TAG
Security. This is
the upstream group where key contributors and experts of the CNCF
Landscape assemble and define security best practices across all the
individual Cloud Native projects. We are asking them for an
independent security
review
and recommendations, particularly around multi-tenancy.

If you want to join the conversation, we are all ears. Please refer to
the open RFC documents and have your say there. We definitely want to
get this right for everyone.

In addition to that we are working hard to round up features, improve
their performance, security and overall stability.

If you want to follow all the other GA related work, we explained how
to do that
here
and if you would like to participate in any of the discussions, come
and find us
on Slack or in our regular meetings. We are always looking forward to
growing Team Flux and the closer we get to GA, it's getting even more
important to have all voices heard.

File: content/en/blog/2023-02-01-january-update.md

author: dholbach
date: 2023-02-01 08:30:00+00:00
title: January 2023 Update
url: /blog/2023/02/january-2023-update/
tags: [monthly-update]
resources:

  • src: "**.{png,jpg}"
    title: "Image #:counter"

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.

Now it's the beginning of February 2023 - let's recap together what
happened in December and January - it has been a lot!

News in the Flux family

Flux 0.38 brings performance improvements and new features

We have released Flux v0.38. Users are encouraged to upgrade for the best
experience. Here is a short summary of its features and improvements:

  • Graduation of Notification APIs to v1beta2, to upgrade please see
    the release notes.
  • Support for defining Kustomize components with Kustomization.spec.components.
  • Support for piping multi-doc YAMLs when publishing OCI artifacts with
    kustomize build . | flux push artifact --path=-.
  • Support for Gitea commit status updates with Provider.spec.type set to
    gitea.
  • Improve the memory usage of helm-controller by disabling the caching of
    Secret and ConfigMap resources.
  • Update the Helm SDK to v3.10.3 (fix for Helm CVEs).
  • All code references to libgit2 were removed, and the
    GitRepository.spec.gitImplementation field is no longer being honored.

The official example repository
was refactored. The new version comes with the following improvements:

  • Make the example compatible with ARM64 Kubernetes clusters.
  • Add Weave GitOps Helm release to showcase the Flux
    UI    .
  • Replace the ingress-nginx Bitnami chart with the official one that contains
    multi-arch container images.
  • Add cert-manager Helm release to showcase how to install CRDs and custom
    resources using dependsOn.
  • Add Let’s Encrypt ClusterIssuer to showcase how to patch resources in
    production with Flux Kustomization.
  • Add the flux-system overlay to showcase how to configure Flux at
    bootstrap time.

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

Security news

Flux 0.39, the upcoming release,
will come with SBOMs and SLSA Provenance attached to all the controllers
container images. In addition, all controller images will be updated to
Alpine 3.17 (which contains CVE fixes for OS packages).

Starting with 0.39, the Flux controllers should consume less memory on busy
clusters due to the disabling of Secret and ConfigMap caching.

Flagger 1.27 and 1.28 add support for APISIX and different autoscaling configs

1.28 comes with support for setting a different autoscaling
configuration for the primary workload.
The .spec.autoscalerRef.primaryScalerReplicas is useful in the
situation where the user does not want to scale the canary workload
to the exact same size as the primary, especially when opting for a
canary deployment pattern where only a small portion of traffic is
routed to the canary workload pods.

1.27 comes with support for Apache APISIX.
For more details see the tutorial.

Flux Ecosystem

Flux Subsystem for Argo

Flamingo is a tool that
combines Flux and Argo CD to provide the best of both worlds for
implementing GitOps on Kubernetes clusters. With Flamingo, you can:

  • Automate the deployment of your applications to Kubernetes clusters and
    benefit from the improved collaboration and deployment speed and
    reliability that GitOps offers.
  • Enjoy a seamless and integrated experience for managing deployments,
    with the automation capabilities of Flux embedded inside the
    user-friendly interface of Argo CD.
  • Take advantage of additional features and capabilities that are not
    available in either Flux or Argo CD individually, such as the robust Helm
    support from Flux, Flux OCI Repository, Weave GitOps Terraform Controller
    for Infrastructure as Code, Weave Policy Engine, or Argo CD
    ApplicationSet for Flux-managed resources.

In recent releases, the team updated Flamingo to support Flux v0.38 and Argo
CD v2.5.7, v2.4.19 and v2.3.13. Please note that Argo CD v2.2 will not be
supported and updated by Flamingo anymore.

Flux Argo CD Image
v0.38 v2.5 v2.5.9-fl.3-main-14aff24e
v0.38 v2.4 v2.4.21-fl.3-main-14aff24e
v0.38 v2.3 v2.3.15-fl.3-main-14aff24e
v0.37 v2.2 v2.2.16-fl.3-main-2bba0ae6

Terraform-controller

The tf-controller team
is currently working on getting the new release
v0.14 out.
They are updating the Terraform binary to version 1.3.7 and the Flux tool
to version 0.38. Additionally, they are fixing the Helm chart and enabling
the parallelism option for the apply stage. They are currently at release
candidate v0.14.0-rc.2 with the new Helm chart version 0.10.0. Please stay
tuned for further updates.

Weave GitOps

Besides a huge amount of general small improvements, the team has fixed two
security vulnerabilities
(1,
2)
and made GitOps Run much
more secure along the way. If you're using a version older than 0.12.0 you are highly
encouraged to upgrade.

Also with GitOps Run you can now open the deployed application's Web UI by
simply hitting a key on your keyboard. GitOps Run sets up the port-forwarding
and opens up a browser window for you.

As always lots of improvements went into Weave GitOps' Web UI so make sure to
take a look.

On the Weave GitOps Enterprise side you can now automatically create Pipelines
from
GitOpsTemplates,
the Terraform UI
has been improved to allow for a more detailed view into a Terraform inventory
and support for observing and managing
Secrets has
landed in its initial incarnation.

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
December and January here are a couple of talks we would like to highlight.

{{< youtube JHmQlSvL0II >}}

HashiCorp User Group Luxembourg: GitOps your Terraform Configurations

Flux Terraform Controller is a controller for Flux to reconcile Terraform
configurations in the GitOps way with the power of Flux and Terraform,
Terraform Controller allows you to GitOps-ify your infrastructure, and
your application resources, in the Kubernetes and Terraform universe.

Flux Terraform Controller ensures what you’ve defined in your Terraform
configurations is what’s always running and available. Flux continuously
looks for changes and reconciles with the desired state. Take advantage
of all the benefits of GitOps: streamlined and secure deployments, quicker
time to market, and more time to concentrate on app development!

{{< youtube uRiCRTSkPOQ >}}

Flux’s Security & Scalability with OCI & Helm (Part 2) with Kingdon Barrett

With Flux, you can distribute and reconcile Kubernetes configuration packaged
as OCI artifacts. Instead of connecting Flux to a Git repository where the
application desired state is defined, you can connect Flux to a container
registry where you’ll push the application deploy manifests, right next to
the application container images.

During this session Kingdon Barrett, OSS Engineer at Weaveworks & Flux
Maintainer, shows you how to quickly create scalable and Cosign-verified GitOps
configurations with Flux using the same process with two demo environments: one
will be a Kustomize Environment and the other a Helm-based environment.

{{< youtube Bmh7kKYLIhY >}}

Flux Security & Scalability using VS Code GitOps Extension

Recently Flux has released two new features (OCI and Cosign) for scalable and
secure GitOps. Juozas Gaigalas, a Developer Experience Engineer at Weaveworks,
will demonstrate how developers and platform engineers can quickly create
scalable and Cosign-verified GitOps configurations using VS Code GitOps Tools
extension. New and experienced Flux users can learn about Flux’s OCI and Cosign
support through this demo. Join us!

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!

{{< youtube H9MJtNSYFi8 >}}

{{< youtube al049I2j1jk >}}

Upcoming Events 📆

We are happy to announce that we have a number of events coming up in
February - 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

Conference Call For Papers

Conferences are all about the people. It's also more fun to present
together. You get to share collective experience and be more entertaining
as a duo!

Two upcoming call for paper deadlines are the following

  • CFP until 2023-02-05, SustainabilityCon

    May 10 – 12, 2023 | Vancouver, Canada
    Join the community of developers, technologists, sustainability leaders
    and anyone working on technological solutions to decarbonize the global
    economy, mitigate and address the impacts of climate change, and build a
    more sustainable future. SustainabilityCon provides a forum to drive open
    source innovation in energy efficiency and interoperability and clean
    development practices within industries ranging from manufacturing to
    agriculture and beyond through collaboration and learning within the community.

  • CFP until 2023-02-10, GitOpsCon

    May 8 – 9, 2023 | Vancouver, Canada

    cdCon + GitOpsCon is designed to foster collaboration, discussion, and
    knowledge sharing by bringing two communities together. It’s the best
    place for vendors and end users to collaborate in shaping the future of
    GitOps and Continuous Delivery (CD).

Talk to Niki Manoledaki for SustainabilityCon and in general to Vanessa
Abankwah and Stacey Potter if you want to present anything Flagger, Flux,
GitOps related at any of the events with us!

Soulé Ba joins Flux Core Maintainers

Soulé Ba has been working on Flux for a long while. Already a maintainer
of Flux's go-git-providers, he didn't stop there but was involved in
a lot of the RFC planning process of many features and contributed code and
fixes for a long long time.

The Flux community is grateful to have you. Well deserved becoming a
Core maintainer now, Soulé!

Your Community Team

We have been working on filling up the speakers calendar for the next weeks
and organising proposals for the upcoming CFP deadlines for the next
conferences. If you are interested in speaking about Flux and GitOps, please
reach out to us!

Next up we are going to look into making our Community page more interesting
and useful. We are also going
to apply for Google Season of
Docs. If you have input or
ideas and would like to get involved, talk to us on Slack!

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

Bill Doerrfeld: Introduction to Flux
(containerjournal.com)

Read more in this article about Flux, where Bill interviewed Priyanka "Pinky"
Ravi about what's new in Flux. It's a nice introduction to Flux.

GitOps has become a chosen strategy for releasing and deploying
cloud-native microservices. The goal of GitOps, a term coined by Alexis
Richardson, CEO of Weaveworks, in 2017, is to “make operations automatic
for the whole system based on a model of the system which was living
outside the system.” And propelling the GitOps practice is Flux, an open
source tool that provides GitOps for apps and infrastructure.

In late 2022, Flux became the 18th project to reach graduation status with
the Cloud Native Computing Foundation (CNCF). Earlier this year, downloads of
the Flux container image surpassed a staggering one billion.

Max Strübing: Automatic deployment updates with Flux (D2iQ Engineering
Blog)

We were very pleased to see this blog post from our friends at D2iQ. Do go
check it out, particularly if you are new to Flux. Max takes a how-to approach
to explaining automatic deployment updates with Flux and explains why this
is generally a good idea:

  • You can deploy fast, easily and often by simply pushing to a repository
  • You can run a git revert if you messed up your environment and everything
    is like it was before
  • This means you can easily roll back to every state of your application or
    infrastructure
  • Not everyone needs access to the actual infrastructure environment, access
    to the git repository is enough to manage the infrastructure
  • Self-documenting infrastructure: you do not need to ssh into a server and
    look around running services or explore all resources on a Kubernetes cluster
  • Easy to create a demo environment by replicating the repository or creating
    a second deploy target

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:
DoneOps and Riley.

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:

  • The Flux landing page is shorter and less overwhelming now.
    This was achieved by moving the adopters logos into a horizontal
    scroll band, dropping some old content and there will be more to
    come here.
  • Flagger docs were update to the latest.
  • Flux Bootstrap: cheatsheet for how to Persistent storage for Flux
    internal artifacts
  • Our FAQ now has entries about how to safely rename a
    Flux Kustomization and how to set local overrides to a Helm chart.
    As it's one of the very common FAQs: We also mention the different
    Flux UIs a lot more prominently now!
  • Flux GCP docs were updated.
  • We improved the Flux Support page to be even clearer
    about how to get Support for Flux, no matter if it's professionally
    or for community support.
  • We renived a lot of unnecessary website build code; now a lot of the
    dynamic content is generated straight from YAML through Hugo Data
    Templates. This makes the website build process a lot more stable
    and we have less build scripts to maintain!
  • Update to latest hugo plus docsy and gallery themes.

Thanks a lot to these folks who contributed to docs and website: Stefan
Prodan, Arhell, Aurel Canciu, Hidde Beydals, Sanskar Jaiswal, h20220026,
Paulo Gomes, Stacey Potter, Johannes Wienke, Jonathan Meyers, Kingdon
Barrett, Lassi Pölönen, Max Jonas Werner, Nate, Scott Rigby, Sunny,
Tarunbot, h20220025, surya.

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, 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. 📞 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    .
  8. 👍 Users trust Flux: Flux is a CNCF Graduated project
    and was categorised as "Adopt" on the CNCF CI/CD Tech
    Radar
    (alongside Helm).
  9. 💖 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.

File: content/en/blog/2024-03-19-flux-kubeconeu2024.md

author: Tamao date: 2024-03-19 08:00:00+00:00 title: Flux project gains New Corporate Support and Ecosystem in 2024 url: /blog/2024/03/flux-project-gains-new-corporate-support-and-ecosystem-in-2024/ tags: [announcement]

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.

File: content/en/blog/_index.md

title: Blog
type: section
menu:
main:
weight: 20

File: content/en/blog/2020-12-01-december-update/index.md

author: dholbach
date: 2020-12-01 12:30:00+00:00
title: December Update
resources:

  • src: "**.{png,jpg}"
    title: "Image #:counter"
    tags: [monthly-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 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: https://github.com/fluxcd/flux2-multi-tenancy.

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:

https://github.com/fluxcd/flux2-kustomize-helm-example

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:

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

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:

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:

{{< youtube R6OeIgb7lUI >}}

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.

File: content/en/blog/2021-03-01-march-update/index.md

author: dholbach
date: 2021-03-01 08:30:00+00:00
title: March 2021 Update
resources:

  • src: "**.{png,jpg}"
    title: "Image #:counter"
    tags: [monthly-update]

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.

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 https://github.com/fluxcd/flux2/discussions/413.

Thanks a lot to everyone who contributed to these releases! 💖

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,
including bootstrapping 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:

📍 Flux v2 Documentation

📍 Flux v2 Guide Migrate from Flux v1

📍 Flux v2 roadmap.

Check out our calendar section 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.

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.

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.

File: content/en/blog/2021-03-08-flux-is-a-cncf-incubation-project/index.md

author: dholbach
date: 2021-03-10 06:30:00+00:00
title: Flux is a CNCF Incubation project
evergreen: true
tags: [announcement]
resources:

  • src: "**.{png,jpg}"
    title: "Image #:counter"

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.

File: content/en/blog/2021-04-29-may-update/index.md

author: dholbach
date: 2021-04-29 06:30:00+00:00
title: May 2021 update
url: /blog/2021/04/may-2021-update/
resources:

  • src: "**.{png,jpg}"
    title: "Image #:counter"
    tags: [monthly-update]

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.

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.

  • 04 May 2021 - Meet the Maintainer - Stefan Prodan -
    you must be registered here to attend this
    session.

  • 05 May 2021 - Keynote: CNCF Project Update: Flux - Stefan
    Prodan     at KubeCon 2021 Europe.

  • 05 May 2021 - Helm Users! What Flux 2 Can Do For
    You     - Scott Rigby & Kingdon Barrett, Weaveworks

    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.

  • 06 May 2021 - Flux: Multi-tenancy Deep Dive - Philip
    Laine     at KubeCon 2021 Europe

    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.

  • 07 May 2021 - Meet the Maintainer - Aurel
    Canciu     - you must be registered
    here     to attend this session

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 our calendar section for more upcoming
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! 💖

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!

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.

File: content/en/blog/2021-05-31-june-update/index.md

author: dholbach
date: 2021-05-31 08:30:00+00:00
title: June 2021 update
url: /blog/2021/05/june-2021-update/
resources:

  • src: "**.{png,jpg}"
    title: "Image #:counter"
    tags: [monthly-update]

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 last month's update here.

Let's recap what happened in May - there has been so much happening!

Newest Flux release

With the 0.14 release of Flux we added a number of big features to Flux.

The highlights are:

  • We replaced the Flux monitoring stack with Prometheus Operator and
    kube-prometheus-stack.
  • Support for a wider range of SSH key formats (CLI)
  • Send Flux events to Azure Event Hub (notification-controller)
  • Support for a wider range of OpenPGP key formats (source-controller)
  • Reduce the memory usage when cloning repositories with large files
    (source-controller)
  • Support for including the content of app repos into the main config
    one (better alternative to git submodules and kustomize remote
    bases) (source-controller)

Docs:

If you are entirely new to Flux, check out our get started
guide. If you are on
an older version of Flux, check out our migration
documentation.

Flagger 1.11 is here

Over in the Flagger project, since our last blog the versions 1.9, 1.10 and
1.11 were released and they bring a number of nice new features and
improvements.

1.9.0 came with improvements to the Gloo Edge integration:

  • Starting with this version, Flagger no longer requires Gloo
    discovery to be enabled. Flagger generated the Gloo upstream
    objects on its own and optionally it can use an existing upstream
    (specified with .spec.upstreamRef) as a template.
  • Also: Adjusted Nginx ingress canary headers on init and promotion

1.10.0 comes with support for Graphite metric templates, additionally:

  • ConfigTracker: Scan envFrom in init-containers
  • e2e: Update Istio to v1.10 and Contour to v1.15

:warning: Flagger 1.11.0 comes with a breaking change: the minimum supported
version of Kubernetes is v1.19.0.

This release comes with support for Kubernetes Ingress networking.k8s.io/v1.
The Ingress from networking.k8s.io/v1beta1 is no longer supported, affected
integrations: NGINX and Skipper ingress controllers.

KubeCon round-up

KubeCon 2021 Europe happened in early May and the Flux team was happy to
represent. If you entirely missed the event, here are a couple of links
we'd like to share:

These are recordings of talks which were given by Flux maintainers.

We were also present at the Flux booth at the CNCF Project Pavillion.
This was new for us and we really enjoyed being part of this. A number
of Flux maintainers and community members were at the virtual booth to
meet and greet, answer questions and do impromptu lightning talks - we
watched some of the keynotes together and shared feedback.

We had a fantastic time, laughed a lot and were pleased to learn more
about how everyone uses Flux in production and how folks can start
getting more involved in our community. Thanks everyone for supporting
us at KubeCon!

The CNCF Flux Store is up

As one of the perks of reaching Incubation status within the CNCF, there
is now a Flux section in the CNCF Store. If you are looking for a new
hoodie, new socks, a birthday present or anything else, please sure to
check out https://store.cncf.io/collections/flux.

If you have fully re-clothed yourself in Flux things, be sure to share a
pic on our Slack
channel!

(Learn more about the store and where its proceeds go
here.)

Our community is growing

We finally built a nicer home to show off who all is part of our
community: https://fluxcd.io/adopters.

From start-ups to Fortune 500 companies many have accompanied us for a
couple of years already, quite a few migrated to the latest of Flux and
quite a few use Flagger.

If you use any of the Flux projects in your organisation, please
consider adding yourself as well: instructions can be found
here.

Thanks a lot everyone who already added themselves - your support means
a lot to us! 💖

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.

We are very happy to be part of a big event that 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).

09-10 Jun 2021 - GitOps Days 2021

Sign up for it today, share it with your friends far and wide. It's a
free event!

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

In other news

Reviewing Flux Governance

More than half a year ago we established our Flux Governance
document. The idea behind
it was to formalise our values around community, the roles and
responsibilities and processes; many of which had been transparent and
with our full integrity, but still quite ad-hoc up until that point.

For us it's time to review this together with our
Community and
Contributors docs.
So we are turning to you for feedback: please let us know what you
think.
What was your experience up until now? Do you feel things are clear
enough?

We are striving for a great contributor experience, so your feedback on
all of the above is going to make a difference.

Representing Flux and Flagger at CNCF

The CNCF does a great job of informing the world of its member projects
and we just made sure to update all relevant information, branding and
logos. If you ever need to borrow our logos, colours or any other info
for a presentation or something, check out the CNCF CI/CD
Landscape,
the Flux and
Flagger
branding or our entry on the list of CNCF
projects.

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.

File: content/en/blog/2021-07-02-july-update/index.md

author: dholbach
date: 2021-07-02 11:30:00+00:00
title: July 2021 update
url: /blog/2021/07/july-2021-update/
resources:

  • src: "**.{png,jpg}"
    title: "Image #:counter"
    tags: [monthly-update]

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 last month's update
here.

Let's recap what happened in June - there has been so much happening!

From now on Flux APIs will be stable

We moved our APIs to v1beta1, which means that all Flux APIs are stable
from now on. To us this means that Flux is production ready. You can
make use of all these APIs, we'll support them from now on. Going
forward, breaking changes to the beta CRDs will be accompanied by a
conversion mechanism.

Incidentally this also marks the 100th release in the fluxcd/flux2
repo. :fireworks:

How about you give us a :star: if you like it?

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

Flux Project Facts

  1. 🤼 Flux provides GitOps for both apps or
    infrastructure.     With help from Flagger, Flux can
    automate the release process of apps using strategies like
    canaries 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 progressive delivery (PD)
    through automatic reconciliation. Flux can update container image
    declarations in your YAML and push them automatically back to Git
    for you (based on new image tags discovered via scanning).

  3. 🔩 Flux plays nice with your existing tools: your Git
    providers (GitHub, GitLab, Bitbucket, can even use s3-compatible
    buckets as a source), all major container registries, and all CI
    workflow providers.

  4. ☸️ 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.

  5. 🤹 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.

  6. 📞 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    .

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

New releases in the Flux family

Flux 0.16 hits the streets

We've released flux2 v0.16.0. Starting with this version, all Flux APIs
are considered stable and ready for production use. :sparkles:

The highlights are:

  • :rocket: The image automation APIs have been
    promoted from v1alpha2 to v1beta1. There are no breaking changes; to
    upgrade from image.toolkit.fluxcd.io/v1alpha2, simply change the
    API version to v1beta1 for all the image manifests in Git.

  • :mechanical_arm: Flux has full support for mixed-arch
    Kubernetes clusters. We now run the conformance test suite for Flux
    pre-releases on both AMD64 and ARM64.

  • :mag_right: New flux trace command that allows Flux
    users to point the CLI to a Kubernetes object in-cluster and get a
    detailed report about the GitOps pipeline that manages that particular
    object.

    cli
    $ flux trace podinfo-5dcdc87bc5-9pcrh --kind=pod \
--api-version=v1 --namespace=podinfo
Object:         pod/podinfo-5dcdc87bc5-9pcrh
Namespace:      podinfo
Status:         Managed by Flux
---
HelmRelease:    podinfo
Namespace:      podinfo
Revision:       6.0.0
Status:         Last reconciled at 2021-06-24 08:37:55 +0300 EEST
Message:        Release reconciliation succeeded
---
HelmChart:      podinfo-podinfo
Namespace:      flux-system
Chart:          podinfo
Version:        >=1.0.0-alpha
Revision:       6.0.0
Status:         Last reconciled at 2021-06-24 08:31:40 +0300 EEST
Message:        Fetched revision: 6.0.0
---
HelmRepository: podinfo
Namespace:      flux-system
URL:            https://stefanprodan.github.io/podinfo
Revision:       8411f23d07d3701f0e96e7d9e503b7936d7e1d56
Status:         Last reconciled at 2021-06-24 07:57:22 +0300 EEST
Message:        Fetched revision: 8411f23d07d3701f0e96e7d9e503b7936d7e1d56

:notebook_with_decorative_cover: Check out the Flux roadmap updates.

⚠ Breaking Changes in 0.15

In this version, Flux and its controllers have been upgraded to
Kustomize v4. While Kustomize v4 comes with many improvements and bug
fixes, it introduces a couple of breaking changes:

  • YAML anchors are no longer supported in Kustomize v4, see
    kustomize/issues/3675
    for more details.
  • Due to the removal of hashicorp/go-getter from Kustomize v4, the set
    of URLs accepted by Kustomize in the resources filed is reduced to
    file system paths, URLs to plain YAMLs and values compatible with
    git clone. This means you can no longer use resources from
    archives (zip, tgz, etc).
  • Due to a
    bug
    in Kustomize v4, if you have non-string keys in your
    manifests, the controller will fail with json: unsupported type
    error.

More details on breaking changes can be found at
#1522

Flagger 1.12 got released

1.12.1: This release comes with a fix to Flagger when used with Flux v2.

  • Improvements: Update Go to v1.16 and Kubernetes packages to v1.21.1
    #940
  • Fixes: Remove the GitOps Toolkit metadata from generated objects
    #939

1.12.0: This release comes with support for disabling the SSL
certificate verification for the Prometheus and Graphite metric
providers.

  • Improvements:
    • Add insecureSkipVerify option for Prometheus and Graphite
      #935
    • Copy labels from Gloo upstreams
      #932
    • Improve language and correct typos in FAQs docs
      #925
    • Remove Flux GC markers from generated objects
      #936
  • Fixes: Require SMI TrafficSplit Service and Weight
    #878

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.

The Bug Scrub

Kingdon Barrett organised our first ever Bug
Scrub.
To quote from the announcement:

For us, a great way to get started, is to learn more about Flux
through direct experience, when e.g. trying to reproduce issues
reported by other Flux users, and the general business of chopping
wood and carrying water. The Flux Bug Scrub is born.

The inaugural first Bug Scrub event commenced and concluded on June 30.
It was a great success where we collectively as a team visited 53 issues
in about 60 minutes. This was a terrific opportunity which we will be
repeating on a regular weekly basis for the time being.

Kingdon will continue hosting these hour-long gatherings on a staggered
weekly basis, in the empty time slot which is opposite the existing
"CNCF Flux Project Meeting" community meeting; the next Bug Scrub is on
July 8 at 8:00 Pacific / 11:00 Eastern Time / 15:00 UTC, (and from now
on you can find them on the CNCF Flux
calendar.)
Volunteers at any skill level are welcome to attend, come spend an hour
levelling up your Flux knowledge by reviewing open issues with the team.

Watch this space and our social channels for news and more details about
these events as they happen. Also reach out to Kingdon if you want to
get involved in any bug scrubbing.

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

In other news

People writing about Flux

(Typical) journey towards full GitOps

This is a new section where we want to highlight people who talk and
write about Flux. If you have an article you would like us to refer to,
hit us up on Slack or Twitter or Email. We're looking forward to giving
you a shout-out!

Alexander Holbreich wrote a very nice article called "(Typical)
journey towards full
GitOps".

It's well-written, easy to read and goes into enough detail for
newcomers to understand it. Thanks Alexander for this write-up!

Flux at the Okteto Community Call

https://okteto.com/blog/june-2021-community-call-recap/

One of the Flux maintainers, @kingdonb,
was invited on the Okteto community call for show-and-tell about how
Flux and Okteto integration works; the video link is in the blog post
which is featured on the Okteto blog at the link above. See how the
Okteto CLI can be used to invoke a debugger inside a pod running on
your dev cluster, which together with VS Code shortens the inner loop
of development, providing a unique developer experience with Flux.

Website and Docs news

Our web and docs team has been busy as well.

🤹 First of all we would like to congratulate everyone who added
themselves to the Flux Adopters page. It's
beautiful for all of us who work on the Flux to see how our projects are
used in the wild.

📔 We moved our legacy documentation (Flux Legacy and Helm Operator) from
docs.fluxcd.io to fluxcd.io/legacy and replaced all old docs with
redirects. This was done because our docs were hosted on two different
pieces of infrastructure and came from different repositories. They were
hard to update and some of our users got confused about which docs they
were looking at. If you have any feedback about this, let us know.

🔋 We also just added a Flux Integrations
page. If your extension
or integration is not listed yet, please add yourself. We will make this
page shine more in the future - we are also happy to work on joint blog
posts, etc. Just come and talk to us!

💖 Our landing page received a number of style updates and now shows Flux
contributors! It's great to be able to see everyone who is making this
happen.

Many docs have received updates and more information and we are pleased
that many new docs PRs have been coming in from new contributors! We now
check links automatically as well.

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.

File: content/en/blog/2021-08-02-august-update/index.md

author: dholbach
date: 2021-07-30 15:30:00+00:00
title: August 2021 update
url: /blog/2021/08/august-2021-update/
resources:

  • src: "**.{png,jpg}"
    title: "Image #:counter"
    tags: [monthly-update]

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 last month's update
here.

Let's recap what happened in July - even though a lot of us took some
much needed holidays, a lot has been happening!

Flux Project Facts

We are very proud of what we put together, here 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 an
    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, and all CI workflow providers.
  4. ☸️ 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.
  5. 🤹 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.
  6. 📞 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    .
  7. 💖 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.

This section has made it onto the landing page of https://fluxcd.io
now - let us know how you like it!

News in the Flux family

Controller refactoring coming up

If you have been following the repositories under the
fluxcd organisation on Github, you
will have noticed that its actually the *-controller projects which
provide the functionality of Flux. Their names should be fairly
self-explanatory: "source", "helm", "kustomize", "notifications"
and so on.

We had many contributors jump in and help since we started the big Flux
rewrite, but we noticed that the learning curve was a little steep and
everybody spent a little too much time learning how the controllers
interacted, and similar concepts.

Hidde Beydals recently sat down and implemented helper functions which
will aid in unifying codebases and settings standards across all Flux
Controllers. The bulk of this work has landed under
pkg/runtime.
Its README does a pretty good job explaining the helper functions and
important considerations.

Here we want to give a big shout-out to the Cluster API
project,
as for example the conditions and patch packages were heavily inspired
by the project's work!

The idea behind this was to

  • Reduce duplication of code
  • Reduce a certain subset of race condition related bugs in Flux
    controllers
  • Make writing e2e tests much easier and uniform
  • Make maintaining Flux controllers easier for others to help with
  • Make writing new controllers much clearer process (help widen
    ecosystem of controllers built on the GitOps Toolkit)
  • Make us feel more comfortable in the code

Check out the most recent version of Go reference documentation here:
https://pkg.go.dev/github.com/fluxcd/pkg/[email protected].

The overall plan is:

  • If you are proficient in Go and have some experience with
    controller-runtime
    this might be straight up your alley. If you are interested in
    learning more about it, you might want to get started with this
    Kubebuilder tutorial.
  • Review the pkg/runtime reference
    docs    .
  • Review how these new helper functions are used to standardize Source
    Controller in this Pull Request.
  • Based on those patterns, work together on a per-pattern, per
    controller Pull Request.

Track the wider effort by subscribing to these issues:

If you would like to help out in the refactoring work, please reach out
to Scott Rigby on Slack.

Flux migration news

In last month's update we discussed how Flux's APIs are now stable. To
clarify what this means for the Flux project as a whole, we added the
following section to our migration
timetable:

  • Flux 1: Superseded

    • All existing projects encouraged to migrate to Flux 2, and
      report any bugs
    • Flux 1 Helm Operator code freeze -- no further updates except
      CVEs

  • Flux 2 CLI: Needs further testing, may get breaking changes

    • CLI needs further user testing during this migration period

  • GitOps Toolkit
    APIs and Controllers

    • All Beta, Production Ready
      The GOTK Custom Resource Definitions which are at v1beta1 and
      v2beta1 and their controllers are considered stable and
      production ready. Going forward, breaking changes to the beta
      CRDs will be accompanied by a conversion mechanism.
    • All Flux 1 features stable and supported in Flux 2
    • Promoting Alpha versions to Beta makes this Production Ready

Reach out to us if you have any questions about this!

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.

Flux Bug Scrub

Our Flux Bug Scrub event is now a regular feature, with the current
scheduling information available on the CNCF Flux Dev
Calendar,
usually scheduled opposite the CNCF Flux Project Meeting. You can
subscribe to the
calendar
to receive notifications about upcoming events and schedule changes. The
Bug Scrub is an opportunity to meet with other Flux contributors in
another setting besides the Dev meeting, where we try to identify "Good
First Issues" and spend an hour working on issue triage as a group.
These meetings are open to the general public, so individuals of any
skill level are welcome.

The theme and focus of the Bug Scrub can vary from week to week; we are
floating the idea of doing an FAQ scrub or Docs scrub, where instead of
reviewing issues and doing triage on PRs, we comb through recent Slack
history and try to find new Frequently Asked Questions that we can add
to the docs, in order to save the Flux team from writing out the same
replies longhand every time a question is asked again. Many folks are
coming to the Bug Scrub just to learn more about Flux and for a window
into Flux current events.

One goal of this event is to convert Flux users into Flux contributors,
so we will try to make sure that all attendees who are interested in
making a contribution get an issue assignment before the end of the
event. We hope that you will join us for a Bug Scrub some time soon.

For details and more information about the Flux Bug Scrub, how it works,
and what you need to do in order to participate: please read and review
the Bug Scrub
Process/Protocol
doc, or revisit the blog post that announced our First Bug
Scrub.
Remember to find current scheduling information on the CNCF Flux Dev
Calendar,
and stay tuned for more info!

GitOpsCon North America

Still a little further down the line, GitOpsCon North
America
is happening October 12, 2021 as a Day-0 Event leading up to
CloudNativeCon/KubeCon in Los Angeles, California + Virtually of course.

GitOpsCon North America (#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.

The event is vendor-neutral and is being organized by the CNCF GitOps
Working Group. Topics include getting started with GitOps, scaling and
managing GitOps, lessons learned from production deployments, technical
sessions, and thought leadership.

The schedule is not yet available, but will be soon. Now is a good time
though to register.

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

In other news

Flux User Interviews

As a community we want to share our success stories more, so Scott Rigby
and Daniel Holbach will soon start reaching out to folks who use Flux,
who built solutions on top of Flux or do advocacy for Flux. If you were
involved in any of these things, or know of an interesting story we
should be telling to inspire, celebrate and teach others, please let us
know. We want to reach far and wide and paint Flux's community as
colourful and diverse as it is!

News from the Website and our Docs

We updated to a new version of the docsy
theme, which gives us
more short-codes we can use to express ourselves in our documentation.
Alison also improved the ways tabs look as you can see
here:

Alison also put quite a bit of work into writing
up
how we want our documents to look and which short-codes are most
useful.
This should make it much easier if you want to start contributing
documentation for Flux.

In the FAQ section, Hendrik Ferber explained how to patch CoreDNS and
other pre-installed
addons.

Additionally, to give some of the success stories Flux users have shared
more room, we added this section to the landing page of
https://fluxcd.io - if you have more, we are all ears!

Many others helped us improve the site and docs in other ways - thanks
to everyone!

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.

Explore Related Technologies & Topics

View All 9,111+ Repositories →

Discover similar high-velocity repositories, agent skills, and OpenAPI specifications across the ecosystem.

⚡ MCP Servers Model Context Protocol → 🧠 Agent Skills Prompt & rule files → 🔌 OpenAPI Specs REST & Swagger schemas →