1. 为什么要在 vSphere 7 上跑 Tanzu Kubernetes 集群第一次接触 vSphere 7 内置的 Tanzu Kubernetes 集群功能时我的反应是这不就是把 K8s 塞进虚拟机里吗。但真正用起来才发现这套方案解决的是一个非常具体的痛点企业已经有成熟的 vSphere 虚拟化平台和运维团队不想为了跑容器再单独搭一套裸金属 Kubernetes 集群。传统做法是在物理机上装 K8s网络、存储、监控全部要重新规划运维团队还得重新学一套东西。而 vSphere 7 的 Tanzu 方案本质上是让 vSphere 自己变成一个K8s 编排器——你通过 vSphere 的管理界面声明一个集群规格它自动帮你在 ESXi 主机上创建一批虚拟机在这些虚拟机里装好 K8s 组件最后把 kubeconfig 交给你。整个过程不需要你手动 SSH 到任何节点上装 kubelet、配 etcd。这套东西适合谁我总结下来是三类人一是手里已经有 vSphere 环境、想快速验证容器化改造的运维工程师二是需要给开发团队提供自助式 K8s 集群的平台管理员三是想搞清楚 vSphere 和 K8s 到底怎么结合的技术负责人。如果你连 vSphere 都没碰过建议先把 vCenter 的基本操作摸熟再来看这个。需要提前说清楚一个概念区分vSphere 7 里有两个容易混淆的东西。一个是Tanzu Kubernetes Grid Service简称 TKG Service这是 vSphere with Tanzu 的一部分让你在 vSphere 上直接创建Tanzu Kubernetes 集群官方叫 TKCTanzu Kubernetes Cluster。另一个是独立的Tanzu Kubernetes GridTKG那是可以跑在多种基础设施上的完整发行版。这篇讲的是前者也就是 vSphere 7 里内置的那套。2. 动手前的环境准备与前置条件2.1 版本与许可的硬性门槛这一步踩坑的人最多因为版本不对后面全白搭。我列一下最低要求组件最低版本说明vSphere / ESXi7.0 Update 1 及以上U1 之前的功能不完整建议直接上 U2 或 U3vCenter Server7.0 U1 及以上必须部署 vCenter独立 ESXi 不行NSX-T3.0 及以上网络方案之一非必须但推荐许可级别Enterprise Plus这是关键标准版没有 Tanzu 功能许可这块我要重点提醒vSphere with Tanzu 需要 Enterprise Plus 级别的许可而且还要额外启用 Tanzu 相关的授权。很多人环境搭好了发现工作负载管理菜单是灰的八成就是许可不够。这个不是技术问题是商务问题提前跟采购确认好。2.2 网络方案的选型逻辑vSphere with Tanzu 支持两种网络方案选哪个直接决定你后面配置的复杂度NSX-T 方案功能最全支持 LoadBalancer 服务、网络策略、命名空间隔离。但需要单独部署 NSX-T Manager 集群配置量大学习曲线陡。vDSvSphere Distributed Switch方案用 vSphere 自带的分布式交换机配置简单但 LoadBalancer 功能受限需要额外部署一个 HAProxy 或 Avi 来做负载均衡。我的建议是如果只是做 PoC 或者小规模内部使用选 vDS 方案能省掉大量 NSX-T 的配置工作。如果是生产环境、需要多租户隔离那 NSX-T 是绕不开的。下面我以 vDS 方案为主线讲因为它的门槛更低更适合大多数人上手。2.3 三台管理虚机的规划启用工作负载管理之前需要先准备好管理网络的三台虚机官方叫 Supervisor 的组成部分实际部署时会自动创建但你要预留资源控制平面节点3 台每台建议 4 vCPU / 16GB 内存 / 16GB 磁盘Worker 节点至少 3 台规格同上这些虚机是 Supervisor Cluster 的载体它们本身跑的是 ESXi 上的特殊虚拟机叫 CRX 或 Photon OS不是普通的 Linux 虚机。资源要提前在集群里预留出来别到时候发现 ESXi 主机内存不够。提示Supervisor Cluster 的这三台控制平面节点是管理面跟你后面创建的 Tanzu Kubernetes 集群是两回事。前者是管集群的集群后者才是你真正跑业务负载的地方。这个概念一定要分清否则后面看拓扑图会晕。2.4 存储策略的准备K8s 的 Pod 需要持久化存储vSphere 里对应的是Storage Policy。你需要在 vCenter 里提前创建好一个存储策略比如基于 vSAN 的vSAN Default Storage Policy或者基于 VMFS 的自定义策略。这个策略后面在创建 TKC 集群时要指定用来给 PVCPersistent Volume Claim提供底层存储。如果环境里没有 vSAN用普通的共享存储iSCSI、NFS也行但需要装对应的 CSI 驱动。vSphere 7 内置了 vSphere CSI 驱动对 vSAN 和 VMFS 支持最好。3. 启用工作负载管理的完整实操3.1 在 vCenter 里开启 Workload Management登录 vCenter进入你的集群Cluster对象点击配置标签页找到工作负载管理Workload Management。点击启用会进入一个向导。向导第一步是选择网络方案。这里选vDS 方案如果你的环境有 NSX-T也可以选 NSX-T。然后选择你准备好的分布式交换机指定管理网络的端口组。第二步是配置 Supervisor Cluster 的规格。这里要填控制平面大小Small / Medium / Large对应不同的 vCPU 和内存。PoC 选 Small 就够。API Server 端点填一个 VIP 地址这个地址要提前在 DNS 里解析好指向后面 Supervisor 的 API Server。DNS 服务器必须填Supervisor 节点要靠它解析域名。第三步是选择存储策略选你前面创建好的那个。第四步是确认配置点完成。这时候 vCenter 会开始自动部署 Supervisor Cluster大概需要 15-30 分钟。你可以在工作负载管理页面看到进度。3.2 验证 Supervisor Cluster 状态部署完成后进入工作负载管理 - 集群应该能看到 Supervisor Cluster 的状态是运行中。同时在 vCenter 的主机和集群视图里会多出一个叫SupervisorControlPlane之类的资源池里面有三台虚机。这时候你可以用kubectl连上 Supervisor Cluster 试试# 从 vCenter 下载 Supervisor Cluster 的 kubeconfig # 在 vCenter 的工作负载管理页面有下载链接 export KUBECONFIG./supervisor-kubeconfig.yaml kubectl get nodes如果能看到三台控制平面节点说明 Supervisor 已经就绪。注意这个 kubeconfig 的权限很高是管理员级别的别随便分发。3.3 创建命名空间Namespace在 vSphere with Tanzu 里命名空间是资源隔离和权限分配的基本单位。你创建的 Tanzu Kubernetes 集群必须归属于某个命名空间。在 vCenter 里进入工作负载管理 - 命名空间点击新建命名空间。填一个名字比如dev-team-a。然后配置权限给这个命名空间分配用户或用户组比如把某个 AD 组设为编辑者。资源限制可以设置 CPU、内存、存储的配额防止某个团队把资源吃光。存储指定这个命名空间可以用的存储策略。创建完成后这个命名空间在 Supervisor Cluster 里就对应一个 K8s Namespace。你可以用 Supervisor 的 kubeconfig 查看kubectl get namespaces # 应该能看到 dev-team-a3.4 给命名空间分配 Tanzu Kubernetes 版本这一步很多人会漏掉。Tanzu Kubernetes 集群的版本比如 v1.21、v1.22是通过TanzuKubernetesRelease对象管理的。你需要先确认集群里有哪些可用的版本kubectl get tanzukubernetesreleases如果列表是空的说明没有可用的版本。这时候需要去 vCenter 的工作负载管理 - Tanzu Kubernetes 版本里检查是否有版本被标记为可用。如果没有可能需要从官方渠道导入 OVA 镜像。这个导入过程比较耗时建议提前做。4. 创建你的第一个 Tanzu Kubernetes 集群4.1 用 YAML 声明式创建集群vSphere with Tanzu 创建 TKC 集群有两种方式一是通过 vCenter 界面点选二是通过 YAML 声明。我强烈推荐YAML 方式因为可版本化、可复用、可自动化。下面是一个典型的 TKC 集群 YAMLapiVersion: run.tanzu.vmware.com/v1alpha1 kind: TanzuKubernetesCluster metadata: name: my-first-tkc namespace: dev-team-a spec: topology: controlPlane: replicas: 3 vmClass: guaranteed-small storageClass: vsan-default-storage-policy tkr: reference: name: v1.22.6---vmware.1-tkg.1 nodePools: - name: worker-pool-1 replicas: 3 vmClass: guaranteed-medium storageClass: vsan-default-storage-policy tkr: reference: name: v1.22.6---vmware.1-tkg.1 settings: network: cni: name: antrea services: cidrBlocks: [10.96.0.0/12] pods: cidrBlocks: [192.168.0.0/16] storage: defaultClass: vsan-default-storage-policy几个关键字段解释一下vmClass虚机规格类guaranteed-small表示 2 vCPU / 8GB 内存guaranteed-medium是 4 vCPU / 16GB。这个类是在 Supervisor 里预定义的可以用kubectl get virtualmachineclasses查看。storageClass存储策略对应你前面在 vCenter 里创建的。tkr.reference.nameTanzu Kubernetes Release 的版本名必须跟kubectl get tanzukubernetesreleases里的名字完全一致。cni.name容器网络插件vSphere 7 默认用 Antrea也支持 Calico。cidrBlocksPod 和 Service 的网段注意不要跟你的物理网络冲突。4.2 应用 YAML 并观察创建过程把上面的 YAML 保存为tkc.yaml然后kubectl apply -f tkc.yaml接下来就是等待。TKC 集群的创建过程包括创建虚机、安装 K8s 组件、加入集群、配置网络。整个过程大概 10-20 分钟。你可以用下面的命令观察状态kubectl get tkc -n dev-team-a kubectl describe tkc my-first-tkc -n dev-team-a当status.phase变成running时集群就绪了。4.3 获取 TKC 集群的 kubeconfig集群创建好后你需要拿到它的 kubeconfig 才能操作。vSphere 提供了一个 secret 来存储kubectl get secret my-first-tkc-kubeconfig -n dev-team-a -o jsonpath{.data.value} | base64 -d tkc-kubeconfig.yaml export KUBECONFIG./tkc-kubeconfig.yaml kubectl get nodes这时候你应该能看到 3 个控制平面节点和 3 个 worker 节点。恭喜你的第一个 TKC 集群跑起来了。注意这个 kubeconfig 里的证书是有有效期的默认大概一年。到期前记得更新否则会突然连不上。更新方法是在 vCenter 里重新生成或者用kubectl的证书轮换功能。5. 集群运维中的常见问题与排查5.1 集群一直卡在 Creating 状态这是最常见的问题。排查思路按顺序来看 Supervisor 的事件kubectl get events -n dev-team-a --sort-by.lastTimestamp通常能看到具体卡在哪一步。检查资源配额命名空间的 CPU/内存配额是否够。如果配额不足虚机创建会失败。检查存储策略存储策略是否真的能分配到存储。有时候策略创建了但没关联到数据存储。检查 IP 池vDS 方案下Supervisor 需要一个 IP 池来给 TKC 节点分配 IP。如果 IP 池耗尽新节点起不来。我遇到过一次卡在 Creating 超过 40 分钟最后发现是 IP 池只配了 10 个地址而集群需要 6 个节点加一些临时地址刚好不够。把 IP 池扩大后立刻就好了。5.2 Pod 无法访问外部网络TKC 集群默认的 CNI 是 AntreaPod 出网需要 SNAT。如果 Pod 访问不了外网检查Supervisor 的出口网络Supervisor 节点本身能不能访问外网。Antrea 的 SNAT 规则kubectl get antreacontrollerinfo看看状态。DNS 配置Pod 里的/etc/resolv.conf是否正确指向了 DNS 服务器。5.3 PVC 一直 PendingPVC 卡在 Pending九成是存储策略的问题。检查kubectl get pvc -n namespace kubectl describe pvc pvc-name -n namespace看 Events 里有没有 no storage class 或 failed to provision volume 之类的信息。常见原因是存储策略没有正确关联到 vSphere 的存储或者 CSI 驱动没装好。5.4 常见问题速查表现象可能原因排查命令TKC 卡在 Creating资源配额不足 / IP 池耗尽kubectl get events -n nsPod 无法出网SNAT 未生效 / DNS 错误kubectl exec -it pod -- nslookup baidu.comPVC Pending存储策略未关联 / CSI 异常kubectl describe pvc namekubeconfig 失效证书过期重新生成 kubeconfig节点 NotReady网络插件异常 / 资源不足kubectl describe node name6. 几个我踩过的坑和实操心得第一个坑版本匹配。Tanzu Kubernetes Release 的版本必须跟 Supervisor 的版本兼容。我试过用一个较新的 TKR 去连一个较旧的 Supervisor结果集群创建到一半就失败了。建议在 vCenter 的Tanzu Kubernetes 版本页面里只启用跟当前 Supervisor 兼容的版本。第二个坑DNS 必须提前配好。Supervisor 和 TKC 节点都依赖 DNS 解析。如果 DNS 没配好节点之间无法互相发现集群永远起不来。我建议在启用工作负载管理之前先把所有需要的域名解析API Server VIP、节点主机名在 DNS 里配好。第三个坑资源预留。Supervisor Cluster 的三台控制平面虚机是常驻的会一直占用 ESXi 主机的资源。如果你的 ESXi 主机资源紧张建议先扩容再启用。我见过有人在一台 64GB 内存的 ESXi 上启用结果 Supervisor 一跑起来剩下的资源连一个 TKC 集群都开不出来。第四个坑kubeconfig 管理。Supervisor 的 kubeconfig 权限极高能操作所有命名空间。千万别把它当成日常使用的 kubeconfig。日常操作应该用命名空间级别的 kubeconfig或者用 TKC 集群自己的 kubeconfig。第五个坑升级要谨慎。TKC 集群的升级比如从 1.21 升到 1.22是通过修改 YAML 里的 TKR 版本触发的。升级过程中控制平面会滚动重启业务会有短暂中断。生产环境建议在维护窗口做并且提前备份 etcd。7. 这套方案到底值不值得用用下来我的感受是如果你的团队已经在用 vSphere而且不想维护两套基础设施那这套方案非常值得。它把 K8s 集群的生命周期管理交给了 vSphere运维团队不需要学太多新东西开发团队也能自助申请集群。但如果你追求极致的性能和灵活性或者需要跑大规模 GPU 训练之类的负载那裸金属 K8s 或者公有云托管 K8s 可能更合适。vSphere 上的 TKC 集群毕竟跑在虚机里网络和存储都有虚拟化层的开销。还有一个现实问题这套方案的许可成本不低。Enterprise Plus 加上 Tanzu 授权价格比标准版高不少。如果只是小规模测试可以考虑用 vSphere 的评估版先跑通流程再决定要不要采购。最后分享一个小技巧创建 TKC 集群时worker 节点的数量建议至少 3 个这样即使一个节点挂了业务也不会中断。控制平面 3 个节点是标配别省。如果资源实在紧张可以先用 1 个控制平面 1 个 worker 做 PoC但生产环境千万别这么干。这套东西的生态还在快速演进vSphere 8 里已经有不少改进。如果你现在还在用 vSphere 7建议至少升到 U3稳定性和功能都成熟很多。