Correct way of using Kong with Helm in production

Questions
1

Hey,
I’m trying to understand what is the right way of configuring Kong with Helm in production environments. All examples use kubectl apply -f ..., and I’m trying to understand how to create a configuration that will always be loaded when starting the Helm. Should I create my own Helm Chart and depend on Kong? Should I use Kustomize?

Thanks!
Nir

2

Hey,
I’m still pretty green on Kong and do not have an instance in production, but my sentiment has been to install Kong using the official chart, and then also create your own ‘local’ helm chart containing all your cluster wide KongClusterPlugin, KongCredential, etc CRDs. If you will using Redis load balancing then that would likely be a third Helm chart. So you might end up with a small collection of Helm charts to fully describe Kong. (You could of course do subcharts too…)

Good luck, don’t forget to report back when you have something you like :slight_smile:

3

Kong official helm chart

Above chart is what you would use to install/upgrade kong on your cluster.

And now to configure your services, routes , plugins etc you could use kubectl apply from your CI/CD pipelines or you could create helm charts for those as well.
Hope this helps

4

Thanks! But that’s exactly what I asked. I know how to run the Helm chart and do the configs. I wondered what’s the recommended way to define the other components of a deploy (like a config map with a custom plugin). Is it another Helm chart that wraps Kong?

5

I don’t really have any recommendations around how you wrap it. It depends what toolset and resource skill set you already have in your team. Some customers go helm with wrapper chart which configures configmap, secrets etc while others use kubectl to create those and use the output in the helm chart. So it just depends what you prefers and works better for your team. If your a helm shop you could go helm for all the pieces.