roboll / helmfile

Deploy Kubernetes Helm Charts
MIT License
4.05k stars 565 forks source link

Clarification on Using Kustomize with Helmfile for Upstream Kubernetes Component Patching #2186

Open kundeng opened 3 weeks ago

kundeng commented 3 weeks ago

Summary: I would like to understand whether using Helmfile with Kustomize is recommended for patching upstream Kubernetes components (e.g., OpenShift storage or image registry). After reviewing the documentation and experimenting, I’ve encountered challenges that make it unclear whether this integration is suitable for declarative patch management. Specifically, I want to avoid relying on one-off imperative commands and manage everything as code.

Context:

My goal is to deploy and manage both infrastructure and applications declaratively, without running ad-hoc commands. For example, after installing an OpenShift cluster, I need to patch certain built-in components like storage operators or the image registry. These components are part of the upstream Kubernetes system and not tied to any specific application deployment.

Challenge:

I’ve encountered an issue when trying to patch these components using Kustomize within Helmfile. It seems I need to declare ownership of certain system components by adding special annotations. Without these annotations, Helm or Helmfile reports errors such as:

•   Resource not managed by Helm: When trying to patch components that were originally created outside of Helm.

To apply patches smoothly, it looks like I need to add annotations like these to the upstream resources:

metadata: annotations: meta.helm.sh/release-name: meta.helm.sh/release-namespace: labels: app.kubernetes.io/managed-by: Helm

These annotations effectively “claim ownership” of the resources on behalf of Helm, allowing Helmfile to manage them. However, this approach feels intrusive since it forces us to adopt control over components that should ideally remain under the upstream system’s management.

Question:

•   Is it recommended to use Helmfile with Kustomize for patching upstream components this way?
•   Is there a cleaner way to manage such patches without adding ownership annotations to system resources?
•   Alternatively, is there a better strategy for managing patches declaratively within Helmfile that avoids imperative commands and ownership conflicts?

Thank you for your guidance!

oradwell commented 3 weeks ago

repository has moved. please open your issue here: https://github.com/helmfile/helmfile/issues

kundeng commented 3 weeks ago

I opened a discussion there, but I highly doubt I will get reply soon. LOL>