Kubernetes部署和初始化容器

Question

我最近了解到 Kubernetes 有一个名为 Init Containers 的功能。这很棒，因为我可以使用该功能在我的 Web 应用程序服务运行之前等待我的 postgres 服务并创建/迁移数据库。

然而，似乎只能在 Pod yaml 文件中配置 Init Containers。我是否可以通过 Deployment yaml 文件来实现这一点？还是我必须做出选择？

- Mitkins

Answer 1

为避免混淆，我将回答您的具体问题。我同意奥斯温的观点，您可能需要考虑另一种方法。

是的，您可以在部署中使用 init 容器。这是一个使用旧样式（1.6 之前）的示例，但它应该可以工作。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: 'nginx'
spec:
  replicas: 1
  selector:
    matchLabels:
      app: 'nginx'

  template:
    metadata:
      labels:
        app: 'nginx'
      annotations:
        pod.beta.kubernetes.io/init-containers: '[
            {
                "name": "install",
                "image": "busybox",
                "imagePullPolicy": "IfNotPresent",
                "command": ["wget", "-O", "/application/index.html", "http://kubernetes.io/index.html"],
                "volumeMounts": [
                    {
                      "name": "application",
                      "mountPath": "/application"
                    }
                ]
            }
        ]'
    spec:
      volumes:
        - name: 'application'
          emptyDir: {}

      containers:

      - name: webserver
        image: 'nginx'
        ports:
        - name: http
          containerPort: 80
        volumeMounts:
          - name: 'application'
            mountPath: '/application'

- JamStar

---

就问题而言，你说得一针见血。事实证明，我的GCE集群仍然是1.5版本。你的代码可以工作，但我决定升级到1.6版本。然后我就能在Deployment yaml中加入initContainers了。 - Mitkins

很高兴能帮到你。 - JamStar

@JamStar，init 容器会在每个部署中执行一次还是在每个 Pod 中执行一次？ - Javier Holguera

初始化容器在真正的 Pod 启动之前，因此每个部署只有一个。 - JamStar

除了@JamStar所说的之外：如果您将副本设置为大于1的数字，则将具有与副本相同数量的init-container。（但是，如果您将副本设置为一个，并在模板部分中声明了多个容器，则只会有一个init-container实例） - Julien O

Answer 2

您可能希望在这种情况下使用就绪探针而不是初始化容器。请查看此链接和博客以获取更多信息。还要注意，部署将不会将流量发送到未报告就绪的 Pod-如果这是您的担忧的话。

这是一个众所周知的模式，在 Web 服务器中进行就绪探针检查 DB 端点/数据可用性之前才报告就绪。与额外的初始化容器的复杂性相比，这是一个简单的解决方案，具有正确检测 DB 中断的优点。

- Oswin Noetzelmann

---

我认为初始化容器与就绪探针在任何方面都没有关联。初始化容器会一直运行，直到成功退出，然后才会启动应用程序容器。根据文档，k8s将等待所有初始化容器成功后再启动应用程序容器。初始化容器旨在运行有限的一次性Pod启动任务，而就绪探针用于报告无限期运行的应用程序的状态。并非所有引导任务都适合放在应用程序容器中。 - alexykot

OP的原始问题不仅是等待DB可用，而且还要“创建/迁移数据库”，这是就绪探针范围之外的单独特定任务。 - alexykot

在这种标准情况下，DB容器将在准备就绪之前执行所需的初始化操作，而Web服务将在DB端点准备就绪之前不会准备就绪 - 简单而有效，并且在我看来是最好的关注点分离。避免了基础架构层面的复杂性。 - Oswin Noetzelmann

数据库可能不在容器中，例如它可以是托管的云实例。而且我不确定数据库容器如何知道应用程序需要什么模式结构。 - alexykot

就我所知，OP 的问题首先是关于“initContainers”的。我不明白数据库的位置（在集群内部还是其他地方）与如何运行迁移有关，因为迁移是应用逻辑，而不是数据库服务器逻辑。因此，我认为无论如何，“init containers”都是相关的。您可以将迁移逻辑放入应用程序启动或同一Pod中的initContainer中，我认为这两种方法都是合理的且旨在实现预期的目的。 - alexykot