云原生中间件 — 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
官网地址:
https://strimzi.io/

08

总结

Strimzi Kafka Operator 是通过使用 java 语言开发一套 Operator 框架,基于此框架,设计和实现的 Kafka Operator。随着 Kafka 上云的需求不断提出,相信 Strimzi Kafka Operator 会得到很好的发展。


 本文作者 :熊中祥

「DaoCloud 道客」技术合伙人

云原生技术专家

DaoCloud 公司简介:「DaoCloud 道客」云原生领域的创新领导者,成立于 2014 年底,拥有自主知识产权的核心技术,致力于打造开放的云原生操作系统为企业数字化转型赋能。产品能力覆盖云原生应用的开发、交付、运维全生命周期,并提供公有云、私有云和混合云等多种交付方式。成立迄今,公司已在金融科技、先进制造、智能汽车、零售网点、城市大脑等多个领域深耕,标杆客户包括交通银行、浦发银行、上汽集团、东风汽车、海尔集团、屈臣氏、金拱门(麦当劳)等。目前,公司已完成了 D 轮超亿元融资,被誉为科技领域准独角兽企业。公司在北京、武汉、深圳、成都设立多家分公司及合资公司,总员工人数超过 400 人,是上海市高新技术企业、上海市“科技小巨人”企业和上海市“专精特新”企业,并入选了科创板培育企业名单。

未经允许不得转载:DaoCloud道客博客 » 云原生中间件 — Kafka Operator 总览篇

申请试用