这是己亥年的最后一篇公众号更新,想谈谈自己与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-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也会不定期分享一些阶段性的成果。
最后,也祝各位技术爱好者在即将到来的新年里,万事如意