Mqttboard problems on Kubernetes

Hi,

We’ve been looking into setting up Docker Hub on Kubernetes for evaluation.
While everything seems to work with a custom made Helm chart, mqttboard fails to come up with the following error:

Serving files from /opt/http/content at http://192.3.91.125:80/

If you have a problem with port blocking in a browser, see the class header
in SimpleHttp.java. You can always use curl, too.

Exception in thread “main” java.net.BindException: Permission denied
at java.base/sun.nio.ch.Net.bind0(Native Method)
at java.base/sun.nio.ch.Net.bind(Net.java:552)
at java.base/sun.nio.ch.Net.bind(Net.java:541)
at java.base/sun.nio.ch.NioSocketImpl.bind(NioSocketImpl.java:643)
at java.base/java.net.ServerSocket.bind(ServerSocket.java:395)
at java.base/java.net.ServerSocket.(ServerSocket.java:281)
at java.base/java.net.ServerSocket.(ServerSocket.java:172)
at server.QueryListener.run(QueryListener.kt:40)
at MainKt.main(Main.kt:101)

I tracked this down to “java -jar $HTTP_DIR/simples-all.jar -i -p 80 $HTTP_DIR/content / &” in “/opt/waterstream-kafka/devbox.sh”.

Attempting to run the script manually results in the same error as above:

bash-4.4$ java -jar /opt/http/simples-all.jar -i -p 80 /opt/http/content / &
[2] 2602
bash-4.4$
Serving files from /opt/http/content at http://192.3.91.125:80/

If you have a problem with port blocking in a browser, see the class header
in SimpleHttp.java. You can always use curl, too.

Exception in thread “main” java.net.BindException: Permission denied
at java.base/sun.nio.ch.Net.bind0(Native Method)
at java.base/sun.nio.ch.Net.bind(Net.java:552)
at java.base/sun.nio.ch.Net.bind(Net.java:541)
at java.base/sun.nio.ch.NioSocketImpl.bind(NioSocketImpl.java:643)
at java.base/java.net.ServerSocket.bind(ServerSocket.java:395)
at java.base/java.net.ServerSocket.(ServerSocket.java:281)
at java.base/java.net.ServerSocket.(ServerSocket.java:172)
at server.QueryListener.run(QueryListener.kt:40)
at MainKt.main(Main.kt:101)

Same occurred with port 81 for example.

Remapping the default mqttboard port 80 and containerPort 80 to something a bit more random, like 3123, results instead in the following error stream:

bash-4.4$ java -jar /opt/http/simples-all.jar -i -p 3123 /opt/http/content / &
[3] 2630
bash-4.4$
Serving files from /opt/http/content at http://192.3.91.125:3123/

If you have a problem with port blocking in a browser, see the class header
in SimpleHttp.java. You can always use curl, too.

Protocol error: “PROXY” unrecognized
Protocol error: “PROXY” unrecognized
Protocol error: “PROXY” unrecognized
Protocol error: “PROXY” unrecognized
^C
bash-4.4$ Protocol error: “PROXY” unrecognized
Protocol error: “PROXY” unrecognized
Protocol error: “PROXY” unrecognized
Protocol error: “PROXY” unrecognized

Looks to me like either the webserver application isn’t playing nicely with Kubernetes networking, or there are some other services utilizing port 80 somewhere that I missed, that the webserver uses.

Any ideas what could be causing this issue and if/how it could be resolved?

Hello. It appears that Kubernetes doesn’t like ports below 1000. In the future releases of Waterstream we’ll make devbox HTTP port configurable. In the meantime, you can deploy MQTT Board (GitHub - flespi-software/MQTT-Board: Diagnostic-oriented MQTT client tool. Supports MQTT 5.0 and 3.1.X protocols, connections to multiple brokers, MQTT operations logs and multiple subscribe widgets with unique/history topic filtering mode. Saves configuration in browser's local cache.) in a separate HTTP server and point it to MQTT WebSocket port of Waterstream (9001)

Hi Paul,

Thanks for the input! Will be looking into the temporary solution you suggested.

Does sound like that’s definitely a part of the issue, but I am still trying to understand why seemingly random ports like 3123, 8123, etc. prompt “Protocol error: “PROXY” unrecognized” when the containerPort is also exposed.

This does not occur if the webserver is launched on a non-exposed port, but only if the containerPort is exposed for traffic, which makes me think the webserver has some compatibility issues with Kubernetes other than the port range.

Hi @suislab, welcome to the Watestream forum!