K
Q

Deploying multiple version of a single application with Helm in the same namespace

7/2/2021

I have a situation where i have an application for which i would like to run several set of instances configured differently. I guess from readying online, people would usually having several version of the same application in your clusters.

But let me somewhat describe the use case at the high level. The application is a component that takes as configuration a a dataset and a set of instructions stating how to process the dataset. The dataset is actually a datasource.

So in the same namespace, we would like for instance process 2 dataset.

So it is like having two deployments for the same application. Each dataset has different requirements, hence we should be able to have deployment1 scale to 10 instance and deployement 2 scale to 5 instance.

The thing is it is the same application and so far it is the same helm chart, and deployment definition.

The question is what are the different options that exist to handle that at this time.

examples, pointers, article are welcome.

So far i found the following article as the most promising:

https://itnext.io/support-multiple-versions-of-a-service-in-kubernetes-using-helm-ce26adcb516d

Another thing i though about is duplicating the deployment chart into 2 sub-charts of which the folder name differ.

-- MaatDeamon
kubernetes
kubernetes-helm

Similar Questions

Kubernetes: expose multiple containers using service and ingress with static ip
Kubernetes nginx-ingress how to deal with routing in Express
How to start kafka on kubernetes
How to resolve "-bash: kubeless: command not found" issue in Google Kubernetes Engine?
Spark - Master: got disassociated, removing it

2 Answers

7/3/2021

You can "cascade" the values YAML files to achieve what you want. For example, you could define common.yaml to be all the common settings for your application. Then, each separate instance would be a second YAML file.

Here is an example. Let's say that the file common.yaml looks like this:

namespace: myapp-dev
pod-count: 1
use_ssl: true
image-name: debian:buster-slim
... more ...

Let's say you want two Deployments, own that scales to 5 replicas and one that scales to 10. You would create two more files:

# local5.yaml
pod-count: 5

and

# local10.yaml
pod-count: 10

Note that you do not have to repeat the settings in common.yaml. To deploy the five-replica version you do something like this:

$ helm install -f common.yaml -f local5.yaml five .

To deploy the 10-replica version:

$ helm install -f common.yaml -f local10.yaml ten .

The YAML files cascade with the later file overriding the earlier.

-- rlandster
Source: StackOverflow
7/2/2021

Helm supports this pretty straightforwardly.

In Helm terminology, you would write a chart that describes how to install one copy of your application. This creates Kubernetes Deployments and other manifests; but it has templating that allows parts of the application to be filled in at deploy time. One copy of the installation is a release, but you can have multiple releases, in the same or different Kubernetes namespaces.

For example, say you have a YAML template for a Kubernetes deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-processor
spec:
  replicas: {{ .Values.replicas }}
  template:
    spec:
      containers:
        - env:
            - name: DATASET_NAME
              value: {{ .Values.dataset }}
          # and the other things that usually go into a container spec

When you go to deploy this, you can create a values file:

# a.yaml
replicas: 10
dataset: dataset-1

And you can deploy it:

helm install \
  one        \ # release name
  .          \ # chart location
  -f a.yaml    # additional values to use

If you use kubectl get deployment, you will see one-processor, and if you look at it in detail, you will see it has 10 replicas and its environment variable is set to dataset-1.

You can create a second deployment with different settings in the same namespace:

# b.yaml
replicas: 5
dataset: dataset-2
helm install two . -f b.yaml

Or in a different namespace:

helm install three . -n other-namespace -f c.yaml

It's theoretically possible to have a chart that only installs other subcharts (an umbrella chart), but there are some practical issues with it, most notably that Helm will want to install only one copy of a given chart no matter where it appears in the chart hierarchy. There are other higher-level tools like Helmsman and Helmfile that would allow you to basically describe these multiple helm install commands in a single file.

-- David Maze
Source: StackOverflow