我在kubernetes上运行flink1.8 wordcount示例作业时，注意到一个行为。有时，taskmanager pod OOMKilled jobmanager日志显示，重新启动（现在不需要担心），但整个作业都失败了 The assigned slot XXX was removed .
我的问题是，为什么整个工作都失败了？有没有一种方法可以配置flink，使作业更能容忍短暂的taskmanager失败？
我在kubernetes上运行flink1.8 wordcount示例作业时，注意到一个行为。有时，taskmanager pod OOMKilled jobmanager日志显示，重新启动（现在不需要担心），但整个作业都失败了 The assigned slot XXX was removed .
我的问题是，为什么整个工作都失败了？有没有一种方法可以配置flink，使作业更能容忍短暂的taskmanager失败？
3条答案
按热度按时间xytpbqjk1#
apache flink的容错机制是基于周期性检查点的，可以保证一次状态的一致性，即在从故障中恢复之后，状态是一致的，就像从未发生过故障一样（当然假设应用程序逻辑是确定性的）。
为了实现这一点，flink定期对应用程序的状态（所谓的检查点）进行一致的快照。如果出现故障，整个应用程序将重置为最新的竞争检查点。为此，flink（直到flink1.8）总是重新启动整个应用程序。失败是终止工作进程的任何原因，包括应用程序失败、jvmoom、终止容器、硬件故障等。
在flink1.9（一周前发布，请参阅公告）中，flink添加了所谓的故障转移区域（请参阅此处），这可以减少重新启动的任务的数量。对于连续流应用程序，这仅适用于应用程序没有洗牌（keyby、broadcast、partition…）操作的情况。在这种情况下，只有受影响的管道重新启动，所有其他管道继续处理数据。
jmo0nnb32#
pod中的容器可能会由于许多原因而失败，例如其中的进程以非零退出代码退出，或者容器因超过内存限制而被终止
您可以使用作业规范
因此，使用这个吊舱将留在系统中，容器将重新运行。
有关详细信息，请参阅官方工作文件：https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/
q9rjltbz3#
在运行flink作业之前，你应该做一个容量计划，否则，你会经常遇到oom问题，在kubernetes环境中，你应该计算你的作业将消耗多少内存，并将部署的resources.limits.memory设置为高于它的resources.requests.memory，如果resources.requests.memory远低于您的作业实际成本，您的pod将处于收回状态，这也将导致您的作业失败。