OpenShift上采用Route监听器类型的Strimzi Kafka集群能否外部访问Zookeeper

核心结论 #

• Strimzi 原生没有提供Zookeeper外部访问的配置能力，架构设计上也不推荐将Zookeeper暴露到集群外部
  Zookeeper作为Kafka集群的元数据核心存储组件，一旦开放外部访问，误操作极易造成集群元数据损坏、整体服务不可用，安全风险极高。Strimzi 的所有集群管理逻辑，都是通过Kafka Broker的Admin API完成，从设计层面就不会直接开放Zookeeper的外部链路。
• 日常Kafka CLI管理操作完全不需要直连Zookeeper
  所有Kafka官方提供的管理类CLI（Topic创建/删除/配置查询、集群配额调整、生产消费测试等），都可以直接对接Kafka Broker的监听端口完成操作，不需要和Zookeeper建立连接。

两种可落地的CLI管理方案 #

• 本地主机直连操作
  下载和当前集群Kafka版本完全匹配的Kafka二进制压缩包，使用包内自带的CLI工具即可，常见工具包括kafka-topics.sh、kafka-configs.sh、kafka-console-producer.sh等。只需要提前配置好客户端的TLS证书、认证信息，对接你已经配置好的外部443端口监听器，就可以在本地完成所有常规运维操作，全程不需要访问Zookeeper。
• Kafka Pod 内操作
  如果觉得本地配置证书链路比较繁琐，可以直接通过OpenShift UI或CLI登录到Strimzi部署的Kafka Pod内部。Strimzi 构建的Kafka容器镜像中，已经预装了对应版本的全部Kafka CLI工具（包含上述提到的所有官方脚本），同时内置了集群内部的认证证书、客户端配置参数，进入Pod后可以直接运行CLI命令完成集群管理，同样是通过内部监听器连接Kafka Broker，不需要直连Zookeeper。

风险提示 #

即使你手动通过自定义Service、路由等方式打通Zookeeper的外部访问链路，也极不推荐做长期的外部暴露配置：

• 手动修改的Zookeeper相关资源，会被Strimzi Operator的持续 reconcile 逻辑覆盖，维护成本极高
• Zookeeper层面的操作没有Kafka层的权限校验机制，一旦出现误操作没有回滚保护，极易导致集群故障
  如果确实需要临时排查Zookeeper层面的故障，建议通过临时端口转发的方式连接Zookeeper，排查完成后立刻关闭转发链路。

内容的提问来源于stack exchange，提问作者Barat Sahdzijeu