StreamNative Cloud for Kafka
目前 StreamNative Cloud for Kafka 服务是预测试版本,只对少数用户定向开放体验。
StreamNative Cloud 简介
StreamNative Cloud 提供了全托管(Cloud-Hosted)和半托管(Cloud-Managed)两种云端服务,前者是由 StreamNative 提供的全 SaaS 服务,用户可以在云端以 SaaS 模式使用 Pulsar——注册账号后,团队即可创建集群,并根据暴露的地址进行使用。半托管服务和全托管一样,在控制面都使用 StreamNative 的 API 服务,但区别在于前者允许用户将集群负载建立并运行在自己的云环境中。StreamNative Cloud 操作体验统一、学习成本低,并且用可以把业务流量的负载都保留在自己的集群内。
StreamNative Cloud 简介
- • StreamNative Cloud 的架构基础设施完全依托于 K8s 实现,目前提供了 AWS 和 GCP(GoogleCloud Platform) 的支持,后期将加入对 Azure、阿里云等云厂商的支持。
- • StreamNative Cloud 的存储服务目前只提供了 Bookie 的基本存储,默认使用各个云厂商提供的网络云盘,最大程度减轻运维压力。未来会考虑基于各个云厂商的对象存储做扩展。
- • StreamNative Cloud 的计算服务提供了 Pulsar Broker 和 Pulsar Functions 服务。
StreamNative Cloud for Kafka 简介
StreamNative Cloud for KafkaⓇ 是基于 StreamNative Cloud 提供的一个兼容 Kafka API 的云端服务,核心组件主要包括:
- • Kafka-on-Pulsar(KoP):对 StreamNative Cloud Broker 组件开启 KoP 服务;
- • Cloud Enhanced Networking(Istio): 使用 Istio 对 StreamNative Cloud 中服务进行协议代理和流量管理。
StreamNative Cloud for Kafka 特性
在云端环境提供 KoP 可以很好地结合 Kafka 和 Pulsar 两大主流消息中间件服务各自的优势:
- • 打破 Kafka 存在的诸多限制:如突破 Kafka Topic 数量限制,达到千级别 topic 后,单集群会受到很大影响,而 KoP 通过 Pulsar 存储计算分离不会受到 Kafka 的限制;简单扩缩容,不会受到 Kafka Rebalance 限制等;利用了 Pulsar 内置的多租户和跨地域复制功能。企业与团队无需再设计变通方案来共享 Kafka 集群,通过 Pulsar 中的租户、命名空间和可执行策略即可使用稳固的模型来共享集群,适用于事件驱动架构和基于微服务的应用程序。
- • 弥补 Pulsar 的生态不足:Pulsar 在生态上和 Kafka 仍有差距,比如 Client SDK 和 Connector 在数量和广度上不如 Kafka。KoP 提供对 Kafka API 提供完整兼容支持,充分利用两大生态;
- • 功能齐全的管理模式;简化基础设施的同时支持不同的场景。
StreamNative Cloud for Kafka 优势
StreamNative Cloud for Kafka 使用
目前该服务处于内测阶段,感兴趣的用户可以进入 网页 [1] 申请试用。
点击上述开关,选择对应规格的机型、创建对应服务即可获得开启 KoP 的 Pulsar 集群。
主要的配置均已自动完成,系统会提供 KoP 访问的公网域名(如上图),使用该域名即可连接自己的 Kafka 程序。
实现原理
KoP 服务暴露 - NodePort
在 K8s 环境中使用 KoP 时,如何暴露服务是最基础的问题。 Pulsar 和 Kafka 在这里有所不同,前者相对比较简单,Pulsar 使用了 Proxy 服务帮助 Broker 做 Topic lookup 和读写消息转发,部署好 Proxy 后将 Proxy service 地址映射出去,客户端只需要访问地址而无需关心每个 Broker 的地址; Kafka 在 K8s 环境下则常常需要依赖 NodePort 来暴露服务。
KoP 服务暴露 - LoadBalancer
Kafka 在 K8s 环境下除了可以依赖 NodePort 来暴露服务,在实践中还可以基于 LoadBalancer 来暴露服务,这里借助了 Istio 的路由能力来暴露 Kafka Broker。
Istio 集成
StreamNative 团队衡量两种 Kafka 暴露服务方案后,最终选择了基于 Istio 的暴露方法,因为 StreamNative Cloud 引入 Istio 有很多优势:
- • 实现多协议的统一访问代理:Pulsar / KoP / MoP……
除了 KoP,Pulsar 还有多个插件协议如 MoP、AoP、RoP,通过 Istio 可以实现多协议的统一访问代理的管理,也方便未来增加新的插件协议后进行扩展。 - • 更安全的内部通信访问:Strict mTLS in Peer authentication
Istio 也可以为全托管的服务内部提供安全性保障。在集群注入 Istio 后,默认各服务之间用 Strict mTLS 通信。单集群内的 ZooKeeper、BookKeeper、Broker 等组件都可以在 mTLS 加密下进行通信。 - • Cloud 上复杂网络拓扑的管理:支持跨云服务,提升可靠性;
容灾级别高、数据安全性要求级别高的用户,可以同时跨多个云各自创建 Pulsar 集群,并开启跨地域复制服务进行数据同步。即使某个云厂商大面积故障,用户也可以进行切换,受到的影响非常小。跨地域复制特性本身可以对订阅进行复制,故障集群切换后也可以按照之前消费 offset 信息进行消费。 - • 更精细的流量管理:异常流量的熔断、服务的灰度升级等等。
使用 Istio 后,Lookup 访问情况如下:
上图中共有四个客户端,橘色与红色客户端都在 K8s 内部,分别访问 Kafka 和 Pulsar 地址。对内部服务来说访问方式不变,直接访问 Broker 对应的 LoadBalancer 地址,连接 Broker 的无头服务。K8s 集群外部的客户端需要通过 Istio 网关,借助其路由能力访问具体的域名地址。网关会将流量转发到 K8s 服务的地址上,最终到达具体的 Broker。上图中 6652 和 6650 端口、9092 和 9094 端口的作用一致,只是为了更好地区分流量而分别处理。
KoP 原理相同,从外部 9093 端口访问后会被终止,继而访问 9094 端口。外部 Pulsar 与 Kafka 客户端访问后会获取目标 Broker 的地址,这是 Lookup 后获得的连接地址,可以通过网关来访问。
Lookup 结束后,开始生产和消费访问:
外部客户端获得 Broker 地址后,生产和消费访问会通过映射到网关转发到对应的 Broker 上,不再通过 K8s 服务。内部客户端则不受影响。通过这种方式后不再需要 Pulsar Proxy,全部流量统一通过 Istio 管理,防止 KoP 无法使用仅 Pulsar 自带的 Proxy 服务。
这种方案需要管理的服务和配置数量较多,比较复杂,为此 StreamNative 团队在 Pulsar Operators 上做了扩展:
- • Broker CRD 增加 ProtocolHandlersConfig、KoPProtocolHandlerConfig 等配置,简化 KoP 相关配置管理;
- • Broker CRD 增加 IstioConfig,实现 Gateway、VirtualService、DestinationRule 自动创建和监听。
未来规划
StreamNative Cloud In China 未来计划:
- • 在国内提供基于 AWS China 的云托管服务;
- • 对接更多国内公有云:阿里云、华为云等;
- • 提供 StreamNative Cloud for Kafka 的试用体验;
- • 提供 StreamNative Cloud for MQTT 的试用体验。