AWS Load Balancer Controller 中默认创建公网负载均衡器的需求探讨

在 Kubernetes 集群中使用 AWS 负载均衡器时，AWS Load Balancer Controller 作为管理负载均衡器的关键组件，其默认行为对于集群管理员和开发者来说至关重要。近期社区中出现了关于控制器默认创建负载均衡器类型的讨论，这引发了我们对 AWS 负载均衡器默认配置的深入思考。

背景与现状

AWS Load Balancer Controller 目前默认创建的 Network Load Balancer (NLB) 是内部类型（internal），这与传统的 Classic Load Balancer 的行为不一致。这种差异在从传统负载均衡器迁移到 NLB 时可能会带来兼容性问题，特别是对于那些期望负载均衡器默认具有公网访问能力的用户。

技术挑战

当用户从 in-tree 的负载均衡控制器迁移到 AWS Load Balancer Controller 时，会遇到一个显著的行为变化：必须通过显式添加注解才能创建面向公网的 NLB。这种不一致性可能导致：

1. 迁移过程中的配置遗漏
2. 意外的网络访问行为变化
3. 需要额外的运维工作来确保配置正确性

社区解决方案讨论

经过社区内部讨论，提出了以下可能的解决方案：

1. 命令行参数方案：为控制器添加一个命令行标志，允许管理员配置默认创建的负载均衡器类型（公网或内网）
2. Webhook 调整：通过修改准入控制 Webhook 的行为来改变默认创建逻辑

目前社区更倾向于第一种方案，因为它提供了更清晰的配置方式和更好的可维护性。这种方案需要：

• 在控制器中添加新的配置参数
• 确保向后兼容性
• 进行必要的安全评估

临时解决方案

在实际生产环境中，一些用户采用了临时解决方案：

1. 修改准入控制 Webhook 配置，限制其作用范围
2. 通过策略管理工具确保服务注解的正确应用
3. 使用基础设施即代码工具预先配置必要的注解

未来展望

这一功能的实现将带来以下好处：

1. 更好的迁移体验：从传统负载均衡器迁移时行为更加一致
2. 更灵活的配置：允许不同环境采用不同的默认策略
3. 降低运维复杂度：减少必须的注解数量

实施建议

对于希望实现这一功能的开发者，建议考虑：

1. 保持与现有注解系统的兼容性
2. 提供清晰的文档说明默认行为的变化
3. 考虑添加指标来监控默认负载均衡器类型的创建情况
4. 实现适当的权限控制，防止意外创建公网负载均衡器

这一改进虽然看似简单，但对于提升用户体验和简化运维工作流程具有重要意义，值得社区投入资源进行实现。