Kubernetes for Mir 2

I originally started this in another topic and it kept editing it and gradually built it up to this point so I decided to move it here. Your all welcome to give input (if you know kubernetes or not). I know very little so it is pretty much all theory based at the moment.

i've recently been exposed to kubernetes through work, I've not looked into it too much however i'll probably do some more reading around it soon.

I think the general concept is that you can have a cluster which holds one or many pods. The pod(s) are your application(s) (e.g. in our case server.exe?!) and they are run synchronously sharing the load. If one goes down the others will continue to run without any issues.

So this was for @Far (bit in bold)
How do you think the server would cope in it's current state using kubernetes and how much work do you think it would take to get it to a standard that allows it to run synchronously smoothly and error free?

Would love to work with this more for personal projects outside of work to familiarise myself with it and understand how it works. I may get some training if I request to sit in on it at work however I'm only a newbie so depending on budget/ spaces I may not. This is currently the only thing I work on outside of work that I could consider experimenting with using kubernetes (and maybe a reactive website when/if i get around to starting it).

I guess I could start up another project but first i'd have to find something I want to work on. In terms of mir servers; the application of kubernetes would to be able to kill pods that have failed (due to errors) and redeploy them (I don't know yet if this is automatic or manual) however in theory your server would be forever running. Yet unhealthy errors would still need to be caught. It also allows a server owner to make an update without the user suspecting a thing; the new server.exe will be deployed (or several) and then the old ones would be killed off in the process. There may be issue with with client.exe compatibility however i'm sure it could be rolled out so that while an old server has active connection the pod will be kept alive. New connection will be forced to update and connected to the new instance so it will gradually dwindle so that there are no active connections on the old server and it is killed off.

My only issue is that what if you get the case of a user who never logs off? I assume bugs that are fixed server side/ client side which are of big importance will need to be addressed urgently. Currently the crystal patching system just overwrites the old.exe with the new.exe; in this case we can't do that as it will be in use and you can delete the application bla bla bla you get what I mean.

I'm not sure if there is a way to secretly update a client.exe without the user knowing (of course they give consent) so that it's patched as they play. Or if it is possible to have a secondary client.exe download in the background and then the old client.exe picks that up and without the user knowing it automatically migrates them to the new client.exe (this is all theory) however it feel it is still likely to cause disruption (a minor disconnection to reload client.exe's or migrate etc).

P.S. rereading I may have got some terms mixed up, I was in 3-4 hours of meetings today with different terminologies being used. I think pods are the same are containers. I'm not entirely sure; i guess it depends on company models. Today I was in one meeting with AppDynamics representatives who were demoing a plugin to support kubernetes; it caused many headaches with all kinds of terms being thrown around... nodes; pods; clusters; containers; layers; tiers and more >.<

Well there is currently on going development for SQL support; the in memory part would be the issue. However I don't know if the cluster has the memory to say and all pods share it. I would have to read into that to find out.

azzi said:

I think its more for loading seperate sources rather than instances e.g. loading monster DB from a seperate source, Account DB from a seperate source in turn making the load on the "Server.exe" less - therefore bringing cycles down on the server itself.

I think this is what Day's trying to get at (Tell me if im wrong mate but thats my general first impression of what you've said)

Click to expand...

Not quiet that low level. You wouldn't seperate the database's, the databases they would be in one centralised place.

Yes you could share resources so that one server isn't running doing all the work; cycles will go down as you say due to the load being run across multiple servers.
e.g one server running 2000 cycles/s and a kubernetes cluster with 5 servers could share that load so each having approx 400 cycles each.

This I think is the main benefit / use of it. However the other side of it which I was trying to explain is that you could run say Server.exe (version 1.5) and gradually deploy Server.exe (version 1.6) followed by terminating the server.exe version 1.5 allowing an instant cross over from versions 1.5 -> version 1.6 without taking the server down or a pretty much instant / very little disruption to the players.

On top of this; if your running lets say 5 servers and one of them happens to crash because of a code error. From word of mouth I think kubernetes will identify that it's failed and kill it off automatically. It will then start up and run a new server.exe to compensate for that instance being lost. I don't know what effects that would have on a live server (whether all players on that instance will be migrated to another live instance or whether all connections would terminate.

It sounds like a very interesting tool / concept. Like I said I'm very interested in looking into it however i'm busy. Maybe i'll do some reading this weekend.

---------- Post Merged at 10:17 PM ---------- Previous Post was at 10:11 PM ----------

Here's an image which I think demonstrates my 1000s of words in a simple diagram.

The container that has a red cross through it has been terminated (in this example an error occured); the container is caught and put in garbage and recreated (or restarted); i don't know the technical implementation.

You could also deploy version 1.5 and version 1.6 servers; then kill off the version 1.5 servers. I don't know if you could limit the connections to divert in real time or whether they will connect randomly to v1.5 and v1.6 until you terminate 1.5 servers (causing the users connected to them to migrate to 1.6)

http://imgur.com/a/Sgb0e

.. no there wouldn't be multiple physical servers, just multiple instances of the virtual server.exe on the same physical server

Sure because mir has such a small player base it's pointless or has little benefit. I just thought the idea behind it was pretty cool.