I have a few microservices and one of them needs to use postreSQL. I configure this microservice using Helm 3.I have two different values.yaml per environments such as values.stage.yaml and values.prod.yaml.So my confusion is,
Should I independentyl install the PostreSQL? What I mean, in my scr code I have helm chart call helm/app. Should I create one more chart for PostreSQL? How can I configure the PostreSQL per environments.
2.In future, if one more microservice would like to use the same PostreSQL, what should I do to provide this feature.
Your chart should declare postgresql as a dependency, in Helm 3 in its Chart.yaml file. (In Helm 2 there was a separate requirements.yaml file.) You will need to run helm dep up (helm dependency update) before deploying your chart, but then when you run helm install it will install both your application and its database dependency.
So your Chart.yaml can look roughly like
apiVersion: v2
name: app
...
dependencies:
- name: postgresql
version: '^8'
repository: #stable
(In Helm 3 you also need to helm repo add the stable Helm charts repository.)
You can configure the database per environment in the same way you configure the rest of your application. Database settings would be nested under the subchart's name; at the command line you might --set postgresql.postgresqlPassword=..., and in a YAML file you'd put database settings under a postgresql: key.
If you have a second service that needs PostgreSQL, it should declare a dependency in the same way and install its own independent copy of the database. With database installation isolated inside containers this isn't considered particularly heavy-weight. If your two services need to communicate, they should do it via a network (often HTTP) connection and not by sharing a database.
By default, Helm picks values.yaml of root directory of the chart.
To install same Helm Chart with different values, you can do something like,
helm install . -f values.stage.yaml
Related
I have a few services running on a kubernetes cluster, and I use Helm Chart where I placed all my services. However, I was asked to transfer Helm Charts into Helmfile.
If I use
helmfile import myrepo/mychart
helmfile sync
Will it redeploy and substitute existing running pods or It will deploy just deploy additional services mentioned
Helm uses a packaging format called charts. A chart is a collection of files that describe a related set of Kubernetes resources. A single chart might be used to deploy something simple, like a memcached pod, or something complex, like a full web app stack with HTTP servers, databases, caches, and so on.
Helmfile is a declarative spec for deploying helm charts. It lets you...
Keep a directory of chart value files and maintain changes in version control.
Apply CI/CD to configuration changes.
Periodically sync to avoid skew in environments.
To avoid upgrades for each iteration of helm, the helmfile executable delegates to helm - as a result, helm must be installed.
Like #DavidMaze suggested, use helm diff command first to determine the changes and then use helm sync command for applying them.
I have multiple subcharts under one helm chart. I install those using the command
helm install my-app . --values values.dev.yaml
It is working fine. All subcharts are part of a one release. Now I have requirements that other member will be starting working those individual subcharts and want to upgrade their subchart without deleting/upgrading the entire application's subchats and in the same release
so when for upgrading one one say frontend subchart from it. I tried
helm upgrade my-app ./charts/frontend --values values.dev.yaml.
It will terminate all the other pods and will keep only pod for this subchart frontend running. Is there any way to upgrade only subcharts of the application without touching the other subcharts?
Just run helm upgrade on the top-level chart normally
rm requirements.lock
helm dependency update
helm upgrade my-app . -f values.dev.yaml
This will "redeploy" the entire chart, including all of its subcharts, but Helm knows to not resubmit unchanged objects to Kubernetes, and Kubernetes knows to not take action when an unmodified object is submitted.
Helm subcharts have some limitations; in addition to what you describe here about not being able to separately manage subcharts' versions, they will also flatten recursive dependencies together (if A depends on B depends on Redis, and A depends on C depends on Redis, B and C will share a single Redis installation and could conflict). If you need to separately manage the versions, consider installing the charts as separate top-level releases.
If your sub-charts are 3rd party dependencies (i.e. you are combining some charts together in a single chart), you can update the external charts by updating Helm dependencies:
Once in the Helm chart dir, where Chart.yaml lives, run
$ helm dependency update
To make sure you get the latest dependency, update Helm repos first:
$ helm repo update && helm dependency update
This will download the latest dependent charts (or the latest allowed, depending on your Chart.yaml config.
Please Note that helm dependency update will download txz files. If no action is taken (i.e. ignore them in git), they could end up version-controlled in your git repo.
Hi everyone,
I have deployed a Kubernetes cluster based on kubeadm and for the purpose of performing HorizontalPodAutoscaling based on the Custom Metrics, I have deployed prometheus-adpater through Helm.
Now, i want to edit the configuration for prometheus-adpater and because i am new to Helm, i don't know how to do this. So could you guid me how to edit the deployed helm charts?
I guess helm upgrade is that are you looking for.
This command upgrades a release to a specified version of a chart and/or updates chart values.
So if you have deployed prometheus-adapter, you can use command helm fetch
Download a chart from a repository and (optionally) unpack it in local directory
You will have all yamls, you can edit them and upgrade your current deployed chart via helm upgrade
I found an example, which should explain it to you more precisely.
You're trying to customize an installed chart. Please use this guide Customizing the Chart Before Installing.
The key parts:
There are two ways to pass configuration data during install:
--values (or -f): Specify a YAML file with overrides. This can be specified multiple times and the rightmost file will take precedence
--set name=value: Specify overrides on the command line
There are a couple more ways to customize a Helm Chart values:
You may create a file with defined config and then helm install my-app [chart] -f /path/to/myconfig.yaml
As an example for a config file, please refer, for example, to redis one.
The second one is to check for the files the helm repo add or helm repo update create. You may check with helm env the variable HELM_REPOSITORY_CACHE that shows where those files are.
Untar the chart and look for the values config file or even go to the Kubernetes manifests /templates for a more in-depth customization. Then, install the chart.
I am just wondering if anyone has figured out a declarative way to have helm charts installed/configured as part of a cluster initiation and that could be checked into source control. Using Kuberenetes I have very much gotten used to the "everything as code" type of workflow and I realize that installing and configuring helm is based mostly on imperative workflows via the CLI.
The reason I am asking is because currently we have our cluster in development and will be recreating it in production. Most of our configuration has been done declaratively via the deployment.yaml file. However we have spent a significant amount of time installing and configuring certain helm charts (e.g. prometheus, grafana etc.)
There a tools like helmfile or helmsman which allow you to declare to be installed Helm releases as code.
Here is an example from a helmfile.yaml doing so:
releases:
# Published chart example
- name: promnorbacxubuntu # name of this release
namespace: prometheus # target namespace
chart: stable/prometheus # the chart being installed to create this release, referenced by `repository/chart` syntax
set: # values (--set)
- name: rbac.create
value: false
Running helmfile charts will then ensure that all listed releases are installed
My team had a similar kind of problem and we solved it with Operators. And the best part about of Operators is that there are 3 kinds and one of them is Helm based.
So you could use a Helm Based Operator , create an associated CRD and then declare your configurations there. Those configurations are then ported directly to the Helm chart without you, as the user, having to do anything.
My helm depends on another helm from public repository. I've installed it manually and put the command to documentation. But I'd like to do it automatically.
Is there some way to set such dependencies?
You may take a look on helm chart dependencies with requirements.yaml
And as an example - Kafka helm chart with zookeeper dependency.