如何处理 flink 管理和 k8s 管理答案

【问题标题】：How to handle flink management and k8s management如何处理 flink 管理和 k8s 管理
【发布时间】：2020-05-12 06:31:14
【问题描述】：

我正在考虑使用 K8s 部署 Flink。我是 Flink 的新手，有一个简单的问题：

说我用 K8s 管理 docker 并将 TaskManager 部署到 docker 中。

据我了解，docker 失败时可以被 K8s 重启，Task 失败时可以被 Flink 重启。

如果一个Task在docker的容器中运行，而容器由于某种原因突然失败了，在Flink看来，Task失败了，应该重启该task，而在K8s看来，一个容器失败了，docker应该重新启动。在这种情况下，我们是否应该担心两种“被重启”的冲突？

【问题讨论】：

“码头工人”不是一个东西。 Docker 是管理/运行容器的软件，容器运行时。 Kubernetes 现在可以使用许多容器运行时。 s/docker/container/g
抱歉，我不知道 flink 是如何管理任务的！
这个问题是关于 Docker 守护进程失败，还是在容器内运行的特定进程？
@DavidMaze 我的意思是容器失败了。

标签： docker kubernetes deployment apache-flink

【解决方案1】：

我想你想在这里阅读官方的 kubernetes 设置指南：https://ci.apache.org/projects/flink/flink-docs-release-1.10/ops/deployment/kubernetes.html

它描述了使其工作的 3 种方法：

Session Cluster：这涉及在附录中启动 2 个部署，并要求您在开始时手动或通过脚本提交 Flink 作业。这与您开发时的本地独立集群非常相似，只是它现在位于您的 kubernetes 集群中
Job Cluster：通过将 Flink 部署为 k8s 作业，您将能够消除作业提交步骤。
Helm chart：看样子项目已经2年没有更新了，所以你的里程可能会有所不同。

我在会话集群上取得了成功，但我最终想尝试“正确”的方式，即使用第二种方法将其部署为 kubernetes 作业。

根据您的 Flink Source 和故障类型，您的 Flink 作业将失败。你不应该担心“冲突”。要么 Kubernetes 将重新启动容器，要么 Flink 将处理它可以处理的错误。经过一定程度的重试后，它将取消，具体取决于您如何配置它。有关详细信息，请参阅Configuration。如果容器以非 0 的代码退出，Kubernetes 将尝试重新启动它。但是，它可能会或可能不会重新提交作业，具体取决于您是否将作业部署在作业集群中，或者您是否有用于所使用映像的初始化脚本。在会话集群中，这可能会出现问题，具体取决于作业提交是通过任务管理器还是作业管理器完成的。如果作业是通过任务管理器提交的，那么我们需要取消现有的失败作业，以便重新提交的作业可以开始。

注意：如果您确实使用了 Session Cluster，并且为checkpoints 使用了基于文件系统的 Stateful Backend（非 RocksDB Stateful Backend），那么您需要找到一种让作业管理器和任务管理器共享的方法checkpoint directory。

如果任务管理器使用作业管理器无法访问的检查点目录，则任务管理器的持久层会建立并最终导致某种磁盘空间不足错误。如果您决定使用 RocksDB 并启用增量检查点，这可能不是问题

【讨论】：

为什么说“工作集群”是正确的方法？您的说法是否意味着“会话集群”是否正确？
我认为这是 kubernetes 设置的“正确”方式的原因是，在会话集群中部署 Flink 作业需要额外的步骤来处理重启后提交作业。如答案中所述，此额外步骤可能很棘手。如果我们将作业提交步骤绑定到作业管理器，则可能不会出现问题。但是，如果将并行度设置为 1 或在任务管理器重新启动后重复作业，则将作业提交与任务管理器的生命周期联系起来会创建多个排队的作业。我还没有亲自尝试过 Job Cluster 设置，所以这可能只是我个人的猜测