helm 部署 bitnami/zookeeper 是最稳方案，省去手写 statefulset、myid 和 zoo.cfg 配置；需设 replicacount=3、persistence.enabled=true、storageclass 及合理 resources；验证须进容器用 zkcli.sh 连各节点测试 quorum。
直接用 Helm 部署 bitnami/zookeeper 是当前最稳、最省事的方案，不用手写 StatefulSet、不用调 myid、不碰 zoo.cfg 里一堆端口配置——除非你有强定制需求或审计硬性要求。
为什么别从头写 StatefulSet 配置
官方推荐的 StatefulSet YAML 看似规范，但实际踩坑点密集：
-
server.1=zk-0.zk-hs:2888:3888这类静态配置必须和 Pod 名、Headless Service 名、DNS 解析严格对齐，任意一环错（比如改了serviceName却漏改command中的--servers参数），集群就卡在Waiting for server being ready -
dataDir和dataLogDir若没分开挂载，高并发写日志时会触发磁盘 I/O 争抢，ZK 节点频繁Connection loss - Pod 反亲和策略写成
preferredDuringScheduling而非requiredDuringSchedulingIgnoredDuringExecution，三个副本可能被调度到同一节点，失去容错意义
helm install 时必须显式设的参数
Bitnami Chart 默认值对生产环境偏保守，这几个参数不覆盖基本跑不起来：
-
--set replicaCount=3：ZooKeeper 奇数节点是法定人数（quorum）前提，1或2节点无法容忍任何故障 -
--set persistence.enabled=true：禁用持久化等于重启即丢集群状态，leader选举失败率飙升 -
--set persistence.storageClass=your-storageclass：不能依赖defaultStorageClass，NFS/HostPath 类型在多节点间同步延迟会导致zxid不一致 -
--set resources.requests.memory=1Gi：ZK JVM 堆默认只配 512Mi，稍大点的 watch 事件堆积就会 OOMKill
验证 ZooKeeper 集群是否真可用
kubectl get pods -n zookeeper 全 Running 不代表服务就通——ZK 的 clientPort 可能监听了，但内部 quorum 没形成。必须进容器实测：
执行：kubectl exec -it zookeeper-0 -n zookeeper -- zkCli.sh -server zookeeper-0.zk-hs:2181
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
进去后运行：ls /，如果返回 [zookeeper] 且无超时，说明单点连通；再换连 zookeeper-1.zk-hs:2181，能同样返回才确认集群级可用。
常见失败现象：Exception closing session 0x0: org.apache.zookeeper.KeeperException$ConnectionLossException —— 多半是 DNS 解析慢或 tickTime/initLimit 在底层被 Chart 覆盖成过小值（Bitnami 默认 tickTime=2000 安全，但若你覆盖了 zookeeper.extraEnvVars 误设为 500 就会崩）。
应用连接 ZooKeeper 的 endpoint 写法
客户端代码里填的地址不是 zookeeper:2181 这种 ClusterIP Service 地址，而是 Headless Service 的 DNS 名：
- 集群内访问：用
zookeeper-0.zk-hs.zookeeper.svc.cluster.local:2181（单点）或拼接全部三个：zookeeper-0.zk-hs,zookeeper-1.zk-hs,zookeeper-2.zk-hs:2181 - Java 客户端（Curator/ZKClient）会自动解析并轮询，但必须确保传入的是逗号分隔的完整列表，少一个节点名，初始化阶段就报
Unable to connect to server - 千万别把
zk-hs（Headless Service）和zk-cs（ClusterIP Service）混用——后者只做负载均衡，ZK 协议本身不支持后端多实例共享连接，会直接断连
真正麻烦的从来不是部署动作本身，而是确认「三个 Pod 都能互相握手成功」这件事——它藏在 DNS、网络策略、JVM 参数、甚至底层 storageclass 的 sync 模式里，任何一个环节松动，ZK 就退化成单点伪集群。
