前不久，相信许多朋友的朋友圈都被两个名字“Tanzu”和“Project Pacific”刷屏了；这些年容器越来越火热，我们也看到VMware陆续推出了vSphere Integrated Containers、Pivotal Kubernetes Service......以及相关产品越来越多的与容器集成的潜力，如NSX DC、vRealize Automation......vRealize Network Insight5.0已经发布，能实现对容器网络的强大洞察力。Tanzu让我想起了vSphere Integrated OpenStack（VIO），前些年发布的另一款同样是VMware针对市场动态的战略产品。只能说，摩拳擦掌、跃跃欲试，期待Hands on Lab能早日推出动手实验，让我等先睹一快。
我们再把目光切回到持续连载的NSX DC(NSX-T)产品，在今天的分享中，我将用几个实际的演示用例，向各位展示：借助NSX DC实现云原生网络与安全后，能为IT管理员带来哪些便捷和实惠。
关于NSX DC如何与容器部署集成，VMware官方配置手册已经写得非常详细；包括NSX DC相应版本支持的容器平台、版本和操作系统兼容性等。建议有兴趣自己动手体验的朋友，可以采用Ansible自动实现OpenShift和NSX DC集成。
NSX DC支持与裸金属容器和虚拟机容器集成实现云原生网络与安全。但是从部署的难易程度、对现有网络的改动程度、高可用等多方面综合考量，建议采用虚拟机形式部署容器，即承载容器的Linux操作系统是运行在vSphere上的一台虚拟机。
我从MAPRSC多个角度来简单说明一下这种HOST-VM模型集成的优势：
M可管理性：vCenter可以实现对vSphere和虚拟机的集中管理；同时借助Orchestrator服务编排可以实现快速部署和弹性伸缩；
A可用性：vSphere HA支持服务器、虚拟机、操作系统三个不同级别的高可用，避免传统裸金属服务器容易造成的单点故障；vMotion满足不影响业务的计划内的停机维护，是保障核心业务连续性的关键设计决策；
P性能：vSphere解耦硬件与软件，容器业务不会再受到兼容性的影响；分布式资源调度DRS能让虚拟机和容器运行在高效率的Hypervisor上，避免资源竞争导致性能下降；vRealize Operations提供运行状态监控和风险预判，避免资源过剩导致成本虚高，也为容器业务平台高效稳定运行保驾护航；
R可恢复性：面向虚拟机的备份-还原解决方案同样适用于容器虚拟机；SRM可以提供最小RPO=5min的容灾方案，结合NSX DC的跨数据中心、跨云解决方案，能提供强大的可恢复性保障；
S安全性：在安全性方面，无论是裸金属还是虚拟机版本的容器，均能实现POD细粒度的安全防护，实现安全在最贴近业务的地点运行；通过由企业CA或者公网CA签发的证书，加密组件之间的通信，可以降低遭受黑客攻击篡改导致数据泄露的风险。
C合规性：NSX DC和容器的集成，能实现租户之间、业务之间、虚拟机与宿主机之间等流量安全隔离，满足等保2.0定义的合规性要求；与裸金属部署容器相比，虚拟机部署容器可以更好地节约授权成本，满足企业正版化合规性要求，在解决IT痛点的同时，对成本花销有一个比较好的控制。
接下来，我将用几个演示用例，更为直观地向各位演示NSX DC与容器集成的优越性。
0x01.IPAM解决混乱无章的地址规划
在实际的项目中，有用户提出：我们有一部分业务运行在OpenShift上，但是对于网络地址的规划很混乱，有没有什么方案可以帮助我们解决痛点。
首先，各位跟着我先将目光投放到NSX DC Manager的管理界面，其中有2个菜单，分别是：
- 高级网络与安全-网络-IPAM
- 高级网络与安全-清单-组-IP池
管理员可以定义若干资源池，提供给容器使用，如在我的演示环境中：
OpenShift容器Namespaces(Route)可用的IP地址段，这些地址全部可被外部网络路由可达；
OpenShift容器Namespaces(SNAT)可用的IP地址段，外部VLAN网络没有这些地址段的路由；使用这些IP的Pod必须通过源地址转换SNAT才能访问外部网络；
SNAT可用的IP地址池，提供前者Namespaces通过源地址转换访问外部网络使用，本身可以被外部网络路由可达；
LB可用的IP地址池，作为Ingress入口，提供外部网络访问容器业务使用，本身可以被外部网络路由可达。
当系统管理员创建一个微服务的时候，根据YAML文件的设置，OpenShift会通过NCP自动从NSX DC定义的资源池中分配IP地址，提供给包括Pod、Namespace、Ingress等使用。
- 比如，管理员创建了一个微服务，NSX DC会从定义的IPAM为每一个Namespace分配独立的一个地址段，容器Pod会自动获取该地址段的一个可用地址
- NSX DC会自动为每一个Namespace创建一个逻辑交换机和Tier1级别逻辑路由器，并将该逻辑路由器连接到Tier0逻辑路由器，实现与外部网络的互联
- 如对于yelb这个Namespace，NSX DC为其分配了192.168.24.160/28，合计16个可用的IP地址；其中第一个可用IP为网络地址；最后一个可用IP为广播地址；第二个可用地址为该Namespace的网关地址
- 该微服务一共创建了5个Pod，因此从剩余可用的13个IP地址中，连续分配5个提供给Pod使用；这些分配的IP地址与OpenShift命令行查看的Pod地址是一致的。
- 除此以外，NSX DC实现云原生网络与安全场景中，容器网络大多采用SNAT方式与外部互联，因此需要Ingress才能实现外部网络对微服务的访问，这将通过NSX DC提供的负载均衡器实现；NSX DC同样会从可用的IP地址规划中分配一个地址给负载均衡器的虚拟服务器使用，如本实例中的“192.168.8.135”
通过用例，各位可以看到NSX DC与容器集成后，所有的网络地址分配均自动实现，不再需要管理员手动介入；也不会出现IP地址混乱或者冲突的情况，大大提高了网络管理员的工作效率，是NSX DC实现云原生网络与安全的第一大好处。
0x02.TRACE FLOW帮助管理员快速定位网络故障
在日常的网络问题排查过程中，管理员最常用的工具就是PING和TRACEROUTE命令(不同的操作系统可能有不同的命令，但是实现的功能是一样的)。
我们来看看下面的这个例子：
- 管理员想要验证容器nsx-demo-rc-87f8d与nsx-demo-rc-zmwjw之间的网络连通性；以及nsx-demo-rc-87f8d与外部网络之间的连通性
- 命令行验证Pod之间的连通性
- 命令行验证容器网络与外部网络的连通性
可以看到与Windows和Linux操作系统一样，容器验证连通性虽然可以用PING等方式，但命令比较复杂。对于出现网络不可达的情况，很难定位故障，会增加管理员排查的复杂度。
那么在与NSX DC集成后，能为管理员的日常运维带来什么变革呢？
- 通过NSX DC的图形化界面，管理员可以对连接到这个Namespace的容器Pod有统一的全局可视化，包括Pod当前的连接状态、端口等
- 对于特定的某一个Pod，管理员可以查看更为详细的状态，比如它属于哪个群集、哪个项目等
- 管理员可以查看包括MAC表、流量统计等信息
- 如果管理员怀疑防火墙策略阻挡了流量，可以通过快速链接，找到Pod对应的分布式防火墙策略，进行快速排查
- 与在OpenShift命令行获得的结果相同，可以看到yelb-appserver这个容器Pod通过NCP从管理员预先定义的IPAM规划中，自动获取了192.168.24.163这个IP地址
- 在之前的演示中，我们发现通过PING命令来排查网络故障有比较大的局限性；现在让我们看看借助VMware NSX DC的跟踪流工具能否帮助管理员更好地实现运维
- 比如，管理员在NSX DC的图形界面，试图查看容器yelb-appserver与另一个租户的一台裸金属服务器s7-front-01之间的数据流走向
- 可以看到NSX DC能够将整个数据流的走向详细地描绘，包括数据包经过的逻辑交换机、逻辑路由器、分布式防火墙；Overlay传输经过的封装隧道以及可能存在的网络地址转换NAT
试想，如果因为防火墙规则或者NAT转换出错导致网络不可达的场景下，使用PING或者TRACEROUTE只能得到不可达或者某一个传输节点故障的结果，无法像使用NSX DC那样，能够对整个数据包经过的设备、节点、通道有一个清晰的可见性和洞察力。
有人会质疑，NSX DC的Trace Flow只能显示由它创建的逻辑网络路径，一旦流量进入VLAN网络，就无法追踪并呈现在页面上。这是一个客观存在的“缺陷”，但是各位要明白：第一，设计并实施VMware NSX DC的“假设”是VLAN网络或者Underlay网络正常，物理网络故障导致的“风险”需要被考量，但并非NSX DC设计与实施的“范围”；第二，借助于VMware vRealize Network Insight，支持对容器网络在内的逻辑网络以及各类物理设备组网的VLAN网络实现可见性和洞察力，来填补这个“缺陷”。
0x03.Pod细粒度的QoS支持
有时候，管理员需要限制Pod的入向或者出向带宽，这类需求可以借助于NSX DC的端口配置文件轻松实现。在NSX DC与OpenShift集成后，创建的每一个Namespace对应一个逻辑交换机；每一个Pod对应逻辑交换机上的一个端口；而NSX DC的端口配置文件支持针对逻辑交换机全局或者端口两种层级生效。我们知道，对于采用VMXNET3虚拟网卡的容器虚拟机来说，节点与节点之间的带宽可以达到10Gbps；现在我将通过端口配置文件，设置出向和入向的流量均为0.1Gbps。
- 在没有任何QoS的情况下，网络带宽将被完全占用
- 在NSXMGR上创建一个QoS策略，如输出输入带宽限制为100Mbps
- 可以在多个维度生效这个逻辑交换机QoS策略：
对于NSX-DEMO NAMESPACE(逻辑交换机)，全局应用生效
对于Default-Client，在逻辑端口级别生效
- 可以看到在应用了QoS策略后，有效带宽只有限定的100Mbps，包括出向和入向。
因此，借助于NSX DC的端口配置文件，管理员可以非常方便的设置包括QoS、端口镜像、Spoof Guard等在内的多项功能，来实现各类需求；实现方式是通过在GUI界面简单的鼠标点击，大大提高了管理员的运维效率。
现在，让我们总结一下NSX DC与容器集成后带来的好处之三：
0x01.IPAM解决混乱无章的地址规划
0x02.TRACE FLOW帮助管理员快速定位网络故障
0x03.Pod细粒度的QoS支持
在下一篇分享中，我将继续为各位带来NSX DC与容器集成后带来的好处，敬请关注。
