作者来自 Elastic Omer KushmaroECK 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 上启用 mTLSapiVersion: 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 支持固定在已认证的GOFIPS140v1.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.0helm 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、设置maxSkew1的 topology spread constraints并为你注入向下传递的标签。如果你希望固定到特定可用区集合可以提供zones: [...]。在已有 NodeSet 上启用该功能会触发一次性滚动重启。我可以在不修改 spec 的情况下触发 Kubernetes 上 Elasticsearch 集群的滚动重启吗可以。ECK 3.4 在 Elasticsearch 资源上引入两个 annotationeck.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
在 Kubernetes 上的 Elastic Cloud：简化的可用区感知、重启和 mTLS
发布时间：2026/5/16 10:49:20
作者来自 Elastic Omer KushmaroECK 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 上启用 mTLSapiVersion: 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 支持固定在已认证的GOFIPS140v1.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.0helm 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、设置maxSkew1的 topology spread constraints并为你注入向下传递的标签。如果你希望固定到特定可用区集合可以提供zones: [...]。在已有 NodeSet 上启用该功能会触发一次性滚动重启。我可以在不修改 spec 的情况下触发 Kubernetes 上 Elasticsearch 集群的滚动重启吗可以。ECK 3.4 在 Elasticsearch 资源上引入两个 annotationeck.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
