高性能 Kubernetes 元数据存储 KubeBrain 的设计思路和落地效果

如果无法正常显示,请先停止浏览器的去广告插件。
分享至:
1. KubeBrain 字节跳动高性能 K8s 元信息存储 许辰 字节跳动资深研发工程师
2.
3. 许 辰 字节跳动基础架构工程师  本科和硕士毕业于北京大学计算机系  负责大规模 Kubernetes 系统的构建和优化  KubeBrain/ KubeGateway/ KubeZoo 等多个项目的发起人
4. • 背景介绍 • 设计思路 • 性能优化 • 落地效果 • 未来演进
5. 背景 • • Kubernetes 规模增大 10 倍以上  公司业务快速发展  存储、大数据、机器学习等场景云原生化 新场景对 Kubernetes 性能要求更高  离线场景,Pod 生命周期短、变更频率高
6. 如何扩展 Kubernetes 集群 多个集群横向扩展 单个集群规模垂直扩展    降低运维管理成本 减少资源碎片 提高资源利用率
7. Kubernetes 的架构特点 K8s 各组件 apiserver etcd apiserver 中心化架构 随着规模增大存储系统成为瓶颈 所有组件通过 apisever 交互 etcd 存在性能问题
8. 元信息存储 etcd
9. etcd 存在的问题
10. 自研元信息存储 如何解决存储瓶颈? 调优 etcd 参数 设计新的元信息存储 按照对象拆分 etcd … KubeBrain 1. 大脑 2. 谐音科比 Kobe Bryant
11. • 背景介绍 • 设计思路 • 性能优化 • 落地效果 • 未来演进
12. K8s 元信息存储的需求 (1)  读 • 单 Key 读,提供线性一致性 • Range 扫描读,支持快照读,支持分页  写 • K8s 乐观锁 resource version • 单 Key CAS  Watch • Kubernetes list-watch 的底层依赖
13. K8s 元信息存储的需求 (2)
14. K8s 元信息存储的需求 (3) 所以 etcd 为目前 K8s 唯一支持的存储
15. KubeBrain 架构 Kine KubeBrain
16. KubeBrain 架构 • 主从架构 • 主负责写和事件分发 • 从负责读 • 底层对接分布式强一致性存储 • CAS 事务写 • 快照读
17. 实现架构图
18. 存储层
19. 存储层 – 分布式 KV Store ByteKV • Multi Raft Goup • 全局有序 Range 分区 • 强一致性 • 支持多 • 支持 key 事务 CAS • 支持快照读 • 高性能
20. 存储层 - 数据格式 etcd Etcd 以 Revision 为 Key 内存 Btree 索引维护 key 和 revision 的映射关系 KubeBrain 能否使用类似的格式? 1. 否 2. 底层存储引擎全局有序,有写热点那问题
21. 存储层 - 数据格式 KubeBrain
22. 逻辑层
23. 逻辑层 – 写
24. 逻辑层 – Watch(1) Watch 机制本质上是一个消息队列系统 1. 可靠性 - 不重复、不丢失 2. 顺序性 - 保证最终状态的一致性 3. 实时性 - 高性能 一定有一个单点对消息进行排序 采用主从架构
25. 逻辑层 – Watch(2) 一主多从 1. 仅主节点负责写入和事件生成 2. 从节点只读
26. 逻辑层 – Watch(3) • Master 内存中保留最近写入的 事件 • 写入滑动窗口记录并发写操作的 结果 • 消费滑动窗口中的数据实现有序 的 Event 推送 • 当前消费的最大位置为 Brain 层 的 Committed Index,与 快照 读有关
27. 逻辑层 – 单 Key 读
28. 逻辑层 – Range 读
29. 逻辑层 – Range 读一致性 • Range 从 Leader 获取滑动窗 口当前 Committed Index 序 号 • 根据当前序号进行快照读 • Range 后 Client 通过 Watch 从leader RingBuffer 中获取 增量事件,达到 最终一致性
30. 逻辑层 – 选主
31. 逻辑层 – TSO
32. 接入层
33. 接入层
34. 客户端
35. 客户端
36. K8s 元信息存储的需求
37. • 背景介绍 • 设计思路 • 性能优化 • 落地效果 • 未来演进
38. 性能优化
39. 写优化 - 1 降低锁粒度 存储引擎替换 表锁 -> 行锁,增大了写的并发
40. 写优化 - 2 单点写 -> 多点写 multi raft range 分片,增大写并发 Brain 层无磁盘 io,只有网络 io
41. 写优化 - 3 事务优化 精心设计 key 格式 一个 k8s 对象的索引和数据在同一分区内 跨分区分布式事务 -> 分区内单机事务
42. 读优化 - 1 Range 读 Unary -> Stream 代替分页,降低延迟 内存高效复用,避免 OOM
43. 读优化 - 2 多分片并发读 通过并发,大大减少读时延
44. 读优化 - 3 读写分离 follower 可以无限扩展,没有 raft 同步问题 读写之间无相互影响
45. 读优化 - 4 Count 优化 基于周期性 Compact 统计,存在内存 降低时延,减轻存储压力
46. Watch 优化 - 1 写性能提升带来直接收益 写延迟降低,watch 延迟自然会降低
47. Watch 优化 - 2 纯内存态实现 无延迟损耗
48. Watch 优化 - 3 逻辑优化 update 方法中,PreKV 字段 apiserver 不会使用,减少一次读
49. 压测数据
50. • 背景介绍 • 设计思路 • 性能优化 • 落地效果 • 未来演进
51. 落地效果  压测环境 •  配合 apiserver 优化手段,规模达 5w 节点 200w Pod 生产环境 • 2 W 节点 100w Pod 超大集群,有效降低资源碎片率
52. 落地效果 读写 QPS > 1w
53. • 背景介绍 • 设计思路 • 性能优化 • 落地效果 • 未来演进
54. 影响力构建 已经开源,以 TiKV 作为存储引擎 集成进入 Kubernetes 作为新型 Storage Backend
55. 持续优化和完善系统
56. 架构演进 • 目前所有消息严格要求有序 消息不重不丢、严格有序,所以写必须单点 • • Kubernetes 本质是一个最终一致性的系统 • • 关注单个对象的最终状态 分片多点写,避免写单点 • 分片内部消息严格有序 • 分片间消息可以乱序 • 读、写、watch 能力均可以水平扩展
57. 欢迎交流 联系邮箱: 扫码关注 KubeBrain: xuchen.xiaoying@bytedance.com
58.
59.
60.

ホーム - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.1. UTC+08:00, 2024-11-15 17:30
浙ICP备14020137号-1 $お客様$