Elastic Blog

What's new in ECK 3.5

8.5内容质量

TL;DR · AI 摘要

ECK 3.5 引入动态命名空间管理、暂停编排和全栈 mTLS，提升 Kubernetes 上 Elasticsearch 的灵活性和安全性。

核心要点

  • 动态命名空间通过 Kubernetes 标签选择器实现零重启管理
  • 暂停编排功能可在维护窗口暂停配置变更但保留基础运维
  • 全栈 mTLS 自动化证书管理覆盖所有 Elasticsearch 连接组件

结构提纲

按章节快速跳转。

  1. §引言

    介绍 ECK 3.5 三大核心更新：动态命名空间、暂停编排和全栈 mTLS。

  2. ·规模化挑战

    揭示 Kubernetes 上运营 Elastic 面临的动态环境和安全需求挑战。

  3. ·动态命名空间

    通过标签选择器替代静态列表实现命名空间的零重启管理。

  4. ·暂停编排

    维护窗口期间可暂停配置变更但保持基础运维任务运行。

  5. ·全栈 mTLS

    所有组件自动获取 ECK 管理的客户端证书实现端到端加密。

  6. ·StackConfigPolicy

    支持声明式角色定义和动态变量替换的策略管理增强。

思维导图

用一张图看清主题之间的关系。

查看大纲文本（无障碍 / 无 JS 友好）
  • ECK 3.5 新特性
    • 动态命名空间
      • 标签选择器管理
      • 零重启机制
    • 暂停编排
      • 维护窗口暂停
      • 基础运维保留
    • 全栈 mTLS
      • 自动证书管理
      • 全组件覆盖

金句 / Highlights

值得收藏与分享的关键句。

#ECK#Kubernetes#Elasticsearch#mTLS#动态命名空间
打开原文

ECK 3.5：动态命名空间、暂停编排和随处可用的 mTLS | Elastic 博客

ECK 3.5 新特性

动态命名空间、暂停编排和所有组件支持 mTLS

作者

Kostas Stamatakis

