The document is a presentation by Scott Rigby on using Flux with Helm to implement GitOps principles for existing Helm users and new users alike. It covers the benefits of Flux, moving from Helm CLI to Helm controller, and provides insight into configuring Flux to manage existing Helm releases effectively. Key topics include common use cases, pitfalls when integrating CI and CD, and the advantages of using Flux for continuous delivery within Kubernetes environments.

1. © 2018 Cloud Native Computing Foundation
1
GitOps for
Helm Users!
Scott Rigby, DX Engineer @ Weaveworks

2. © 2018 Cloud Native Computing Foundation
2
Who I am
Scott is a Brooklyn based interdisciplinary artist and Developer
Experience Engineer at Weaveworks. He co-founded the
Basekamp art and research group in 1998 and the massively
collaborative Plausible Artworlds international network. In
technology he enjoys helping develop open source software that
anyone can use, most recently projects in the cloud native
landscape including co-maintaining Helm and Flux. In daily
decisions, large or small, he tries to help make the world a better
place for everyone.
Scott Rigby
Maintainer
👋
Scott
DX Engineer @r6by
Co-chair

3. © 2018 Cloud Native Computing Foundation
3
Agenda
● Who this talk is for
● Brief context for new users
● Benefits of flux for helm users
● Moving from helm CLI to helm controller
● Demo

4. © 2018 Cloud Native Computing Foundation
4
Who this talk is for
● Existing Helm Users!
○ Many of you are using helm in your CI automation
○ Many of you are additionally using imperative helm CLI
commands
○ Some of you may only be using helm CLI commands
● New to Helm? No worries!
○ I’ll also give a short intro to helm so brand new users can
benefit too

5. Brief Context for New Users

6. © 2018 Cloud Native Computing Foundation
6
Intro to Helm
Helm.sh | Docs: https://helm.sh/docs/

7. © 2018 Cloud Native Computing Foundation
7
Helm Scope
• CRD upgrades
• Manage or structure multiple
environments. You must use other
tools for this (e.g., Helmfile,
bash/Makefile)
• Control loop, or retry logic
• Automated responses (beyond
rollback)
• Automated drift detection
(imperatively this can be done with
helm diff plugin)
✅ In Scope 🚫 Out of Scope
• Supports CLI and SDK (which Flux
uses)
• Packaging
• Configuration
• Imperative app delivery
• Versioning and rollbacks
• etc…

8. © 2018 Cloud Native Computing Foundation
8
Source: opengitops.dev

9. © 2018 Cloud Native Computing Foundation
9
Intro to Flux Family
fluxcd.io flagger.app

10. © 2018 Cloud Native Computing Foundation
10
🤝 Flux provides GitOps for both apps and infrastructure
🤖 Just push to Git and Flux does the rest
🔩 Flux works with your existing tools
☸ Flux works with any Kubernetes and all common Kubernetes
tooling
🤹 Flux does Multi-Tenancy (and “Multi-everything”)
📞 Flux alerts and notifies
👍 Users trust Flux
💖 Flux has a lovely community that is very easy to work with!
Flux in Short
fluxcd.io

11. © 2018 Cloud Native Computing Foundation
11
Overview of Flux
Source
controller
Kustomize
controller
Helm Controller Notification
Controller
Image Reflector &
Automation
Controller
Flux
Flux is a set of
Kubernetes Controllers
fluxcd.io

12. © 2018 Cloud Native Computing Foundation
12
How Flux Source & Helm Controllers Work
fluxcd.io

13. Show me the…benefits!
🔒 🦮 🏎 🚀 📈

14. © 2018 Cloud Native Computing Foundation
14
Moving from Helm CLI to Helm Controller
● It all starts with using Helm declaratively
● For helm CI automation users, this is the process of decoupling your CI/CD
● For all helm users, when using flux, helm releases are properly separated into
continuous delivery (CD)
● Change can be 👻 scary 😱, but you're here because you know it's
necessary. Some things that might help:
○ tips to convince whoever you need to
○ companies big and small, old and new are adopting GitOps
○ point to success stories from others (quotes, talks)
○ Taking ownership is easier when you can share risk
○ Defer to experts to help make your case

15. DEMO TIME!

16. © 2018 Cloud Native Computing Foundation
16
Common Use Cases
You can install Flux and helm-controller on an existing cluster with
running helm releases, or use new Helm Release configurations to
move to new infrastructure.
● In-place lift-and-shift / pivot-to-GitOps
● Migrate on fresh infra
You can also mix and match:
● Custom Helm charts
● Shared internal or community Helm charts

17. © 2018 Cloud Native Computing Foundation
17
Configuring Flux to Own Existing Releases
1. Refer to any Helm values files already checked into Git
○ Whether applied with some scripting per environment
(`ENV-values.yaml`)
○ That may be declared in a Helmfile
2. Inspect the state of the cluster
○ This is important if you have people modifying helm releases
imperatively
○ `helm get values my-release`
3. Then configure the Flux HelmRelease with your Helm values
○ Using HelmRelease Values
○ or ConfigMaps/Secrets referenced by HelmRelease `ValuesFrom`

18. © 2018 Cloud Native Computing Foundation
18
Common Pitfalls
● If you have custom logic, such as health checks when mixing CI and CD together, you'll
need to determine how to port that logic to a Flux-compatible solution
○ If this proves challenging, it can be a sign that your CI and CD are overly coupled,
which could cause other issues with your release process
○ To solve: More cleanly separate your CI and CD. You may also want to consider
more resilient tools to accomplish the same goals – e.g., use Flagger for traffic
directing based on health checks and other conditions (opens up a path to
blue/green, canary, etc)
● It's possible to accidentally structure your source repos in ways that make it difficult for
people access the things they need
○ Ensure folks can update their HelmReleases during incident response – whether
access in the repo, or giving in-cluster access to temporarily suspend Flux
reconciliation per Helm release and perform imperative fixes
○ To solve: Can split into multiple repos according to user access rights
○ Solutions vary by git provider: GitHub CODEOWNERS, GitLab has per-directory ACLs