[stable/Kong] Can't use plugins present inside Custom Kong Image

[mukgupta]

Is your feature request related to a problem? Please describe.
We use a custom docker image for Kong in which we add some custom plugins. We were using Kong helm chart version 0.10.0 so far and used to enable those plugins by setting the environment variable KONG_PLUGINS=bundled,custom_plugin1,custom_plugin2 etc. In the latest version of helm chart (0.26.0), custom plugins are supposed to be mounted via configmaps/secrets which breaks our workflow. If we set the plugins variable to {}, default value of KONG_PLUGINS becomes bundled which disables our plugins

Describe the solution you'd like
We can have some variable inside current plugins map, that lets us specify the plugins inside the docker image

Additional context
Because of the way things are setup in our organization, we have to use a custom docker image and cannot move the plugin code to configmaps

[hbagdi]

@mukgupta

Can you use env section to set your plugins?

env:
  plugins: bundled,custom_plugin1,custom_plugin2

Anything defined in env takes precedence over the defaults that are populated by the chart.

[mukgupta]

@hbagdi : I tried this, but it doesn't seem to work. It creates two environment variables by the name KONG_PLUGINS one with value bundled and the other bundled,custom_plugin1,custom_plugin2. The first one is taking precedence since inside the container, value of KONG_PLUGINS is bundled

[rainest]

@mukgupta when I've tested, defining the same variable twice (once in env and once elsewhere) does do this, but the second definition (from env) takes precedence when configuration is read. This may not be true in all environments, and doesn't appear to be in yours. What flavor of Kubernetes and what Kong distribution are you using?

For the issue at hand, are you able to define your custom plugins using the plugins section of values.yaml, using an empty configmap for each? That should get the correct list in the first value, while effectively ignoring the normal requirement to store the plugin in a configmap. That system uses its own /opt/kong/plugins/ directory, so it shouldn't conflict with anything in the standard Kong plugin path.

Later on we'll probably want to look at adding an option to assume the plugin is already present in the image and doesn't require an additional configmap.

[mukgupta]

@rainest : I am using EKS 1.13 and Kong 1.1.2-alpine docker image.
The solution you are suggesting should work but seems bit hackish. For now, our requirements will be met by version 0.21.1 of this chart, since our main goal was to upgrade to ingress controller 0.6

[rainest]

Looks like we'll need to find some better way of handling the env overrides (maybe a helper to check for an env value and use it if present) regardless, since the existing behavior is officially undefined (apparently implementation-dependent) and Kubernetes ultimately intends to disallow the duplicates altogether based on past discussion in kubernetes/kubernetes#65106 (comment)

[felippe-mendonca]

I also had notice this behavior after update the chart. By the way, I didn't have problems with custom plugins being not enabled. However, kubernets had complaint when patching the deployment, some thing regards the order of environment variables. Maybe we should have another way of defining plugins list, in order to ensure only on entry of KONG_PLUGINS environment variable. My suggestion:

• If plugins are listed on .Values.plugins, plugins field on .Values.env will be discarded.
• Include an entry on .Values.plugins named preInstalled, such as:

plugins:
  configMaps:
  - pluginName: rewriter
    name: kong-plugin-rewriter
  secrets:
  - pluginName: rewriter
    name: kong-plugin-rewriter
  preInstalled:
  - foo
  - bar

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.

[rainest]

/unstale

[zffocussss]

I have this issue,as well

[hbagdi]

I just merged in Kong/charts#4 which should fix this problem.
Please use Chart version 1.1.0 form the Kong charts repo.

[rainest]

Note that the PR above ensures that user-provided env values always take precedence. That overrides any values that would normally be generated by the plugins block: if you're using Secret or ConfigMap plugins there also, you'll need to add their names to your value in the env block.

Coming soon should be rainest/charts-citest@594163d also, which extends the existing plugins block with a new inImage class. These are effectively just additional plugin names tacked onto the list generated from any Secret/ConfigMap plugins, and should make using both at once simple.

[hbagdi]

Please close this issue. If problem persists or there is another issue, please open a new one at https://github.com/kong/charts.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.

[stale]

This issue is being automatically closed due to inactivity.