Elastic Cloud on Kubernetes (ECK) 中 Logstash 连接 Elasticsearch 数据热节点的 SSL 证书问题解析

问题背景

在使用 ECK (Elastic Cloud on Kubernetes) 管理 Elasticsearch 集群时，用户希望通过 Logstash 将日志输出到集群。当直接使用基础 Elasticsearch 服务时，配置工作正常，但当尝试将日志仅输出到数据热节点（data hot nodes）时，遇到了 SSL 证书验证问题。

核心问题分析

当 Logstash 配置为连接 Elasticsearch 热节点服务时（elasticsearch-es-hot），SSL 证书验证失败。错误信息显示证书的主题备用名称（SAN）不匹配：

Certificate for <elasticsearch-es-hot.elastic.svc> doesn't match any of the subject alternative names: [... *.elasticsearch-es-hot.elastic.svc ...]

关键点在于：

1. 证书 SAN 包含通配符格式 *.elasticsearch-es-hot.elastic.svc
2. 但 Logstash 尝试验证的是具体服务名称 elasticsearch-es-hot.elastic.svc
3. 这种不匹配导致 SSL 验证失败

解决方案建议

推荐方案：创建专用服务

更合理的做法是创建一个专用的 Kubernetes Service，通过标签选择器（label selector）来定位特定的 Pod 组，而不是直接针对特定的 NodeSet。这样做的好处包括：

1. 避免与特定 NodeSet 名称耦合，提高配置的灵活性
2. 适应未来可能的架构变化，如节点集重命名或层级分布调整
3. 更好地遵循 Kubernetes 的最佳实践

证书配置调整

如果需要自定义证书，可以通过以下方式实现：

1. 配置静态 IP 或自定义域名
2. 调整证书的 SAN 字段以包含所需的具体服务名称
3. 确保证书同时包含通配符和具体服务名称的 SAN 条目

技术实现要点

1. 服务发现：在 Kubernetes 环境中，服务发现应通过 Service 资源实现，而非直接依赖底层节点集名称
2. 证书管理：理解 ECK 自动生成的证书结构和内容，必要时进行自定义配置
3. 安全权衡：虽然将 ssl_verification_mode 设置为 none 可以临时解决问题，但这会降低安全性，不是推荐做法

最佳实践总结

1. 始终通过 Kubernetes Service 进行服务访问，避免直接依赖底层实现细节
2. 确保证书的 SAN 字段包含所有可能被访问的服务名称
3. 保持 SSL 验证为 full 模式以确保通信安全
4. 定期审查和更新证书配置以适应架构变化

通过遵循这些原则，可以构建既安全又灵活的 Logstash 到 Elasticsearch 的数据管道。