AWS Kubernetes - MySQL DB instance - RDS or Docker Mysql Image

Question

We're trying to migrate to either a cheap hosting or aws Kubernetes to cut costs. Our website is a game site and has around 100 users. The servers include 2 mysql db, 2 tomcat server and a management server. It doesn't use much resource. So I've been thinking of launching a single node k8s and launch these servers as a docker instances. I want to cut costs to less than 300 dollars per month.

RDS pricing seems too much and using that might end up more than 300 dollars.

I wanted to know if its okay to use a mysql docker image inside ks8 node along side tomcat image? DB can start with 100 GB of storage for each DB (maybe 300GB to 500 GB totally for both for a long term). No s3 or anything else is needed.

This is my first time planning something from scratch and I'm new to AWS and K8s. Wanted some suggestions before I start testing it out.

Answer 1

It's generally not recommended to put the actual data of a database in a docker container. As the concept of these is they are stateless.

However I have seen people say that its fine to have the engine in a container and the data on a shared drive. Although you then have to manage locking of the db files in case two images try to use the same db.

Also, the cloud providers are wise to serverless style antics, you are unlikely to be able to run a db more cheaply than the equivalent RDS option.

I see you can get a micro reserved instance for $10 a month? and 500Gb of db storage is $66 a month?#

You can also sign up for various start up packages and get stuff for free. Which I would highly recommend if you are even vaguely serious about running your game as a business.

https://azure.microsoft.com/en-gb/free/startups/?ref=MS4SU

Answer 2

Sharing a few points from my experience of moving from a managed database to a Do-It-Yourself setup.

Cloud providers have a very stable database offering in general covering a lot of aspects like scaling, managing reliability, setting up backups, disaster recovery through geo-replication. Setting up configurations here are quite literally just a few button clicks. Monitoring and Alerting are easier and provided out of the box. You can create a database instance in the region close to your application, and migration is super easy too - again, button clicks.

In addition basic security, basic DoS protection, networking/domain registration, and load balancing.

It's up to you to decide if you need all of the above or a few of them, but regardless - at some point, you are going to have a DBA expert in your team and make all the configurations.

In k8s, it's a little tricky for DB. k8s works best when apps are stateless, you applications can be brought up/down, restarted easily. That's not the case with database. You might have to go with a stateful set, create affinity between the disk and compute, setup monitoring and alert (probably with prometheus). You might want to provide the right compute and memory limits to ensure QoS is high so that in situations where you have a lack of resources, your DB pod would be the last to be killed. In case you provide multiple pods, ensure you have a load balancer(service), that load balancer will need additional resources too.

Very quickly your focus will move out of building applications and go towards database operations. We finally had to go back to a managed database and it was well worth some added cost.

Regarding the costs, depending on the application, performance expectation, and database size, there are a few options. You can try the Azure option @Ewan has mentioned or checkout Heroku options which are less expensive too.