Adding Database Containers to Application Templates
Best practices for running your application with databases running in a container
Adding a database to your application for durability is a common use case and this document should cover the basic use cases for adding a database to your application. There are a few caveats that come with running databases in containers which we'll cover here:
Containers and pods in Kubernetes can be restarted and deleted and moved at any time, so they should not be relied upon for any critical services
Because containers are ephemeral and can move around, it is vital to use a persistent storage volume so that restarting a container does not erase the database!
Kubernetes can start a container and assume it's running but the database may not be completely initialized or ready yet. Therefore, you should use readiness probes to ensure the deployments wait until the database is fully ready to receive traffic.
Passwords can be randomized and the database connections should be kept internal only so that external people cannot access the data or store their own data in your tables, even if it is a test database.