VNet内部Azure容器实例（ACI）负载均衡实现方案咨询

先对齐几个已验证不可用方案的核心限制，减少重复测试成本：

• Azure Load Balancer 无法直接适配的本质：当前标准版LB的后端池仅支持通过资源ID绑定VM/VMSS类资源，不支持直接接入VNet集成模式下的ACI网卡；手动录入ACI的私有IP会面临IP漂移问题（ACI销毁、重建后IP会重新分配），长期维护成本极高
• Traffic Manager 不适用的原因：它是基于DNS解析的客户端侧负载均衡，无VNet内部专属转发入口，流量不会经过集中的负载节点，不符合“负载均衡资源统一转发请求到后端ACI”的架构要求

可落地的适配方案 #

方案一：使用Application Gateway V2 SKU（托管度最高，推荐优先测试） #

你之前判断App Gateway不适配，大概率是混淆了基础版SKU的能力边界：

• 只要将标准V2 SKU的应用网关部署在与ACI同VNet的专属子网中，即可直接把VNet集成ACI的私有IP录入后端池，不需要依赖ACI的资源ID绑定
• 访问逻辑：同VNet内的虚拟机统一访问应用网关的私有IP入口，由应用网关通过配置的监听器、路由规则，将请求转发到后端池内的某一台ACI实例
• 自带能力覆盖：健康探测、会话亲和、SSL卸载、WAF防护，完全不需要自行维护负载节点
• 注意事项：
  • 基础版SKU的应用网关不支持手动录入任意私有IP作为后端，必须选择标准V2或WAF V2 SKU
  • ACI只要不触发销毁重建，分配到的私有IP会固定保留在所属子网中，不会漂移
  • 应用网关需要使用单独的/24段子网，网段不能和ACI、VM的子网重叠，否则会部署失败

方案二：轻量VMSS反向代理层（灵活性最高，成本最低） #

如果需要自定义负载逻辑（比如调整负载算法、做请求头改写），可以搭建这个极简架构：

• 部署一个小规格的VMSS（比如B1ms实例，初始1-2台），节点上运行Nginx的stream模块或HAProxy作为四层反向代理
• 将所有ACI实例的私有IP配置为反向代理的上游节点
• 给VMSS关联一个内部Azure Load Balancer（VMSS是LB原生支持的后端类型，无适配问题），所有虚拟机的请求统一指向这个内部LB的私有IP
• 优势：相比App Gateway成本更低，反向代理的规则可以完全自定义，没有托管服务的配置限制

方案三：动态适配层（适合ACI频繁扩缩容的场景） #

如果业务侧ACI的实例数量、IP会随流量动态变化，可以增加一个极轻量的感知层，解决IP漂移的维护成本问题：

• 部署一个VNet集成模式的Azure Function，通过Azure API实时拉取同网络下所有ACI实例的私有IP列表
• 编写简单逻辑自动将最新的IP列表同步到App Gateway后端池，或者同步到反向代理的配置文件中触发热重载
• 整个感知层的资源消耗极低，适合长时间运行

测试阶段的避坑提示 #

• 部署ACI时必须使用VNet集成模式，且将ACI放在专属的委托子网中，不要和VM、App Gateway的子网混布
• 先做基础连通性验证：从同VNet的测试VM上直接访问ACI的业务端口，确认NSG路由规则没有拦截流量，再叠加负载层
• 不需要为ACI配置公网IP，所有流量走VNet内部路由即可

内容的提问来源于stack exchange，提问作者omaticat