如何最好地在kubernetes集群中运行一次性迁移任务 [英] How best to run one-off migration tasks in a kubernetes cluster

问题描述

在将新版本的应用程序部署到Kubernetes集群之前，我想运行数据库迁移.我希望这些迁移能够作为持续交付管道的一部分自动运行.迁移将被封装为容器映像.实现此目标的最佳机制是什么?

I have database migrations which I'd like to run before deploying a new version of my app into a Kubernetes cluster. I want these migrations to be run automatically as part of a Continuous Delivery pipeline. The migration will be encapsulated as a container image. What's the best mechanism to achieve this?

解决方案要求:

• 能够确定迁移是否失败，以便我们随后不再尝试将新版本的应用程序部署到集群中.
• 如果迁移失败，请放弃-不要继续尝试.
• 能够访问日志以诊断失败的迁移.

我以为Kubernetes中的Jobs功能可以简化这一过程，但是似乎存在一些挑战:

I had assumed that the Jobs functionality in Kubernetes would make this easy, but there appear to be a few challenges:

• Kubernetes将重复运行其容器以非零退出代码终止的容器，即使作业的restartPolicy为never.
• 在等待排队作业的结果时阻塞似乎需要手动滚动脚本

• Kubernetes will repeatedly re-run containers whose processes terminate with a non-zero exit code, even if the Job has a restartPolicy of never.
• blocking while waiting on the result of a queued-up job seems to require hand-rolled scripts

使用裸豆荚"会更好吗?如果是这样，那怎么办?

Would using "bare pods" be a better approach? If so, how might that work?

推荐答案

在等待排队作业的结果时阻塞似乎需要手动滚动脚本

blocking while waiting on the result of a queued-up job seems to require hand-rolled scripts

借助kubectl wait命令，不再需要此操作.

This isn't necessary anymore thanks to the kubectl wait command.

这是我在CI中运行数据库迁移的方式:

Here's how I'm running db migrations in CI:

kubectl apply -f migration-job.yml
kubectl wait --for=condition=complete --timeout=60s job/migration
kubectl delete job/migration

万一发生故障或超时，前两个CLI命令之一将返回错误的退出代码，然后强制其余CI管道终止.

In case of failure or timeout, one of the two first CLI commands returns with an erroneous exit code which then forces the rest of the CI pipeline to terminate.

migration-job.yml描述了配置有restartPolicy: Never和相当低的activeDeadlineSeconds的kubernetes Job资源.

migration-job.yml describes a kubernetes Job resource configured with restartPolicy: Never and a reasonably low activeDeadlineSeconds.

您还可以使用spec.ttlSecondsAfterFinished 属性代替手动运行kubectl delete，但在撰写本文时仍处于Alpha状态，并且至少不受Google Kubernetes Engine支持.

You could also use the spec.ttlSecondsAfterFinished attribute instead of manually running kubectl delete but that's still in alpha at the time of writing and not supported by Google Kubernetes Engine at least.

这篇关于如何最好地在kubernetes集群中运行一次性迁移任务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！