Skip to content

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

@kundeng

Description

@kundeng

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!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions