如果您运行的是 Kubernetes 上的 Elastic Cloud (ECK)，此版本旨在减少您日常工作中的摩擦。

更易于操作，更易于理解

ECK 3.4 版本的重点是减少在 Kubernetes 上运行 Elastic Stack 时需要考虑的问题。每个标题的更改都选取了一个多步骤任务，并将其转化为一个单一的陈述性答案：

• 简化的区域感知。现在，只需在 NodeSet 上填写一个字段，即可告知 ECK 集群应分布在多个可用区。操作员将代表您处理拓扑、调度和 Elasticsearch 端的感知配置。您的清单反映的是您的意图，而不是其连接方式。

• 重启群集的方法与其他方法相同。触发滚动重启现在是 Elasticsearch 资源上的一个注释。它是声明式的，符合 GitOps，并且会留下审计跟踪。不要为了发布而对无关字段进行强制编辑。

• mTLS 由运营商自动配置。在 Kibana 和 Elasticsearch 手动连接互联 TLS 需要管理 CA、每个组件的客户端证书、挂载、轮换以及两端的配置。ECK 3.4 能够处理所有这些问题：在 Elasticsearch 上设置一个标记，将 Kibana 指向它，然后操作员就可以管理其余部分。

这次发布旨在让 ECK 的日常操作变得枯燥乏味，但这是最好的那种枯燥乏味：需要记住的字段更少，保持同步的额外操作更少，清单也更易于理解。

简化的区域感知

通过在 NodeSet 上设置一个字段，即可实现 Elasticsearch 集群在多个可用区内的高可用性。ECK 3.4 可为您处理拓扑分布、Pod 调度和 Elasticsearch 端感知配置。

在此之前，您必须在四个不同的对象之间手动连接所有这些设置：Elasticsearch 资源上用于向下节点标签的注释、NodeSet 配置中的感知属性、Pod 模板中用于显示区域的 fieldRef 环境变量、匹配的 topologySpreadConstraints 块以及将集群固定到特定区域的 nodeAffinity 规则。大约 40 行 YAML，很容易配置错误。

在 ECK 3.4 中，同一个区域感知集群由四行组成：

要固定到特定的区域集，请为其命名，ECK 会添加与其匹配的所需节点亲和规则：

如果您确实需要自定义 maxSkew 或 whenUnsatisfiable，在 podTemplate 中提供具有相同 topologyKey 的匹配拓扑扩展约束仍然是最佳选择。您的覆盖设置仍然有效。

升级注意事项：在现有 NodeSet 上启用 zoneAwareness 会更改 StatefulSet Pod 模板（新拓扑分布约束、ZONE 环境变量、节点亲和性、node.attr.zone），这会触发受影响 NodeSet 的一次性滚动重启。请做好相应的规划。

要了解有关简化区域管理的更多信息，您可以阅读 Elastic 文档上的此页面。

声明式滚动重启

在 3.4 版本中，无需更改配置即可重启 Elasticsearch 集群已成为一项标准工作流。Elasticsearch 资源上的两个新注释完成了这项工作：

• eck.k8s.elastic.co/restart-trigger：设置或更改此值（通常选择时间戳）以启动滚动重启。更改该值会触发稍后的另一次重启，而删除注释则不会。

• eck.k8s.elastic.co/restart-allocation-delay：可选的持续时间字符串（例如“20m”）作为重启期间的分配延迟传递给 Elasticsearch 节点关闭 API，以便在 Pod 回收期间暂缓重新平衡操作。

在底层，ECK 将触发值传播到 Pod 注释，这会更改 StatefulSet 模板哈希值，并使每个 Pod 通过现有的滚动升级路径进行处理（节点关闭 API、谓词、逐个删除 Pod）。没有新的重启机制需要学习，滚动升级中已有的状态消息和可观测性也会沿用。

对于 GitOps 用户而言，这意味着 Flux/ArgoCD 管道只需修改一个注释即可请求重启：无需处理规格漂移，无需处理差异更新，也无需强制编辑无关字段。

Kibana ↔ Elasticsearch 的托管 mTLS

Kibana 与 Elasticsearch 之间的双向 TLS 协调功能已随本次发布推出。Elasticsearch CRD 接受一个新的字段 spec.http.tls.client.authentication: true，该字段指示集群在其 HTTP 接口上要求客户端证书。ECK 负责其余工作：它会根据任何标记为 eck.k8s.elastic.co/client-certificate: true 的密钥构建信任包，将其挂载到 Elasticsearch Pod 中，设置 xpack.security.http.ssl.client_authentication: required，并签发操作员端客户端证书，以便在整个部署过程中能够持续与集群通信。

这使得为堆栈启用和配置 mTLS（在此次发布中仅限 Elasticsearch 和 Kibana）成为一项更简单的任务。

在 Elasticsearch 上启用 mTLS：

