Benjamin Good, Solutions Architect, Google Cloud, wrote this piece in which he considers if you should run a database on Kubernetes. Today, more and more applications are being deployed in containers on Kubernetes—so much so that we’ve heard Kubernetes called the Linux of the cloud.
It will be easier to run a database on Kubernetes if it includes concepts like sharding, failover elections and replication built into its DNA (for example: ElasticSearch, Cassandra, or MongoDB).
However the data layer hasn’t gotten much traction with containerization. Handling things like state (the database), availability to other layers of the application, and redundancy for a database can have very specific requirements. That makes it challenging to run a database in a distributed environment.
It is important to remember that pods (the database application containers) are transient, so the likelihood of database application restarts or failovers is higher. Also, some of the more database-specific administrative tasks—backups, scaling, tuning, etc. – are different due to the added abstractions that come with containerization.
Next, consider the function that database is performing in the context of your application and business. Databases that are storing more transient and caching layers are better fits for Kubernetes.
To find out more read article in full. Solid advice!
[Read More]