RKE2中自定义CIDR范围后CoreDNS服务IP分配异常问题解析

问题背景

在使用RKE2(v1.31.5版本)部署Kubernetes集群时，管理员在配置文件中明确指定了自定义的CIDR范围：

• 集群CIDR: 192.168.0.0/17
• 服务CIDR: 192.168.128.0/17
• 集群DNS: 192.168.128.10

但实际部署后发现CoreDNS组件仍尝试使用默认的10.43.0.0/16范围分配IP地址，导致服务启动失败。

问题现象

当管理员按照上述配置启动rke2-server服务后，观察到以下异常现象：

1. CoreDNS Pod进入CrashLoopBackoff状态
2. 日志显示CoreDNS尝试使用10.43.0.10作为集群DNS地址
3. 错误信息明确提示IP分配失败，因为10.43.0.10不在配置的192.168.128.0/17有效范围内

根本原因

经过深入分析，发现问题并非出在RKE2或CoreDNS本身，而是操作顺序问题：

1. 管理员首次启动rke2-server时使用的是默认配置
2. 在服务运行后修改了配置文件
3. 再次启动时，系统保留了部分初始状态

这种操作顺序导致虽然配置文件中指定了新的CIDR范围，但系统仍尝试使用初始的默认值。

解决方案

正确的操作流程应该是：

1. 确保在首次启动rke2-server前就完成所有配置修改
2. 如果已经使用默认配置启动过服务，需要：
   • 完全清理集群状态
   • 删除相关数据目录
   • 确保所有组件完全停止
3. 然后再使用修改后的配置文件启动服务

技术要点

1. RKE2配置加载机制：RKE2在首次启动时会持久化部分配置状态，后续修改需要特别注意清理机制
2. Helm Chart部署特性：CoreDNS通过Helm Chart部署，其配置在首次安装时确定，后续修改需要完整的重新部署流程
3. IP分配验证：Kubernetes服务IP分配有严格的验证机制，确保分配的IP必须在配置的service-cidr范围内

最佳实践建议

1. 生产环境中部署前应充分规划网络方案
2. 修改关键网络配置后建议重建集群而非直接重启
3. 使用配置管理工具确保配置变更的原子性和一致性
4. 重要变更前备份关键数据和配置

总结

这个问题展示了Kubernetes网络配置的重要性以及操作顺序对集群状态的影响。通过理解RKE2的配置加载机制和Kubernetes的服务IP分配原理，管理员可以避免类似问题，确保集群网络按预期工作。记住在修改关键网络参数时，全新的部署往往比修改现有集群更可靠。