I am looking for a helm chart that contains the default (most commonly used) configuration for ZooKeeper (config for statefulset, netpol, service, etc.), v3.5.0+. A chart that I can then use to deploy a ZK cluster in a k8s cluster.
I was hoping to obtain such a Helm chart (the values.yaml file) from Bitnami (e.g. https://charts.bitnami.com/, or https://bitnami.com/stack/zookeeper/helm). But no luck.
Any ideas or pointers would be greatly appreciated.
Thank you,
Ahmed.
You can get default values.yaml from the GitHub repository or through the helm command.
helm show values bitnami/zookeeper > vaules.yaml
Or
From the GitHub repository, they have a link to the GitHub repository for every chart.
bitnami/zookeeper/values.yaml
Related
We wanna use TDengine on Kubernetes. But I dont see any docs，is there any problem runing in k8s or somethings?
As helm chart is popular in kubernetes to deploy service，If can use helm install tdengine to install a cluster in kubernetes，that will be wonderful.
If possible，I can contribute helm chart and test it in my cluster.
https://github.com/taosdata/TDengine-Operator/tree/3.0/helm/tdengine
how about these two guys
https://docs.tdengine.com/deployment/helm/
it could help you on TDengine database K8s cluster with Helm
I am new to Helm Kubernetes. I am currently using a list of bash commands to create a local Minikube cluster with many containers installed. In order to alleviate the manual burden we were thinking of creating an (umbrella) Helm Chart to execute the whole list of commands.
Between the commands that I would need to run in the Chart there are few (cleanup) kubectl deletes, i.e. :
kubectl delete all,configmap --all -n system --force --grace-period=0
and also some helm installs, i.e.:
helm repo add bitnami https://charts.bitnami.com/bitnami && \
helm install postgres bitnami/postgresql --set postgresqlPassword=test,postgresqlDatabase=test && \
Question1: is it possible to include kubectl command in my Helm Chart?
Question2: is it possible to add a dependency from a Chart only remotely available? I.e. the dependency from postgres above.
Question3: If you think Helm is not the correct tool for doing this, what would you suggest instead?
Thank you
You can't embed imperative kubectl commands in a Helm chart. An installed Helm chart keeps track of a specific set of Kubernetes resources it owns; you can helm delete the release, and that will delete that specific set of things. Similarly, if you have an installed Helm chart, you can helm upgrade it, and the new chart contents will replace the old ones.
For the workflow you describe – you're maintaining a developer environment based on Minikube, and you want to be able to start clean – there are two good approaches to take:
helm delete the release(s) that are already there, which will uninstall their managed Kubernetes resources; or
minikube delete the whole "cluster" (as a single container or VM), and then minikube start a new empty "cluster".
I'm attempting to use a Docker Registry to host Helm charts (see https://helm.sh/docs/topics/registries/). We use Spinnaker to Bake the Helm charts and deploy the resulting manifest.
We have it set up so that the Helm chart is one of the Artifacts in the Configuration step of the pipeline. When we set it up so that we reference the helm chart in the docker image field using the format {host}/{org}/{imagename}:{tag} with the appropriate docker-registry's account selected we get an Failed on startup: Unmatched expected artifact ExpectedArtifact.
Are we approaching this the right way? Would Spinnaker even support pulling a Helm chart from a Docker Registry?
It seems plausible we could introspect the manifest of that Docker Registry entry, get the sha256 of the blob for the helm chart and directly call the docker-registry blobs endpoint (https://docs.docker.com/registry/spec/api/#pulling-an-image) but that seems very roundabout and not obvious which helm chart we're looking at.
This is totally possible and it might just be a configuration issue in how you've set up the pipeline. In your configuration stage you want to include the artifact and then have a bake from manifest stage before the deploy stage. Hopefully this link helps: https://spinnaker.io/guides/user/kubernetes-v2/deploy-helm/#configure-the-bake-manifest-stage and you can always reach out in https://spinnakerteam.slack.com/ for more help.
I deploy kong via helm on my kubernetes cluster but I can't configure it as I want.
helm install stable/kong -f values.yaml
value.yaml:
{
"persistence.size":"1Gi",
"persistence.storageClass":"my-kong-storage"
}
Unfortunately, the created persistenceVolumeClaim stays at 8G instead of 1Gi. Even adding "persistence.enabled":false has no effect on deployment. So I think my all my configuration is bad.
What should be a good configuration file?
I am using kubernetes rancher deployment on bare metal servers.
I use Local Persistent Volumes. (working well with mongo-replicaset deployment)
What you are trying to do is to configure a dependency chart (a.k.a subchart ) which is a little different from a main chart when it comes to writing values.yaml. Here is how you can do it:
As postgresql is a dependency chart for kong so you have to use the name of the dependency chart as a key then the rest of the options you need to modify in the following form:
The content of values.yaml does not need to be surrounded with curly braces. so you need to remove it from the code you posted in the question.
<dependcy-chart-name>:
<configuration-key-name>: <configuration-value>
For Rancher you have to write it as the following:
#values.yaml for rancher
postgresql.persistence.storageClass: "my-kong-storage"
postgresql.persistence.size: "1Gi"
Unlike if you are using helm itself with vanilla kubernetes - at least - you can write the values.yml as below:
#values.yaml for helm
postgresql:
persistence:
storageClass: "my-kong-storage"
size: "1Gi"
More about Dealing with SubChart values
More about Postgresql chart configuration
Please tell us which cluster setup you are using. A cloud managed service? Custom setup kubernetes?
The problem you are facing is that there is a "minimum size" of storage to be provisioned. For example in IBM Cloud it is 20 GB.
So even if 2GB are requested in the PVC , you will end up with a 20GB PV.
Please check the documentation of your NFS Provisioner / Storage Class
I am trying to implement the CI/CD pipeline for my microservice by using Jenkins, Kubernetes and Kubernetes Helm. Here I am using Helm chart for packaging of YAML files and deployment into Kubernetes cluster. I am now learning the implementation of Helm chart and deployment. When I am learning, I found the image name definition in deployment YAML file.
I have two questions:
If we only defining the image name, then it will automatically pull from Docker Hub? Or do we need to define additionally anything in the deployment chart YAML file for pulling?
How the Helm Tiller communicating with Docker Hub registry?
Docker image names in Kubernetes manifests follow the same rules as everywhere else. If you have an image name like postgres:9.6 or myname/myimage:foo, those will be looked up on Docker Hub like normal. If you're using a third-party repository (Google GCR, Amazon ECR, quay.io, ...) you need to include the repository name in the image name. It's the exact same string you'd give to docker run or docker build -t.
Helm doesn't directly talk to the Docker registry. The Helm flow here is:
The local Helm client sends the chart to the Helm Tiller.
Tiller applies any templating in the chart, and sends it to the Kubernetes API.
This creates a Deployment object with an embedded Pod spec.
Kubernetes creates Pods from the Deployment, which have image name references.
So if your Helm chart names an image that doesn't exist, all of this flow will run normally, until it creates Pods that wind up in ImagePullBackOff state.
P.S.: if you're not already doing this, you should make the image tag (the part after the colon) configurable in your Helm chart, and declare your image name as something like myregistry.io/myname/myimage:{{ .Values.tag }}. Your CD system can then give each build a distinct tag and pass it into helm install. This makes it possible to roll back fairly seamlessly.
Run the command below. It will generate blank chart with values.yaml, add key value pare inside values.yaml and use them in your deployment.yaml file as variable.
helm create mychart