🥙5Bx03 NSX DC能为容器云原生做些什么(2)

临近年末，工作量突然猛增，都没有时间更新公众号~今日得空，我们继续来聊聊NSX DC能为容器云原生做些什么。

上回说到，NSX DC与容器集成后，能为管理员带来显而易见的三大好处，分别是：

0x01.IPAM解决混乱无章的地址规划

0x02.TRACE FLOW帮助管理员快速定位网络故障

0x03.Pod细粒度的QoS支持

今天，我们来聊一聊NSX DC建置的云原生网络还能提供哪些强大的功能。

0x04.灵活便捷的负载均衡功能实现

在与一些企业IT交流的过程中，我发现大部分企业均采用外部专门的负载均衡器提供容器访问入口。在这种情况下，系统管理员需要面对以下几个问题：

外部负载均衡器难以实现东西向负载均衡的需求

容器入口（南北向负载均衡）很难做到自动化、灵活性的配置

我们知道，VMware NSX DC可提供网络功能虚拟化功能（后文称NFV），其中就包括了负载均衡器。那么，在采用NSX DC与容器集成的场景下，能否解决上述两个系统管理员的痛点呢？

先来看看东西向负载均衡的情况：

创建一个名为nsx-demo的命名空间、四个容器Pod和一个服务

apiVersion:v1

kind:Service

metadata:

name: nsx-demo

labels:

app: nsx-demo

spec:

ports:

- port: 80

selector:

app: nsx-demo

我们来查看一下该服务的群集IP

该IP地址为nsx-demo相关Pods的东西向负载均衡群集IP地址；查看流表，看到该东西向负载均衡器地址已经激活，并参与流量交互

可以看到已经有访问流量被自动负载均衡到不同的Pod

为了验证东西负载均衡器，我们使用另一个命令空间的Pod，尝试访问群集地址，确认流量被负载均衡到不同的POD

# wget -O- http://172.30.158.1

第一次负载到192.168.0.37，第二次负载到192.168.0.35

查看流表，可以看到这些记录

通过这个演示，各位可以发现NSX DC在为容器提供东西向负载均衡的时候，拥有2个特点：

负载均衡依赖Linux的虚拟服务内核模块（IPVS）

东西向的负载均衡场景下，NSX DC不会创建负载均衡器实例

那么，在提供南北向负载均衡的时候，NSX DC又是如何实现的呢？

与验证东西向负载均衡一样，我创建了一个nsx-web命名空间、两个容器Pod和一个基于Service Type的负载均衡器

apiVersion:v1

kind:Service

metadata:

name: nsx-web

labels:

app: mod2

spec:

ports:

- port: 80

targetPort: 80

protocol: TCP

name: nsx-web

selector:

app: nsx-web

type: LoadBalancer

等待容器创建完成，查看负载均衡器IP地址可以看到相关容器的负载均衡器地址为192.168.8.133:80，而192.168.8.133是我实现在NSX DC Manager（后文称NSXMGR）上定义的，专门用于负载均衡器虚拟服务器网络地址的IP地址池中的一个可用地址

在NSXMGR上查看创建的虚拟机服务器IP和端口与容器信息相匹配，并且自动关联了服务器池

查看服务器池和成员服务器，可以看到相关成员服务器IP地址与容器命令行查看到的信息相匹配

外部用户访问负载均衡器IP地址可以看到不同的用户被负载均衡到两个内部Pod

在这种采用定义Service Type为LoadBalancer的场景下，每一个容器入口（南北向负载均衡器）都会由NSXMGR自动创建出一个虚拟负载均衡器，并且自动分配一个预先定义的可用的IP地址。用户使用YAML创建负载均衡器服务的时候，NCP会将这些信息提交给NSXMGR，NSXMGR在收到用户的配置请求后，自动完成所有的配置工作；不再需要管理员手动去负载均衡器管理界面进行配置，减轻了工作量，助力业务快速上线。

不过，有人会问如果使用这种方式来实现对容器业务的访问，业务数量与可路由的IP地址数量（负载均衡器IP地址池容量）需要满足1:1；强大的NSX DC能否对此情况进行优化呢？

答案是肯定的！除了基于Service Type的负载均衡，NSX DC也支持Ingress形式的南北向负载均衡。

apiVersion:extensions/v1beta1

kind:Ingress

metadata:

name: nsx-demo-ingress

spec:

rules:

- host: nsx-web-openshift.tenant2.teamv.local

http:

paths:

- backend:

serviceName: nsx-demo

servicePort: 80

与之前的演示相同，我创建一个nsx-demo命名空间、两个容器Pod和一个Ingress入口等待容器和入口创建完成

在默认创建的HTTP负载均衡虚拟机服务器上，可以看到HTTP FORWARDING出现了入口转发匹配条件，与创建的容器信息一致

确认负载均衡成员和虚拟服务器IP地址

