Architecture-center: 保护网络流量 - 这将如何工作

感谢您的报告 - 此问题正在审核中。 这是 Microsoft 内部 DevOps 错误 ID AB#271079

感谢您联系@melzayet。 这两种交通流来自不同的来源。 顶部（绿色）流是发往在集群节点上运行的集群工作负载（Web 应用程序/api 等）的 HTTP 流量。 这些请求的 HTTP 响应将返回到 WAF 和客户端。

底部（橙色）流是源自包含节点的子网的流量。 这将是到外部容器注册表、Kubernetes API 服务器等的流量。基本上，我们希望使用我们的企业出口防火墙规则保护的任何源自集群的流量。

由于流量源自 UDR 管理的网络外部，而且我们在单独的子网中使用 _internal_ 负载均衡器，因此它采用相同的返回路径。 UDR 规则适用于在其范围内发起的流量。

此外，需要明确的是，此解决方案仅解决了出口锁定（定义为源自集群的流量），它不会通过防火墙将入口和出口都集中起来。

我假设您正在谈论的 DNAT 部分来自AKS 文档中的特别是 this ）。 在这种情况下，他们还强制所有入口流量也流过防火墙。 在他们的情况下，他们使用 _public_ 负载均衡器作为入口，我们的解决方案不使用公共负载均衡器作为入口。 我们正在与 AAG 联系，然后通过专用入口子网中的 _internal_ 负载平衡器路由，然后将不会受到非对称路由问题的影响。 如果您直接通过公共负载均衡器 IP 公开您的服务，那么您肯定会遇到非对称路由问题。

让我知道我是否可以帮助澄清更多 - 我知道这似乎有点“违反直觉”。 随意使用参考实现进行部署，在该旅程结束时，您将拥有一个网站，其中通过入口路由处理工作负载 HTTP 流量（客户端 -> WAF -> 内部 LB -> 节点池 -> WAF -> 客户端）集群发起的流量（nodepool -> FW -> external resource -> FW -> nodepool）通过出口路由处理。

@ckittel感谢您分享这方面的见解！ 我把这个问题交给你。

@ckittel非常感谢您提供详细而翔实的回复。 我认为我的困惑来自不对称问题，但你澄清得很好。 再次感谢您抽出时间