I'm new to Kubernetes and trying to get my head around how to effectively use Argo CD for deploying applications. I've been able to create basic Helm templates and deploy them via GitLab, including integrating secrets with 1Password. However, I'm wondering about the best practices for deploying additional resources like Gateway and HTTPRoute objects. For instance, how should I manage multiple pods, with pod A handling mydomain.com and pod B managing mydomain.com/someapp? Also, concerning StorageClasses and PersistentVolumeClaims (PVCs), should I bundle them together? I would assume that there's a distinct relationship between a PVC and its respective StorageClass (SC), but I'd appreciate clarification on this.
5 Answers
When it comes to Gateway objects, they are generally intended to represent network ingress, so you'll typically have just a couple in your cluster. Given the complexities around domain names and certificates, consider deploying a Gateway per application or app group. HTTPRoutes should ideally be included in the app's Helm chart, but if necessary, create a separate chart for those resources that can be reused across multiple apps.
Ultimately, aim to deploy everything through Argo CD, except for the initial bootstrap manifests like ArgoCD itself and any necessary networking components. Use logical separation for your manifests: keep StorageClasses in a dedicated infrastructure app since they don't change often, and group PVCs with the applications they relate to. Finding the right balance in how you deploy will take some time but is crucial for efficiency.
I suggest using the App of Apps approach along with a monorepo for easier management. Separate your Argo app sets into infrastructure and application categories. For complex Helm charts like Prometheus, it's often easier to manage custom resources by separating them into different apps, especially if they have their own health checks.
It's a common misconception that there's a 1:1 relationship between PVCs and StorageClasses. You can actually use one StorageClass for multiple PVCs across your cluster. For example, if you're using AWS, a StorageClass like 'gp3-persistent' can back many PVCs. Typically, you'd handle the StorageClass at the infrastructure level, while keeping PVCs tied to your specific applications.
You might want to check out the App-of-Apps pattern and consider using Sync Waves annotations for better organization. This will help you maintain clarity when deploying your resources, especially in a complex setup.
That makes sense! Having a single Gateway for multiple apps simplifies management, but I guess it can get tricky with how you want to configure your certificates.