Elastic Cloud on Kubernetes (ECK) 中 Kibana 路径重写导致 Fleet Server 部署失败的解决方案

问题背景

在 Kubernetes 环境中使用 Elastic Cloud on Kubernetes (ECK) 部署 Elastic Stack 时，用户可能会遇到一个典型问题：当 Kibana 配置了 server.basePath 路径重写后，Fleet Server 代理无法正常部署。这种情况通常发生在需要通过 Ingress 暴露 Kibana 服务并设置自定义路径的场景中。

问题现象分析

当用户按照以下步骤操作时会出现问题：

1. 部署 ECK 基础组件
2. 创建 Elasticsearch 资源
3. 部署 Kibana 资源
4. 修改 Kibana 配置以支持路径重写（如 /monitoring/kibana）
5. 尝试部署 Fleet Server 代理

此时，ECK 操作日志中会出现 404 错误，提示无法访问 /api/fleet/setup 端点。这是因为操作器不知道 server.basePath 的配置变更，仍然尝试访问原始路径而非重写后的路径。

技术原理

Kibana 的 server.basePath 配置用于设置 Kibana 的基础路径，这在多租户或通过反向代理访问的场景中很常见。当启用此功能时：

• 所有 Kibana API 端点都会在原始路径前加上基础路径
• server.rewriteBasePath 控制是否自动重写路径

然而，ECK 操作器在设计上存在以下限制：

1. 操作器不会自动检测或适应 Kibana 的基础路径配置
2. 操作器与 Kibana 通信时使用硬编码的 API 路径
3. 目前仅支持通过 config 字段配置的路径重写，不支持环境变量方式

解决方案

推荐方案：使用 Kibana 配置字段

最可靠的解决方案是使用 Kibana 资源的 config 字段而非环境变量来配置路径重写：

apiVersion: kibana.k8s.elastic.co/v1
kind: Kibana
metadata:
  name: monitoring
spec:
  config:
    server:
      basePath: /monitoring/kibana
      rewriteBasePath: true

这种方式能够确保操作器正确识别路径配置，是目前官方支持的唯一方法。

替代方案：Ingress 层路径重写

如果必须使用环境变量配置，可以考虑在 Ingress 层面实现路径重写。以 Nginx Ingress 为例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: kibana-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
  - http:
      paths:
      - path: /monitoring/kibana(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: monitoring-kb-http
            port:
              number: 5601

这种方案将路径重写的工作交给 Ingress 控制器处理，保持了 Kibana 内部路径的原始性。

未来改进方向

ECK 开发团队已经将此问题标记为 bug，并计划在未来的 2.15.0 版本中改进。可能的改进方向包括：

1. 操作器自动检测 Kibana 的路径配置（包括环境变量方式）
2. 支持动态构建 API 请求路径
3. 提供更明确的错误提示

最佳实践建议

1. 始终优先使用 Kibana 资源的 config 字段而非环境变量进行配置
2. 在修改 Kibana 配置后，确保重新部署依赖组件（如 Fleet Server）
3. 监控 ECK 操作日志，及时发现配置不兼容问题
4. 考虑使用 ConfigMap 管理复杂的 Kibana 配置

通过理解这些技术细节和解决方案，用户可以更顺利地在 Kubernetes 上部署和管理 Elastic Stack，特别是在需要自定义路径的高级场景中。