《Apache Flink 案例集（2022版）》——4.云原生——京东-Flink on K8s 在京东的持续优化实践（上）

2023-05-25 594

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 《Apache Flink 案例集（2022版）》——4.云原生——京东-Flink on K8s 在京东的持续优化实践（上）

作者：付海涛

用户背景

京东集团定位于“以供应链为基础的技术与服务企业”，目前业务已涉及零售、数字科技、物流、技术服务、健康、保险、物流地产、云计算、AI和海外等领域，其中核心业务为零售、数字科技、物流、技术服务四大板块。

平台建设

在 2017 年左右，京东实时计算是多个引擎并存的，包括 Storm、Spark Streaming 以及正在引入的新一代计算引擎 Flink，其中 Storm 集群运行在物理机上，Spark Streaming 运行在 YARN 上，不同的运行环境导致部署和运营成本特别高，且资源利用有一定浪费，所以迫切需要一个统一的集群资源管理和调度系统来解决这个问题。

经过一系列的尝试、优化和性能对比后，京东最终选择了K8s 来解决这些问题。K8s 是目前业内非常流行的容器编排和管理平台，它可以很方便地管理成千上万的容器化应用，易于部署和运维；很容易做到混合部署，将不同负载的服务比如在线服务、机器学习、流批计算等混合在一起，获得更好的资源利用；此外，它还具有天然容器隔离、原生弹性自愈的能力，可以提供更好的隔离性与安全性。

京东的实时计算平台容器化历程如下：

2018 年初，实时计算平台开始全面容器化改造；

到 2018 年 6 月，已经有 20% 的任务运行在 K8s 上，从运行结果看，无论是资源的共享能力、还是业务处理能力，以及敏捷性和效率方面都获得了较大提升，初步达到了预期的效果；

到 2019 年 2 月实现了实时计算全部容器化；此后至今，京东一直在弹性伸缩、服务混部、任务快速恢复能力建设等方面进行Flink on K8s的优化和实践。

京东 Flink on K8s 的平台架构如上图，最下面是物理机和云主机，之上是 K8s，它采用京东自研的 JDOS 平台，基于标准的 K8s 进行了许多定制优化，使之更适应京东生产环境的实际情况。JDOS 大部分运行在物理机上，少部分是在云主机上。再往上是基于社区版 Flink 进行深度定制化后的 Flink 引擎。

最上面就是京东的实时计算平台 JRC，支持 SQL 作业和 jar 包作业，提供高吞吐、低延迟、高可用、弹性自愈易用的一站式海量流批数据计算能力，支持丰富的数据源和目标源，具备完善的作业管理、配置、部署、日志监控和自运维的功能，提供备份回滚和一键迁移的功能。

京东实时计算平台服务于京东内部非常多的业务线，主要应用场景包括实时数仓，实时大屏、实时推荐、实时报表、实时风控和实时监控等。

生产实践

最开始京东的容器化方案采用的是基于 K8s Deployment 部署的Standalone Session集群，这是资源静态分配的模式，需要用户在创建的时候就决定好所需要的管理节点 Jobmanager 的个数和规格 (包括 CPU 的核数、内存和磁盘的大小等)、运行节点 TaskManager 的个数和规格 (包括 CPU、内存和磁盘大小等)，以及TaskManager包含的Slot个数。创建集群后，JRC平台通过 K8s 客户端向K8s Master发出请求，创建JobManager的Deployment，这里使用 ZK 保证高可用，使用 HDFS 和 OSS 进行状态存储，集群创建完成后就可以提交任务了。

在实践的过程中发现该方案存在一些不足：它需要业务提前预估出所需要的资源，对业务不太友好，无法满足灵活多变的业务场景。比如对一些复杂拓扑或者一个集群跑多个任务的场景，业务很难预先精准确定出所需要资源，这时候一般都会先创建出一个较大的集群，这样就会带来一定的资源浪费。在任务运行的过程中，也没有办法根据任务的运行情况，按需进行资源的动态伸缩。

于是京东对容器化方案进行了升级，支持弹性资源模式。这是采用资源按需分配的方式，如上图所示。它需要用户在创建时指定好所需要管理节点 JobManager 的个数和规格，以及运行节点TaskManager的规格，而TaskManager的个数可以不指定。点击创建集群后，JRC平台会通过K8s客户端向K8s Master发出请求，创建JobManager的Deployment以及可选地预创建指定数量TaskManager Pod。

平台提交任务后，由 JobMaster 通过 JDResourceManager 向 JRC 平台发出申请资源的 rest 请求，然后平台向K8s Master动态申请资源去创建运行askManager 的Pod。在运行过程中，如果发现某个TaskManager长时间空闲，可以根据配置动态释放资源。这里通过平台与K8s交互进行资源的创建和销毁，主要是为了保证计算平台对资源的管控，同时避免了集群配置和逻辑变化对镜像的影响；通过支持用户配置TaskManager个数进行资源的预分配，可以做到与资源静态分配同样快速的任务提交速度；同时通过定制资源分配策略，可以做到兼容原有slot分散分布的均衡调度。

在 Flink on K8s 的环境中，日志和监控指标是非常重要的，它可以辅助观察整个集群、容器、任务的运行情况，根据日志和监控快速定位问题并及时处理。

日志采集采用京东的 Logbook 服务，它的基本机制是在每个 Node 上会运行一个 log agent，用于采集指定路径的日志；然后 Jobmanager 或 Taskmanager 会按照指定规则输出日志到指定目录，之后日志就会被自动采集到 Logbook 系统；最后可以通过计算平台进行实时日志和历史日志的检索和查询。

接下来是容器网络的性能问题。一般来说虚拟化的东西都会带来一定的性能损耗，容器网络作为容器虚拟化的一个重要组件，相比物理机网络来说，不可避免地会出现一些性能的损耗。性能的下降程度根据网络插件的不同、协议类型和数据包的大小会有所不同。

此外，网络损耗对于 checkpoint 的快慢影响也很大。根据实践对比测试，网络模式不同的情况下，同样的环境下运行同样的任务，采用容器网络任务的 checkpoint 时长比使用主机网络慢了一倍以上。那么怎么解决这个容器网络的性能问题？

一是可以根据机房环境选择合适的网络模式：比如对于京东一些旧的机房，容器网络性能下降特别明显，而且网络的架构也不能升级，采用了主机网络 (如上图所示，在 pod yaml 文件中配置 hostNetwork=true) 来避免损耗的问题，虽说这不太符合 K8s 的风格，但需要根据条件做个权衡；而对于新的机房，由于基础网络的性能提升以及采用了新的高性能网络插件，性能损耗相比主机网非常小，就采用了容器网；

二是尽量不要使用异构网络环境，避免 K8s 跨机房，同时适当调整集群网络的相关参数，增加网络的容错能力。比如可以适当调大akka.ask.timeout 和taskmanager.network.request-backoff.max 两个参数。