0

I am new to docker/contaners etc. I have a node server running on a metal machine on port 8080. I have NginX running as a reverse proxy for it.

The application establishes a web socket per client connected, to facilitate real-time chat. At the moment, the websocket map is in-process, which means that I cannot scale to multiple processes (yes, I know, lame); however, I will need to update the architecture so that I allow users to communicate with other users even if they are connected to websockets on different processes.

The database is Mongo.

The question is: what would this look like if I were to port it to Kubernetes? What would it replace, and how? Would I still use NginX? Or would Kubernetes provide a way to act as reverse proxy? If I did that, would that mean that I would be able to deploy my app anywhere, and just see it work? Would the app container include the whole CentOs/Node/etc. stack?

0

Kubernetes would let you have a fleet of metal machines, which it would treat as a cluster. On top of the machines in the cluster, it would handle scheduling an autoscaled number of stateless node websocket servers, using kubernetes objects called Pods and ReplicaSets.

There is a kubernetes object called Ingress, which in most cases is nginx under the hood, and could replace your existing nginx.

You could run mongo in kubernetes as well. Mongo wants to store data on local disk. Doing that is more complicated in kubernetes, but possible.

To handle the websocket state map, you could run redis in kubernetes, though again kubernetes expects the applications it runs to be stateless, and movable to any node in the cluster. Or, it expects the application to have its own cluster model with leader election and durable data synchronization.

If you did all that architectural work and prepared all of that kubernetes configuration, then you could deploy the whole system of applications on anyone's kubernetes cluster.

A tool called Helm https://helm.sh/ is in the business of collecting kubernetes object configurations into packages, enabling that sort of convenience.

In each app container typically lives an OS, runtime-specific libraries, and then the application itself. Many people use container lineages that have minimal OSes, rather than a full distribution, e.g. with a lot of userland command line tools, since one does not usually ssh or shell into a container.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.