Flux CD deep dive: architecture, CRDs, and mental models

# Flux CD deep dive: architecture, CRDs, and mental models ## What started the discussion Hey everyone! I've been running Flux CD both at work and in my homelab for a few years now. After doing some onboarding sessions for new colleagues at work, I thought that the information may be useful to others as well. I decided to put together a video covering some of the things that helped me actually understand how Flux works rather than just copying manifests. The main things I focus on is how the different controllers and their CRDs map to commands you'd run manually, and what the actual chain of events is to get from a git commit to a running workload. Once that clicked for me, the whole system became a lot more intuitive. I also cover how I structure my homelab repository, bootstrapping with the Flux Operator so Flux can manage and upgrade itself, and a live demo where I delete a namespace and let Flux rebuild it. Repo: https://github.com/mirceanton/home-ops Video: https://youtu.be/hoi2GzvJUXM Curious how others approach their Flux setup. Especially around the operator bootstrap and handling the CRD dependency cleanly. I've seen some repos that attempt to bundle all CRDs at cluster creation time, but that feels a bit messy to me. ## What stood out in the comments ### Discussion point 1 As somebody who has been a user and fanboy of Flux since the v1 and Weaveworks days: Flux is probably the single most underappreciated project under the CNCF umbrella, it has laid the groundwork for Kubernetes and GitOps workflows as we know them nowadays (8y ago or so this was an alien concept) and imho the only reason ArgoCD has surpassed it in popularity was the more user-friendly UI they packaged up. Thank you Stefan & gang for the tenacity and service to the community. ### Discussion point 2 Do you know how the mental model is different between argocd and flux? I originally started using ArgoCD because it had a GUI but now find I’m doing everything declaratively anyways so flux may be better. ### Discussion point 3 ControlPlane’s FluxCD D2 Reference Architecture which is focused mostly in gitless is the way to go. Now, with this architecture all the responsibility lies on template generation and pipeline. Such an improvement. Huge thanks to Stefan and Control Plane team. On your CRD topic, I have a set up based on Brian Fair awesome flux (head, crd, infra) but in a monorepo with template generation for gitless. That works nicely for me. ### Discussion point 4 There is a [flux plugin for k9s](https://github.com/derailed/k9s/blob/master/plugins/flux.yaml) ### Discussion point 5 We do something similar at work with the D2 architecture but with the multi-tenant approach of one repo per tenant. What I disliked about the d2 architecture is the heavy use of kustomize overlays to differentiate between environments and I found it more difficult to do promotions between environments especially in automated ways, i.e. via renovate We're still not using OCI as our source, so not gitless, more or less for the same reason. I've seen this being frowned upon in some discussions, but we really found that syncing the staging environment to the main branch of the tenant repo and production to a prod branch worked fairly well for us, combined with post build substitution and per-env configs. Everything is tracked via PRs and promotion is done by running a dedicated promotion pipeline since we're using branch protections quite heavily I'll have to dig a bit deeper into the gitless approach, I guess, but I found it a bit more convoluted than it needed to be. ## Thread snapshot - Original subreddit: r/kubernetes - Original author: u/MikeAnth - Reddit score: 84 - Comment count: 23 - Original thread: https://www.reddit.com/r/kubernetes/comments/1rkkdgg/flux_cd_deep_dive_architecture_crds_and_mental/