Use --validate by default for calls to helm template

[schlichtanders]

What happened?

when using kustomize with helm chart generator, it fails to build cert-manager from its helm chart.

The underlying problem seems to be described in this older helm issue helm/helm#10086
Concretely helm does not use the kubernetes version found by kubectl by default to compare against kubeVersion field. Instead, you need to add the --validate flag for it to pick the currently activated kubernetes cluster version.

I couldn't find any workaround, so I guess the helmchartgenerator is so far not working for cert-manager and other helm charts which configure kubeVersion > 1.20.0

Kustomize is really cool, but the helm support is unfortunately buggy at a couple of really crucial places. It is almost unusable.

What did you expect to happen?

build cert-manager without problems

How can we reproduce it (as minimally and precisely as possible)?

the kustomize.yaml config is super simple

helmCharts:
- name: cert-manager
  repo: https://charts.jetstack.io
  version: v1.13.1
  releaseName: cert-manager
  valuesFile: values.yaml
  includeCRDs: true

sortOptions:
  order: fifo

with the following values.yaml file

installCRDs: true
namespace: "cert-manager"

build it with kubectl kustomize --enable-helm path/to/folder

Expected output

no error

Actual output

it fails with the following error

error: accumulating resources: accumulation err='accumulating resources from 'cert-manager': 'path/to/overlay/cert-manager' must resolve to a file': recursed accumulation of path 'path/to/overlay/cert-manager': Error: chart requires kubeVersion: >= 1.22.0-0 which is incompatible with Kubernetes v1.20.0

Use --debug flag to render out invalid YAML
: unable to run: 'helm template cert-manager /path/to/overlay/cert-manager/charts/cert-manager -f /tmp/kustomize-helm-2586829190/cert-manager-kustomize-values.yaml --include-crds' with env=[HELM_CONFIG_HOME=/tmp/kustomize-helm-2586829190/helm HELM_CACHE_HOME=/tmp/kustomize-helm-2586829190/helm/.cache HELM_DATA_HOME=/tmp/kustomize-helm-2586829190/helm/.data] (is 'helm' installed?): exit status 1

Kustomize version

v5.0.4-0.20230601165947-6ce0bf390ce3

Operating system

Linux

[Gatschknoedel]

This would be a very nice feature. Edit: maybe not by default but make it configurable

[stormqueen1990]

Hello there, @schlichtanders! 👋

This issue was opened a while back and I noticed it was originally reproduced using v5.0.4 of Kustomize. I tried reproducing it with the latest version (v5.3.0) of Kustomize and it succeeds with both kustomize build --enable-helm and kubectl kustomize --enable-helm.

Could you please confirm whether this remains an issue with the latest version of Kustomize? If so, is there a different set of steps that reproduce the issue?

[koba1t]

We already have a kube-version option in helmCharts.
Could this function resolve your issue?
#5270

[skeet70]

I encountered this same issue in kustomize 5.2.1 with helm 3.13.3 -> 3.9.4.

It isn't present in kustomize 5.3.0 but 5.3.0 also changes the directory structure of the generated charts, which I don't have the time to chase down the impacts of in our infrastructure/scripts right now.

[koba1t]

Please refer to this comment: #5505 (comment)

/kind helm
/triage out-of-scope
/close

[k8s-ci-robot]

@koba1t: The label(s) kind/helm cannot be applied, because the repository doesn't have them.

In response to this:

Please refer to this comment: #5505 (comment)

/kind helm
/triage out-of-scope
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-ci-robot]

@koba1t: Closing this issue.

In response to this:

Please refer to this comment: #5505 (comment)

/kind helm
/triage out-of-scope
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[nilfr]

@stormqueen1990 I am still experiencing this with kustomize v5.4.1. My use case is that my Helm chart contains a check using .Capabilities.APIVersions.Has "monitoring.coreos.com/v1". This means that it will never return the ServiceMonitor. Now in helm, I could just pass --validate, but in kustomize this is currently not possible.

Reproduction steps

1. Create a directory called test/ with the following two files:

   # kustomization.yaml
   apiVersion: kustomize.config.k8s.io/v1beta1
   kind: Kustomization
   namespace: example
   helmCharts:
     - name: redis-ha
       repo: "https://dandydeveloper.github.io/charts"
       version: "4.23.0"
       releaseName: cache
       namespace: example
       valuesFile: "values.yaml"
   ---
   # values.yaml
   exporter:
     enabled: true
     serviceMonitor:
       enabled: true

2. Run the following commands:

   # Add helm chart repo.
   helm repo add dandydeveloper https://dandydeveloper.github.io/charts
   # Template helm chart without validate and check for `ServiceMonitor`. (returns nothing)
   helm template cache dandydeveloper/redis-ha --values test/values.yaml | yq 'select(.kind == 
   "ServiceMonitor") | .metadata.name'
   # Template helm chart with validate and check for `ServiceMonitor`. (returns "cache-redis-ha")
   helm template cache dandydeveloper/redis-ha --validate --values test/values.yaml | yq 'select(.kind == 
   "ServiceMonitor") | .metadata.name'
   # Build simple kustomization. (returns nothing)
   kustomize build --enable-helm test/ | yq 'select(.kind == "ServiceMonitor") | .metadata.name'

Could we re-open this issue?

[koba1t]

Hi @nilfr
We already have apiVersions(ApiVersions is the Kubernetes API versions used for Capabilities.APIVersions) support.
#4926

Please set this parameter for your helmCharts entry.

[nilfr]

@koba1t This works, thank you!

For anyone coming across this, please refer to this comment on #3458 for more information.

[vertisan]

Hi @nilfr We already have apiVersions(ApiVersions is the Kubernetes API versions used for Capabilities.APIVersions) support. #4926

Please set this parameter for your helmCharts entry.

Still, are there any chances of adding --validate support? Knowing a given Chart, there will be no problem with providing additional apiVersion, but what about some larger and unknown ones, e.g. kube-prometheus-stack? At this moment, this will require analyzing the Chart and wondering what API needs to be added to apiVersions.

However, --validate (even as an additional option to add) will avoid this :)

[koba1t]

@vertisan
Please refer to this comment: #5505 (comment)