Kube-Hetzner项目中Nginx Ingress控制器部署问题的分析与解决方案

在Kubernetes集群部署过程中，Ingress控制器作为集群入口流量的重要组件，其正确部署至关重要。本文将深入分析kube-hetzner/terraform-hcloud-kube-hetzner项目中Nginx Ingress控制器部署时遇到的典型问题，并提供专业解决方案。

问题现象

当用户在使用Terraform部署Kube-Hetzner集群时，如果同时满足以下三个条件：

1. 禁用了控制平面节点的调度功能（allow_scheduling_on_control_plane=false）
2. 配置了Nginx作为Ingress控制器（ingress_controller="nginx"）
3. 仅使用自动伸缩节点池（agent_nodepools为空，autoscaler_nodepools配置有效）

集群部署过程会卡在Nginx等待负载均衡器阶段。根本原因是Nginx控制器Pod无法被调度到任何节点上，而集群自动伸缩器（Cluster Autoscaler）此时尚未部署，无法触发节点扩容。

技术背景分析

组件部署顺序问题

在Kube-Hetzner项目中，组件部署存在依赖关系：

1. 首先部署Nginx Ingress控制器
2. 然后部署集群自动伸缩器

这种顺序在特定配置下会导致死锁：Nginx需要节点才能运行，但自动伸缩器还未就绪无法创建新节点。

节点调度策略影响

当禁用控制平面调度时，Nginx Pod只能运行在工作节点上。如果初始工作节点数为0，且没有自动伸缩器及时扩容，Pod将永远处于Pending状态。

解决方案

推荐解决方案

修改部署顺序，优先部署集群自动伸缩器，再部署Nginx Ingress控制器。这种调整可以确保：

1. 自动伸缩器先就绪
2. 当Nginx Pod因无节点而Pending时，自动伸缩器能及时扩容节点
3. Nginx Pod最终能被成功调度

临时解决方案

对于已经遇到此问题的用户，可以采用两阶段部署方案：

1. 初始部署时设置ingress_controller="none"
2. 集群就绪后，再修改为ingress_controller="nginx"

这种方法利用了已就绪的自动伸缩器，确保Nginx Pod能被正确调度。

最佳实践建议

1. 初始节点规划：即使使用自动伸缩，建议至少配置1个初始工作节点，避免完全依赖自动伸缩
2. 资源预留：确保节点资源预留配置合理（如示例中的kubelet_args）
3. 监控部署：密切关注Pod调度状态，及时发现类似问题
4. 测试验证：在生产部署前，先在测试环境验证配置

技术实现细节

在Terraform实现层面，解决方案涉及调整模块中的资源创建顺序。具体需要：

1. 将cluster-autoscaler Deployment的创建移到nginx-ingress之前
2. 确保相关依赖关系正确设置
3. 添加适当的条件检查，防止资源创建竞争

这种调整既解决了当前问题，又保持了模块的灵活性和可配置性。

总结

Kubernetes集群部署中的组件依赖和调度策略需要仔细设计。通过分析Nginx Ingress控制器部署问题，我们不仅解决了特定场景下的部署卡死问题，也为类似组件部署顺序问题提供了解决思路。理解这些底层机制有助于运维人员更好地设计和维护生产级Kubernetes集群。