Question

我想在kubernetes上运行一个Apache flink（1.11.1）流应用程序。使用文件系统状态后端保存到s3。指向s3的检查点有效

args:
  - "standalone-job"
    - "-s"
    - "s3://BUCKET_NAME/34619f2862ce3e5fc91d80eae13a434a/chk-4/_metadata"
    - "--job-classname"
    - "com.abc.def.MY_JOB"
    - "--kafka-broker"
    - "KAFKA_HOST:9092"

所以我面临的问题是：

我必须手动选择先前的状态目录。有可能使它变得更好吗？
该作业会增加chk目录，但它不使用检查点。意味着当我第一次看到一个事件时，我会抛出一个新事件，并且每当我通过Gitlab部署应用程序的较新版本时，都会将其存储到ListState<String>中。
为什么在将state.backend定义到文件系统时，必须在代码中显式启用检查点？ env.enableCheckpointing(Duration.ofSeconds(60).toMillis());和env.getCheckpointConfig().enableExternalizedCheckpoints(RETAIN_ON_CANCELLATION);

Answer 1

您可能更喜欢Ververica Platform: Community Edition，它将{{3}}的抽象级别提高到您不必在此级别处理细节的程度。它具有一个专为CI / CD设计的API。
我不确定我是否理解您的第二点，但是在恢复过程中，您的工作会倒带并重新处理一些数据是正常的。 Flink不能保证只进行一次语义处理，而只能保证一次语义：每个事件都会影响一次由Flink管理的状态。这是通过回滚到最近检查点的偏移量，然后将所有其他状态恢复到使用所有数据直到这些偏移量之后的状态来实现的。
必须具有状态后端，以便在作业运行时存储作业的工作状态。如果您未启用检查点，那么工作状态将不会被检查点，并且无法恢复。但是，从Flink 1.11开始，您可以使用

execution.checkpointing.interval: 60000
execution.checkpointing.externalized-checkpoint-retention: RETAIN_ON_CANCELLATION

Answer 2

有多种方法可以将工作负载部署到kubernetes，简单的YAML文件，Helm Chart和Operator。

升级有状态Flink作业并不像升级无状态服务那样简单，只需更新二进制文件并重新启动即可。

升级Flink作业，您需要获取一个保存点或获取最新的检查点目录，然后更新二进制文件并最终重新提交作业，在这种情况下，我认为简单的YAML文件和Helm Chart无法帮助您实现这一目标，您应该考虑实施Flink Operator进行升级工作。

https://github.com/GoogleCloudPlatform/flink-on-k8s-operator

在kubernetes上连续部署有状态apache flink应用程序

所以我面临的问题是：

2 个答案: