Elasticsearch 云原生落地实战：在 Kubernetes 中稳如磐石地跑起一个生产级集群
你有没有遇到过这样的场景？
刚把 Elasticsearch 打包进容器、用 Deployment 部署三副本，kubectl get pods显示全 Running，心里一喜——结果curl http://es:9200/_cat/nodes一看：只有一台在线；再查日志，满屏NoNodeAvailableException、master_not_discovered_exception；手动 exec 进去ping es-headless能通，但nslookup es-headless却返回空……
这不是配置写错了，也不是镜像有问题——这是你在用无状态的锤子，硬砸有状态的钉子。
Elasticsearch 不是 Nginx，它对“我是谁”“我在哪”“我的数据在哪”有近乎偏执的要求。而 Kubernetes 的默认控制器 Deployment，天生就为“随时可杀、随时可换”的无状态服务设计。强行套用，等于让一个需要固定工位、专属档案柜、实名考勤的银行柜员，天天坐随机工位、共用抽屉、靠工号牌临时认人——不出问题才怪。
所以，真正的云原生部署，不是把 ES “塞进” K8s，而是让 K8s “读懂” ES 的语言。核心就一句话：用 StatefulSet 锚定身份，用 Headless Service 解析彼此，用 PVC 锁死数据，再配上恰到好处的配置注入与热更新能力——四者缺一不可。下面我们就从一次真实的部署出发，一层层剥开这些组件如何咬合运转。
为什么非得是 StatefulSet？因为 ES 要的不是 Pod，是“节点”
先看一个最朴素却致命的问题：
ES 启动时必须明确告诉自己：“我的名字叫es-node-0”，同时还得知道“另外两个兄弟叫es-node-1和es-node-2”，并且要能通过 DNS 或 IP 找到他们。这个“名字”，不是随便起的别名，而是写进集群元数据、参与 master 选举、决定分片分配的唯一标识。
Deployment 创建的 Pod 名字形如es-7f8b9c4d5-xyz12，每次重建都变；而 StatefulSet 的 Pod 名永远是es-cluster-0、es-cluster-1、es-cluster-2—— 稳定、有序、可预测。
更关键的是，StatefulSet 自带“绑定契约”：
- 每个 Pod 启动前，K8s 先确保其专属 PVC 已就绪并挂载；
- 删除 Pod 时，PVC 不删（除非你显式设置deleteClaim: true）；
- 重启 Pod，hostname 不变、IP 可能变但 DNS 记录自动刷新、PVC 还是那个 PVC。
这就直接满足了 ES 的三大刚需：
✅节点名固定→node.name: $(POD_NAME)可安全取值
✅网络可解析→ 配合 Headless Service，es-cluster-0.es-headless.default.svc.cluster.local永远指向正确的 Pod
✅磁盘不丢数据→/usr/share/elasticsearch/data目录始终挂载同一块物理盘（或逻辑卷）
所以你看 StatefulSet 的 YAML
