You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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!
The text was updated successfully, but these errors were encountered:
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:
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:
Thank you for your guidance!
The text was updated successfully, but these errors were encountered: