Elastic Cloud on Kubernetes中Kibana集成策略管理问题解析

在Elastic Cloud on Kubernetes（ECK）环境中，用户经常需要通过Kibana自定义资源（Custom Resource）来管理Elastic Agent的策略配置。近期发现一个典型场景：当用户尝试通过Kibana CRD添加新的集成包（如kibana和kubernetes）到现有Agent策略时，虽然集成包显示已安装，但实际策略并未更新到Agent策略中。

问题现象

用户通过以下配置尝试添加集成：

xpack.fleet.packages:
  - name: kibana
    version: latest
  - name: kubernetes
    version: latest
xpack.fleet.agentPolicies:
  - name: Elastic Agent on ECK policy
    package_policies:
      - id: kibana-1
        name: kibana-1
        package:
          name: kibana
      - name: kubernetes-1
        id: kubernetes-1
        package:
          name: kubernetes

尽管配置正确，Kibana界面上显示集成包已安装，但Agent策略中并未出现新增的集成配置。

根本原因

这个问题源于Elastic Fleet的托管策略机制。默认情况下，通过Kibana UI创建的Agent策略是可编辑的（非托管状态），而通过CRD配置的策略需要显式声明为托管策略才能被系统识别和管理。

解决方案

需要在每个Agent策略配置中添加is_managed: true参数：

xpack.fleet.agentPolicies:
  - name: Elastic Agent on ECK policy
    is_managed: true
    package_policies:
      - id: kibana-1
        name: kibana-1
        package:
          name: kibana

这个标志告诉Fleet服务该策略完全由配置管理，不应通过UI修改。当设置为true后，任何通过CRD做的策略变更都会实时同步到Agent策略中。

最佳实践建议

1. 统一管理方式：建议所有通过CRD配置的策略都设置为托管模式，避免UI和CRD配置冲突
2. 变更顺序：先确保所需package在xpack.fleet.packages中声明，再添加到具体策略
3. 版本控制：对于生产环境，建议固定package版本而非使用latest
4. 监控验证：变更后检查Kibana日志确认策略同步状态

技术原理

Elastic Fleet的策略管理系统采用双模式设计：

• 托管模式（is_managed=true）：完全由后端配置驱动，适合基础设施即代码场景
• 非托管模式：允许通过UI灵活调整，适合临时调试

在ECK环境下，由于配置通常通过GitOps流程管理，采用托管模式能更好地保证环境一致性。当策略被标记为托管后，Fleet服务会拒绝任何非配置来源的修改请求，确保系统状态与声明式配置严格一致。

这个问题也提醒我们，在使用复杂系统时，理解各个组件的交互模式和权限控制机制非常重要。对于Elastic Stack这类多组件系统，配置项的细微差别可能导致完全不同的行为表现。