1. 17
  1. 7

    Lots of gotchas running NodeJS apps in k8s. Single threaded by default. There are cases were more than 1 CPU don’t make sense. One has to take care of signal propagation (using tini), drop root privileges, install modules as “node” user (to avoid introducing vulnerabilities as root), avoid starting the app via package.JSON commands & run “node /path/to/exec” via CMD to avoid bash (signal propagation…). I will add this info to my list :-)


    1. 5

      Yes, it’s a bit of a minefield! The signal propagation one is that has bitten me in the past, especially with the differences in how the RUN command in a Dockerfile work based on using the array syntax or not!

    2. 4

      Great info!

      I once saw a project that dynamically adjusted the number of processes/threads in the server in order to maximize request throughput using gradient descent… I wish that were easier to do…

      1. 4

        Yes, it’s a known problem that languages don’t respect the cgroup limits. AFAIK some languages do it correctly. Java for example does it automatically IIRC.

        1. 1

          Haproxy is affected by this. It will completely starve itself by starting 100s of worker threads and then get stuck in scheduling hell… But only after the concurrency goes above the number of allowed cores (plus how ever much buffer you have for connection wait and kernel buffers/network card buffers), so it’s a complete landmine. It degrades, then falls completely over. Slow lorising it’s clients all over the place.