4

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

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

有任何想法吗？

4

4 回答 4

3

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

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

于 2018-02-15T12:45:59.380 回答
0

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

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

--

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

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

于 2017-02-08T19:01:20.527 回答
0

每个 Pod 都可以配置一个init 容器，这似乎很适合您的问题。因此，与其让 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
于 2017-02-08T18:51:00.863 回答
0

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

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

于 2019-09-23T16:51:58.193 回答