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

上回说到，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产品集成的用例，提供自动化的网络与安全交付，敬请期待。