我在 Kubernetes 上运行 Flink 1.8 WordCount 示例作业时，我注意到了一个行为。有时，任务管理器 Pod 会OOMKilled并重新启动(目前不是问题(，但整个作业失败，JobManager 日志显示The assigned slot XXX was removed。
我的问题是，为什么整个工作会失败？有没有办法配置 Flink 以使作业对暂时性任务管理器故障的容忍度更高？
Apache Flink 的容错机制基于周期性检查点，可以保证恰好一次的状态一致性，即从故障中恢复后，状态是一致的，并且与故障从未发生过一样(当然假设确定性应用程序逻辑(。
为了实现这一点，Flink 会定期拍摄应用程序状态的一致快照(所谓的检查点(。如果发生故障，整个应用程序将重置为最新的竞争检查点。为此，Flink(直到 Flink 1.8(总是重新启动整个应用程序。故障是终止工作进程的任何原因，包括应用程序故障、JVM OOM、终止容器、硬件故障等。
在 Flink 1.9(一周前发布，见公告(中，Flink 增加了所谓的故障转移区域(见这里(，可以减少重启任务的数量。对于连续流式处理应用程序，这仅适用于应用程序没有随机播放(键按、广播、分区等(操作的情况。在这种情况下，只会重新启动受影响的管道，所有其他管道将继续处理数据。
运行 Flink 作业 你应该先做一个容量计划，否则，你会经常遇到OOM问题，在 Kubernetes 环境中你应该计算你的作业将花费多少内存，并将部署的资源.限制.内存设置得高于它以及 resources.requests.memory，如果resources.requests.memory远低于您的工作实际成本，您的 Pod 将处于逐出状态，这也会导致您的作业失败。
Pod 中的容器可能会由于多种原因而失败，例如其中的进程以非零退出代码退出，或者容器因超出内存限制而被杀死
您可以使用作业规范
.spec.template.spec.restartPolicy = "OnFailure"
因此，使用此 pod 将保留在系统中，容器将重新运行。
有关更多信息，请查看官方工作文档：https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/