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
Is your feature request related to a problem? Please describe.
Say I have 5 clusters divided under 2 tiers:
Dev: (tier=dev label)
dev1
dev2
dev3
Stage: (tier=stage label)
stage1
stage2
In dev I have just upgraded to kube-prometheus-stack-58.4.0 and in stage I'm still running kube-prometheus-stack-57.0.0. I want to be able to upgrade all clusters in a given tier together so I use my tier label for targeting.
All of my clusters use external-dns so I want an annotation on my service. Something along the lines of:
This does not currently seem to be possible when using kustomize based on my understanding of the documentation found here.
Describe the solution you'd like
I would like to be able to template the path in kustomizationRefs as that would allow me to use kustomize and re-use ClusterProfiles. Something like: manifests/overlay/{{ .Cluster.metadata.name }}/prometheus would solve the situation I described above.
Describe alternatives you've considered
The currently available solutions are:
I cannot use kustomize at all and instead use the templating feature in the values section. This works assuming the helm chart I'm using has support for whatever property I'm trying to set. Stacking templating like this (Helm + ClusterProfile) feels fraught with peril and is not something I would like to rely on in a production setting.
Create a ClusterProfile per cluster providing the path to each cluster specific kustomize overlay like: manifests/overlay/dev1/prometheus. This solution unfortunately introduces a bunch of overhead as ClusterProfiles cannot be re-used between clusters. Every update means touching n*m ClusterProfiles where n is the number of applications and m is the number of clusters.
Additional context
I might very well have missed some fundamental feature of either kustomize or sveltos. If that is the case please point me to the relevant documentation.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Say I have 5 clusters divided under 2 tiers:
In dev I have just upgraded to
kube-prometheus-stack-58.4.0
and in stage I'm still runningkube-prometheus-stack-57.0.0
. I want to be able to upgrade all clusters in a given tier together so I use mytier
label for targeting.All of my clusters use external-dns so I want an annotation on my service. Something along the lines of:
external-dns.alpha.kubernetes.io/hostname: ingress.dev1.mydomain.com
external-dns.alpha.kubernetes.io/hostname: ingress.dev2.mydomain.com
external-dns.alpha.kubernetes.io/hostname: ingress.dev3.mydomain.com
This does not currently seem to be possible when using
kustomize
based on my understanding of the documentation found here.Describe the solution you'd like
I would like to be able to template the
path
inkustomizationRefs
as that would allow me to usekustomize
and re-use ClusterProfiles. Something like:manifests/overlay/{{ .Cluster.metadata.name }}/prometheus
would solve the situation I described above.Describe alternatives you've considered
The currently available solutions are:
manifests/overlay/dev1/prometheus
. This solution unfortunately introduces a bunch of overhead as ClusterProfiles cannot be re-used between clusters. Every update means touchingn*m
ClusterProfiles wheren
is the number of applications andm
is the number of clusters.Additional context
I might very well have missed some fundamental feature of either kustomize or sveltos. If that is the case please point me to the relevant documentation.
The text was updated successfully, but these errors were encountered: