问题描述
希望在运行在AWS上的Kubernetes集群上部署一个监听UDP的StatsD服务。他们的目标是让现有的应用程序能够通过UDP发送StatsD指标。然而，在使用外部负载均衡器（CLB、ALB、NLB）的情况下，Kubernetes文档和他们的测试表明目前不支持UDP监听器。虽然可以使用NodePort来公开UDP端口，但在节点替换或故障时需要支持多节点和故障转移场景。用户寻求关于在这种情况下的建议或运行类似设置的经验分享。
解决方案
请注意以下操作可能涉及Kubernetes和AWS的特定配置，具体操作前请备份重要数据并仔细阅读文档。
解决方案1：使用NodePort + 节点选择器
一种方法是使用NodePort来公开UDP端口，并使用节点选择器确保在多节点和故障转移场景下的稳定性。以下是实现此方案的步骤：
- 创建一个Deployment或StatefulSet，用于部署StatsD容器。
- 在Service中定义NodePort类型的端口，并将选择器配置为适用于所需的节点。
- 使用AWS的Auto Scaling来管理节点，确保有足够的可用节点。
这种方法可以确保在节点故障时，StatsD服务可以迁移到其他可用节点，从而实现故障转移。
解决方案2：使用独立的UDP收集器
如果在Kubernetes集群中难以直接实现UDP监听，您可以考虑部署独立的UDP收集器，然后将其配置为将UDP数据转发到StatsD。以下是一个可能的步骤：
- 在Kubernetes集群之外，部署一个独立的UDP收集器，例如使用AWS的EC2实例。
- 配置UDP收集器以监听来自应用程序的UDP数据，并将其转发到StatsD服务。
- 在应用程序中配置将UDP数据发送到UDP收集器的地址和端口。
这种方法允许您绕过Kubernetes的限制，同时仍然能够收集应用程序的StatsD指标。
解决方案3：等待官方支持或第三方解决方案
如果当前Kubernetes版本不支持在外部负载均衡器下的UDP监听器，您还可以考虑等待官方的更新，或者寻找第三方解决方案。
总结
在Kubernetes集群中部署监听UDP的StatsD可能需要一些额外的配置和策略。您可以选择使用NodePort与节点选择器，部署独立的UDP收集器，或者等待官方或第三方解决方案的支持。根据您的特定需求和环境，选择适合您的最佳解决方案。
请注意，操作涉及到Kubernetes和AWS的特定设置，因此在实际操作前，请务必仔细阅读相关文档并备份重要数据。
原始问题评论中提到了一些有关使用DNS解析进行容器间通信的建议，以及使用Spot.io的Managed Instance进行解决的可能性。这些方法可以作为探索的选项，但由于不直接涉及到在Kubernetes上部署监听UDP的StatsD，我在本解决方案中未做详细说明。如有需要，您可以根据实际情况进行进一步的研究和实践。