Two Releases of Kong Ingress Controller Helm Chart

Kubernetes
1

Hi Kong folks,

We have a use-case where we need to open up multiple HTTP listeners on Kong proxy with different configuration. Our use-case requires plain-text listeners using HTTP1.1 and HTTP2 protocol. Nginx does not support using both protocols on same listener as seen here.

Unfortunately, Kong Ingress Controller Helm chart does not support this, proxy.http.servicePort takes in a string, similar to this. Adding support for multiple servicePorts per service is a bit cumbersome since Kong chart uses the same configuration for many components, not only the HTTP proxy.

To get around this limitation we decided to deploy two instances of Kong Helm chart with different proxy.http.servicePort values. Each deployment of Kong has two proxy listener ports with two corresponding NodePorts that get traffic direct from an NLB, which in turn redirect traffic to the proxy listener port depending on the port specified in the request URL. The two Kong deployments are of the same class and should both satisfy all Ingress records.

For example:

  • dummy.com:80 (HTTP1.1) → NLB port 80 → NodePort port 30000 → kong-proxy1 Service → kong-proxy1 container HTTP1.1 listener
  • dummy.com:433 (HTTPs) → NLB port 433 → NodePort port 30001 → kong-proxy1 Service → kong-proxy1 container HTTP2+ssl listener
  • dummy.com:3001 (HTTP2) → NLB port 3001 → NodePort port 30002 → kong-proxy2 Service → kong-proxy2 container HTTP2 listener
  • dummy.com:3002 (HTTPs) → NLB port 3002 → NodePort port 30004 → kong-proxy2 Service → kong-proxy2 container HTTP2+ssl listener

The deployment seems to be working as expect so far on our development environment.
My questions are:

  1. As this setup is a bit unorthodox, do you see any obvious issues?
  2. Could this setup lead to unforeseen race cases?

Thank you,

Fares

2

Multiple instances handling the same Ingress resource will both try to update its status, and the Ingress will only report one or the other’s listener. That may not be an issue since the status by itself is just informational–it could become one if you have something else that needs to use that information, however. The only way around that would be creating copies of each Ingress with a different class and configuring each instance to use that.

The chart configuration is designed to simplify the configuration required to set up ports across the Deployment, Service, and Kong listen string configuration at the cost of flexibility. However, you can override the proxy listen it normally generates by setting env.proxy_listen and edit the Deployment an Service ports after creating the release: Helm 3’s diff algorithm will preserve those through upgrades, though you’d need to redo the edits if you delete and re-install. That’s cumbersome, but it will work in a pinch to override the normal auto-generated content without forking the templates.