这就是Docker Compose和Docker Swarm的美妙之处...他们的简洁。
我们在部署ELK堆栈时也遇到了Kubernetes的这个缺点。我们通过使用side-car（initContainer）解决了这个问题。side-car只是同一pod中最先运行的另一个容器，当它完成时，Kubernetes会自动启动[main]容器。我们将它作为一个简单的shell脚本，在Elasticsearch启动并运行之前一直处于循环状态，然后退出，Kibana的容器启动。
下面是一个边车的例子，等待，直到Grafana准备好。
将此“initContainer”块添加到Pod中其他容器的正上方：

spec:
      initContainers:
      - name: wait-for-grafana
        image: darthcabs/tiny-tools:1
        args:
        - /bin/bash
        - -c
        - >
          set -x;
          while [[ "$(curl -s -o /dev/null -w ''%{http_code}'' http://grafana:3000/login)" != "200" ]]; do 
            echo '.'
            sleep 15;
          done
      containers:
          .
          .
  (your other containers)
          .
          .

这是故意忽略的，原因是应用程序应该负责连接到服务（如数据库）的连接/重新连接逻辑，这超出了Kubernetes的范围。

除了this link (k8s-AppController)之外，我不知道你的问题的直接答案，我不认为对数据库和应用程序使用相同的部署是明智的。因为你把数据库和应用程序紧密地耦合在一起，失去了根据需要扩展其中任何一个的强大的k8s选项。更进一步，如果你的数据库pod死了，你也失去了你的数据。
就我个人而言，我会做的是有一个单独的StatefulSet与Persistent Volume的数据库和部署的应用程序，并使用Service，以确保他们的通信。
是的，我必须运行几个不同的命令，可能需要至少两个单独的部署文件，但这样我就可以将它们解耦，并根据需要扩展它们，而且我的数据也是持久的！

如前所述，您应该在单独的pod中运行数据库和应用程序容器，并将它们与服务连接起来。
不幸的是，Kubernetes和Helm都没有提供类似于您所描述的功能。我们遇到了很多问题，尝试了一些方法，直到我们决定开发一个小型实用程序来解决这个问题。
下面是我们开发的工具的链接：https://github.com/Opsfleet/depends-on
你可以让pod根据readinessProbe的配置等待其他pod准备就绪，这和Docker的depends_on功能非常接近。

在Kubernetes的术语中，一个docker-compose集是Pod。
所以，那里没有depends_on的等价物。Kubernetes将检查一个pod中的所有容器，它们都必须是活的才能将该pod标记为健康的，并且将始终一起运行它们。
在您的情况下，您需要准备部署的配置，如下所示：

apiVersion: extensions/v1beta1
 kind: Deployment
 metadata:
   name: my-app
 spec:
   replicas: 1
   template:
     metadata:
       labels:
         app: app-and-db
     spec:
       containers:
         - name: app
           image: nginx
           ports:
             - containerPort: 80
         - name: db
           image: mysql
           ports:
             - containerPort: 3306

pod启动后，您的数据库将在应用程序的localhost接口上可用，因为network conception：
pod中的容器共享IP地址和端口空间，可以通过localhost找到彼此，也可以使用SystemV信号量或POSIX共享内存等标准进程间通信进行通信。
但是，正如@leninhasda所提到的，在pod中运行数据库和应用程序而不使用Persistent Volume并不是一个好主意。

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
活动性和就绪性如何？？？支持命令、http请求等，以检查另一个服务是否响应正常

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - curl http://service2/api/v2/health-check
      initialDelaySeconds: 5
      periodSeconds: 5