Typhoon项目在AWS上部署Kubernetes集群的负载均衡健康检查问题解析

在使用Typhoon项目在AWS平台上部署基于Flatcar Linux的Kubernetes集群时，用户可能会遇到一个常见现象：工作节点目标组的健康检查全部失败，导致流量无法正确路由到Pod。本文将深入分析这一现象的原因，并解释其背后的设计理念。

现象描述

当用户通过Typhoon的Terraform模块在AWS上创建Kubernetes集群后，AWS负载均衡器(ELB)的健康检查会显示所有工作节点目标组处于不健康状态。尽管用户可以通过SSH连接到工作节点，并且确认Pod(如简单的Nginx服务)运行正常，但通过负载均衡器仍然无法访问服务。

原因分析

这一现象实际上是Typhoon项目的预期行为，与操作系统和平台无关。Typhoon在AWS上创建的负载均衡器被设计为需要与用户选择的Ingress控制器配合工作。默认情况下，负载均衡器会检查工作节点上的10254端口的/healthz路径，只有当工作节点上运行了能够响应此健康检查的Ingress控制器时，负载均衡器才会将80/443流量路由到该节点。

设计理念

Typhoon采用这种设计是为了提供灵活性，允许用户选择最适合自己需求的Ingress控制器解决方案。项目本身不强制绑定任何特定的Ingress控制器，而是将选择权交给用户。这种设计模式体现了Kubernetes生态系统的模块化理念，使得基础设施组件可以根据实际需求进行灵活组合。

解决方案

要解决这个问题，用户需要自行部署一个Ingress控制器。以Nginx Ingress控制器为例，用户可以参考Typhoon项目提供的示例清单进行部署。部署完成后，Ingress控制器会响应负载均衡器的健康检查，从而使流量能够正常路由。

对于不需要使用Ingress控制器的场景，用户也可以选择修改负载均衡器的健康检查配置，或者直接通过工作节点的安全组开放特定端口来访问服务。不过，这种做法通常只适用于测试环境，生产环境建议采用标准的Ingress控制器方案。

总结

Typhoon项目在AWS上的这种设计体现了基础设施即代码的最佳实践，通过清晰的职责分离，既保证了核心集群的稳定性，又为用户提供了充分的定制空间。理解这一设计理念有助于用户更好地利用Typhoon项目构建符合自身需求的Kubernetes基础设施。