Investigate the websocket pool max limit

[ashu8912]

#1247

WebSocket's in web browsers typically have a connection limit imposed by the browser to prevent excessive resource usage. Major browsers like Chrome, Firefox, and Safari usually allowed around 6 to 13 simultaneous WebSocket connections per domain, with variations depending on the browser and version. With a limit of 200 overall WebSocket connections for the whole browser.

On headlamp we use WebSocket connections at various places such as listing pods, namespaces, the exec API, the attach API etc. And if we use a plugin that relies heavily on something as simple as exec the user is likely going to run into a problem of opening up many different socket connections for the same exec URL, in such cases we should look for ways to optimize the socket request and only create one socket connection for same URL exec.

This is only a problem if the max limit of WebSocket connections that can be opened at a time in browser is very low (in range of 5-6), we should investigate how different browsers have this max limit set and look for places in headlamp where the WebSocket connection can be optimized.

Multi-cluster / multi namespaces

If on the node list view we are looking at multiple clusters, then it will need one WebSocket per list of nodes. This will easily use up the total amount of 6 WebSocket's per domain.

What about plugins and multiple clusters? We don't have a use case for this right now, but it is likely with a multi-cluster view then plugins would want to operate on multiple clusters at once.

Kubernetes WebSocket API

The Kubernetes API doesn't allow efficient reuse of WebSocket's, because WebSocket's use a URL and Kubernetes uses a separate URL for each resources.

Inspektor Gadget and WebSocket

Efficient handling of limited WebSocket's can't really be done at the Browser side, because if you are running several gadgets with one WebSocket each then that goes over the browser limit.

[knrt10]

Looking into this

[illume]

We have investigated this and have a way forward.

The result:

• We need tests to confirm the behaviour (in progress)
• We need to multiplex the websocket connections (@knrt10 has additionally investigated this) see multi-plexing single browser websocket to multiple backend websockets #1802
• We can limit the amount of clusters used in multi cluster view to 3 until websocket multiplexing is done
• websockets are not supported on some proxy servers used in corporate environments, to support the realtime features we need to fallback to polling, or not provide realtime updates