Apache Pulsar Broker初始化失败：initContainer检测ZooKeeper异常

通过ArgoCD在EKS集群部署v3.8.0版本的Apache Pulsar Helm Chart，Broker及依赖它的Proxy初始化失败，其initContainer持续输出以下日志：

pulsar cluster pulsar-cluster-dev isn't initialized yet ... check in 3 seconds ...

本地端口转发ZooKeeper后可正常连接，且ZK中/admin/clusters/pulsar-cluster-dev条目已正确配置，内容如下：

[zk: localhost:2181(CONNECTED) 0] get /admin/clusters/pulsar-cluster-dev
{"brokerClientTlsKeyStoreType":"JKS","brokerClientSslFactoryPlugin":"org.apache.pulsar.common.util.DefaultPulsarSslFactory","brokerClientTlsEnabledWithKeyStore":false,"brokerClientTlsTrustStoreType":"JKS","brokerServiceUrlTls":"pulsar+ssl://pulsar-broker.dev.svc.cluster.local:6651/","brokerClientTlsEnabled":false,"tlsAllowInsecureConnection":false,"serviceUrl":"http://pulsar-broker.dev.svc.cluster.local:8080/","serviceUrlTls":"https://pulsar-broker.dev.svc.cluster.local:8443/","brokerServiceUrl":"pulsar://pulsar-broker.dev.svc.cluster.local:6650/"}

相关initContainer配置及Argo Application配置见下文。

可能的原因分析 #

• 镜像版本不兼容：initContainer使用apachepulsar/pulsar-all:4.0.1，与部署的Pulsar Chart 3.8.0版本差异较大，可能导致zk-shell命令行为不一致
• Pod到ZK的网络连通性问题：本地能访问ZK，但Broker/Proxy Pod可能存在DNS解析失败、网络策略限制等问题，无法正常访问pulsar-zookeeper:2181
• 命令超时逻辑缺陷：initContainer内部的timeout 15设置过短，ZK响应延迟时命令直接返回失败，触发无意义的循环等待
• ArgoCD初始化流程冲突：设置useReleaseStatus: false后，Chart的初始化Job可能未正确执行或完成元数据验证

解决方案 #

1. 对齐initContainer镜像版本 #

将initContainer镜像替换为与Chart版本匹配的apachepulsar/pulsar-all:3.8.0，避免版本差异导致的命令兼容性问题：

initContainers:
  - args:
      - |2-

        export BOOKIE_MEM="-Xmx128M"; until timeout 15 bin/pulsar zookeeper-shell -server pulsar-zookeeper:2181 get /admin/clusters/pulsar-cluster-dev; do
          echo "pulsar cluster pulsar-cluster-dev isn't initialized yet ... check in 3 seconds ..." && sleep 3;
        done;
    command:
      - timeout
      - "600"
      - sh
      - -c
    image: apachepulsar/pulsar-all:3.8.0  # 修改为与Chart一致的版本
    imagePullPolicy: IfNotPresent
    name: wait-zookeeper-ready
    # 其余配置保持不变

2. 验证Pod到ZK的网络连通性 #

在initContainer中临时添加网络诊断命令，确认访问ZK的可行性：

initContainers:
  - args:
      - |2-

        # 先执行网络诊断
        ping -c 3 pulsar-zookeeper && nslookup pulsar-zookeeper && telnet pulsar-zookeeper 2181;
        # 原等待命令
        export BOOKIE_MEM="-Xmx128M"; until timeout 15 bin/pulsar zookeeper-shell -server pulsar-zookeeper:2181 get /admin/clusters/pulsar-cluster-dev; do
          echo "pulsar cluster pulsar-cluster-dev isn't initialized yet ... check in 3 seconds ..." && sleep 3;
        done;
    # 其余配置不变

若诊断命令失败，检查：

• ZK Service状态：kubectl get svc pulsar-zookeeper -n dev
• 命名空间网络策略是否允许访问2181端口
• CoreDNS是否正常解析服务名

3. 调整命令超时逻辑 #

移除initContainer内部的timeout 15限制，避免提前终止命令：

initContainers:
  - args:
      - |2-

        export BOOKIE_MEM="-Xmx128M"; until bin/pulsar zookeeper-shell -server pulsar-zookeeper:2181 get /admin/clusters/pulsar-cluster-dev; do
          echo "pulsar cluster pulsar-cluster-dev isn't initialized yet ... check in 3 seconds ..." && sleep 3;
        done;
    command:
      - timeout
      - "600"
      - sh
      - -c
    # 其余配置不变

4. 确保初始化Job正确执行 #

由于ArgoCD不跟踪Release.IsInstall状态，手动触发初始化Job：

kubectl apply -f <(helm template pulsar apache/pulsar --version 3.8.0 -n dev --set initialize=true,useReleaseStatus=false,clusterName=pulsar-cluster-dev --show-only templates/initialize.yaml)

等待Job执行完成后，再同步ArgoCD Application。

5. 手动验证容器内命令执行结果 #

进入initContainer容器，手动执行命令排查具体错误：

kubectl exec -it <broker-pod-name> -c wait-zookeeper-ready -n dev -- bash
bin/pulsar zookeeper-shell -server pulsar-zookeeper:2181 get /admin/clusters/pulsar-cluster-dev

观察命令输出，确认是否存在认证、路径权限等细节问题。

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