版权声明：原创文章 https://blog.csdn.net/cpongo5/article/details/88995611
\u003cp\u003e\u003cstrong\u003e本文最初发布于Zalando网站Technology Blog板块，经原作者授权由InfoQ中文站翻译并分享\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e最近，我在用\u003ca href=\"https://flink.apache.org/\"\u003eApache Flink\u003c/a\u003e构建小型的流处理应用。在Zalando，我们默认使用Kubernetes进行部署，所以计划将Flink和开发的一些作业都部署到Kubernetes集群上。在这个过程中，我学到了很多关于Flink和Kubernetes的知识，在这篇文章里会和大家分享一下。\u003c/p\u003e\n\u003ch2\u003e一些挑战\u003c/h2\u003e\n\u003cp\u003e首先是合规性。在Zalando，正产环境运行的代码必须经过至少2人的审核，并且所有部署的内容都可以追溯到git commit。通常\u003ca href=\"https://ci.apache.org/projects/flink/flink-docs-release-1.7/tutorials/local_setup.html#run-the-example\"\u003e部署Flink\u003c/a\u003e任务会将包含有任务和依赖的JAR包上传到运行中的Flink集群，但这不符合我们内部的合规流程。\u003c/p\u003e\n\u003cp\u003e其二是容器编排的成熟度。Flink一个重要的卖点是支持容错的流处理。但如下一节所述，在容器编排系统中没有设计可靠性相关的功能，这使得在Kubernetes上运行Flink集群并不是你想的那么简单。\u003c/p\u003e\n\u003cp\u003e其三是碎片化的文档。不论是Flink还是Kubernetes都在快速的发展中，这使一些文档很容易就过时了（就像我这篇blog，或者是论坛/新闻组的帖子）。可惜的是，对于如何在Kubernetes上可靠地运行Flink，现在官方文档能提供的信息还不够完善。\u003c/p\u003e\n\u003ch2\u003eFlink的架构和部署模式\u003c/h2\u003e\n\u003cp\u003e为了理解如何在Kubernetes集群上部署Flink，需要先对其架构和部署模式有个大致的了解。如果你已经很熟悉Flink了，可以跳过本节。\u003c/p\u003e\n\u003cp\u003eFlink由作业管理器（Job Manager）和任务管理器（Task Manager）两个部分组成。作业管理器协调流处理作业，管理作业的提交及其生命周期，并将工作分配给任务管理器。任务管理器执行实际的流处理逻辑。同一时间只可能有一个活跃的作业管理器，但任务管理器可以有n个。\u003c/p\u003e\n\u003cp\u003e为了实现弹性的、有状态的、流式的处理，Flink使用了检查点（\u003ca href=\"https://ci.apache.org/projects/flink/flink-docs-release-1.7/dev/stream/state/checkpointing.html\"\u003eCheckpointing\u003c/a\u003e）来周期性地记录各种流处理操作的状态，并进行持久化存储。从故障中恢复时，流处理作业可以从最新的检查点继续执行。检查点的操作由作业管理器进行协调，它知道最新完成的检查点的位置，这在后面会很重要。\u003c/p\u003e\n\u003cp\u003e\u003cimg src=\"https://static.geekbang.org/infoq/5ca30919dfc02.png?imageView2/0/w/800\" alt=\"image\" /\u003e\u003c/p\u003e\n\u003cp\u003eFlink集群可以以两种独立的模式运行：第一种叫Standalone或者叫Session Cluster，是一个可以运行多个流处理作业的单一集群。任务管理器在作业之间共享。第二种叫作业集群Job Cluster，专门用于运行单个流处理作业。\u003c/p\u003e\n\u003cp\u003eFlink集群可以在\u003ca href=\"https://ci.apache.org/projects/flink/flink-docs-release-1.7/ops/jobmanager_high_availability.html\"\u003eHA模式\u003c/a\u003e下运行。在这个模式下，多个作业管理器的实例同时运行，其中的一个会被选举为leader。如果leader失效了，会从其他运行的作业管理器中选出一个新的leader。Flink使用Zookeeper来进行leader选举。\u003c/p\u003e\n\u003cp\u003e\u003cimg src=\"https://static.geekbang.org/infoq/5ca309d5741ae.png?imageView2/0/w/800\" alt=\"image\" /\u003e\u003c/p\u003e\n\u003ch2\u003e部署Kubernetes\u003c/h2\u003e\n\u003cp\u003e在上文提到的两种模式中，我们选择了Job Cluster模式来运行Flink。有两个原因：第一是因为Job Cluster的Docker镜像需要包含有Flink作业的JAR包。这能很好地解决合规性问题，因为我们可以重复使用与常规JVM应用相同的工作流程。第二个原因是这种部署模型能为每个Flink作业独立地扩展任务管理器。\u003c/p\u003e\n\u003cp\u003e我们将作业管理器作为一个部署（Deployment）并设置了1副本，任务管理器设置了n副本。任务管理器通过Kubernetes服务发现作业管理器。这个设置和官方文档不太相同，官方文档是建议将Job Cluster的作业管理器当做Kubernetes的作业来运行。但我们认为这种场景下（一个永不停止的流任务）使用部署的方式会更可靠，因为可以确保有一个pod一直在运行，而作业是可以完成的，使得集群可以没有任何作业管理器。这就是为什么我们的设置比较类似于文档中关于session cluster的描述。\u003c/p\u003e\n\u003cp\u003e作业管理器pod的失效由部署控制器（Deployment Controller）来处理，它会负责生成新的作业管理器。鉴于这是相对较快的操作，我们无需在热备份中维护多个作业管理器，不然会增加部署的复杂性。任务管理器使用Kubernetes服务来定位作业管理器。\u003c/p\u003e\n\u003cp\u003e如上文所述，作业管理器会在内存中保留一些和检查点相关的状态。在作业管理器崩溃时，这些状态会丢失，所以我们会在Zookeeper中持久化这些状态。这意味着即使没有选举leader的需求以及Flink HA模式的发现功能（就像Kubernetes本身处理的那样），仍然需要用到Zookeeper来存储检查点的状态。\u003c/p\u003e\n\u003cp\u003e我们在Kubernetes集群上已经部署了etcd集群和etcd-operator，所以不想再引入另一个分布式调度系统了。我们试了一下zetcd，这是一个基于etcdv3的Zookeeper API。用着挺顺利，所以我们决定坚持下去。\u003c/p\u003e\n\u003cp\u003e在这种设置下我们会遇到另一个问题，作业管理器有时会陷入不健康的状态，而只有通过重启作业管理器才能解决。这个我们会通过livenessProbe来解决，它会检查作业管理器是否健康、作业是否仍然在运行。\u003c/p\u003e\n\u003cp\u003e还需要注意的是，这个设置仅适用于Flink大于1.6.1的版本，因为存在无法从job cluster的检查点恢复的bug。\u003c/p\u003e\n\u003ch2\u003e小结\u003c/h2\u003e\n\u003cp\u003e上面的设置在生产环境中已经运行了好几个月，并能很好地服务于我们的用例。这也说明，即使在实现的过程中会遇到一些小障碍，在Kubernetes上平稳地运行Flink还是可行的。\u003c/p\u003e\n\u003cp\u003e原文链接：\u003ca href=\"https://jobs.zalando.com/tech/blog/running-apache-flink-on-kubernetes/index.html\"\u003ehttps://jobs.zalando.com/tech/blog/running-apache-flink-on-kubernetes/index.html\u003c/a\u003e\u003c/p\u003e\n