外部用户访问nsx-web.tenant2.teamv.local（域名），可以负载均衡到两个容器POD注意：外部需要添加DNS解析记录，直接使用IP地址无法触发HTTP FORWARDING规则

在这种基于Ingress的南北向负载均衡器场景中，不同的URI可以指向相同的IP地址，通过匹配不同的HTTP转发规则实现N:1的可路由IP地址分配。

通过上述三个演示用例，各位可以看到NSX DC与容器集成后，提供满足东西向、南北向的负载均衡为业务及应用服务；系统管理员无需额外的负载均衡配置，NSX DC提供的Edge负载均衡完全可以满足容器业务的高性能、灵活性和自动化配置要求。

0x05.Pod细粒度的安全微分段，提供容器网络安全防护

在之前的连载中，我们讲过NSX三个字母的含义，即网络、安全和任意。

越来越多的企业已经从传统的数据中心组网，演变成一个集合了数据中心、分支机构、容器、虚拟化和公有云等等多元素的“虚拟云网络”。现在企业对于安全越发重视，NSX DC能否实现容器业务的安全防护呢？如果能，细粒度能否满足等保2.0定义的合规呢？

在回答这个问题之前，我们先将目光从容器网络转移到普通的NSX DC逻辑网络拓扑上；无论是NSX DC产品中的NSX-V还是NSX-T，提供虚拟机安全防护的“分布式防火墙”都是由连接在逻辑交换机（虚拟机端口组）上虚拟机的虚拟网卡，与逻辑交换机（虚拟机端口组）的接口之间的IO链实现的。

在上一篇分享中，我提到NSX DC提供的容器NameSpace其实就是逻辑交换机，每一个容器Pod都会连接在NameSpace的某一个端口上，因此NSX DC同样可以实现容器的安全微分段，而且是Pod级别的细粒度。

我们不妨来看一下这个用例：

创建一组3-Tier应用

等待2台Web、1台App、1台DB和1台Redis容器正常运行

在NSXMGR界面，可以非常直观地查看到NAMESPACE YELB-K8S的状态

根据NCP配置文件的定义，所有的容器分布式防火墙策略均会被创建在对应的Sections区间内，默认情况下，目前YELB-K8S容器可以被不受限制地访问

同样地，该组容器可通过INGRESS实现南北向负载均衡，域名为yelb-k8s.tenant2.teamv.local

默认情况下，用户可以通过域名访问容器应用，前端Web收到用户请求后，将由中间件yelb-appserver处理

创建一组分布式防火墙策略注意，管理员也可以在NSXMGR上通过UI界面，手动创建策略

在NSXMGR上，这些策略将会在对应的区域之间被创建

在完成防火墙策略创建后，用户依旧可以正常访问YELB-K8S应用

通过NSXMGR可以查看到Tenant1租户的一台服务器访问YELB-K8S应用的数据流走向

同时对于阻挡的流量，分布式防火墙将直接进行处理，流量不会进入传输网络转发

在虚拟云网络环境越来越普遍的今天，安全边界越来越模糊，解耦网络边界与安全边界已经势在必行。对于普通的虚拟化环境而言，NSX DC能实现最小计算单元，即虚拟机的安全微分段防护；而对于容器环境来说，NSX DC同样能实现最小计算单元，即容器Pod的安全微分段防护。

在上次的分享用例中，我演示了使用NSXMGR的TraceFlow功能，描绘端到端的数据流走向，来提高管理员的运维效率；同时NSXMGR也能提供Pod细粒度的QoS。在今天的最后一个用例中，我将演示NSX DC如何针对云原生网络提供端口镜像功能。

0x06.Pod细粒度的端口镜像，提供云原生网络运维支持

创建一个UBUNTU容器

在NSXMGR上创建新的端口镜像文件，将容器流量Mirror到特定的服务器，如172.16.18.120

在逻辑交换机或者端口级别，关联该端口镜像配置文件

在容器内部执行包括PING、CURL等操作

在目标服务器通过Wireshark抓包，可以看到相互的通信流

在测试用例结束后，恢复端口镜像配置

在传统的数据中心网络，当业务流量不出宿主机的场景下，管理员无法通过端口镜像实现抓包、分析和取证等工作。而NSX DC构建的云原生网络，很好地解决了这个运维痛点，是解耦网络边界与安全边界的一个典型应用。

现在，我们来总结一下演示过的NSX DC提供的网络与安全解决方案覆盖的对象：

VMware vSphere

KVM或者基于KVM的解决方案，如OpenStack

裸金属服务器

容器平台

NSX DC能够为异构的平台、多云平台等提供统一的虚拟云网络环境，提供目标对象最小计算单元细粒度的安全防护，同时提供标准API接口，满足与第三方产品的集成。

在后续的分享中，我将演示VMware vRealize Automation与NSX DC产品集成的用例，提供自动化的网络与安全交付，敬请期待。