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