Hey everyone! I'm new to Kubernetes and currently working on building a SaaS product using a k3d cluster for development. I've been exploring ways to manage third-party dependencies like cert-manager and cnpg in my dev environment. I've tried a few methods so far:
1. **Helmfile**: This didn't work out so well for me. It felt awkward, and I ran into issues with dependencies not being ready when they should be.
2. **Umbrella Chart**: I combined all my specific Helm charts into one large chart. It was easy to set up but really complicated rolling out interdependent charts since upgrades weren't straightforward.
3. **Wrapper Chart**: Right now, I'm trying to wrap individual Helm charts in my own. It lets me configure values and add custom manifests, but I've heard this might be an anti-pattern since it complicates tracking upstream dependencies.
I'm toying with the idea of writing a script to manage these deployments, but I know that simple Bash scripts are usually better for rolls than debugging. If anyone has tips or patterns that work for managing third-party charts in dev, I'd really appreciate your input!
5 Answers
Using an umbrella chart can work if done carefully. We maintain a base cluster chart that a lot of clients use. While upgrading components separately isn’t always easy, if you test everything together and release based on that, it tends to go smoothly. Just make sure all parts are in sync before upgrading, or hold off until they can be. Check out our GitHub for reference!
Exactly! It’s all about managing dependencies effectively without falling into anti-pattern traps.
I wrap all my Helm charts in Kustomize and deploy them using FluxCD. It really streamlines the process and keeps things clean—definitely the way to go!
Totally! This is how most of us should be consuming Helm charts these days. Makes life much easier!
For a local dev setup, I usually automate the cluster creation with a script using KinD and just set it up with the essentials to get things running. This approach simplifies development without overcomplicating the environment.
Consider using ArgoCD for all environments, including development. You can set up multi-source ArgoCD application resources that pull from Helm charts and your own Git repo with custom values files. Also, since Helm 3 is OCI-compliant, you can cache all external charts in a Harbor registry. This sets you up pretty well!
I’ve found that using FluxCD in a layered approach really helps. You could structure it with a core layer (like Flux and cert controllers) and then divide your configurations and add-ons down the line. It keeps everything organized and helps manage upgrades without conflicts, since apps can run parallel unless they depend on each other.
Agreed! But be cautious with umbrella charts; they can lead to complexity and maintenance headaches. It might be better to go for a more declarative approach and leverage GitOps for deployments instead.