虚拟云网络系列 | Antrea 应用于 VMware 方案功能简介（十二）

接续 Antrea 网络系列，接下来我想和大家讨论的是 Antrea 本身的两个网络与定址相关功能：Antrea Egress/Antrea IPAM。但在开始说明这两个机制前，先得讨论在原生 Kubernetes 方案内基础的网络与定址设计，通常在企业环境内会产生什么问题，才进而能探讨为什么需要新的机制，有哪些效益。因此本篇的重点就先着重在「现行的问题是什么」。

---

下面是本篇用来举例，但很典型显示常见企业客户 Kubernetes 环境的示意图。在此环境内有一个 Kubernetes 丛集，上面放了多个生产应用 (Portal/ERP/CRM/Vote)。每个生产应用为了资源区隔等考量，放在各自对应的 Namespace 里面。

请大家回忆一下原生 Kubernetes 最基本的定址机制，或是我们叫做 Node-IPAM：

•每一个 Kubernetes Node 内会被分配一个子网段。上图内，最左边的 Node 的内部网段是 10.10.1.0/24，最右边 Node 的内部网段是 10.10.7.0/24。这里的内部网段，当我们手动安装 Kubernetes 用 kubeadm init 启用时，可以用–pod-network-cidr 这个参数给一个大范围（比如说 10.10.0.0/16），然后每个新的 Kubernetes Node 加进来时，就从上面的范围内拿一段走，做为自己的子网段。

•当一个 Pod 被分派在某台 Node 内启用运作时，会从这个 Node 的内部子网段内分派一个 IP 地址填入。在上图左边 Node，里面有来自 Portal/ERP/Vote 不同 namespace 内建立的 Pod，每个 Pod 拿到的都是 10.10.1.0/24 内的 IP 地址。相同的，最右边的 Node 里面有 Portal/ERP/CRM 三个不同 namespace 内建立的 Pod，每个 Pod 拿到的都是 10.10.7.0/24 内的 IP 地址。

•在同一个 Namespace（同一个 Project/应用）内，各个 Pod 拿到的 IP 地址是混乱的，比如说 ERP namespace 内的 Pod，拿到的 IP 来自不同网段，包括 10.10.1.12, 10.10.7.11, 10.10.9.82, 10.10.10.2。

 

接着请看下面第二个图。客户的现状是应用资料库目前还在外部没有转成容器，因此 K8S 内的 Pod 要能够连到外部资料库进行存取。

在标准 Kubernetes 的 Pod 基础连外机制 (Egress) 做法是什么呢？

· 每个 Pod 连外时，都会用所在K8S Node 的 Interface IP 做 Source-NAT。上图内，在左边 Node 里面，所有不同 Namespace 的 Pod，往外连线时，来源地址都会改为 172.16.11.11 的 Interface IP；同样右边 Node 里面的所有 Pod 连到外面世界时，都会带 172.16.11.17 的 Interface IP。

· 在外部的防火墙或是资料库设备，看到这些连线时，只会看到来源地址是来自各台 K8S Node 的介面 IP，无法区分这个连线是来自哪个 Namespace/Project/应用。举个例子请大家想一下，如果外部的 ERP 资料库，要限制只有属于 ERP 的 Pod 可以连线到它身上，此时要怎么做呢？

用上面两张图，我们讨论了近年几乎在每个客户 Kubernetes 生产环境都有碰到的网络问题，用下面这张图来做个整理。这些问题尤其常出现在金融与政府客户要进行应用转型过程当中：

· 外部防火墙或业务系统只看得到 K8S Node IP，看不到真实的应用网络连线来源，无法对应是哪个业务系统，此时在资安政策要求的防火墙控管、应用连线稽核纪录都无法进行。

· 也不单纯是连外才有这个问题，即使都在 Kubernetes 内部连接不用 NAT，但当应用仍然要求纪录连线资讯时，看到的 IP 是杂乱的。比如说在前面的案例，如果 AP 日志纪录了有 10.10.1.5 的 pod 来连接它，我们只知道这是一个在 Node 1 号上面运作的 Pod，其他什么资讯都没有。况且 Pod 如果重启，IP 就换掉了，这个 IP 资讯根本没有意义。

· 对于外对内的连线，很多客户也希望不要有 NAT 像是 Nodeport/LB/Ingress 等机制，而可以直接用标准路由的方式让外部系统连到这些 Pod。在基础标准 CNI 运作方式是不容易满足的。

· 很多客户希望 Pod 产生时 IP 可以固定不要变动。当然，通常也是稽核的考量。甚至有些是应用不想改，程式码内就把 IP 写死了。

先讲一下之前每次听到这些客户要求时，我的内心想法。简而言之就是：那你继续用虚机不就好了吗？用虚机也是部署很快很敏捷很稳定效能很好的啊？上面你的每个要求用 vSphere 全部通通都做得到啊？

基本上是这样，整个云原生应用，还有 Kubernetes 架构相关的设计，就是要把 IP 对应用的影响与绑定移除掉。IP 地址只是最底层要连接时的构件，但上层应用构件互联时，就仅用构件的服务名称/FQDN 即可。应用层构件的识别应该是采用比如公私钥而非 IP 地址，构件间的安全保护，也应该改由 Label/Service 这些来定义而不会是 IP 或网段。如果客户整个应用从上层往下都采用云原生的概念来考虑，构件都改为容器，前面那四个困扰应该是不存在的。

但现况就是绝大部分的企业应该都还会有这些原本应用的技术债，难以在短期内大幅翻新。也因此，如果新技术方案在企业转型过程中，能够解决或至少缓解上述问题，那对客户当然也会有很大的好处。我们接下来讨论 Antrea Egress 与 IPAM 功能，就会着重在如何透过这些新机制，来解决前述客户的痛点。

 

本文作者：Colin Jao （饶康立）, VMware 资深技术顾问，主要负责 VMware NSX 产品线，目前致力于网络虚拟化、分布式安全防护技术与新应用递送方案的介绍与推广。

内容来源｜公众号：VMware 中国研发中心

有任何疑问，欢迎扫描下方公众号联系我们哦～