CrunchyData Postgres-Operator中使用MinIO备份时TLS配置的重要性

在Kubernetes环境中使用CrunchyData Postgres-Operator进行PostgreSQL集群管理时，将备份存储到MinIO对象存储是一个常见需求。然而，许多用户在配置过程中会遇到一个关键问题：当尝试配置S3/MinIO备份时，数据库用户创建可能失败，或者备份功能无法正常工作。

问题现象分析

在配置PostgresCluster资源时，用户可能会观察到以下两种现象：

1. 不配置S3密钥时：

   • 数据库用户能够成功创建
   • 但备份功能无法工作，pgbackrest无法创建stanza
   • 日志中会显示退出代码37的错误

2. 配置S3密钥时：

   • 数据库用户创建失败
   • 备份功能看似正常（没有错误日志）
   • 但实际上备份可能无法真正完成

根本原因

经过深入分析，发现问题的核心在于MinIO连接的安全性配置。pgbackrest对S3/MinIO连接有一个关键要求：必须使用TLS加密连接。当用户尝试使用非加密的HTTP连接时，虽然某些操作可能看似成功，但实际上会导致各种不可预知的行为。

解决方案

要解决这个问题，需要确保以下几点：

1. MinIO服务必须配置TLS：

   • 为MinIO服务配置有效的TLS证书
   • 确保MinIO服务监听HTTPS端口（通常是9443而非9000）

2. PostgresCluster配置调整：

   • 在spec.backups.pgbackrest.repos.s3中指定正确的HTTPS端点
   • 确保端点URL使用https://前缀
   • 示例配置：

     s3:
       bucket: sedaro-backups
       endpoint: https://minio-service.sedaro:9443
       region: us-east-1
     

3. 证书信任配置：

   • 如果使用自签名证书，需要在PostgreSQL Pod中配置信任
   • 可以通过挂载CA证书到容器中实现

最佳实践建议

1. 始终使用TLS：即使是内部网络通信，也建议使用TLS加密
2. 密钥管理：将S3密钥存储在Kubernetes Secret中，而不是直接写在YAML配置里
3. 测试验证：配置完成后，手动执行备份测试并验证备份文件是否确实存储在MinIO中
4. 监控设置：配置适当的监控和告警，确保备份作业按预期运行

总结

在CrunchyData Postgres-Operator中配置MinIO备份时，TLS不是可选项而是必选项。忽视这一要求会导致各种难以诊断的问题。通过正确配置TLS连接，不仅可以解决用户创建和备份功能的问题，还能提高整个数据库备份过程的安全性。

对于生产环境，建议进一步考虑：

• 使用证书管理器自动管理TLS证书
• 配置备份作业的监控和告警
• 定期测试备份恢复流程
• 考虑多区域备份以提高灾难恢复能力