Apache APISIX使用自签名证书访问ETCD集群的Prometheus监控问题解决方案

问题背景

在使用Apache APISIX与ETCD集群集成时，当ETCD集群启用了基于自签名证书的TLS加密通信，APISIX虽然能够正常访问ETCD进行路由配置管理，但在启用Prometheus插件时会出现证书验证失败的问题。具体表现为Prometheus插件无法获取apisix_etcd_reachable指标，并在日志中报错"certificate host mismatch"。

问题分析

这个问题源于ETCD服务端证书的SAN(Subject Alternative Name)配置不完整。当APISIX通过Prometheus插件检查ETCD可达性时，会验证服务端证书中的主机名信息。如果证书中只包含了IP地址而没有对应的主机名记录，就会导致主机名验证失败。

解决方案

1. 完善ETCD服务端证书配置

在生成ETCD服务端证书时，需要在CSR配置文件中明确指定所有ETCD节点的主机名：

{
    "hosts": [
        "etcd-node-1",
        "etcd-node-2",
        "etcd-node-3",
        "10.186.44.42"  // 实际ETCD节点IP
    ]
}

这样生成的证书将包含所有必要的主机名信息，满足SNI(Server Name Indication)验证的要求。

2. 配置APISIX的ETCD TLS连接参数

在APISIX配置中，需要添加SNI参数指定ETCD节点的主机名：

deployment:
  etcd:
    tls:
      cert: /pki/client.pem
      key: /pki/client-key.pem
      sni: etcd-node-1  # 与证书中的主机名一致
      verify: true

技术原理

1. SNI机制：TLS握手过程中，客户端会通过SNI扩展告知服务器它要连接的主机名，服务器据此返回对应的证书。

2. 证书验证：APISIX在验证ETCD服务端证书时，会检查证书中的主机名是否与请求的目标匹配。当证书中缺少相应主机名记录时，验证就会失败。

3. Prometheus插件行为：该插件会定期检查ETCD的可达性，这个检查过程需要完整的TLS握手和证书验证。

最佳实践建议

1. 证书管理：建议使用统一的证书管理工具生成ETCD集群证书，确保所有节点证书包含完整的主机名和IP信息。

2. 配置标准化：在APISIX配置中，建议使用环境变量来管理证书路径和SNI值，便于不同环境的部署。

3. 监控配置：在启用Prometheus插件后，建议定期检查apisix_etcd_reachable指标，确保ETCD连接状态正常。

总结

通过完善ETCD服务端证书的SAN配置和在APISIX中正确设置SNI参数，可以有效解决Prometheus插件在TLS环境下获取ETCD可达性指标失败的问题。这不仅是解决具体错误的方法，也是构建安全、可靠的微服务基础设施的重要实践。