On #GitOpsCon EU yesterday, I learned from Christian Hernandez that there is a pattern name for rendering your Kubernetes Manifests on the CI server using CM tools (Helm, Kustomize, JSonnet, CueLang, Timoni, etc.) before deploying them via #GitOps: "Rendered Manifests" 👏🥳 This pattern is a great addition to the config management section of our GitOps patterns collections: https://lnkd.in/gzqNH_WN I especially like having a name for this pattern, because we have been using it ever since we migrated from Flux v1 to Argo CD in 2020. 💡 We also provide some examples on how to implement it in the GitOps playground: https://lnkd.in/gCfuyyXR It's also worth mentioning that Flux recommends this pattern for it's OCI artifacts feature, without using the pattern name, yet 😉 https://lnkd.in/g--ykp3q Christian Hernandez what would you say is the opposite of rendered manifest, i.e. rendering on the GitOps operator? "Native" rendering?
I'd probably call it "Late Rendering" (much like lazy evaluation in spirit, but I'd probably focus on the time rather than possible savings/cost of the evaluation).
Clear explanation of the pattern. Naming it makes discussions around CI-side rendering vs operator-side rendering much easier, especially for teams running mixed Flux and Argo setups. This aligns with what we hear from teams testing Kunobi. Once multiple clusters and different rendering approaches are involved, visibility and drift detection depend heavily on understanding where manifests are produced. Good to see this concept articulated so precisely.
Saved for later!
Thank you! And yes, I haven't seen much about this pattern probably because there wasn't really a name for it! Now we have one! I would call it "GitOps Controller Rendering"