通过努力,我们有了一个完整配置的工作负载域,其中包括一个NSX-T Edge部署。现在,我们准备继续使用Kubernetes 部署vSphere。通过VMware Cloud Foundation 4.0中的SDDC Manager,我们确保NSX-T Edge可用,并且还确保Workload Domain获得了足够的许可以启用带有Kubernetes的vSphere。
为清楚起见,本文基于GA Cloud的VMware Cloud Foundation 4.0之前版本。尽管人们认为在撰写本文至产品上市之间应该没有太大变化,但我希望读者意识到在此之前功能行为和用户界面仍可能会发生变化。
验证工作负载域
该过程的第一步是验证工作负载域是否可以通过Kubernetes支持vSphere。SDDC管理器现在有一个名为“解决方案”的新部分。当前,有一个名为Kubernetes的解决方案–工作负载管理。首先,显然没有创建工作负载管理解决方案:
单击部署链接以开始。显示的第一个窗口是先决条件–您需要正确的许可证版本,带有NSX-T Edge群集和各个子网的已配置的基于NSX-T的工作负载域,其中两个必须进行路由(对于Ingress和Egress)。
选择以上所有条件后,我们就可以开始工作负载管理部署了。在“群集”部分中,选择工作负载域。如果存在兼容性问题,群集将不会显示在“兼容”部分中。相反,它将显示在不兼容部分中。不兼容视图还将显示群集不兼容的原因。在下面的屏幕截图中,我的WLD没有得到适当的许可,因此与带有Kubernetes的vSphere不兼容。
解决不兼容的原因后(例如,将正确的许可证版本应用于VI WLD),WLD将出现在“兼容”部分,您可以继续进行验证步骤。
现在,我们将进行全面验证,以确保凭据,资源和网络都存在,并且可用于使用Kubernetes推出vSphere。
验证了使用Kubernetes的vSphere的要求后,我们可以连接到vSphere环境以完成使用Kubernetes的vSphere设置。单击在vSphere中完成按钮:
vSphere与Kubernetes部署
单击“在vSphere中完成”按钮后,将启动vSphere Client,然后我们将其置于启用工作负载管理的起点。总共有5个步骤。第一步是选择一个vSphere群集,因为同一VI Workload Domain中可能存在多个群集。在此示例中,只有一个,因此我们选择它。
选择集群后,下一步是在“集群设置”中选择控制平面的大小。换句话说,将哪些资源分配到Supervisor Kubernetes Cluster Master虚拟机。
Project Pacific是带有Kubernetes的vSphere的原始名称。
出于可用性目的,提供了3个主服务器,称为“主管控制平面VM”。对于带有Kubernetes的vSphere,工作节点是集群中的ESXi主机。
下一步是提供控制平面主节点和工作负载网络的各种IP范围(例如Pod和Services)的网络详细信息。Pod和Service CIDR不需要是可路由的,但Ingress和Egress当然可以。在先决条件中,它声明入口和出口都至少需要/ 27 CIDR。这是32个IP地址的连续范围。请注意,在我的实验室测试中,我能够使用带有/ 28(仅16个IP地址)的Kubernetes部署vSphere。在部署时,立即创建了12条SNAT规则,因此/ 28仅可用于最基本的部署。每个新名称空间也将需要一个SNAT,因此最多只能有2个名称空间。要在带有Kubernetes的vSphere上做一些有用的事情,您肯定需要/ 27 CIDR,至少对于出口而言。
下一步是为带有Kubernetes的vSphere选择所需的各种磁盘的存储策略。基本上,您在此步骤中要做的是为控制平面节点磁盘,临时(临时)磁盘和图像缓存选择存储策略。
单击“选择存储”时,将显示可用存储策略列表。只需选择您要用于特定存储类型的存储。
最后,检查选择并完成。这将开始使用Kubernetes部署vSphere。
可以从vSphere Client监视进度,尤其是“最近”任务。
现在有很多动作在发生。其中一些任务包括但不限于:
部署3个主VM / Supervisor控制平面VM
在NSX-T中为整个K8s服务阵列创建一组SNAT规则(出口)
在NSX-T中为K8s控制平面创建负载均衡器(入口)
在ESXi主机上安装Spherelet,以便它们充当Kubernetes辅助节点
从NSX-T中,我们可以看到12个SNAT规则:
如前所述,一旦您开始构建名称空间,就会创建一个新的SNAT规则。因此,在部署时正确设置Egress CIDR非常重要,否则您很快就会用完地址。
我提到过,还创建了一个负载均衡器–用于多主控平面API服务器。我们可以连接到LB虚拟IP地址,而不是连接到单个主机。这意味着,如果任何控制平面虚拟机存在问题,将不会引起注意。与API服务器的连接将直接重定向到后端的其他控制平面主机。这是在我的环境中用于控制平面的入口/负载平衡器IP地址:
您可以从vCenter Server上名为wcpsvc.log的日志文件中监视所有带有Kubernetes的vSphere部署活动。我通常让tail命令运行以查看详细活动:
root@vcsa-04 [ ~ ]# cd /var/log/vmware/wcproot@vcsa-04 [ /var/log/vmware/wcp ]# ls -l
total 18532
-rw------- 1 root root 23102 Mar 20 09:00 gcm-telemetry
-rw-r--r-- 1 root root 9445965 Mar 20 09:02 nsxd.log
-rw------- 1 root root 111 Mar 19 11:05 stdstream.log-0.stderr
-rw------- 1 root root 42 Mar 19 11:05 stdstream.log-0.stdout
-rw------- 1 root root 1865 Mar 19 04:06 stdstream.log-1.stderr
-rw------- 1 root root 42 Mar 18 16:06 stdstream.log-1.stdout
-rw------- 1 root root 3719 Mar 20 08:25 stdstream.log.stderr
-rw------- 1 root root 42 Mar 19 12:20 stdstream.log.stdout
-rw-r--r-- 1 root root 778392 Mar 19 12:09 wcpsvc-2020-03-19T12-09-03.220.log.gz
-rw-r--r-- 1 root root 8687263 Mar 20 09:03 wcpsvc.logroot@vcsa-04 [ /var/log/vmware/wcp ]# tail -f wcpsvc.log
如果一切都按计划进行,则应该在vSphere Client和SDDC Manager>解决方案>工作负载管理中都看到部署完成:
在vSphere客户端中,如果我们导航到vSphere UI中的``工作负载管理>命名空间'',则会看到一条消息,指出工作负载管理已成功部署,并且现在可以通过在Supervisor群集上创建命名空间和其他Kubernetes对象来开始工作了。这些可以是您的典型Kubernetes对象(例如Pod,Deployments,StatefulSets),也可以是其他事物,例如Tanzu Kubernetes Grid(TKG)Guest Kubernetes集群的完整部署。
希望这篇文章显示了VMware Cloud Foundation 4.0中如何实现自动化配置、验证和部署基础架构,这些基础架构有助于使用Kubernetes轻松部署vSphere。