作者：来自 Elastic Omer Kushmaro
ECK 3.4 将可用区感知的高可用从 40 行 YAML 简化为一个字段，通过 annotation 添加声明式滚动重启，并自动配置 Kibana 与 Elasticsearch 之间的 mTLS。
上手 Elasticsearch：你可以深入阅读 Elasticsearch Labs 仓库中的示例 notebooks，开始免费云试用，或立即在本地机器上体验 Elastic。
ECK 3.4 让 Kubernetes 上的 Elastic Stack 运维更简单。可用区感知的高可用、可安全执行的滚动重启，以及 Kibana ↔ Elasticsearch 的 mTLS，都可以在你的配置清单中用一行完成。
如果你在使用 Elastic Cloud on Kubernetes（ ECK ），这个版本的重点是降低你日常运维中的复杂度。
更易运维，更易理解
ECK 3.4 是一个专注于减少你在 Kubernetes 上运行 Elastic Stack 时 “需要思考的事情” 的版本。每一项主要改进都把一个多步骤任务简化为一个声明式配置：
- 简化的可用区感知。现在只需在 NodeSet 上设置一个字段，就可以告诉 ECK 集群需要跨可用区分布。operator 会自动处理拓扑、调度以及 Elasticsearch 侧的可用区感知配置。你的配置清单表达的是“你想要什么”，而不是“如何实现”。
- 用和其他操作一样的方式重启集群。触发滚动重启现在只需要在 Elasticsearch 资源上添加一个 annotation。这是声明式的，适配 GitOps，并且会留下审计记录。不再需要通过修改无关字段来触发发布流程。
- mTLS 由 operator 自动配置。在 Kibana 和 Elasticsearch 之间手动配置双向 TLS 需要管理 CA、各组件客户端证书、挂载、轮换以及两端配置。ECK 3.4 会自动完成这些工作：在 Elasticsearch 上开启一个开关，让 Kibana 指向它，其余全部由 operator 接管。
这一版本的目标是让 ECK 的日常运维变得“无聊”——这是好事：需要记住的字段更少、同步步骤更少、配置也更容易理解。
简化的可用区感知
通过在 NodeSet 上设置一个字段，就可以让 Elasticsearch 集群在多个可用区之间实现高可用。ECK 3.4 会为你处理拓扑分布、Pod 调度以及 Elasticsearch 侧的可用区感知配置。
在之前的版本中，你需要在四个不同的对象中手动配置这一切：在 Elasticsearch 资源上添加用于向下传递节点标签的 annotation，在 NodeSet 配置中设置感知属性，在 Pod 模板中通过 fieldRef env 变量暴露可用区信息，以及配置 topologySpreadConstraints 并结合 nodeAffinity 规则将集群固定到指定可用区。大约需要四十行 YAML，而且很容易配置错误。
在 ECK 3.4 中，同样的可用区感知集群只需要四行：
apiVersion: elasticsearch.k8s.elastic.co/v1 kind: Elasticsearch metadata: name: my-cluster spec: version: 9.4.0 nodeSets: - name: default count: 3 zoneAwareness: {}要将集群固定到一组特定的可用区，只需要给这些可用区命名，ECK 会自动添加对应的 required node affinity 规则：
spec: nodeSets: - name: hot count: 3 zoneAwareness: zones: ["us-east-1a", "us-east-1b", "us-east-1c"]如果你确实需要自定义maxSkew或whenUnsatisfiable，那么在 podTemplate 中提供一个带有相同topologyKey的topology spread constraint仍然会优先生效。你的覆盖配置仍然是覆盖配置。
关于升级有一点需要注意：在已有 NodeSet 上启用 zoneAwareness 会修改 StatefulSet 的 pod template（新增 topology spread constraints、ZONE 环境变量、node affinity、node.attr.zone），这会触发一次性对受影响 NodeSet 的滚动重启。需要提前规划。
要了解更多关于简化的可用区管理，可以阅读 Elastic Docs 上的相关页面。
声明式滚动重启
在 3.4 中，在不修改 Elasticsearch spec 的情况下重启集群，已经成为一等公民工作流。Elasticsearch 资源上的两个新 annotation 完成这项工作：
eck.k8s.elastic.co/restart-trigger：设置或修改该值（通常使用时间戳），即可触发滚动重启。更改该值会在之后再次触发重启；删除该 annotation 不会产生任何效果。eck.k8s.elastic.co/restart-allocation-delay：可选的持续时间字符串（例如"20m"），在重启期间作为 allocation delay 传递给 Elasticsearch 节点下线 API，用于在 Pod 重新循环时延迟重新分配。
apiVersion: elasticsearch.k8s.elastic.co/v1 kind: Elasticsearch metadata: name: my-cluster annotations: eck.k8s.elastic.co/restart-trigger: "2026-04-30T10:00:00Z" eck.k8s.elastic.co/restart-allocation-delay: "20m" spec: version: 9.4.0在底层实现中，ECK 会将触发值传播到 Pod 的 annotation，这会改变 StatefulSet 的模板 hash，并让所有 Pod 走现有的滚动升级路径（node shutdown API、谓词检查、一次只删除一个 Pod）。这里并没有引入任何新的重启机制需要学习，你已有的滚动升级状态信息和可观测能力都会继续适用。
对于 GitOps 用户来说，这意味着 Flux/ArgoCD 流水线只需要通过修改一个 annotation 就可以发起重启：不会产生 spec 漂移，不会造成 diff 噪音，也不需要通过修改无关字段来强制触发更新。
托管式 Kibana ↔ Elasticsearch mTLS
在这个版本中，引入了 Kibana 与 Elasticsearch 之间的双向 TLS（ mutual TLS ）编排能力。Elasticsearch CRD 新增了一个字段spec.http.tls.client.authentication: true，用于告诉集群在 HTTPs 接口上要求客户端证书。ECK 会完成其余工作：从所有带有eck.k8s.elastic.co/client-certificate: true标签的 Secret 构建信任包，将其挂载到 Elasticsearch Pod 中，设置xpack.security.http.ssl.client_authentication: required，并为 operator 生成客户端证书，以确保在整个滚动过程中持续与集群通信。
这使得在整个 Elastic Stack（本版本仅支持 Elasticsearch 和 Kibana）中启用和配置 mTLS 变得更加简单。
在 Elasticsearch 上启用 mTLS：
apiVersion: elasticsearch.k8s.elastic.co/v1 kind: Elasticsearch metadata: name: secure-cluster spec: version: 9.4.0 http: tls: client: authentication: true # <---- This is all you need nodeSets: - name: default count: 3在客户端侧，Kibana 的 association controller 现在会检测所引用 Elasticsearch 上的 client-authentication-required annotation，并自动为 Kibana 生成客户端证书 —— 无需额外配置。如果你想使用自定义证书（例如 cert-manager 或内部 PKI），只需要指向你已经准备好的 Secret 即可：
apiVersion: kibana.k8s.elastic.co/v1 kind: Kibana metadata: name: kibana spec: version: 9.4.0 count: 1 elasticsearchRef: name: secure-cluster clientCertificateSecretName: my-custom-client-certECK 会轮换证书，将 Secret 挂载到 Kibana Pod 中，并配置elasticsearch.ssl.certificate和elasticsearch.ssl.key。在所有 Pod 完成滚动之前，mTLS 相关资源的清理会被延迟，因此在整个迁移过程中连接保持稳定。
在 3.4 版本中，Kibana 是首个获得这种一等公民支持的 Stack 组件。APM Server、Beats、Fleet Server、Elastic Agent、Logstash、Maps 以及 Enterprise Search 的支持将在不久后推出。在此期间，一份新的指南会通过 cert-manager 介绍这些组件的手动 mTLS 配置方法。
其他重要改进
本版本还包含一些值得关注的改进，以下是按相关 pull request 列出的内容。
- 在启用 FIPS 的 operator 中提供原生 Go FIPS 140-3（独立镜像）。FIPS 版本的 ECK 镜像（
docker.elastic.co/eck/eck-operator-fips:3.4.0，以及 UBI 版本eck-operator-ubi-fips:3.4.0）现在提供原生 Go FIPS 140-3 支持，固定在已认证的GOFIPS140=v1.0.0模块，并在运行时强制执行。标准的eck-operator镜像保持不变。对于 Elasticsearch 9.4.0 或更高版本，当设置xpack.security.fips_mode.enabled: true时，operator 还会自动生成并挂载符合 FIPS 的 keystore 密码（#9263，#9287）。 - 可靠性修复值得一提：
- 现在可以检测证书链中的过期 CA 并触发重新签发（#9197）。
- 远程 CA Secret 生成失败现在是非阻塞的（#9271）。
- 修复了轻量级多租户场景中的 NetworkPolicy namespace selector 标签（#9153）。
- 当已存在同名 volume 时，Elasticsearch controller 会跳过默认 PVC（#9199）。
- DaemonSet reconciler 以与 Deployment reconciler 相同的方式处理过期缓存（#9256）。
开始使用
如果你已经在运行 ECK，可以通过 Helm 升级到 3.4.0：
helm upgrade elastic-operator elastic/eck-operator -n elastic-system或者直接应用最新的 operator 清单：
kubectl apply -f https://download.elastic.co/downloads/eck/3.4.0/crds.yaml kubectl apply -f https://download.elastic.co/downloads/eck/3.4.0/operator.yaml如果你是 ECK 新用户，可以从快速入门指南开始，在几分钟内在 Kubernetes 上运行一个 Elasticsearch 集群。
完整的变更列表请查看 GitHub 上的 ECK 3.4.0 发布说明。
要立即开始使用 Elastic Cloud，请登录 Elastic Cloud 控制台或注册免费试用。
常见问题
如何在 ECK 中让 Elasticsearch 集群具备可用区感知，而无需编写 topology spread constraints？
在 Elasticsearch 资源上设置spec.nodeSets[].zoneAwareness: {}。ECK 会自动推导拓扑结构、添加node.attr.zone、设置maxSkew=1的 topology spread constraints，并为你注入向下传递的标签。如果你希望固定到特定可用区集合，可以提供zones: [...]。在已有 NodeSet 上启用该功能会触发一次性滚动重启。
我可以在不修改 spec 的情况下触发 Kubernetes 上 Elasticsearch 集群的滚动重启吗？
可以。ECK 3.4 在 Elasticsearch 资源上引入两个 annotation：eck.k8s.elastic.co/restart-trigger（设置或修改该值，例如使用时间戳，即可触发滚动重启）以及eck.k8s.elastic.co/restart-allocation-delay（可选的持续时间字符串，传递给 Elasticsearch 节点下线 API）。删除 trigger annotation 不会触发新的重启。
如何在 Kubernetes 上为 Elasticsearch 和 Kibana 启用双向 TLS（ mTLS ）？
在 ECK 3.4 中，在 Elasticsearch CRD 上设置spec.http.tls.client.authentication: true，并通过elasticsearchRef在 Kibana 中引用它。ECK 会为 Kibana 自动生成客户端证书，从任何带有eck.k8s.elastic.co/client-certificate: true标签的 Secret 构建信任包，并为你配置xpack.security.http.ssl.client_authentication: required。Kibana ↔ Elasticsearch 的 mTLS 在 3.4 中为技术预览功能。
ECK 3.4 的 mTLS 是否支持所有 Stack 组件，例如 Beats 和 Fleet？
目前还不支持。Kibana 是 3.4 中第一个获得一等公民 mTLS 支持的 Stack 组件——operator 会自动为其生成客户端证书。APM Server、Beats、Fleet Server、Elastic Agent、Logstash、Maps 和 Enterprise Search 的支持将在下一版本推出。在此期间，有一份新的指南介绍如何使用 cert-manager 为这些组件手动配置 mTLS。
ECK 是否支持 FIPS 140-3？
支持，但在独立的 operator 镜像中提供。ECK 3.4 发布了 FIPS 版本构建（docker.elastic.co/eck/eck-operator-fips:3.4.0以及 UBI 版本），具备原生 Go FIPS 140-3 支持。标准eck-operator镜像保持不变。对于 Elasticsearch 9.4.0 或更高版本，当设置xpack.security.fips_mode.enabled: true时，ECK 还会自动生成并挂载符合 FIPS 标准的 keystore 密码。
这些内容有帮助吗？
原文：https://www.elastic.co/search-labs/blog/elasticsearch-kubernetes-zone-awareness-restarts-mtls
