Best Practices for Bundling Argo CD Applications and Managing Resources
Asked by
TechSavvy234
I'm new to Kubernetes, and I'm trying to wrap my head around what to bundle in my Argo CD applications. I've got the basics down, creating Helm templates and deploying them to my Kubernetes cluster from GitLab, with secrets managed through 1Password. However, I'm unsure about best practices for deploying other resources like Gateway and HTTPRoute objects. For instance, if I have multiple pods that serve parts of an HTTP application, such as one pod handling [mydomain.com](http://mydomain.com) and another for [mydomain.com/someapp](http://mydomain.com/someapp), how should I manage those deployments? Additionally, what's the deal with StorageClasses and PVCs? I know I should bundle the PVC with the app, but should I include the StorageClass too, given that there's typically a one-to-one relationship between a PVC and a StorageClass?
Answers
Gateway objects can get complex since they handle network ingress. You might want to consider having one gateway per app or group of apps. Deploy the Gateway as its own app alongside the others. As for HTTPRoute, it should typically be in your app's Helm chart, but if not, creating a separate chart might be a good move.
Reply to this answer
Check out the App-of-Apps pattern and Sync Waves annotation; they can really help with organizing your resources effectively.
Reply to this answer
Definitely deploy everything via Argo CD! The only exceptions are things like bootstrap manifests for Argo CD itself. As for resource organization, you should keep cluster-scoped resources, like StorageClasses, separate from namespace-scoped resources. Those infrastructure-related items can go in their own Argo application.
Reply to this answer
Just a heads up: the relationship between PVCs and StorageClasses isn't one-to-one. You can actually use a single StorageClass for multiple PVCs across your cluster. The StorageClass is more of a template for the PVs used by PVCs.
Reply to this answer
Using an App-of-Apps approach can simplify things. Group your Argo applications logically by infrastructure vs. applications. For complex Helm charts, like those for Prometheus, consider separating CRDs into their own apps to avoid sync issues.
Reply to this answer
Add your answer
Answers are reviewed before publication.
Related Discussions