I am using microk8s to run Kubernetes on my Ubuntu server. I am using the helm v3 as my helm command.
This is the result of the helm version command:
version.BuildInfo{Version:"v3.9.2", GitCommit:"1addefbfe665c350f4daf868a9adc5600cc064fd", GitTreeState:"clean", GoVersion:"go1.17.12"}
I am trying to run this helm chart on this K8s instance:
apiVersion: v2
name: myTest
description: The test daemon (test) helm chart
type: application
version: 1.4.0
appVersion: v1.18.0
kubeVersion: ">= 1.19.0"
...
But I am getting this error:
INSTALLATION FAILED: chart requires kubeVersion: >= 1.19.0 which is incompatible with Kubernetes v1.19.15-34+c064bb32deff78
I tried different versions of Microk8s as 1.21, 1.24, and 1.19 but there is the same result.
I installed this service on minikube without any problem :(
According to the Semantic Versioning specification you have a pre-release version of Kubernetes. (This is possibly an issue in microk8s's release process.) The Helm documentation for the kubeVersion: field states that it depends on the Go github.com/Masterminds/semver package. Its documentation notes:
SemVer comparisons using constraints without a prerelease comparator will skip prerelease versions. For example, >=1.2.3 will skip prereleases when looking at a list of releases while >=1.2.3-0 will evaluate and find prereleases.
So setting in your Chart.yaml that you're willing to tolerate pre-release versions should address this:
kubeVersion: ">= 1.19.0-0" # adding a -0 on the end
Related
I'm following the instructions to setup Dask on K8s Cluster. I'm on MacOS, have K8s running on Docker Desktop, kubectl version 1.22.5 and helm version 3.8.0. After adding the repository, downloading default configuration, installing helm chart using command
RELEASE=my-dask-gateway
NAMESPACE=dask-gateway
VERSION=0.9.0
helm upgrade --install \
--namespace $NAMESPACE \
--version $VERSION \
--values path/to/your/config.yaml \
$RELEASE \
dask/dask-gateway
generates following output/error
"dask" already exists with the same configuration, skipping
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "dmwm-bigdata" chart repository
...Successfully got an update from the "dask" chart repository
Update Complete. ⎈Happy Helming!⎈
Release "my-dask-gateway" does not exist. Installing it now.
Error: failed to install CRD crds/daskclusters.yaml: unable to recognize "": no matches for kind "CustomResourceDefinition" in version "apiextensions.k8s.io/v1beta1"
An older post suggests to either update the manifest or use older version of kubernetes. Does that mean dask is not compatible with recent versions of kubernetes?
Posting community wiki answer for better visibility:
This is fixed in the repo main. You could grab the CRDs from there, or wait for a release, which we are hoping to do soon. Otherwise, yes, you would need an older version of kubernetes for dask-gateway to work.
I am wondering and apparently have not yet found anywhere if there is a way via which I can specifically override the value of "version" key's value from the dependencies chart in Helm
# Chart.yaml
dependencies:
- name: bitnami/postgresql
version: **"8.10.5"**
repository: "https://charts.bitnami.com/bitnami"
I tried something like below:
# Chart.yaml
dependencies:
- name: bitnami/postgresql
version: "{{.Values.postgresql.version}}"
repository: "https://charts.bitnami.com/bitnami"
and
# Values.yaml
postgreSQL:
version: "8.10.5"
But I am getting below error:
Error: cannot load Chart.yaml: error converting YAML to JSON: yaml: invalid map key: map[interface {}]interface {}{".Values.postgresql.version":interface {}(nil)}
If this is currently not possible then can someone advise how do you update the "version" of dependencies in Charts.yaml whenever new version is available of them?
It's not super well documented in the Helm documentation – the generic helm dependency command documentation mentions it, but not the main discussion of chart dependencies – but the version: field is optional, and it uses semantic versioning if it is present. Helm maintains a separate Chart.lock file that lists precise versions of chart dependencies, and the helm dependency update command will update that file.
So for your uses you might say:
dependencies:
- name: bitnami/postgresql
version: '^8' # Any 8.x.x version, but not version 7 or 9
repository: "https://charts.bitnami.com/bitnami"
Or, if you're not configuring the dependency chart at all, just leave out the version: line entirely and use whatever the latest version is.
# Install the chart using the specific Chart.lock version
helm install myservice .
# Get a newer version in Chart.lock and upgrade the database
rm Chart.lock
helm dependency update
helm upgrade myservice .
Do check the Chart.lock file into source control, so you have reproducible deployments.
All of this is also true if you're using the older, Helm v2-compatible layout that lists dependencies in a separate requirements.yaml file. In this case the lock file is requirements.lock, but version: is still a semantic version constraint and the same helm dependency commands update the lock file.
Your approach won't work, because the template engine ({{ .Values.myvar }}) works only in the template folder.
# Chart.yaml
dependencies:
- name: bitnami/postgresql
version: "{{.Values.postgresql.version}}" # Won't be replaced
repository: "https://charts.bitnami.com/bitnami"
I am afraid that the helm team won't change this behaviour according to this discussion:
https://github.com/helm/helm/issues/2492
Apperantly the only way I can think of, is to replace the version with a shell script and afterwards calling the helm commando.
sed -i 's/version: "[0-9].[0-9].[0-9]"/version: "9.9.9"/' Chart.yaml
helm install ....
https://docs.nvidia.com/datacenter/cloud-native/kubernetes/dcgme2e.html
helm install \
--generate-name
gpu-helm-charts/dcgm-exporter
Error: unable to build kubernetes objects from release manifest: unable to recognize "": no matches for kind "ServiceMonitor" in version "monitoring.coreos.com/v1"
I using helm version: 3.5.2
Kubernetes Cluster: 1.19.5
Thanks in advance.
Apparently your Custom Resource Definition creation has finished successfully but its API was not yet available when the installation proceeded with creation of the ServiceMonitor Custom Resource. Running helm install ... command once again should help.
I want to upgrade helm version from 2 version to 3 version since I am facing "Could not find tiller" issue in while using "helm delete --purge " in JenkinsX.
So upgrade does not depend on tiller and makes my job easy. Please help me to resolve this.
jx step helm build
WARNING: No $CHART_REPOSITORY defined so using the default value of: http://jenkins-x-chartmuseum:8080
Adding missing Helm repo: storage.googleapis.com https://storage.googleapis.com/chartmuseum.jenkins-x.io
Successfully added Helm repository storage.googleapis.com.
Adding missing Helm repo: jenkins-x-chartmuseum http://jenkins-x-chartmuseum:8080
Successfully added Helm repository jenkins-x-chartmuseum.
WARNING: No $CHART_REPOSITORY defined so using the default value of: http://jenkins-x-chartmuseum:8080
Adding missing Helm repo: chartmuseum.jenkins-x.io http://chartmuseum.jenkins-x.io
Successfully added Helm repository chartmuseum.jenkins-x.io.
EXITCODE 0[Pipeline] sh
[preview] Running shell script
+ make delete
helm version
Client: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}
Error: could not find tiller
use the command choco upgrade kubernetes-helm
first install chococo/brew then use above for choco cmd or brew upgrade helm.
The latest Helm 3 won't need tiller pod.
With Helm v3.0.2 + a new Kubernetes v1.14.9 cluster.
fyi, I've already added the stable repo:
helm repo add stable https://kubernetes-charts.storage.googleapis.com/
helm install \
--namespace prometheus \
prom-dry-run \
stable/prometheus-operator \
--dry-run
manifest_sorter.go:175: info: skipping unknown hook: "crd-install"
manifest_sorter.go:175: info: skipping unknown hook: "crd-install"
manifest_sorter.go:175: info: skipping unknown hook: "crd-install"
manifest_sorter.go:175: info: skipping unknown hook: "crd-install"
manifest_sorter.go:175: info: skipping unknown hook: "crd-install"
Error: unable to build kubernetes objects from release manifest: [unable to recognize "": no matches for kind "Alertmanager" in version "monitoring.coreos.com/v1", unable to recognize "": no matches for kind "Prometheus" in version "monitoring.coreos.com/v1", unable to recognize "": no matches for kind "PrometheusRule" in version "monitoring.coreos.com/v1", unable to recognize "": no matches for kind "ServiceMonitor" in version "monitoring.coreos.com/v1"]
I thought Helm 3 was backward-compatible with existing charts? Is this an exception?
Is prometheus-operator not compatible with Helm 3? Do I have to use Helm 2? Or is there a backward-compatibility option?
The stable repo is scheduled to be deprecated and probably not updated with latest charts.The canonical source for Helm charts is the Helm Hub. Use below command to add repo and install prometheus operator from Helm Hub using helm 3 or helm 2.
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install my-prom-release bitnami/prometheus-operator
There is a detailed guide for migrating from helm 2 to helm 3
In helm 3 during a dry run, CRDs are not installed but the Kubernetes validation happens against the output of the chart. So any CR that uses a CRD that is installed by the chart will fail validation during dry run.
Current work-arounds:
1.Use helm template instead of dry run
2.Don't reference CRs in the same chart that has the CRDs
3.Install the CRD separately before running the dry run
CRDs were an exception to the Helm v3 chart compatibility, sadly.
The problem is that --dry-run can't generate resources using the CRDs, because the CRDs aren't installed by the dry run. This is apparently a "documented behaviour" although it was documented in the implementation pull-request, not in the Helm Documentation.
Edit: I forgot to mention the best current workaround is to install the CRDs by hand. Then --dry-run will work. Helm v3 ignores CRDs that are already installed, so you can just leave them there once you're happy with your configuration and do the install for real.
Upgrading CRDs in Helm is a whole different (not yet resolved) issue.
stable/prometheus-operator gained support to Helm v3 in 8.2.0 in mid-November 2019 so that's not the issue here.
bitnami/prometheus-operator gained support in 0.3.0 only a couple of days earlier.
Both appear to be actively maintained at the time of writing (March 2020).
In case anyone comes looking and is confused that the above two chart names are not links: Both have been renamed, and one has moved.
They are now prometheus-community/kube-prometheus-stack (replaces stable/prometheus-operator) and bitnami/kube-prometheus respectively.