I'm building a system using Kubernetes where my application has to handle multiple use cases. I want to dynamically provision Deployment, Service, and Ingress resources for each use case via an API. This API could either work directly with the Kubernetes API or create manifests that get pushed to a Git repository. I'd like to ensure each resource set is properly labeled for easy identification and management through ArgoCD. The whole setup should fall under a single ArgoCD Application and remain simple and maintainable, tapping into GitOps practices. I'm seeking recommendations on the best way to achieve this—should I use the native Kubernetes API, develop a lightweight API service for template generation that commits to Git, or consider a specific tool or pattern to simplify the process? Any advice or examples would be greatly appreciated!
Also, keep in mind that the number of use cases is not fixed; it can increase significantly, making individual values files for each use case impractical.
4 Answers
You could use Backstage to render your values.yaml and generate merge requests. Pair that with the ArgoCD PR generator to create your apps. There’s a great tutorial on this from DevOpsToolkit on YouTube if you want a step-by-step guide!
Consider using Helm templates as well. They could give you that dynamic touch you're looking for. Check out the Helm documentation for best practices on creating templates—should really help you out!
Have you thought about using Helm? It can really simplify the process of managing your Kubernetes resources dynamically. It allows you to define your resources as templates, which could be perfect for what you're trying to accomplish!
It sounds like you might be on the path to creating a Kubernetes Operator. That could give you the dynamic behavior you're looking for while making everything manageable!
Yeah, I think creating an operator might be the way to go. I was just hoping for a simpler solution without the overhead of building an operator from scratch!
That's true! But I want to go for something more dynamic. Ideally, I'd like to expose this as an endpoint so we can automate adding use cases without manual intervention.