Patroni连接外部etcd集群时TLS认证问题解析

问题背景

在使用Patroni管理PostgreSQL集群时，许多用户会遇到连接外部etcd集群的认证问题。特别是当etcd集群启用了客户端TLS认证时，Patroni可能会出现连接失败的情况，错误信息通常包含"CommonName of client sending a request against gateway will be ignored and not used as expected"。

技术原理

Patroni作为PostgreSQL的高可用解决方案，依赖分布式配置存储(如etcd)来维护集群状态。当使用etcd v3时，Patroni实际上是通过etcd的gRPC-gateway(代理)进行通信的，这是因为Python语言对gRPC的原生支持不够完善。

etcd的gRPC-gateway会处理JSON和gRPC协议之间的转换，但在这个过程中，客户端证书中的CommonName字段会被忽略。这是设计上的限制，而非bug。

解决方案

对于需要同时使用TLS认证和用户名/密码认证的场景，有以下几种解决方案：

1. 移除客户端证书中的CommonName： 重新生成客户端证书，确保不包含CommonName字段。这样etcd就不会尝试使用CommonName作为用户名，从而避免认证冲突。

2. 仅使用用户名/密码认证： 在Patroni配置中明确指定用户名和密码，同时保持etcd集群启用TLS认证。这种情况下，etcd会优先使用提供的用户名/密码进行认证。

3. 调整etcd配置： 如果业务场景允许，可以考虑在etcd集群中临时禁用客户端TLS认证进行测试，但这不推荐用于生产环境。

最佳实践建议

对于生产环境，建议采用以下配置方式：

1. 保持etcd集群的TLS认证启用，确保通信安全
2. 为Patroni配置专用的客户端证书，不包含CommonName字段
3. 同时配置用户名/密码作为备用认证方式
4. 定期轮换证书和密码，增强安全性

配置示例

etcd3:
  hosts: etcd-1.example.com:2379,etcd-2.example.com:2379,etcd-3.example.com:2379
  cert: /path/to/client.crt  # 不包含CommonName的证书
  key: /path/to/client.key
  protocol: https
  username: patroni-user
  password: strong-password

通过理解这些技术细节和采用适当的配置方案，可以确保Patroni与etcd集群之间建立安全可靠的联系，为PostgreSQL集群提供稳定的高可用支持。