Question

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

由于这个新容器，在运行kubectl describe jobs/migration时，作业始终显示为1，并且我完全失败。我已经尝试重新排序容器，看它是否默认检查一个，但没有任何区别，我无法找到a）杀死容器或b）检查作业中只有一个容器的状态。

有什么想法吗？

Answer 1

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

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

Answer 2

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

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

Answer 3

您尚未发布有关您的具体问题的足够详细信息。但我根据经验做出猜测。

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

-

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

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

Answer 4

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

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

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

4 个答案: