Kubernetes Kafka知乎流式处理平台介绍

1、Kubernetes Kafka知乎流式处理平台介绍技术创新 变革未来史前故事“遗孤组件”自研日志收集工具自研消息队列 业务重度依赖！无人维护状态。问题逐步暴露知乎规模迅速扩张 & 业务稳定性要求增加遗孤组件逐步暴露问题 无法扩展 功能缺陷 监控黑盒体验是这样的日志存储服务器三天两头爆掉 （该删谁的日志）排查问题几乎没有监控指标 （没人敢重启）资源找不到业务 Owner （迁移数据办公室里人肉吼）大量人肉维护工具脚本 （经常失效，频繁更改配置）接锅心情是“呵呵”的明确问题 & 明确方案明确问题和方案系统无法扩展 资源没有管理系统不可监控大量人工维护维护两套技术设施 分布式方案平台方式管理完备监

2、控报警操作全面自动化统一技术设施 -分布式方案 - 核心组件选型选择“大腿”核心消息队列组件：Kafka 数据管道组件：Flume 满足日志收集和消息队列功能 （减少维护设施）分布式方案统一基础设施基础组件架构Kafka 平台管理平台申请 Kafka Topic 完全自动化资源有效管理Kafka 资源形态Kafka Topic 支持三种业务类型：LogDataMessage完善监控 - 监控不怕多被黑盒运维坑苦后的全维度监控：Topic Level： MSG/S、ISR Number、Consumer Lag Broker Level： Broker CPU、Heap Memory、Threa

3、d CountHost Level： CPU Load、Disk Latency后来的故事全部日志收集迁移 Kafka 正准备消息队列迁移到 Kafka，然而不敢继续了 “一只装满鸡蛋的篮子”两次集群宕机：某 Topic 流量突增，Broker 全挂，集群宕机（First Flood！）集群运维调整，磁盘过载，集群宕机 （Double Kill！）酸爽的结论：单集群不靠谱！反思不同 SLA 要求的业务类型提供隔离的 Kafka 集群多集群困境：维护成本成倍上升多集群负载不均匀维护成本上升1 个 Kafka 集群 VS N 个 Kafka 集群集群利用率偏低流量较小的 Kafka 集群也至少需要

4、 3 台主机怎么破更便利的集群管理系统 （改善运维效率）更细粒度的最小部署单元（改善集群利用率）熟悉的需求场景:知乎容器弹性计算平台巨大启发 （Mesos + Docker）知乎全部业务已在容器平台运行近一年Kafka Broker 容器化 & 集群管理知乎容器弹性计算平台经验：定义资源不可变的最小调度单元（Broker Container）通过调整 Container 数量来 Scale 服务（Broker Number）单个容器可以挂掉，服务可用由业务集群逻辑保证（Kafka Cluster）最小调度单元 Broker 资源选择思路：找出瓶颈资源：Kafka - 磁盘 （详尽压测）资源可以

5、隔离：磁盘间天生物理隔离准则：单块磁盘作为 Broker 容器的基准资源CPU & Memory 按照机型适当选取 主机和容器资源配置主机配置：CPU: 2 * 6 coreMemory: 64GDisk: 12 * 2T (No Raid)Broker Container 设置：1 Disk & 1.5 CPU & 4G Memory 8 Max Container Per Host保留 32G 给系统 cache， 保留 4 Disks 做故障备份 Kafka Container 多集群 利用容器实现资源细粒度调度和故障隔离Kafka 容器集群方案选型 基础设施的集群管理由各个平台独立开发

6、Redis、Beanstalk、ZooKeeper：Golang 自研Loadbalance：Python 自研Container：Mesos + Framework 自研MySQL：Mysos（Mesos + Framework 定制）基础设施需要一套统一的调度编排方案，方便维护和功能复用：KubernetesKafka 容器集群管理方案 Kubernetes 资源调度Platform 集群控制技术平台统一集群管理方案 Kubernetes 作为知乎基础架构统一编排调度框架Kubernetes Kafka 持久卷方案Kafka Broker 是有状态节点需要存储持久化的支持官方持久卷基于网络

7、存储 网络存储的性能问题和维护问题 Kubernetes Kafka 持久卷方案选择本地存储设计持久卷 如果解决 Kubernetes 磁盘资源自动调度？定制本地持久卷调度方案自定义 Kubernetes 第三方资源 （LocalPVPod）节点上报各自的磁盘资源情况首先从磁盘资源维度选择集群节点及可用磁盘路径在调度出来的集群节点创建 Broker Pod本地持久卷调度设计本地持久卷容器 LocalPVPod 设计Kafka Broker 容器细节 Broker 参数配置（id、zookeeper）通过环境变量注入容器通过启动脚本解析环境变量生成配置Kafka Broker 容器细节 保证 t

8、opic replica 跨节点分布Kafka rack awareness 参数配置broker.rack = hostnameexport KAFKA_BROKER_RACK=cat /etc/hostname & /usr/bin/start-kafka.shKafka Broker 容器细节 容器网络方案每个节点预留一个内网可路由的 C 段容器 IP 地址池CNI Bridge 模式：range-start: 10.3.194.3,range-end: 10.3.194.254磁盘容灾方案预留应急磁盘软链方式管理替换问题磁盘客户端设计客户端附加功能：收集端指标集群发现功能集群发现的背后思考集群扩容对业务完全透明 (无需重启)禁止跨业务访问资源 （配置中心命名空间）消灭“野生” Kafka 客户端（不提供 broker 列表）：野生 Ka