Project Pacific的第一次接触(转）

这是己亥年的最后一篇公众号更新，想谈谈自己与VMware Pacific产品的第一次接触，提供一些配置的参考，感兴趣的朋友们可以一起对照着在自己的环境中进行模拟。

首先我们来看几张演示用例：

这可能是许多应用开发人员的日常操作，用已经写好的YAML文件，在创建一个容器应用的同时，提供了一个入口，便于外部用户来访问。这并不是一件稀奇的事情，除了运行容器的节点不再是一台裸金属服务器或者虚拟机，而是占据了服务器虚拟化市场九成以上份额的VMware vSphere Server(ESXi)这一点。

之前，我一直天真地将Tanzu和Project Pacific划等号，在与好友，来自VMware的大拿-Gordon.Chen（此处应有鲜花与掌声）交流中，逐渐逐渐开始深入了解Project Pacific，也意识到Tanzu是一盘很大的棋，也让我看到了VMware的宏伟愿景。相信很多“技术宅”与我一样，在了解一个新事物的时候，更喜欢亲自动手，通过LAB来感受一下Project Pacific这个划时代产品带来的革新。

下面就请跟随我的脚步，一步一步搭建起最基本的Supervisor群集，感受一下吧。

 第一步：准备好至少3台ESXi服务器，版本要求7.0

我的环境中，所有的ESXi主机全部采用虚拟机嵌套部署的模式，分配8vCPU、32GB内存，可以非常顺利地完成Supervisor群集的构建。

需要注意的一点：在以前的版本中，ESXi会自动将系统的安装盘格式化成VMFS5，可作为本地存储提供虚拟机分配使用；但是在我接触ESXi7.0的时候发现这种情况发生了改变，这块盘无法再作为数据存储使用，请务必注意。

第二步：完成vCenter Server Appliance 7.0的安装。

这里也有几点需要注意的地方：

1. 7.0只有VCSA，没有在Windows Server上安装的vCenter Server版本；

2. 7.0不再有外置PSC，以增强型链接模式组成SSO域的这种部署方式，这一点如果部署过6.7的朋友一定不陌生，因为VMware把这个信息明确写在了安装过程的提示中；

3. 至少采用小型SMALL规模部署，建议在资源充足的情况下，以中等MEDIUM规模部署。

第三步：完成NSX Data Center 3.0安装

对于NSX-T3.0来说，没有什么特别需要注意的地方，完成这些基础架构的准备工作后，才能正式开始Supervisor群集的部署。

注：3.0在进行主机传输节点配置NSX的过程中，提供了一个进度条，这是非常友好的一次更新！！！（重要的事情也就说一遍）

此时，不妨通过之前的一篇分享，来看看NSX DC与容器集成的场景中，我们需要做的事情，可以发现两者的准备工作基本相似。

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

第四步：部署至少一台（建议两台）NSX-T的边界传输节点，组成一个边界群集。

第五步：将至少3台ESXi主机组成一个群集，开启DRS和HA功能；当然像NTP服务器同步设置、开启SSH服务这些基本的操作，我就不赘述了。

第六步：完成存储策略的设置。

在Project Pacific的世界中，容器镜像、临时存储等均通过虚拟机存储策略的定义，被放置在对应的数据存储中，如VMware vSAN超融合数据存储或者其他NFS、IPSAN这样的共享存储。

在我的环境中，我使用了一台CentOS操作系统的虚拟机部署了NFS服务器角色，提供至少500GB的存储空间给ESXi服务器使用，用于包括容器镜像、临时磁盘等和常规虚拟机在内的所有对象。

比如S5-NFS-01，我首先为他定义并分配了一个“WCP-CLuster-01-TAG”的标记，再创建一个WCP-Storage-Policy虚拟机存储策略，允许将相关的对象存储到包含这个标记的数据存储之上。

第七步：规划并实施网络。

在我的环境中，我通过软路由器规划了如下网络：

• 172.16.18.0/24 用于ESXi服务器、vCenter Server、NSX DC Manager使用的可路由管理网络；

• 172.16.17.0/24 用于容器API Master虚拟机和群集IP使用的可路由网络；

• 172.16.19.0/24 南北向可路由网络，Tier0 SR上联地址为172.16.19.253/24

• 172.16.0.0/21 用于容器内部网络使用的不可路由网络，在满足容器应用东西向可达的需求下，采用封闭网络，避免被外部直接访问，满足业务安全性的考量；

• 10.96.0.0/24 用于容器服务使用的不可路由网络，理由同上；

• 172.16.8.0/24 用于容器入口，提供外部访问应用的可路由网络，以负载均衡器VIP的形式存在；

• 172.16.9.0/24 用于容器出口，以源网络地址转换的方式实现内部网络访问外部，如下载镜像等。

  

因此，整体的网络拓扑如上所示，在运行Supervisor群集创建向导的时候，各位可以看到这张拓扑图展现的整体网络结构。

第八步：通过DCLI方式，在vCenter中添加NSX-T的管理员账号，用于API通信

# dcli +i +show-unreleased-apis

# nsxd principalidentity create --username admin --password VMware1!VMware1!

第九步：一切就绪，开始运行Supervisor群集构建向导。

• 通过vCenter，启用工作负载管理；

• 选择兼容的群集，如WCP Cluster 01群集；

• 根据实际需要，选择部署规模；

• 定义API Master虚拟机（合计三台组成一个群集）的网络规划；

• 选择Edge群集，所有的Tier1逻辑路由器均会自动连接到该Edge群集承载的Tier0逻辑路由器；

• 定义Pod网络，内部网络，不需要被路由；

• 定义输入Ingress CIDR，作为负载均衡器的VIP地址，需要被路由，作为容器入口；

• 定义输出Egress CIDR，作为SNAT的地址，需要被路由，作为容器网络访问包括Internet在内的外部网络的入口；

• 根据虚拟机存储策略的定义，指定各类存储路径；

• 确认无误，开始WCP群集的自动创建。

• 创建时间约1小时，期间可以看到vCenter自动下载并部署OVF，以及在NSX-T Manager上看到一系列逻辑组件的创建。

注：可能会出现一些错误，属于正常现象，耐心等待即可

• 等待群集创建完成，期间必须满足IP地址的正常连通性。

对于Project Pacific来说，最小的管理单元被称为命名空间Namespace；

回想，在之前的服务器虚拟化运维场景中，管理员是通过VMX配置文件，为虚拟机分配硬件资源；也可以创建一个资源池，为某一个应用、租户分配包括CPU、内存在内的资源。

在Project Pacific的世界里，基础架构管理员也像对待虚拟机那样，为Namespace分配资源，比如最多可以使用多少内存、存储，可以创建多少POD等。

因此，在这种架构下，基础架构管理员或者IT运维人员，更关注于平台的性能、高可用性、可恢复性等方面；而开发人员更关注于代码、测试等。双方都在同一个平台，用自己最熟悉的方式共同助力业务的快速上线和稳定运行，是一个理想的协同工作模式。

当然，这仅仅只是我刚刚接触Project Pacific的一点感悟；其实除了Supervisor群集，Pacific的精髓是Guest群集，最近一段时间，我也在努力地学习和摸索中；上述的分享，只是告诉大家想要部署一个Supervisor群集需要执行哪些步骤。

对于一名有强迫症的工程师来说，看到上面的演示环境，是有一种成就感的。在未来的庚子年，我计划推出一些像Cloud Foundation、NSX Advance LoadBalancer(AVI)的分享；同时Project Pacific也会不定期分享一些阶段性的成果。

最后，也祝各位技术爱好者在即将到来的新年里，万事如意