快手Flink on k8s的迁移与稳定性保障

1. 快手Flink on k8s的迁移与稳定性保障演讲人：刘建刚-快手-技术专家 DataFunCon # 2024

2. Contents 目录稳定性保障快手Flink介绍大规模迁移实践未来规划 logo

3. 01 快手Flink介绍

4. 发展历程 • Flink生产可用改造 • 实时计算平台建设 • 公司实时化转型 2018-2020 2021-2022 • 流批一体探索 • 易用性、稳定性、功能性深度优化 • • • • Flink on k8s Runtime adaption 湖仓一体建设 AI场景大规模落地 2023-2024

5. 整体架构

6. 应用规模

7. 02 大规模迁移实践

8. 背景公司需求技术趋势 • 统一、高效的资源管理与调度。 • Kubernetes已发展为容器编排的事实标准。 2018-2022 Flink on yarn • 初期跟Flink结合的比较好。 • 调度性能好，支持上万节点。 • 可以有效地整合Hadoop生态。 Flink发展 • 弹性伸缩 • 存算分离 • Runtime adaption 2023-2024 Flink on k8s 架构演进 • 统一的云生态和丰富的应用。 • 统一的资源管理(资源置换、混部)。 • 更好的隔离性。

9. 核心痛点设计开发测试迁移 •组件交互的平滑迁移 •用户交互的无感知 •功能集成 •异常诊断 •如何达到上线条件。 •如何快速、批量迁移。

10. 设计挑战： 1. 系统组件众多，都是围绕yarn来构建。 2. 用户更熟悉yarn，对k8s没有概念。方案： • 组件复用与拓展，支持逻辑上的集群、队列概念。 • 用户接口不变，保障体验一致性。

11. 开发-组件交互

12. 开发-指标观测背景 Metric是可观测性的重要一环，k8s metric存在以下问题： 1. Flink on k8s以pod为粒度汇报指标，连接数过多。 2. 海量metric存在性能问题，比如Prometheus扩展性差。 3. 如何跟之前的metric处理保持兼容。实现 1. 通过kafkaGateWay来减少与kafka的连接。 2. 采用clickhouse+grafana的metric处理方式。 3. K8s和yarn的metric统一到kafka topic，进行统一的展示。

13. 开发-日志查看背景问题排查最重要的是查看日志，但是k8s存在以下问题： • Pod结束后，日志也会随之消失，导致无法排查问题。 • Pod异常时，如何进行pod的问题诊断。实现我们开发了日志服务来解决用户问题排查的痛点： • 通过hostPath将日志存到本地磁盘，由k8s定期清理。 • 针对常规日志，通过日志服务的web界面查看。 • 针对重要日志，将日志采集到ES，提工具全局分析能力。另外，我们还通过日志服务为用户展示pod event事件来诊断pod异常。

14. 测试确保功能完善、稳定性高、性能不回退。类型说明集成测试组合各个组件和功能，进行端到端的测试，确保整体流程顺畅。故障测试 1. Flink自身，包含master、slave节点的failover。 2. k8s，比如etcd、kubelet、master切主等的异常。 3. 集群硬件异常，包含机器假死、磁盘故障、网络异常等。性能测试 1. Flink自身性能。 2. K8s apiServer性能。 3. K8s调度性能。回归测试为后续的新环境提供回归测试，确保快速迭代。

15. 迁移原则 • 优先选择低优、拓扑简单的作业。 • 监控报警，出现问题及时回滚。 • 支持批量自动迁移。选择一批作业修改作业到 k8s集群重启作业并从快照恢复监控作业健康度一旦出现问题及时回滚

16. 收益资源上，统一了大数据和容器云两大资源池： • 资源置换上，从天级降到分钟级。 • 运维效率上，统一的机器配置能大幅降低人力成本。 • 资源利用上，在离线混部能提高集群利用率。其他： • Flink层面，弹性伸缩成为趋势。 • 用户层面，资源管理更加便捷。

17. 03 稳定性保障

18. 背景稳定是重中之重易用性 • 稳定是实时计算低延迟最重要的保障。 • 公司核心业务的延迟要求在秒级。 • 稳定可以减少人力损耗和资源成本，助力降本增效。功能稳定性性能稳定性保障的难点 • Flink是long-running的在线计算，保障级别高。 • 影响因素繁多，包括用户代码、周边组件、系统环境等。 • Flink运维成本极高，问题排查错综复杂。 • Flink作为新兴技术，延迟要求高、计算拓扑复杂。

19. 保障能力 Flink故障热点问题 • Master failover • 数据，自动打散与rebalance • Task failover • 机器，自动规避和驱逐软件问题硬件故障 • 业务逻辑，工具辅助 • 机器问题，自动拉黑 • 周边组件，风险排除 • AZ故障，自动容灾本章主要介绍挑战最大、影响最广的AZ逃生技术！

20. AZ逃生背景 1. AZ故障，风险大（近一年两次断电风险）、人力紧，影响面广（所有服务和数据）。 2. 公司AZ逃生专项，实现国内和海外的AZ容载能力。 3. 为应对AZ逃生，Flink on k8s屏蔽了底层集群概念、只暴露AZ大资源池。自底而上、自左而右，必须都具备逃生能力，包含其他链路依赖！

21. AZ逃生 Flink引擎 • 挑战一：Flink job配置绑定集群，一旦生成无法修改集群 • 克隆生成新集群作业——步骤复杂，作业冗余 • 支持修改集群，启动时动态生成集群配置！ • 挑战二：Flink快照存在本集群HDFS，AZ故障时会丢失 • HDFS支持多AZ副本——性能差，实现难。 • 工具拷贝到备集群——难维护，难高可用。 • Flink支持定期跨AZ快照——高性能，好使用！

22. AZ逃生实时平台 P0 • 双AZ热备挑战一：资源不足，引发资源抢占、全局高负载等问题 P1 • 双AZ冷备建立分级保障制度，优先保障核心业务的SLA（支持抢占）、以 P2 • 常规作业 P3 • 低优作业，易被强占 Flink整体利益最大化为目标。挑战二：10分钟内完成几十万核、上千作业的逃生操作。相比存储服务，单Flink切换操作重（完全停止、重新启动）通过压测，发现HDD盘高负载jar包下载性能减弱10倍，优化如下： • 云盘解决单机IO瓶颈的问题，存储上实现水平扩容。 • 通过多线程异步加载jar包，彻底抹去jar包下载时间！

23. AZ逃生业务方挑战保障全链路AZ逃生能力 • 建设定期沟通机制，提供用户手册、指导用户改造。 • 自动巡检，通过血缘等检测作业逃生能力。 • 资源管理，协调用户资源腾挪、提示资源风险等。同时，定期演练，确保整体的逃生能力并无一遗漏。

24. AZ逃生整体架构

25. AZ逃生结果 1. 整体逃生由小时级别降低到分钟级别，主要通过IO异步加载、水平扩展及云盘存储等技术。 2. 建立起分级保障机制，在AZ逃生、资源优化、稳定性保证等方面意义重大。

26. 04 未来规划

27. 未来规划存算分离 Runtime adaption 湖仓一体建设分层存储，支持超大状态动态扩缩容支持流批一体的计算引擎全面提升稳定性和性能动态增、删、改算子支持统一的数据湖存储

28. 感谢观看