I have an application "A" which requires postgres database. Once I deploy the helm chart it deploys the child dependent chart postgres.
helm install application_A -n mynamspace ./applicationA-0.1.0.tgz
Now I have another application "B" which also requires postgres database. I wish to deploy the application B in the same namespace but it should not deploy new postgres POD as it is already available from Application A's deployment.
helm install application_B -n mynamspace ./applicationB-0.1.0.tgz
It fails with the following error -
Error: INSTALLATION FAILED: rendered manifests contain a resource that already exists
I want helm to recognize that the dependency of application 'B' is already deployed with the desired version and hence it should automatically avoid deploying the dependent chart.
I am aware of conditional deployment of subchart. It requires me to find out what is already available using shell script to toggle the condition while deploying Application B.
Is there any way in helm to automatically avoid deploying subchart if it is already deployed?
helm version - v3.8.0
Ideally there should not be any relation between two helm release installations. Each helm installation would always try to install their components. Here, it could be failing because of the hardcoded name of resource. Just for your use case, you can use helm in-built lookup function to see if resource exist do not create.
link:
https://helm.sh/docs/chart_template_guide/functions_and_pipelines/#using-the-lookup-function
Related
lately I was experimenting with Skaffold with our Helm Charts and I am in little bit in a dilemma that our Helm Chart \ Sub Charts are compatible with Skaffold or not.
Our helm Charts are looking like the following
my-helm-charts
+-charts
+-project1
+-project2
+-project3
+-project4
+-infrastructure_kafka
+-charts
+-kafka
+-zookeeper
+-infrastructure_cassandra
+-infrastructure_elasticsearch
+-Charts.yaml
+-Values.yaml
The reason we choosed to structure the Helm Charts this way, is that if necessary to spin up extra stages for our project.
Now when I want to develop project2 with Google Cloud Code / Skaffold (which I configured correctly and I can start without problem in IntelliJ) I have to start whole my-helm-charts.
That is actually Ok but the problem is, if I use Debug in Kubernetes, I have a feeling Google Cloud Code/Skaffold can really locate the project2 and no debugging occurs.
My feeling is Google Cloud/Skaffold is more oriented to work with following contruct...
project2-helm
+-templates
+-Charts.yaml
+-Values.yaml
My Subcharts contructs starts in Google Cloud Code/Skaffold without any exception but I can't debug, is it possible to achieve want I want with my structure and if yes, how?
Or is it not possible at all...
Thx for answers...
We recently added a feature called config dependencies which might help here. It allows you to create more specific skaffold.yamls and then map them together with a "requires" field:
https://skaffold.dev/docs/design/config/#configuration-dependencies
Once you have the skaffold.yamls created and the right dependency mapping you can run skaffold with the -m flag to choose once slice of your services:
skaffold dev -m project3
Cloud Code support for modules is incoming.
Cloud Code IntelliJ and Cloud Code VS Code recently added preview level support for deploying and debugging modules of a larger application which uses Skaffold. See more here https://cloud.google.com/code/docs/intellij/skaffold-modules
I am very new to Helm and Kubernetes. I have a use case where, whenever there is a helm upgrade
helm upgrade xxx --values yy.yaml
I need to trigger invocation of a method in my docker image which is deployed onto the kubernetes pods ,so that i can work on the changes encountered in yy.yaml in the image code . Do we have some way of doing it ? Please help me here.
Though your problem is not clear to me but i think, You can use helm hook to do the same thing. Please check documentation.
You can certainly use pre-upgrade hook to invoke your function.
I am using helm built in object 'Release.isUpgrade' to ensure an init-container is only run at upgrade.
I want to only run the init-container when upgrading from a specific Chart version.
Is it possible to get the 'from' Chart version in a helm upgrade ?
It doesn't look like this information is published either in the .Release object or through information available to a hook job.
You probably want a pre-upgrade hook and not an init container. If you have multiple replicas on your deployments, the init container will run on all of them; even if you have just one, if the node it's on fails and is replaced, the replacement will re-run the init container. A pre-upgrade hook will run just once, regardless of how the corresponding deployments are configured.
That hook will be a separate pod (and will require writing code), so within that you can do whatever you want. You can give it read access to the Kubernetes API to get the definition of an existing deployment, for example, and then look at its labels or container image tag to find out what version of the chart/application is running now. (There are standard labels that can help with this.) You could also make the upgrade step just look for its own outputs: if object X is supposed to exist, create it if it's not there, without focusing on specific versions.
I have just started experimenting with Helm kubernetes package manager.
But chart vs template topic seems a bit confusing to me.
I understand that by template I will create kubernetes yaml, which will create the objects and install them.
However the same is true for charts as well, but this latter is an abstraction over the yamls. And ./Charts containns standalone charts, while ./templates is valid only for the base chart. So I know that. But when should I include an other chart or just create a template?
Looking for different kind of charts through the web I still don't know which to use.
Say I have a project called MyApp, which has one component named MyServer which will communicate to MySql.
So I created a chart and put in it MyServer as a template :
./MyApp/templates/MyServer.yaml
What should I do with MySql?
I have seen both solutions in different projects, one just creates an other template:
./MyApp/templates/MySQL.yaml
on other project I saw a chart for MySql from a chart repository:
./MyApp/charts/mysql-version.tgz
On the top of that I have seen a bigdata project (hdfs,kafka,zookeeper,ELK,oracle db..etc) and one component was included as chart in ./charts other was created as a template in./templates.
This whole decision between chart and template seems random and confusing to me.
Could you explain it please when to use which?
A chart is a collection of templates, plus a little extra information like the metadata in the Chart.yaml file and the default values.yaml. In your example, MyApp is itself a chart.
For well-known dependencies (particularly things in the Helm charts repository and especially the stable charts) you're probably better off using the external chart; declare the dependency in your requirements.yaml or (Helm v3) Chart.yaml file and run helm dependency update. This lets you import the chart with two lines, rather than reproducing the StatefulSet, PersistentVolumeClaim, etc. that are included in the chart.
So, is it possible to share the same pod among helm packages with a common reference. Example:
Scenario:
Package A
...
- requirements.yml
require: C
Package B
...
- requirements.yml
require: C
When I run:
helm install A
helm install B
These two pods for A and B project use the same C pod.
Is it possible? Theres a documentation to help me with that?
PS: The C package in my case is a broker, but both A & B package can be deployed separately.
This should work fine with Helm. A little bit of background here. One key aspect here is update:
created/updated in that order.
When you update an object, i.e, kubectl apply on a Pod/Deployment/Service/etc if the object exists it won't be changed, so you'll end up with the same object in the end.
Also, Kubernetes objects with the same name use the idempotency principle:
All objects will have a unique name to allow idempotent creation and retrieval
In your example:
helm install stable/packageA => which also installs PackageC
helm install stable/packageB => will update PackageC, but it's already present and won't change.
You have to make sure that the dependencies for PackageA for PackageB are exactly the same version of PackageC.