《Apache Flink 案例集（2022版）》——4.云原生——京东-Flink on K8s 在京东的持续优化实践（上） https://developer.aliyun.com/article/1228060

接下来是磁盘的性能问题。容器中的存储空间由两部分组成，如上图所示，底层是只读的镜像层，顶部是可读写的容器层。容器运行的时候涉及到文件的写操作都是在容器层中完成的，这里需要一个存储驱动提供联合文件系统来管理。  

存储驱动一般来说为空间效率进行了优化，额外的抽象会带来一定的性能损耗 (取决于具体存储驱动)，写入速度要低于本地文件系统，特别是使用了写时复制的存储驱动来说，损耗更大。这对于写密集型的应用来说，会有更大的性能影响。而在 Flink 中，很多地方都涉及到本地磁盘的读写，比如日志输出、RocksDB 读写、批任务 shuffle 等。那么该如何处理来减小影响？  

一是可以考虑使用外挂的 Volume，使用本地存储卷，直接写数据到 主机文件系统来提升性能；

此外也可以调优磁盘 IO 相关参数，比如调优 RocksDB 参数，提升磁盘的访问性能；

最后也可以考虑采用一些存储计算分离的方案，比如使用 Remote Shuffle，提升本地Shuffle的性能和稳定性。

在实践过程中经常会发现，很多业务的计算任务配置不合理，占用了过多的资源造成了资源浪费。此外，流量存在波峰波谷，如何在洪峰时自动扩容，在波谷时自动缩容，在减少人工干预、保证业务稳定的同时提高资源利用率，这都涉及到资源弹性伸缩的问题。为此京东开发了弹性伸缩的服务，根据作业运行情况动态调整任务的并行度以及 Taskmanager 的规格，来解决作业吞吐不足、资源浪费等问题。  

通过弹性伸缩服务，可以较好地解决一些场景的资源浪费问题，以及任务吞吐与算子并行度呈线性关系条件下的性能问题。不过它还是存在一定的局限性，比如对于外部的系统瓶颈、数据倾斜以及任务本身的性能瓶颈还有无法通过扩并行度提升的场景，不能很好地应对解决。  

此外结合弹性伸缩，京东进行了一些实时流任务和离线批任务错峰混部的尝试。如上图右所示，在凌晨前后，流任务比较空闲，会缩容释放出一些资源给批任务；之后可以使用这些释放的资源在夜间运行批任务；到了白天批任务运行完释放的资源又可以还给流任务，用于扩容以应对流量洪峰，从而提高资源的整体利用率。

相比物理机或 YARN 环境，Flink on K8s 出现问题以后的排查相对要更困难，因为这里面还涉及到 K8s 许多组件，比如容器网络、DNS 解析、K8s 调度等各方面的问题，都存在一定的门槛。  

为了解决这个问题，京东开发了智能诊断的服务，将作业相关的各个维度的监控指标 (包括物理机的、容器的、集群的和任务的指标) 与任务拓扑结合起来并与 K8s 打通，结合Pod日志和任务日志联合进行分析，并将日常人工运维的一些方法进行归纳总结应用到分析策略中，诊断出作业的问题并给出优化建议。目前支持对任务重启、任务背压、Checkpoint失败、集群资源利用率低等一些常见问题进行诊断。

用户收益

全部 on K8s 后收益还是比较明显的：  

首先混合部署服务和资源共享能力获得了提升，节省机器资源 30%；

其次，具有更好的资源隔离和弹性自愈能力，比较容易实现根据业务的负载进行资源的弹性伸缩，保证了业务的稳定性；

最后开发、测试、生产一致性的环境，避免环境给整个开发过程带来问题，同时极大提升了部署和运营自动化的能力，降低了管理运维的成本。

未来规划

未来京东会在以下几方面继续探索：  

1. 调度优化：

一方面是 K8s 层面资源调度优化，更高效地管理大数据的在线服务和离线作业，提升 K8s 集群的利用率和运行效率；

另一方面是 Flink 作业调度优化，支持更丰富、更细粒度的调度策略，提升 Flink 作业资源的利用率和稳定性，满足不同的业务场景需要。  

2. 服务混部：将不同负载的服务混部在一起，在保证服务稳定的前提下尽量提升资源利用率，使服务器的价值最大化；