Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
kundeng opened this issue Oct 30, 2024 · 2 comments

Comments

@kundeng
Copy link

kundeng commented Oct 30, 2024

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
Copy link

oradwell commented Oct 31, 2024

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

@kundeng
Copy link
Author

kundeng commented Oct 31, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants