用StatefulSet部署Elasticsearch是唯一合理选择，因其提供稳定网络标识、独立持久卷、有序滚动更新及Headless Service支持，而Deployment会导致脑裂、数据丢失和扩缩容失败。
直接上结论：用 StatefulSet 部署 Elasticsearch 是唯一合理选择，Deployment 会导致脑裂、数据丢失、扩缩容失败——这不是配置问题，是架构不匹配。
为什么必须用 StatefulSet 而不是 Deployment
Elasticsearch 节点需要稳定的网络标识（如 es-data-0.es-data-svc.default.svc.cluster.local）和独立的持久卷，Deployment 无法提供这两点：
-
Deployment的 Pod 名称随机、DNS 不固定，导致discovery.seed_hosts解析失败或指向错误实例 -
Deployment共享同一 PVC 模板，多个 Pod 挂载同一块存储会引发文件锁冲突，ES 启动直接报java.nio.file.AccessDeniedException - 滚动更新时，
Deployment并发重建 Pod，集群可能瞬间失去多数主节点，触发discovery.zen.minimum_master_nodes校验失败而拒绝服务
Headless Service 必须配对 StatefulSet 使用
Service 的 clusterIP: None（即 headless service）不是可选项，而是 StatefulSet 网络发现的前提：
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 只有 headless service 才能让每个 Pod 拥有独立 DNS A 记录，例如
es-master-0.es-master-svc.default.svc.cluster.local→ 对应具体 IP -
discovery.seed_hosts必须填入这种 FQDN 列表，不能写es-master-svc这种带负载均衡的 service 名 - 若误配成 ClusterIP service，所有节点会解析到同一个 VIP，9300 端口通信全部失败，日志里反复出现
Failed to resolve host或NoNodeAvailableException
master/data/client 节点必须分离部署
混部节点（即一个 Pod 同时设 NODE_MASTER=true 和 NODE_DATA=true）在中等以上规模集群中极易出问题：
- Master 节点承担元数据管理、分片分配等 CPU 密集型任务；Data 节点承担磁盘 I/O 和 JVM 堆压力——资源争抢会导致响应延迟飙升，甚至 master 心跳超时被踢出集群
-
discovery.zen.minimum_master_nodes（ES 6.x）或cluster.initial_master_nodes（ES 7+）必须只由 master-only 节点组成，混部节点参与选举会破坏法定人数计算逻辑 - StatefulSet 的
volumeClaimTemplates应只为 data 节点定义，master 节点用 emptyDir 或 configmap 即可，避免无谓的 PV 绑定等待
JVM 与内核参数不是“调优项”，而是启动前提
ES 容器启动失败的前三大原因都和这俩有关：
-
bootstrap.memory_lock: true时，宿主机必须允许 mlock：容器需加securityContext.capabilities.add: ["IPC_LOCK"]，且节点/etc/security/limits.conf中对应用户（如elasticsearch）要有memlock unlimited -
vm.max_map_count必须 ≥ 262144，该值是内核级限制，不能在容器内改，需在 kubelet 启动前于所有 worker 节点执行sysctl -w vm.max_map_count=262144 -
ES_JAVA_OPTS中-Xms和-Xmx必须相等，且不超过容器内存 limit 的 50%——比如 limit 是8Gi，则堆最大只能设4g，否则 OOM Killer 会优先干掉 ES 进程
最容易被忽略的是：headless service 的 serviceName 必须和 StatefulSet 的 serviceName 字段完全一致，大小写、中划线都不能错；否则 DNS 记录根本不会生成，节点间连 ping 都通不了——这时候查日志只会看到一堆超时，而不是明确的 DNS 错误。
