Advice on moving containerised apps to kubernetes architecture

Hi,

We have a containerised Cloud IDE (Theia NodeJs Express App).
We have a containerised Landing Page (NodeJS Express App) which upon logging in spins up a Cloud IDE Container for the user , and redirects it to the Cloud IDE Container which is now running.
User Work File Persistence is done via a mounted file system
I currently do this via Docker Engine API and it works.

Now how do we integrate this into Kubernetes world which is being introduced into the ecosystem in parallel to my work. I assume the Landing Page App is a pod which can be scaled if necessary. The Cloud IDE app is a bit confusing, because you really want a user to stick the the same container running on a node, until the container dies/expires/sleeps after not being used for a while.
Also , how should the Landing Page App manage creating a pod for a user. Should it just use the Kubernetes API or Rancher API, or is there some better way of orchestrating this.

Would greatly appreciate input from experienced people.

Thanks in advance

It really depends, I think, if the lifecycle of the user ide session is tied to the container the landing thingy creates or not.

If it’s tied, you need to only have one running container for that or can you have more than one? Or what would happen if that container crashes (or the node where that is running crashes)? If a crash is acceptable downtime till the container gets started on some other node, then I think you might be fine. You can do something like the following:

The landing thing uses the kubernetes API to create a pod running that. That can create a deployment, with one replica only, and a service for your landing app to connect (using a service, even if the pod/node running die, it will be created on some other node and the service IP is the same, just routes traffic to the new pod).

The pods can have several containers and communicate over the network on localhost, for example, so you can have a container that interacts with the kubernetes API in the same pod but can be easily replaced with another as long as it keeps its API to the other containers in the pod.

And to answer your question, you definitely want to use the kubernetes API for this. Take a look at kubectl for easy prototypes, but also for sample kubernetes controllers and, maybe also, kubernetes operators.

It really depends on the details which of these are more useful in your case. But there is a big and growing ecosystem to support these uses :slight_smile:

1 Like

Thats really useful.

A follow up question. As my Landing Page pod creates new deployments for each user with for example a container image theia-ide:qa. Is there an object I can create that will group those user deployments ? For example to be able to do an update of the image used by all those deployments by bouncing all of them as a group so they pick up the latest theia-ide:QA tag. Or is deployment the highest level of grouping and am I basically doing this type of management ad hoc using scripts that use kubectl iterating over the deployments and bounce them individually.

Thank you

As a side note, you may want to use clear tag names for your images and not things as latest, as it can cause several issues.

Not sure I follow, do you create more than one deployment per user?

To group them, there are several things you can do. But, basically, the short answer I think is “no”.

You can use labels or annotations, kubernetes API has great support to query with those. But, yeah, you will have to update them (kubectl is your friend here, too, or client libraries).

Or you can use a namespace, but not sure that makes sense in your context and I wouldn’t try to use them if they doesn’t fit.

Thanks for the advice on tags

No I meant one deployment per user. Let’s say I have 50 users having a pod each running their ide. I want to upgrade the underlying image tag. Do I write a script that bounces each pod? Or is there some object or mechanism which can manage a set of deployments and bounce them.

What would your approach be ?

Modify them all with the new image. Maybe canary releases or something similar to avoid issues, but basically you need to modify them all. There is no way around it as long as you have so many deployments, as far as I know