云原生中间件 — Kafka Operator 总览篇
中间件的上云进入到了一个真正的生产落地的过程,Kafka 作为一个高性能,高吞吐能力的消息系统,被很多系统采用。对于 Kafka 的上云,是几乎每一个客户都会提出的需求。接下来,就来了解社区中在 Kafka 上云的实践,以及相关技术分析。本文介绍以 CNCF 的 Strimzi Kafka Operator 项目为例进行分析。对于云原生的中间件一些设计规范和思路,可参见 云原生中间件 -- Redis Operator 篇 。
01 需求分析
首先,先来大概分析一下,客户对 Kafka 的使用需求大概有哪些。
Topic 的管理
用户的管理
权限的管理
集群的高可用
集群的统一外部访问入口
集群的监控和告警
集群的扩缩容
跨集群的数据复制
集群的数据的 Rebalance
集群的自动化运维能力
云原生方式提供服务
页面化管理集群的能力
大数据组件对接
开放的 API 能力,方便上层能力的建设
存储的开放性,适配 CSI
部署编排的多样性
集群负载智能分析和扩容计划的执行
集群版本的兼容和升级
集群的数据传输安全
集群异构环境的适配能力
租户隔离
02 相关术语
Strimzi Kafka Operator:社区的 Kafka Operator 的实现。Kafka 还是那个 Kafka,特点是结合了各种技术,为 Kafka 添加了云原生特色,让其成为了云原生 Kafka 系统。
User:Kafka 的客户端连接 Kafka 集群,需要设置的认证相关的配置信息。
ACL:安全访问控制,定义了哪些 User 可以访问哪些资源,如 Group,Topic。
Connect:顾名思义理解成连接,用于解决连接到外部数据源的意思。
Connector:连接器,用于真正执行连接到数据源之后,数据的处理能力。
Bridge:桥,指的是连接 http 的 client 到 Kafka 集群的能力,通过 http 的 api 的方式发送和消费消息。
Source:源,指的是源头,代表被处理的数据所在的位置。
Sink:这里指的是将什么放入什么的意思,比如将从文件读出来的数据,处理好之后保存到数据库中,那数据库就是 Sink 的对象。
MirrorMaker:可以理解成流量的复制,从一个集群复制到另一个集群。
Exporter:这里指的是 Prometheus 的 Exporter,用于导出监控的数据到 Prometheus 这个时序数据库。
Rebalance:再平衡/重新平衡,在 Kafka 集群运行一段时间之后,对着对集群的运维,增加或者删除节点,分片和副本在机器上分布不均衡,会导致有的机器负载很高,有的很低,需要再平衡的方式来保持机器的负载都是相对合理的。
Cruise-control:字面意思理解成定速巡航,实际在 Kafka 中,代表着控制 Kafka 集群的运行状态,让其保持稳定,通过 Rebalance 的方式完成。
Broker:Kafka 集群的真正的工作节点,用于提供客户端连接,调度分片和副本,接收消息,保存消息,传递消息。
Topic:这是消息系统中的常见概念。用于定义消息队列。
分片:分片定义了消息存储和消费的位置。一个 Topic 可以有多个分片,一个分片可以有多个副本。
副本:副本是为了保证消息的可靠性,使用冗余的机制,数据的副本数据分布在不同的机器。
03 能力介绍
以下架构图介绍了 Strimzi Kafka Operator 提供的围绕 Kafka 集群的整体能力,这里暂不涉及 Strimzi Kafka Operator 本身内部的实现架构,在后面部分会介绍 Strimzi Kafka Operator 本身内部的实现架构。
Kafka Cluster:这里指的就是 Kafka 集群的 Broker 节点组成的集群,可以在创建的时候设置集群的规模。
Kafka Connect:这里指的是通过 Kafka 的 Connect 能力封装的消费数据源数据进行处理之后输出到其它系统的能力,可以用来完成数据的处理和加工。
Kafka Bridge:这里的 Bridge 提供了基于 http 的 api 的的方式和 Kafka 集群进行数据通信的能力。
Kafka Exporter:这里的 exporter 是 Prometheus 的 exporter 规范的实现,提供了监控 Kafka 集群的能力。
Kafka MirrorMaker:这里的 MirrorMaker 是实现了不同的 Kafka 集群之间,数据进行复制的能力。
ZooKeeper:这里的 ZooKeeper 主要用于 Kafka 集群本身的依赖,同时也会保存 Strimzi Kafka Operator 本身的一些内部的业务数据。
04 业务模型
StrimziKafka Operator 提供的一些常见的能力介绍。
Kafka:这是创建和管理 Kafka 集群的资源对象,会根据配置创建 Brokers,ZooKeeper 集群,设置需要的存储,开启集群监控,开启用户管理能力,开启 Topic 管理能力,设置安全通信,设置对外访问方式,开启 Cruise Control 能力。在集群创建成功之后,会在状态中展示 Kafka 集群的连接地址
KafkaTopic:用户在 Kafka 集群中创建出 Topic,对应的会在 Kafka 的集群中创建出 Topic 出来。
KafkaUser:创建用户,用于在客户端连接的时候,使用对应的用户进行连接,同时会为用户设置对应的权限,如对哪些 Topic 有 Read 权限,哪些有 Write 权限,哪些有 Describe 权限,哪些有 Create 权限等等。没有设置正确的权限,会影响正常的 Topic 的访问。
KafkaRebalance:用于定义对 Kafka 集群的哪些资源的使用情况进行智能的分析,定义分析的目标,以及根据定义的分析目标,生成推荐的运维提案,以便根据推荐的方式对 Kafka 的集群进行合理的运维。
KafkaConnect:定义了 Kafka 的 Connect 能力,会启动一个工作负载,提供 http 的服务。Kafka 本身已经定义了一些开箱即用的 Plugins,用于对外部数据进行消费处理,当然也可以定义开发需要的插件。KafkaConnect 会创建工作负载,用于运行这些插件,同时提供 RestAPI 去查询有哪些 Plugins,以及有哪些 connectors 在运行和处理数据,这个 connector 就是真正处理数据的地方。
KafkaConnector:用于定义真正运行数据处理能力的 connectors。以下例子定义了读取文件数据,然后发送到 Topic 的能力,这里有一个最大 Task 的定义。
KafkaMirrorMaker / KafkaMirrorMaker2:完成两个 Kafka 集群之间数据的复制,举例来说两个机房的两个 Kafka 之间数据保持同步的能力。以下例子定义了源集群和目标集群,以及定义了进行复制能力的 Connectors。
KafkaBridge:定义通过 RestAPI 的方式完成消息的发送和消费的能力,会启动工作负载,提供 http 的服务。以下例子定义了启动一个副本的工作负载,监听了 8080 端口提供 http 的 API 能力,同时 Kafka Bridge 连接到 Kafka 集群,最终完成 web client 通过 Kafka Bridge 提供的 RestAPI 去发送和消费消息。
05
架构介绍
总体架构:主要包含了以下 Operator 的能力,构建出了 Kafka Operator 的核心能力,其中 MirrorMaker 相关包含 MirrorMaker 和 MirrorMaker2 两个版本,以及 Kafka Connect 包含 KafkaConnectOperator 、 KafkaConnectorOperator 和 ConnectBuildOperator。
Cluster Operator:包含了 Strimzi Kafka Operator 所需相关的所有的 Operators 的包装,包括 KafkaOperator、KafkaConnectOperator、KafkaMirrorMakerOperator、KafkaMirrorMaker2Operator、KafkaBridgeOperator、KafkaRebalanceOperator,以及启动这些 Operators。
Kafka Operator:主要完成整个 Kafka 集群的创建,包含 Kafka 的 Brokers,Kafka 依赖的 ZooKeeper 集群,负责创建 UserOperator 和 TopicOperator 的 Entity Operator,监控 Kafka 集群的 Kafka Exporter,用于智能分析 Kafka 实际运行负载的 Cruise Control,Kafka 对内/对外的安全通信的 TLS,以及 Kafka 对外提供访问的方式。
Entity Operator:这里的 Entity 可以理解成 Kafka 集群的业务实体,对于 User 和 Topic 就是业务实体,每一套的 Kafka 集群的 User 和 Topic 都是独立管理的。Entity Operator 负责创建出 UserOperator 和 TopicOperator 实例,用于管理单个 Kafka 集群的 User 和 Topic 的业务处理。每一套 Kafka 集群都有独立的 Entity Operator。
User Operator:负责创建出 User,这里的 User 的表现形式主要包括 Mutual TLS client 客户端证书形式的 User 定义,SASL SCRAM-SHA-512 形式的 User 定义,OAuth 的 User 形式。同时根据用户的权限的配置生成对应的鉴权配置,控制用户对 Topic 以及 Group 等 Kafka 的能力进行安全访问控制。
每一套 Kafka 集群都有独立的 User Operator。
Topic Operator:复杂根据期望的 Topic 的配置在 Kafka 中创建 Topic,包括分区数,副本数,retention.ms 的时间,segment.bytes 的大小等 Topic 相关的配置。每一套 Kafka 集群都有独立的 Topic Operator。
KafkaConnect Operator:KafkaConnect 资源对象负责创建 Kafka Connect 服务,用于管理 Kafka Connector。
KafkaConnector Operator:Kafka Connector 资源对象会使用 Kafka 的插件,启动对应的 connector task 去消费数据,处理数据和传输数据到外部存储系统。
ConnectBuild Operator:负责根据插件的源代码去构建出新的 connectors 镜像,根据构建出来的这些新的能力,去处理数据。 在 Kubernetes 平台上使用 Kaniko, 在 OpenShift 使用 BuildConfig 去完成镜像的构建。
KafkaBridge Operator:负责启动 Bridge 的服务,Bridge 服务提供 RestAPI 的方式接受客户端的发送消息请求和消费消息的请求。
Kafka MirrorMaker Operator:完成 Kafa 集群之间的数据的复制工作,可以是单向的复制,也可以是双向的复制,可以用来搭建 Kafka 集群的灾备方案。
06 监控
07 社区
Strimzi Kafka Operator 是基于 Kubernetes 容器技术来解决 Kafka 上云的开源项目,现托管于 CNCF 中。
项目地址:
https://github.com/strimzi/strimzi-kafka-operator
官网地址:
08 总结
Strimzi Kafka Operator 是通过使用 java 语言开发一套 Operator 框架,基于此框架,设计和实现的 Kafka Operator。随着 Kafka 上云的需求不断提出,相信 Strimzi Kafka Operator 会得到很好的发展。
本文作者
熊中祥
「DaoCloud 道客」技术合伙人
云原生技术专家
版权声明: 本文为 InfoQ 作者【Daocloud 道客】的原创文章。
原文链接:【http://xie.infoq.cn/article/1b73cb6d0d4a586b4025d2d0b】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论