解决Kube-Hetzner部署中system-upgrade-controller超时问题

在使用Terraform部署Kube-Hetzner集群时，用户可能会遇到system-upgrade-controller超时的问题。本文将深入分析这一问题的成因，并提供详细的解决方案。

问题现象

在部署过程中，terraform apply命令执行时会在等待system-upgrade-controller部署就绪时超时，错误信息显示为：

error: timed out waiting for the condition on deployments/system-upgrade-controller

根本原因分析

经过排查，这个问题通常由以下几个因素导致：

1. 资源不足：特别是当使用Cilium作为CNI插件时，较新版本的Cilium对内存需求较高，如果控制平面节点配置过低（如使用cpx11实例类型），可能导致组件无法正常启动。

2. 网络配置问题：某些网络环境可能会影响Kubernetes组件间的通信。

3. 版本兼容性问题：使用较旧版本的Kube-Hetzner模块可能存在已知缺陷。

解决方案

升级控制平面节点规格

将控制平面节点的实例类型从cpx11升级到cax11（ARM架构，性价比更高且性能更好）：

control_plane_nodepools = [
  {
    name        = "control-plane-fsn1",
    server_type = "cax11",  # 从cpx11改为cax11
    location    = "fsn1",
    count       = 1
  },
  # 其他控制平面节点配置...
]

确保使用最新模块版本

在Terraform配置中明确指定使用最新版本的Kube-Hetzner模块：

module "kube-hetzner" {
  source  = "kube-hetzner/kube-hetzner/hcloud"
  version = "2.11.7"  # 确保使用最新稳定版本
  # 其他配置...
}

部署前清理环境

在重新部署前，执行以下清理步骤：

1. 运行terraform destroy清理现有资源
2. 使用cleanupkh脚本（如果已安装）确保完全清理
3. 删除本地Terraform状态文件（如有必要）

最佳实践建议

1. 资源规划：对于生产环境，建议控制平面节点至少使用cax11或更高规格的实例类型，特别是当使用功能丰富的CNI如Cilium时。

2. 版本控制：始终明确指定模块版本，避免使用主分支或本地路径，除非有特殊需求。

3. 渐进式部署：可以先部署最小规模的集群（如单控制平面节点）验证配置，再逐步扩展。

4. 监控资源使用：部署完成后，使用kubectl top nodes监控节点资源使用情况，确保没有资源瓶颈。

总结

Kube-Hetzner部署中的system-upgrade-controller超时问题通常与资源不足有关，特别是当使用内存密集型组件如Cilium时。通过升级控制平面节点规格、使用最新模块版本以及确保干净的部署环境，可以有效解决这一问题。对于生产环境，合理的资源规划和版本控制是确保集群稳定运行的关键。