我们在前几篇文章讨论并展示了使用 Antrea 搭配 NSX Manager 来提供便利且企业等级的容器网络安全机制，以及与原生 Kubernetes Network Policies 的运作方式比较。采用 Antrea 搭配 NSX Manager 是我们在各个不同企业客户介绍容器方案时的主打功能之一，也受到很多客户青睐希望在生产环境内进行部署。因此接下来我想将重点放在如何进行 Antrea 与 NSX Manager 的链接整合流程。但开始前，这里要特别用一篇推文来讨论 Antrea 与 NSX Manager 的方案架构。
下面这张图是在 Kubernetes Cluster 内运用 Antrea 作为 Container Network Interface 元件，并且与 NSX Manager 进行整合的架构：
![]()
相关重点构件讨论如下：
Antrea 构件
与我们之前在讨论 Antrea 本身的架构相同，在每个 Kubernetes Nodes 内都会有一个 Antrea Pod 来负责。
- 接收来自 Kubernetes API Server 的指示，编写相关的网络与安全需求如 Pod 之间的网络连接；
- 由 Antrea Controller 端接收 Antrea Network Policy 的要求，提供 Pod 上的安全策略；
- 透过本地上的 Open vSwitch 来实现上述功能。
而 Kubernetes Cluster 内在 Master Nodes 内也会部署一个 Antrea Controller Pod，这个 Controller Pod 是 Antrea 的安全控制端，负责要与 K8S API Server 那边抓取 K8S Inventories 的相关信息，并取得对应 Antrea Network Policy 的 CRD（Customized Resource Definition）要求。
上述构件都和我们之前描述标准 Antrea 方案一模一样，唯一要注意的是 Antrea 至 少必须采用 1.2.3 的社群版本，或 1.3.1-1.2.3 的商用版本，才会支持与 NSX 整合的功能，这是大家需要特别在使用此功能前注意的。下图是 VMware Container Networking with Antrea 1.3.1-1.2.3 的 release note（注：标注红框部分就是对于 NSX 整合新功能的描述。）
![]()
![]()
安特里亚 NSX 适配器
在进行 NSX 集成时，Kubernetes Cluster 内会配置一个独立的 Pod ，在上面架构图内叫做 Antrea NSX Adapter。这个 Pod 一方面负责与 Kubernetes 内的 API Server 以及 Antrea Controller Pod 通信，包含抓取 Kubernetes 相关 Inventory 信息，以及送出从 NSX 那边取得的群组与防火墙政策配置。另一方面则是与 NSX Manager 进行连接，提供上述的信息。
下图内大家看到在做完 Antrea + NSX 整合后， Kubernetes Cluster 内会出现一个开头是 interworking 的这个 pod，就是我们这边讨论的 Antrea NSX Adapter。
![]()
单纯安装 Antrea 作为 K8S Cluster CNI 时不会有上面这个 Pod 出现，只有在进行 NSX 整合时才需要。在后面我们讨论 Antrea+NSX 的安装步骤时会看到相关的配置流程。
NSX 管理器
这里的 NSX Manager 就是我们熟悉的 NSX Data Center 内的 Manager 构件，可以是一台或三台做丛集均可。这边就是我们真正通过 UI 界面进行群组配置以及防火墙政策的地方。几个重点：
- NSX Manager 作为管理/控制层来使用，不是数据/转发层。在此架构内，我们通过 NSX Manager 的 UI 界面进行安全政策配置以及查询 Kubernetes Inventory 信息，但是真正的防火墙实现是由 Antrea 呼叫 OVS 来进行。
- 因此，在此架构内，NSX 仅仅作为管理 / 控制层。不需要连接 vSphere 做 Transport Node Preparation，不需要建 TEP 接口启用 Overlay 网络。各位想要用同一组 NSX Manager 同时管理 SDDC 虚机环境与 Kubernetes 环境当然没问题，但单纯讨论 Antrea + NSX 的整合时，NSX 就只需要安装 Manager 而已。
- 也因为所有“真正的功能”都是在 Antrea 内通过 OVS 实现，因此 Antrea + NSX 这个安全方案能够或不能够做到什么，重点其实是在 Antrea 内有没有开发出此功能，而不是 NSX 本身有没有支持。比如说我们需要 Pod 之间不仅有 L4 防火墙，还想要 L7 的检查功能，IDPS 方案的整合等等。在方案架构内，这些功能会需要在 Antrea 端先做出来，然后才是于 NSX Manager 端来提供管理的接口。
这里多说一句，在前面我们讨论到 Antrea+NSX 可以提供较传统 Network Policies 更完善的功能，架构上其实要分成两部分：
- NSX Manager 是管理层，提供简易使用与维运的 UI 界面。
- Antrea 在转发层实作比传统 Network Policies 更强的安全策略功能。在 Antrea 内这个功能是通过 CRD（Customized Resource Definition）来实现，叫做 Antrea Network Policy。
![]()
- 透过这个强化的 CRD 构件，Antrea 可以提供日志、基于 Tier 的防火墙配置顺序、设定明确的 Deny 规则等等。
因此整个内部作业流程是管理者在 NSX UI 内进行了需求的群组及规则配置，在 Kubernetes Cluster 内的 Antrea NSX Adapter Pod 取得这些配置要求，送给 Antrea Controller 后交给每个 K8S Node 里面的 Antrea Agent，编写 Open vSwitch 来实现防火墙配置，大概是这样。
架构讨论完，下一篇开始我们会详细讨论如何进行 Antrea 整合 NSX 的安装步骤。
内容来源｜公众号：VMware 中国研发中心
本文作者：Colin Jao （饶康立）, VMware 资深技术顾问，主要负责 VMware NSX 产品线，目前致力于网络虚拟化、分布式安全防护技术与新应用递送方案的介绍与推广。
