Kong on kubernetes websocket problem

Hi everyone.
I have installed Kong as ingress controller in Kubernetes to expose microservices.
There is 1 specific microservice, which uses websockets and this is the one that is giving me problems. Kong is rejecting websocket connections for some reason, I have installed the cors plugin, but I still can’t establish the connection.
In local the service works perfect, I can connect without problems. But when I upload it to production and put it behind Kong, when accessing the necessary route for the connection to the websocket, it rejects the connection and does not reach the service pod. While if I use one of the http endpoints of the same service, they work perfect, I only have problems with the websocket.
What problem may be happening in my case? I’ve been trying to fix it for a while but I don’t find much information.

What is the error you receive from Kong?
If you disabled the CORS plugin, does it work?

Iam trying to find any logs for the error. But i cant found anything.
I follow logs of proxy pod with this:
kubectl -n kong logs -f --tail=10 pod/ingress-kong-9994d9749-tpwkr proxy

but dont say anything about the requests.
this is the output:

Where i can find more Kong logs to see the request info?

Also i disabled the CORS plugin, but its still wrong.

Can you use Kong 1.3.1 and test this?
You might be running into https://github.com/Kong/kong/issues/5465.

Can anyone share an example of using websockets with kubernetes ingress controller (just the rough idea, i just need a starting place)? There is no mention of websocket in the kubernetes-ingress-controller/docs :slightly_frowning_face:

@thatbenguy Hi did you solve that issue? can you share it? Thanks

HI @Marcos , In classic kong fashion this really “just works” but there are no docs telling you how to do it and so several hours of sifting through code and bug reports is necessary to get you where you need to be. :unamused:

Anyways, simply put, you just need to wire up the routes to your websocket service as if it were a standard https endpoint, and set the redirect status code to 426.

In my case this means configuring a k8 ingress with the regular kong annotations in addition to the special 426 redirect status code:
from my values.yaml (helm chart deployment)

    kubernetes.io/ingress.class: "kong"
    konghq.com/https-redirect-status-code: "426"
    konghq.com/protocols: https
    konghq.com/strip-path: "true"

My websocket service is then configured to operate over regular http and all seems well.

The deeper details of how this works are still buried in code, but it seems they simply added code to the core server to be able to handle http upgrades and thusly accommodate websocket connections by responding with the correct headers and keeping the connection open. Testing is still underway on my end, but so far it works :man_shrugging: