Install multiple Kong ingresses using helm chart

I have found number of articles with instructions how to install multiple Kong ingresses each in it’s own namespace - all of them were using kubectl and custom YAML files.
Can the same be done using helm chart at ?

Yes, of course. What issue did you run into?

I want install two independent kong ingresses into k8s cluster - one for production and another for dev/test. I understand that in order to have multiple kong ingresses in one k8s cluster, I need to create separate service account and role for each of them and ingress controllers have to be deployed to separate namespaces.
But looking into Kong chart readme ( I do not see any parameter/value that I can use to control what namespace is Kong deployed to, whether it is assigned cluster or namespace rights. Could you please share an example of how to do this?

It does not depend on the Kong chart.
You can define a helm release like the following:

kind: HelmRelease
  name: kong
  namespace: your_namespace

Or if you are using helm to install, it should be

helm install --name kong --namespace your_namespace -f kong_values.yaml kong/kong
1 Like


I had exactlly the some problem and when i change the deployment args

 - args:
        - /kong-ingress-controller
        - --kong-url=https://localhost:8444
        - --admin-tls-skip-verify
        - --publish-service=**<namespace>**/kong-proxy

publish service need the namespace

1 Like

Thank you @flowdopip
could you please elaborate a bit of how you actually installed kong?

Did you just download the yaml file ( and modify the deployment args? What else did you modify in that yaml? I suppose you had to apply the yaml 2 times, once for ech namespace. right?

Or did you install kong using helm chart at How did you pass the modified args section to helm?

Thanks @dieunb
so if I want to use helm, do I just have to run helm install... once for each namespace?

Yes, that right @mkuna
But I highly recommend you do it by using the helm release file.
One helm release per namespace what you want. It helps you to be easy to tracking, changing and updating.

Thanks, will give it a try. Using helm release file sounds like a goo idea.

We’ll probably move towards allowing users to create releases that deploy the controller only in the future, for this and a few other use cases where it’s useful. As-is it works to configure the controller environment to talk to a Kong instance outside its pod, but no way to disable the Kong deployment without manually removing the template.

@traines This came up in another unrelated discussion as well. Let’s make sure we are tracking it internally. This structure will become more important as adoption of hybrid mode of Kong becomes mainstream.

@dieunb @flowdopip
Thank you for your help. I have successfully installed kong into “dev” namespace via helm chart at kong/kong. I had to also specify args mentioned by @flowdopip (via custom values file).

Just want to check one thing: If I want to have multiple kong ingress controllers, I need to specify unique ingress-class for each of them; the name of the class is then used when installing plugins to reference particular ingress controller like:

    annotations : : my-kong-1

Is that right?

@hbagdi @traines
It would be great if helm chart could use the namespace and release name to render the args when creating ingress controller:

- args:
   - --publish-service=<namespace>/<kong-proxy-name>

where <kong-proxy-name> is renerred as <release_name>-kong-proxy

You also need to annotate Ingress resources in addition to KongPlugin resources.

The chart already does that.