Got an issue in deploying the argo-cd helm chart, it seems failing checking the Kubernetes version: argocd: >= 1.22.0-0 and got Kubernetes 1.20.0
Pulumi is not using the installed Helm on my Mac and seems to have kube-version set to 1.20.0!
Pulumi Chart ressource:
new k8s.helm.v3.Chart(
'argo-cd',
{
chart: 'argo-cd',
fetchOpts: {
repo: 'https://argoproj.github.io/argo-helm'
},
namespace: 'argo',
values: {}
},
{
providers: {
kubernetes: cluster.provider
}
}
);
Result:
pulumi:pulumi:Stack (my-project-prod):
error: Error: invocation of kubernetes:helm:template returned an error: failed to generate YAML for specified Helm chart: failed to create chart from template: chart requires kubeVersion: >=1.22.0-0 which is incompatible with Kubernetes v1.20.0
The chart is working as intended. >=1.22.0-0 means the chart must be rendered with a version of the Kubernetes client greater than 1.22.0.
Check your Helm version is compiled against 1.22.
If you want to render your chart against your cluster's capabilities, use helm template --validate. That will tell Helm to pull the Kubernetes version from your cluster. Otherwise it uses the version of Kubernetes the Helm client was compiled against.
You can also refer to this github link for more troubleshooting steps.
Related
In process of project initialization I have a command:
helm upgrade mongodb mongodb/mongodb --install --set replicaSet.enabled=true.
Which fails with error:
Release "mongodb" does not exist. Installing it now.
Error: unable to build kubernetes objects from release manifest: [resource mapping not found for name: "mongodb-arbiter" namespace: "" from "": no matches for kind "PodDisruptionBudget" in version "policy/v1beta1"
ensure CRDs are installed first, resource mapping not found for name: "mongodb-secondary" namespace: "" from "": no matches for kind "PodDisruptionBudget" in version "policy/v1beta1"
ensure CRDs are installed first]
Can you please suggest what to do?
The version of Kubernetes you are using is too new for your helm charts.
Within the latest version of Kubernetes PodDisruptionBudget lives in policy/v1 and not policy/v1beta1 where your chart is looking for it.
I use a helm chart to deploy on an AKS cluster via Azure Devops. Everything works fine but I see a warning at the end of the deployment step:
Starting: Deploy Helm chart to qa3 environment
==============================================================================
Task : Package and deploy Helm charts
Description : Deploy, configure, update a Kubernetes cluster in Azure Container Service by running helm commands
Version : 0.201.0
Author : Microsoft Corporation
Help : https://aka.ms/azpipes-helm-tsg
==============================================================================
/usr/local/bin/helm upgrade --namespace qa3 --install --values /home/vsts/work/1/s/invitation/values.yaml --set deployment.image.tag=***,deployment.environment=qa3,cluster.name=dev,azure.region=westus2,azure.appInsightsKey=***,deployment.deployedBy='cd',application.publicJwtValidationCertPemBase64=***,application.endpointPath=invitational,application.sendGridTemplateId=***,application.twillioFromPhoneNumber=***,secret.AuthToken=***,secret.AccountSid=***,secret.SendGridApiKey=*** --wait --install --reuse-values q5id-app-invitation /home/vsts/work/1/s/invitation
Release "q5id-app-invitation" has been upgraded. Happy Helming!
NAME: q5id-app-invitation
LAST DEPLOYED: Wed Aug 10 14:53:19 2022
NAMESPACE: qa3
STATUS: deployed
REVISION: 3
TEST SUITE: None
/usr/local/bin/kubectl cluster-info
Kubernetes control plane is running at https://***:443
CoreDNS is running at https://***:443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
Metrics-server is running at https://***:443/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
##[warning]Capturing deployment metadata failed with error: TypeError: Cannot read property 'kind' of null
Finishing: Deploy Helm chart to qa3 environment
It looks like the template was successfully deployed, then the kubectl cluster-info was ran, then something else. I cannot understand what might cause this warning:
##[warning]Capturing deployment metadata failed with error: TypeError: Cannot read property 'kind' of null
How can I fix it?
It seems I just had the same issue. The problem is that one of your helm templates is not loading properly.
Let's say your template is conditional and before the condition there is a comment
# enables PodDisruptionBudget
{{- if .Values.pdb }}{{ if .Values.pdb.enabled }}
apiVersion: policy/v1
kind: PodDisruptionBudget
...
{{- end }}{{ end }}
In some cases, it would work without warning when if is true. However, if it's a false your template is kinda "empty" and Azure should skip it. Unfortunately, it cannot, because there is a comment that Azure prints in the pipeline logs. Due to that the template is not skipped and Azure searches for kind of this template, but there is nothing, so this is why the warning appears. To solve it one needs to move the comment inside of the condition.
I have a working bitnami/rabbitmq server helm chart working on my Kubernetes cluster but the graphs displayed on Grafana are not enough, I found this dashboard RabbitMQ-Overview which has sufficient details that can be very useful for my bitnami/rabbitmq server but unfortunately there is no data showing on the dashboard. The issue here is I cannot see my metrics on this dashboard, can someone please suggest a work-around approach for my case. Please note I am using the kube-prometheus-stack helm chart for Prometheus+Grafana services.
Steps to solve this issue:
I enabled the rabbitmq_prometheus for all my Rabbitmq nodes by entering the Pods
rabbitmq-plugins enable rabbitmq_prometheus
Output:
:/$ rabbitmq-plugins list
Listing plugins with pattern "." ...
Configured: E = explicitly enabled; e = implicitly enabled
| Status: * = running on rabbit#rabbitmq-0.broker-server
|/
[E] rabbitmq_management 3.8.9
[e*] rabbitmq_management_agent 3.8.9
[ ] rabbitmq_mqtt 3.8.9
[e*] rabbitmq_peer_discovery_common 3.8.9
[E*] rabbitmq_peer_discovery_k8s 3.8.9
[E*] rabbitmq_prometheus 3.8.9
Made sure I was using the same data source for Prometheus used in my Grafana
I tried creating a prometheus-rabbitmq-exporter to get the metrics from Rabbitmq and send them to RabbitMQ-Overview dashboard but no data was displayed.
my dashboard no data
Please note while reading this documentation to solve my issue I already have metrics from Rabbitmq displayed on Grafana but I need the RabbitMQ-Overview that contains more details about my server.
To build on #amin 's answer, the label can be added to the helm like so:
Before helm chart version 9.0.0
metrics:
serviceMonitor:
enabled: true
additionalLabels:
release: prometheus
After helm chart version 9.0.0
metrics:
serviceMonitor:
enabled: true
labels:
release: prometheus
Fixed the issue after including 2 commands from this table table and need to edit the ServiceMonitor to include the label release: prometheus as it is needed to be visible in the prometheus targets as I am using kube-prometheus-stack helm chart.
helm install -f values.yml broker bitnami/rabbitmq --namespace default --set nodeSelector.test=rabbit --set volumePermissions.enabled=true --set replicaCount=1 --set metrics.enabled=true --set metrics.serviceMonitor.enabled=true
I hope it helps someone in the future!
While installing a helm chart a condition for the dependency works well as the following Chart.yaml file. But it doesn't allow to apply the condition based on the existing Kubernetes resource.
# Chart.yaml
apiVersion: v1
name: my-chart
version: 0.3.1
appVersion: 0.4.5
description: A helm chart with dependency
dependencies:
- name: metrics-server
version: 2.5.0
repository: https://artifacts.myserver.com/v1/helm
condition: metrics-server.enabled
I did a local install of the chart (my-chart) in a namespace(default), then I try to install the same chart in another namespace(pb) I get the following error which says the resource already exists. This resource, "system:metrics-server-aggregated-reader", has been installed cluster wide as previous dependency (metrics-server). Following is the step to reproduce.
user#hostname$helm install my-chart -n default --set metrics-server.enabled=true ./my-chart
NAME: my-chart
LAST DEPLOYED: Wed Nov 25 16:22:52 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
My Cluster
user#hostname$helm install my-chart -n pb --set metrics-server.enabled=true ./my-chart
Error: rendered manifests contain a resource that already exists. Unable to continue with install: ClusterRole "system:metrics-server-aggregated-reader" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-namespace" must equal "pb": current value is "default"
There is a way to modify the template inside the metrics-server chart to conditionally generate the manifest files as described in Helm Conditional Templates. In order to do this I have to modify and maintain the metrics-server chart in internal artifact which will restrict me using the most recent charts.
I am looking for an approach to query the existing Kubernetes resource, "system:metrics-server-aggregated-reader", and only install the dependency chart if such resource do not exists.
When you install a chart with a child chart that doesn't specify a namespace, Helm will use the one specified on command line via --namespace. Is it possible to override this flag for a specific child chart?
For example if I have chart A which depends on chart B and I specify --namespace foo, I want to be able to customize the resources of chart B to be installed into some other namespace bar instead of foo.
Update 2:
Helm 3 added support for multi namespaces https://github.com/helm/helm/issues/2060
Update 1:
If a resource template specifies a metadata.namespace, then it will be installed in that namespace. For example, if I have a pod with metadata.namespace: x and I run helm install mychart --namespace y, that pod will be installed in x. I guess you could use regular helm templates with the namespace to parameterize it.
Original answer:
We do not plan on fully supporting multi-namespaced releases until Helm 3.0
https://github.com/kubernetes/helm/issues/2060#issuecomment-306847365
As a workaround, you install for each namespace individually using --skip-dependencies or with dependency conditions
If you already have different charts then you can use helmfile to achieve this.
Step 1:
create the following folder.
my-awesome-infrastructure/
helm
helmfile
helmfile.yaml
Where helm and helmfile are the binary executables.
Step 2: install the helm diff plugin which is needed used helmfile.
helm plugin install https://github.com/databus23/helm-diff
Step 3: declare your charts in the helmfile.yaml.
helmBinary: ./helm
repositories:
- name: ingress-nginx
url: https://kubernetes.github.io/ingress-nginx
- name: bitnami
url: https://charts.bitnami.com/bitnami
releases:
- name: nginx-ingress
namespace: nginx-ingress
createNamespace: true
chart: ingress-nginx/ingress-nginx
version: ~4.1.0
- name: jupyterhub
namespace: jupyterhub
createNamespace: true
chart: bitnami/jupyterhub
version: ~1.1.12
- name: metrics-server
namespace: metrics-server
createNamespace: true
chart: bitnami/metrics-server
version: ~5.11.9
Step 4: run helmfile to deploy all charts.
./helmfile apply
In the above example, you are deploying three separate charts to three separate namespaces.
Under the covers, helmfile will run helm install separately and create separate releases.