1:1 App/DB Container - Container Architecture and Design

General Discussions
1

This is more of a general question about container design. We have an application that we need N number of times. That application also needs it’s own database per application (1:1). Since the application and db will always be paired for each instance, is there a best design to approach this?

What I’ve been looking at is creating each pod deployment as a two container pod deployment with the database container as an init container and then the application container after that. Reason being is the database needs to be up prior to the application running.

Does anyone see any problems with this design? Combining the two in the same pod will keep my pod creep down. But this leads to my next question, how do I target each SQL instance? DNS?? or do two containers in the same pod have some sort of internal mechanism to talk to each other?

Cluster information:

Kubernetes version: v1.18.18
Cloud being used: bare-metal – on-premise
Installation method: Manual? I don’t know what this question is asking
Host OS: RHEL 7.9
CNI and version: Flannel
CRI and version: Docker 20.10.6, build 370c289

2

Questions I found answers for:

  • The init container direction didn’t work because the init container must run to completion before the next container can startup. Because of this, MSSQL entered a running state, never exited (which we didn’t want) so the next container never got created. We ended up removing the init declarations and just added the MSSQL container as first in the YAML. Kubernetes spins off the containers sequentially so that alone achieved that goal.

  • The pod with multiple containers creates a logical single machine that shares critical aspects like networking stack, IPC, etc. so we simply targeted our app to localhost:1433 and was able to communicate with the SQL container in the pod just fine.