Watch the recording here: https://youtu.be/0KmqEp4VxSQ Welcome Helm users! CNCF Flux has a best-in-class way to use Helm according to GitOps principles. For you, that means improved security, reliability, and velocity - no more being on the pager on the weekends or having painful troubleshooting or rollback when things go wrong. Built on Kubernetes controller-runtime, Flux’s Helm Controller is an example of a mature software agent that uses Helm’s SDK to full effect. Flux’s biggest addition to Helm is a structured declaration layer for your releases that automatically gets reconciled to your cluster based on your configured rules: ⭐️ The Helm client commands let you imperatively do things ⭐️ Flux Helm Custom Resources let you declare what you want the Helm SDK to do automatically During this session, Scott Rigby, Developer Experience Engineer at Weaveworks and Flux & Helm Maintainer, will take you on a tour of Flux’s Helm Controller, share the additional benefits Flux adds to Helm and then walk through a live demo of how to manage helm releases using Flux. If you want to follow along with Scott’s demo, here are a couple of resources to help you prepare ahead of time: 📄 Flux for Helm Users Docs: https://fluxcd.io/docs/use-cases/helm/ 📄 Flux Guide: Manage Helm Releases: https://fluxcd.io/docs/guides/helmreleases/ Speaker Bio: Scott is a Brooklyn based interdisciplinary artist and Developer Advocate 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.

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