快手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. 感谢观看

Главная - Вики-сайт
Copyright © 2011-2024 iteam. Current version is 2.137.3. UTC+08:00, 2024-12-05 17:38
浙ICP备14020137号-1 $Гость$