具有多个容器的作业永远不会成功答案

【问题标题】：Job with multiple containers never succeeds具有多个容器的作业永远不会成功
【发布时间】：2017-06-26 13:05:44
【问题描述】：

我在 GKE 集群中运行 Kubernetes，并且需要在每次部署时运行数据库迁移脚本。对于 staging 这很简单：我们有一个永久的、独立的 MySQL 服务，它有自己的卷。但是对于生产，我们使用 GCE SQL，导致作业有两个容器 - 一个用于迁移，另一个用于云代理。

由于有了这个新容器，在运行kubectl describe jobs/migration 时，该作业始终显示为 1 active，而我完全不知所措。我已经尝试重新排序容器以查看它是否默认检查一个容器，但这没有任何区别，我看不出有一种方法可以 a) 杀死一个容器或 b) 检查 Job 中一个容器的状态。

有什么想法吗？

【问题讨论】：

嗨 - 您可能想要添加部署/Pod 配置和 kubectl 描述输出到您的问题以获得更好的答案。
Kubernetes: stop CloudSQL-proxy sidecar container in multi container Pod/Job的可能重复

标签： kubernetes containers jobs kubernetes-pod

【解决方案1】：

每个 Pod 都可以配置 init container，这似乎很适合您的问题。因此，与其让 Pod 包含两个必须永久运行的容器，不如定义一个 init 容器来预先进行迁移。例如。像这样：

apiVersion: v1
kind: Pod
metadata:
  name: init-container
  annotations:
    pod.beta.kubernetes.io/init-containers: '[
        {
            "name": "migrate",
            "image": "application:version",
            "command": ["migrate up"],
        }
    ]'
spec:
  containers:
  - name: application
    image: application:version
    ports:
    - containerPort: 80

【讨论】：

不，这根本不能解决问题。为了使迁移运行，第二个容器需要存在。第二个容器建立数据库连接，第一个运行迁移代码。这一事实阻止了 init 容器在其他情况下被使用。

【解决方案2】：

您没有针对您的具体问题发布足够的详细信息。但我是根据经验猜测的。

TL;DR：如果容器是独立的，则将它们移动到单独的作业中。

Kubernetes 作业会不断重启，直到作业成功。只有当其中的每个容器都成功时，kubernetes 作业才会成功。

这意味着您的容器应该以防重启的方式返回。一旦容器成功运行，即使再次运行，它也应该返回成功。否则，说容器 1 成功，容器 2 失败。作业重新启动。然后，container1 失败（因为它已经成功了）。因此，Job 不断重启。

【讨论】：

公平点！除了迁移容器运行良好之外，我不完全确定如何完全描述问题，但 Google Cloud 代理容器是长期存在的：它永远不会失败或成功。迁移依赖于代理容器与数据库通信，但它确实可以将它们剥离到单独的作业中——它们应该仍然能够在服务级别上进行通信。

【解决方案3】：

我知道已经晚了一年，但最佳做法是为所有应用程序运行单个 cloudsql 代理服务，然后在应用程序映像中配置数据库访问以将此服务用作数据库主机名。

这样您就不需要将 cloudsql 代理容器放入每个使用 DB 的 pod 中。

【讨论】：

给出正确答案永远不会太晚。将cloudsql-proxy 移至其向下部署/服务解决了我的问题。
不建议在 GKE 上设置，正如 Google 支持所说。

【解决方案4】：

原因是容器/进程永远不会终止。

一种可能的解决方法是：将cloud-sql-proxy 移动到它自己的deployment - 并在其前面添加一个服务。因此，您的 job 将不负责运行长时间运行的 cloud-sql-proxy，因此将终止/完成。

【讨论】：