在客户端，Kibana 的关联控制器现在可以检测引用的 Elasticsearch 上的 client-authentication-required 注释，并自动为 Kibana 生成客户端证书，无需额外配置。如果您想使用自己的证书（如 cert-manager 或内部 PKI），请指向您已配置的密钥：

ECK 会轮换证书，将密钥挂载到 Kibana 容器中，并连接 elasticsearch.ssl.certificate 和 elasticsearch.ssl.key。mTLS 资源的清理工作将延迟到所有 Pod 都完成滚动更新后进行，因此在整个过渡期间都能保持连接性。

Kibana 是首个在 3.4 版本中获得这种优先级待遇的堆栈组件。对 APM 服务器、Beats、Fleet Server、Elastic Agent、Logstash、Maps 和 Enterprise Search 的支持将于近期推出。与此同时，一份新的教程详细介绍了如何使用 cert-manager 为这些组件手动配置 mTLS。

其他显著改进

此版本还包含其他值得关注的改进。以下是一份包含其相关拉取请求的列表。

• 在已启用 FIPS 的操作员（单独镜像）中支持原生 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 时还会自动生成并挂载符合 FIPS 的密钥存储密码 (#9263，#9287）。

• 值得特别指出的可靠性修复：

  • 现在可检测到证书链中的过期 CA，并触发重新签发 (#9197）。

  • 远程 CA 密钥生成失败不会导致阻塞 (#9271)。

  • 在软多租户配置中，NetworkPolicy 命名空间选择器标签是固定的 (#9153)。

  • 如果已经存在同名卷，则 Elasticsearch 控制器会跳过其默认 PVC (#9199)。

  • DaemonSet 调节器处理过期缓存的方式与部署调节器相同 (#9256)。

开始使用

如果您已在运行 ECK，请使用 Helm 升级至 3.4.0：

或直接应用最新的操作员清单：

如果您是 ECK 的新手，请从快速入门指南开始，几分钟内即可在 Kubernetes 上运行 Elasticsearch 集群。

有关更改的完整列表，请参阅 GitHub 上的 ECK 3.4.0 发行说明。

要立即开始使用 Elastic Cloud，请登录到 Elastic Cloud 控制台或注册免费试用。

常见问题

如何在 ECK 中使 Elasticsearch 集群具备区域感知能力，而无需编写拓扑分布约束？

在 Elasticsearch 资源上设置 spec.nodeSets[].zoneAwareness: {}。ECK 会导出拓扑结构，附加 node.attr.zone，设置 maxSkew=1 拓扑分布约束，并为您注入向下标签。如果要绑定到一组特定的可用区，请提供 zones: [...]。在现有 NodeSet 上启用此功能会导致一次性滚动重启。

我能否在不编辑规范的情况下触发 Kubernetes 上 Elasticsearch 集群的滚动重启？

是的。ECK 3.4 在 Elasticsearch 资源上引入了两个注释：eck.k8s.elastic.co/restart-trigger（设置或更改值，例如时间戳，以启动滚动重启）和 eck.k8s.elastic.co/restart-allocation-delay（传递给 Elasticsearch 节点关闭 API 的可选持续时间字符串）。删除触发器注释不会启动新的重启。

如何在 Kubernetes 上启用 Kibana 和 Elasticsearch 之间的双向 TLS？

使用 ECK 3.4，在 Elasticsearch CRD 上设置 spec.http.tls.client.authentication: true，并通过 elasticsearchRef 从 Kibana 引用它。ECK 会自动为 Kibana 生成客户端证书，从任何标记为 eck.k8s.elastic.co/client-certificate: true 的密钥构建信任包，并为您配置 xpack.security.http.ssl.client_authentication: required。适用于 Kibana ↔ Elasticsearch 的 mTLS 在 3.4 版本中是技术预览。

ECK 3.4 的 mTLS 支持是否涵盖 Beats 和 Fleet 等所有堆栈组件？

还没有。Kibana 是首个在 3.4 版本中获得优先 mTLS 支持的堆栈组件——操作员会自动生成客户端证书。对 APM 服务器、Beats、Fleet Server、Elastic Agent、Logstash、Maps 和 Enterprise Search 的支持将在下一个版本中提供。一份新的教程详细介绍了如何为目前使用 cert-manager 的组件手动配置 mTLS。

ECK 支持 FIPS 140-3 吗？

是的，在单独的操作员图像中。ECK 3.4 发布了支持 Go FIPS 140-3 原生版本的 FIPS 风格的版本（docker.elastic.co/eck/eck-operator-fips:3.4.0，外加 UBI 变体）。标准 eck-operator 图像保持不变。对于 Elasticsearch 9.4.0 或更高版本，当设置 xpack.security.fips_mode.enabled: true 时，ECK 还会自动生成并挂载符合 FIPS 标准的密钥库密码。