2026年8月20日

  • 在 Twitter 上分享 [在 Twitter 上分享](#)
  • 在 LinkedIn 上分享 [在 LinkedIn 上分享](#)
  • 在 Facebook 上分享 [在 Facebook 上分享](#)
  • 邮件分享 [通过邮件分享](#)
  • 打印页面 [打印页面](#)

###### 概述

  • 动态命名空间：通过标签选择器而非静态列表管理命名空间，无需重启操作员即可实时添加或移除命名空间。
  • 暂停编排：在维护窗口期间临时暂停基于规范的变更，同时保持关键后台任务运行。
  • 所有组件支持 mTLS：现在所有连接到 Elasticsearch 的组件均可自动使用 ECK 管理的客户端证书。
  • StackConfigPolicy 改进：以声明式方式定义 Elasticsearch 角色，通过动态替换变量创建可复用策略。

Elastic Cloud on Kubernetes（ECK）3.5 使 Elasticsearch Kubernetes 操作员更易于运行、更安全地维护，并默认更安全。本次发布的重要特性之一是命名空间管理：通过一个 kubectl 标签即可实现。为命名空间添加标签后，操作员开始对其进行管理；移除标签后，操作员会立即停止管理，无需重启操作员或修改配置。让我们深入探讨。

挑战：在 Kubernetes 上大规模运行 Elastic

在 Kubernetes 上运行 Elastic 的平台团队很少管理单一静态环境。随着团队加入和退出，命名空间不断变化；维护窗口需要在基础设施变更和操作员的同步循环之间进行精细协调；安全要求日益增加，要求所有组件之间必须使用 mTLS。ECK 3.5 消除了这些工作流程中以往需要重启操作员、修改配置文件和滚动重启 Elasticsearch 的操作。

动态命名空间：基于标签选择器的命名空间管理

ECK 3.5 改变了命名空间的处理方式。操作员现在可以根据命名空间的标签决定管理哪些命名空间。

历史上，ECK 提供了两种选择：管理集群中的所有命名空间，或管理硬编码在操作员配置中的静态命名空间列表。静态列表适用于稳定环境。但在平台即服务场景中，随着团队及其命名空间的持续加入和退出，每次列表变更都需要更新操作员配置并重启操作员。

ECK 3.5 引入了动态命名空间处理。现在，您只需配置一个标准 Kubernetes 标签选择器，操作员会在运行时根据命名空间标签进行评估。

通过 Helm Chart，只需设置一个值即可启用：

yaml
managedNamespaceSelector:
  matchLabels:
    eck-managed: "true"

复制到剪贴板

也支持 matchExpressions，可将操作员作用域限定到特定环境类别：

yaml
managedNamespaceSelector:
  matchExpressions:
    - key: environment
      operator: In
      values: [production, staging]

该选择器取代了静态的 managedNamespaces 列表，并要求操作员以集群范围权限运行，因为它需要监视整个集群中的所有命名空间。

从此时起，命名空间管理变成了一项标签操作：

code
# 上板：操作员立即在命名空间中获取Elastic资源
kubectl label namespace my-namespace eck-managed=true

# 下板：操作员停止协调命名空间中的资源
kubectl label namespace my-namespace eck-managed-

当命名空间获得匹配标签时，会立即完成上板操作。操作员会枚举其中的Elastic资源并开始协调它们。当标签不再匹配时，会执行下板操作，操作员将停止管理这些资源。两种状态转换都是实时发生的。操作员监视Namespace对象，并在标签发生变化时立即做出响应，无需重启操作员。

有几个设计决策值得特别说明：

  • 深度过滤机制：非匹配命名空间的事件在到达控制器前会被丢弃，已离开范围的命名空间的协调请求会被跳过，操作员的Kubernetes客户端会过滤读取操作，使超出范围的资源对绕过事件驱动过滤的代码路径也完全不可见。
  • 下板操作是非破坏性的：下板一个命名空间不会删除或修改其中的Elastic资源。您的Elasticsearch集群和Kibana实例会继续运行；操作员只是在命名空间再次上板前停止管理它们。需要注意的是，由操作员驱动的维护操作（如证书轮换）也会随之停止。
  • 操作员自身的命名空间始终在范围内：无论其标签如何，它都会始终保持包含状态，因此像许可证管理这样的集群级操作永远不会被意外下板。

动态命名空间处理是企业版功能。请访问动态命名空间处理文档以获取完整的配置参考，包括YAML清单安装和许可证处理细节。

暂停编排：安全的维护窗口

ECK 3.5引入了一个专用注解，可在维护窗口期间暂停基于规格的编排操作，同时保持必要的维护任务继续运行：

code
kubectl annotate elasticsearch quickstart eck.k8s.elastic.co/pause-orchestration=true --overwrite

维护操作（如排空Kubernetes节点、应用基础设施变更或迁移存储）一直与持续协调世界回到期望状态的操作员并存时存在矛盾。此前ECK提供了eck.k8s.elastic.co/managed: "false"注解来解决此问题，该注解会完全暂停协调，包括证书轮换和密钥管理等后台工作。

暂停编排更加具有选择性：

暂停

继续

横向扩展/收缩

证书轮换

滚动升级

服务协调

配置发布

用户和密钥管理

卷扩展

健康监控和状态更新

资源的状态会报告一个OrchestrationPaused条件，因此状态一目了然，注解值会通过webhook验证以在静默无响应前捕获拼写错误。

当维护窗口关闭时，移除该注解后任何待处理的规格变更会立即应用。该注解支持所有ECK管理的资源类型，而旧版managed: "false"注解现已弃用，建议改用新注解。

了解更多详情，请访问暂停编排文档。

所有堆栈组件的双向TLS扩展

code

ECK 3.4 引入了配置 Elasticsearch 要求客户端证书的功能，其中 Kibana 是第一个能够提供证书的组件。ECK 3.5 完善了这一功能；现在所有连接到 Elasticsearch 的堆栈组件都会自动接收 ECK 管理的客户端证书，并在连接时使用该证书，覆盖以下组件：

- APM Server
- Beats
- Enterprise Search
- Elastic Maps Server
- Logstash
- 独立 Elastic Agent
- Fleet Server
- 堆栈监控 sidecar
- AutoOps agent

与 3.4 版本相同，Elasticsearch 客户端证书认证需要 Enterprise 许可证。

对于由 Fleet 管理的代理，Fleet Server 会自动将客户端证书信息传播到所有连接的代理，无需额外配置。

更进一步，Fleet Server 现在可以配置为要求连接到它的 Elastic Agents 提供客户端证书，将双向 TLS 扩展到代理与 Fleet Server 之间的通信环节。这是 Enterprise 功能，需要较新的 Fleet Server 版本（即 8.19.19、9.3.8、9.4.4 或 9.5.0 及以上版本）。

如需了解更多详情，请参阅 Elasticsearch 客户端证书认证文档和 Fleet Server 客户端证书认证文档。

## StackConfigPolicy：声明式角色和可复用策略

StackConfigPolicy 是 ECK 用于在 Elasticsearch 集群和 Kibana 实例的舰队中应用一致配置的机制。此次发布新增了两项功能。

### Elasticsearch 角色定义

新的 securityRoles 字段允许您在策略中声明式地定义自定义 Elasticsearch 角色，并在所有目标集群中保持一致地应用：

apiVersion: stackconfigpolicy.k8s.elastic.co/v1alpha1 kind: StackConfigPolicy metadata: name: shared-roles spec: resourceSelector: matchLabels: env: production elasticsearch: securityRoles: click_admins: indices:

  • names: ["events-*"]

privileges: ["read"]

code

ECK 会将这些定义合并到每个 Elasticsearch 容器挂载的 roles.yml 文件中，Elasticsearch 无需重启容器即可热加载这些配置。

### 动态替换变量

新的 variablesFrom 字段允许您从 ConfigMaps 和 Secrets 中加载键值对，并在策略的 elasticsearch 和 kibana 字段中通过 ${VAR} 或 ${VAR:-default} 表达式引用。现在单个策略定义可以跨不同环境复用，只需更改值即可。ECK 会监控所有引用的源，并在它们发生变化时自动进行同步。

如需了解更多详情，请参阅 Stack 配置策略文档。

## 简化容器资源：无需 podTemplate 模板即可设置 CPU 和内存

为 Elastic 工作负载设置 CPU 和内存是 ECK 用户最常进行的自定义操作之一，过去需要遍历四层嵌套路径：podTemplate.spec.containers[name=<main>].resources。这需要大量 YAML 代码来设置内存请求。

ECK 3.5 为每个拥有 pod 的 ECK CRD 添加了顶级 resources 简写方式。比较两种为 Elasticsearch NodeSet 设置 8Gi 内存和 4 核 CPU 的方式：

之前：四层嵌套

spec: nodeSets:

  • name: default

count: 3 podTemplate: spec: containers:

  • name: elasticsearch

resources: requests: { memory: 8Gi, cpu: 4 } limits: { memory: 8Gi, cpu: 4 }

code

之后：顶级字段

spec: nodeSets:

  • name: default

count: 3 resources: requests: { memory: 8Gi, cpu: 4 } limits: { memory: 8Gi, cpu: 4 }

code

两者产生的容器资源完全相同。对于Elasticsearch，该字段位于每个NodeSet上（spec.nodeSets[].resources），因此异构拓扑可以保持每层的资源分配。对于所有其他工作负载（例如Kibana、APM Server、Beats、Elastic Agent、Enterprise Search、Logstash、Elastic Maps Server等），该字段直接位于spec下：

apiVersion: kibana.k8s.elastic.co/v1 kind: Kibana metadata: name: my-kibana spec: version: 9.5.0 count: 1 elasticsearchRef: name: my-cluster resources: requests: { memory: 1Gi, cpu: 500m }

code

这种简写形式与现有清单文件兼容；它仅针对主应用程序容器。如果同时设置了简写和podTemplate的CPU或内存，简写设置会覆盖前者，而非CPU/内存的键（如ephemeral-storage）则会被保留。当两者设置冲突时，准入webhook会发出非阻塞警告，防止意外的重复定义。现有清单文件不受影响：新字段是完全可选的，Elasticsearch自动扩缩容器完全支持该字段。

## 减少操作员内存占用

大型繁忙的Kubernetes集群会对任何操作员的缓存造成压力。ECK 3.5引入了两项互补的改进：

- 控制器运行时缓存现在会自动限制为仅监视带有ECK类型标签的Pod、StatefulSets、Deployments、DaemonSets和PodDisruptionBudget等核心工作负载资源，避免缓存同一集群中运行的无关工作负载的成本。

- 新增的可选标志--restrict-watched-resources进一步缩小了对Secret、Service和ConfigMap的缓存范围，仅包含明确标记为eck.k8s.elastic.co/watched=true的资源，这在拥有大量用户管理资源的集群中可减少内存使用和API服务器负载。

结合3.4版本引入的managed-fields剥离功能，这些改进使操作员的资源占用在与数千个无关资源共享空间的集群中也能保持可预测。

## ECK 3.5的其他重要改进

- 安全设置热重载：对于Elasticsearch 9.5及更高版本，启用eck.k8s.elastic.co/file-based-secure-settings: "true"注解后，spec.secureSettings会通过Elasticsearch基于文件的设置进行传递，更新凭证不再触发滚动重启。此功能适用于可热重载的设置，如快照仓库凭证。

- AutoOps代理收集器配置：AutoOpsAgentPolicy资源现在通过spec.config和spec.configRef字段直接从CRD调整AutoOps代理收集的metricsets及其采集间隔。

- Fleet集成策略中的Kibana空间支持：这使得通过ECK管理的空间感知Fleet配置成为可能。

- Cert-manager兼容性：自定义CA证书解析已放宽，可接受cert-manager生成的证书格式。

- extraObjects的Map支持：Helm图表现在支持Map类型，允许在values文件中组合和覆盖额外清单文件。
  • FIPS：由于Go原生FIPS模块已获得FIPS 140-3认证，启用FIPS的Operator镜像现在使用Go原生FIPS 140-3模式构建，而非之前版本使用的基于BoringCrypto的工具链。结果是生成了完全静态的二进制文件，不再需要动态链接的镜像变体。
  • Kibana就绪探测器：现在使用Kibana状态API，可提供更精确的健康状态信号。

ECK 3.5入门指南

准备升级了吗？ECK 3.5.0现已发布。现有用户可遵循升级文档进行操作；Operator升级将保留您正在运行的Elastic Stack工作负载。

新用户？快速入门指南可在几分钟内帮助您从零开始部署运行中的Elasticsearch集群。标记为Enterprise的功能（如动态命名空间）可通过免费的企业试用许可证进行评估。

如需查看本次发布的完整功能列表、改进项和修复内容，请查阅ECK发布说明。

本文所述任何功能或功能的发布时间和时间安排均归Elastic公司 sole discretion。任何当前不可用的功能可能无法按时或根本不会交付。

分享