CloudNativePG在EKS环境下的节点排水测试问题分析与解决

问题背景

在CloudNativePG 1.25版本中，当运行在Amazon EKS Kubernetes 1.32环境时，节点排水(drain)相关的端到端测试(e2e)经常出现失败情况。测试过程中发现，当尝试排空运行PostgreSQL主实例的节点时，系统无法正常完成排水操作，导致测试超时失败。

问题现象

测试日志显示，在尝试排空节点后，新的operator pod无法被调度到其他节点上。具体表现为系统报错"Unschedulable 0/3 nodes are available: 1 Insufficient cpu, 2 node(s) were unschedulable"，表明集群中没有足够的CPU资源来调度operator pod。

根本原因分析

经过深入调查，发现问题的核心在于EKS测试环境的资源配置不足。当测试执行节点排水操作时，系统需要：

1. 将operator pod从当前节点迁移
2. 在新的节点上重新调度operator pod
3. 确保PostgreSQL集群的高可用性

然而，由于测试环境中节点的CPU资源预留不足，Kubernetes调度器无法找到合适的节点来运行operator pod，导致排水操作失败。具体来说：

• 现有节点的CPU资源不足以容纳operator pod的需求
• Kubernetes的抢占机制也无法找到合适的节点
• 最终导致operator pod无法及时恢复，测试超时

解决方案

针对这一问题，我们采取了以下改进措施：

1. 增加测试节点的CPU资源：提升EKS测试环境中工作节点的CPU配置，确保有足够的资源容纳operator pod的调度需求。

2. 优化资源请求配置：调整operator部署的资源请求(request)和限制(limit)设置，使其更符合实际运行需求。

3. 增强测试健壮性：在测试代码中添加更详细的资源检查逻辑，确保在测试开始前环境资源充足。

实施效果

通过上述改进，我们成功解决了EKS环境下节点排水测试的稳定性问题。改进后的测试表现：

• operator pod能够在排水操作后快速重新调度
• PostgreSQL集群能够在节点排水期间保持高可用
• 测试用例的通过率显著提高

经验总结

这一问题的解决过程为我们提供了宝贵的经验：

1. 环境资源评估：在类似测试场景中，必须充分考虑operator和数据库实例的资源需求，预留足够的资源余量。

2. 调度策略优化：对于关键组件如operator，应考虑使用PodDisruptionBudget等机制确保其可用性。

3. 测试设计原则：端到端测试应包含对底层资源可用性的验证，避免因环境配置问题导致的误判。

这一改进不仅解决了当前的测试问题，也为CloudNativePG在各类云环境中的稳定运行提供了更好的保障。