1. 项目背景与整体设计思路1.1 为什么要在 vSphere 7 上跑 Tanzu Kubernetes 集群先把这个标题拆开看。vSphere 7 是虚拟化层Tanzu Kubernetes 集群后面我统一叫它 TKC也就是 Tanzu Kubernetes Cluster是跑在 vSphere 之上的 Kubernetes 集群。两者结合的核心价值在于你不需要再单独找一堆物理机去搭 Kubernetes而是直接复用现有的 vSphere 资源池在几分钟内拉起一个符合上游社区标准的 K8s 集群。我在实际项目中接触这个组合最初的需求很直接——某公司内部有一个已经跑了多年的 vSphere 环境上面有几百台虚拟机运维团队对 vSphere 的整套体系非常熟悉。现在业务部门要上容器化要求提供 Kubernetes 能力但又不想引入一套完全独立的裸金属 K8s 集群因为那意味着多一套网络方案、多一套存储方案、多一套监控体系。TKGTanzu Kubernetes Grid跑在 vSphere 7 上恰好能把这些统一起来。具体来说vSphere 7 里内置了一个叫Supervisor Cluster主管集群的东西它本质上是一个管理面负责编排 TKC 的生命周期。你在 Supervisor Cluster 上创建一个 TKC它就会自动在指定的资源池里创建若干虚拟机在这些虚拟机里装好 Kubernetes 组件然后把 kubeconfig 交给你。整个过程不需要你手动 SSH 到任何节点上去装 kubelet、装容器运行时。这套方案解决的核心问题是让虚拟化管理员用他们熟悉的方式提供 Kubernetes 服务。适合谁来参考我认为有三类人一是负责 vSphere 基础设施的运维工程师需要了解怎么开启这套能力二是平台工程师需要知道 TKC 的网络、存储、权限怎么配三是应用开发团队的技术负责人需要理解 TKC 和普通 K8s 集群在使用上有什么差异。1.2 整体架构分层与组件关系要理解这套东西怎么跑起来得先把分层搞清楚。从下往上数ESXi 主机层物理资源提供方CPU、内存、存储、网卡都在这里。vCenter Server 层管理 ESXi 主机和虚拟机vSphere 7 的 vCenter 还额外承担了 Supervisor Cluster 的部署入口。Supervisor Cluster 层这是 vSphere 7 引入的新概念它本身是一组运行在 ESXi 上的虚拟机里面跑的是 Kubernetes 控制面组件。它对外暴露 Kubernetes API但它的作用是管理 TKC而不是直接跑你的业务负载。TKC 层真正跑业务容器的工作负载集群。每个 TKC 有自己的控制面节点和工作节点都是虚拟机形态。Namespace 层在 Supervisor Cluster 上资源是按 namespace 划分的。每个 namespace 对应一个资源池、一个存储策略、一个网络配置。你在某个 namespace 里创建 TKC这个 TKC 就继承该 namespace 的资源配额和网络设置。这个分层设计的好处是职责清晰。Supervisor Cluster 的管理员负责分配资源、配置网络和存储策略应用团队在自己的 namespace 里自助创建 TKC不需要关心底层 ESXi 主机在哪、存储卷怎么挂。我见过一些团队把 Supervisor Cluster 和 TKC 混在一起用直接在 Supervisor Cluster 上跑 Pod这是不推荐的——Supervisor Cluster 的资源应该留给管理组件业务负载全部放到 TKC 里。1.3 方案选型的几个关键考量在决定用这套方案之前有几个点值得想清楚。第一网络模式选什么。vSphere 7 的 TKC 支持两种网络模式NSX-T 和 vSphere 网络也叫原生网络。NSX-T 功能更全支持网络策略、负载均衡器、Ingress 等高级能力但前提是你得有一套 NSX-T 环境。如果只是想做基本的 Pod 网络和 Service 访问vSphere 网络也能用但功能受限。我个人的建议是如果已经有 NSX-T那就用 NSX-T如果没有先评估业务是否需要网络策略和高级负载均衡不需要的话 vSphere 网络也能凑合。第二存储策略怎么定。TKC 的节点虚拟机需要存储Pod 的持久卷也需要存储。vSphere 7 里通过存储策略来定义使用哪类数据存储。常见的做法是给 TKC 节点用一个策略比如基于 vSAN 或 iSCSI 的高性能策略给持久卷用另一个策略比如基于 NFS 的大容量策略。这个要在创建 namespace 的时候就规划好后面改起来比较麻烦。第三集群规模怎么估。一个 TKC 默认是 1 个控制面节点加 3 个工作节点。控制面节点默认 2 vCPU、8GB 内存工作节点默认 2 vCPU、8GB 内存。如果你要跑的资源比较多可以在创建时指定更大的规格。但要注意Supervisor Cluster 所在的资源池总容量是有限的所有 TKC 加起来不能超过这个上限。第四版本兼容性。vSphere 7 的不同小版本对 TKC 的支持程度不一样。比如 vSphere 7.0 Update 1 和 Update 2 支持的 Kubernetes 版本就不同。在规划阶段就要确认好 vCenter 的版本以及它支持的 TKC 版本范围。我踩过的坑是vCenter 升级到某个版本后旧的 TKC 模板可能不再兼容需要重新下载新的 OVA 模板。2. 核心细节解析与实操要点2.1 启用 Supervisor Cluster 的前置条件在 vSphere 7 里启用 Supervisor Cluster 不是点一个按钮就完事的需要满足一系列前置条件。我把这些条件分成三类来说。硬件和网络条件至少 3 台 ESXi 主机加入同一个 vCenter 集群且集群开启了 vSphere DRS 和 vSphere HA。这是因为 Supervisor Cluster 的控制面节点需要分布在不同的 ESXi 主机上保证高可用。每台 ESXi 主机至少有一个管理网络和一个工作负载网络。管理网络用于 vCenter 和 ESXi 通信工作负载网络用于 TKC 的 Pod 和 Service 流量。如果使用 NSX-T还需要额外的 NSX-T 管理网络和传输网络。所有 ESXi 主机的时间必须同步建议配置 NTP。vCenter 和许可条件vCenter Server 版本必须是 7.0 或更高且部署在 ESXi 主机上或作为 VCSA 运行。需要 vSphere 7 的 Enterprise Plus 许可或者至少是支持 Supervisor Cluster 的许可级别。这一点很容易被忽略我见过有人用 Standard 许可去试结果发现根本找不到启用入口。vCenter 的 SSO 账户需要有管理员权限。存储条件至少有一个共享存储可供 Supervisor Cluster 使用比如 vSAN、iSCSI、NFS 或 Fibre Channel。需要提前创建好存储策略用于 Supervisor Cluster 的控制面节点和 TKC 节点。注意如果你的环境里只有本地存储没有共享存储Supervisor Cluster 是起不来的。因为控制面节点需要跨 ESXi 主机迁移本地存储绑定了主机无法满足这个要求。2.2 创建 Supervisor Cluster 的实操步骤前置条件满足后创建 Supervisor Cluster 的流程大致如下。我以 vSphere 网络模式为例NSX-T 模式在步骤上类似只是多了一些网络配置项。第一步在 vCenter 里启用 Supervisor Cluster。登录 vCenter进入集群视图在“配置”选项卡里找到“Supervisor Cluster”部分点击“启用”。这时候会弹出一个向导。第二步选择网络模式。向导会让你选“NSX-T”还是“vSphere 网络”。选 vSphere 网络的话需要指定一个管理网络和一个工作负载网络。管理网络用于 Supervisor Cluster 控制面节点的管理流量工作负载网络用于 TKC 的 Pod 和 Service 流量。第三步配置控制面节点规格。默认是 3 个控制面节点每个 2 vCPU、8GB 内存、16GB 磁盘。如果环境规模较大可以适当调大。但要注意控制面节点不是越多越好3 个是标准配置再多也不会提升性能。第四步选择存储策略。这里要选一个存储策略用于控制面节点的虚拟机磁盘。建议选一个基于共享存储的策略比如 vSAN 默认策略或 iSCSI 策略。第五步指定管理网络的具体参数。包括 IP 地址段、子网掩码、网关、DNS 服务器等。这些参数会用于 Supervisor Cluster 控制面节点的管理网卡。第六步确认并启动。向导会显示一个摘要确认无误后点击“完成”。vCenter 会开始部署 Supervisor Cluster这个过程通常需要 15 到 30 分钟。部署完成后你会在集群的“主机和集群”视图里看到一个新的“Supervisor Cluster”对象。实操心得部署过程中如果卡在某个步骤超过 40 分钟大概率是网络或存储配置有问题。我遇到过一次是因为 DNS 解析不通导致控制面节点无法注册。排查方法是登录到部署失败的节点上检查 /var/log/ 下的日志重点看 cloud-init 和 kubelet 的日志。2.3 配置 Namespace 与资源配额Supervisor Cluster 部署好之后下一步是创建 Namespace。Namespace 是资源隔离的基本单位每个 Namespace 对应一个资源池、一个存储策略、一个网络配置。创建 Namespace 的步骤在 vCenter 里进入 Supervisor Cluster 的“命名空间”视图点击“新建命名空间”。输入命名空间名称比如“dev-team-a”。选择权限模型。可以选择“专属”或“共享”。专属模式下只有被授权的用户才能访问这个命名空间共享模式下所有登录用户都能看到。生产环境建议用专属模式。配置资源配额。包括 CPU 限制、内存限制、存储限制、Pod 数量限制等。这些配额决定了这个命名空间里所有 TKC 能使用的资源总量。选择存储策略。这里选的存储策略会用于该命名空间下 TKC 的持久卷。配置网络。如果用的是 vSphere 网络需要指定一个网络段如果用的是 NSX-T需要指定一个 NSX-T 分段。资源配额的计算方法假设你要在一个命名空间里跑 3 个 TKC每个 TKC 有 1 个控制面节点2 vCPU、8GB和 3 个工作节点2 vCPU、8GB。那么总需求是CPU(13) × 2 vCPU × 3 24 vCPU内存(13) × 8GB × 3 96GB存储每个节点 16GB 磁盘总共 (13) × 16GB × 3 192GB再加上 Pod 持久卷的需求比如每个 TKC 需要 100GB 持久卷3 个就是 300GB。所以存储配额至少要给 500GB。注意资源配额是硬限制超过配额后创建 TKC 会失败。但配额也不能给太大否则一个命名空间可能把整个 Supervisor Cluster 的资源吃光。建议按照“实际需求 × 1.5”来设置。2.4 TKC 的版本管理与模板更新TKC 的版本管理是一个容易被忽视但很重要的环节。vSphere 7 里的 TKC 是通过 OVA 模板来部署的每个 Kubernetes 版本对应一个 OVA 模板。这些模板需要从官方渠道下载然后上传到 vCenter 的内容库中。模板更新的流程确认当前 Supervisor Cluster 支持的 TKC 版本范围。可以在 vCenter 的 Supervisor Cluster 配置页面查看。下载对应版本的 OVA 模板。通常是一个几百 MB 到 1 GB 的文件。将 OVA 导入到 vCenter 的内容库。导入过程可能需要 10 到 20 分钟取决于网络速度。在 Supervisor Cluster 的配置里将新模板标记为可用。创建新的 TKC 时就可以选择新版本了。版本升级的注意事项TKC 的版本升级不是原地升级而是创建一个新版本的 TKC然后把工作负载迁移过去。这是因为 TKC 的节点是虚拟机原地升级风险较大。升级前要确认新版本的 Kubernetes API 是否兼容现有工作负载。比如从 1.19 升级到 1.20有些废弃的 API 可能就不能用了。升级过程中旧 TKC 和新 TKC 会同时存在需要确保资源配额足够。我个人的经验是不要频繁升级 TKC 版本除非有明确的安全补丁或功能需求。每次升级都是一次完整的迁移涉及网络、存储、权限的重新配置工作量不小。3. 实操过程与核心环节实现3.1 创建一个 TKC 集群的完整流程前面把前置条件、Supervisor Cluster、Namespace 都准备好了现在可以真正创建一个 TKC 了。我以命令行方式为例因为图形界面虽然直观但命令行更适合自动化和批量操作。第一步获取 Supervisor Cluster 的 kubeconfig。在 vCenter 里进入 Supervisor Cluster 的“概览”页面点击“下载 kubeconfig”。这个 kubeconfig 是用于访问 Supervisor Cluster API 的不是 TKC 的。下载后保存到本地比如~/.kube/supervisor-config。第二步配置 kubectl 使用 Supervisor Cluster 的 kubeconfig。export KUBECONFIG~/.kube/supervisor-config kubectl get namespaces如果配置正确你应该能看到 Supervisor Cluster 上的所有命名空间包括你之前创建的那个。第三步在命名空间里创建 TKC 的 YAML 定义。TKC 是通过一个自定义资源Custom Resource来定义的这个资源的类型叫TanzuKubernetesCluster。下面是一个示例 YAMLapiVersion: run.tanzu.vmware.com/v1alpha1 kind: TanzuKubernetesCluster metadata: name: tkc-dev-01 namespace: dev-team-a spec: topology: controlPlane: count: 1 class: guaranteed-small storageClass: vsan-default workers: count: 3 class: guaranteed-small storageClass: vsan-default distribution: version: v1.19.3 settings: network: cni: name: antrea services: cidrBlocks: [10.96.0.0/12] pods: cidrBlocks: [192.168.0.0/16]这个 YAML 里几个关键字段解释一下topology.controlPlane.count控制面节点数量通常为 1 或 3。1 个用于测试3 个用于生产。topology.workers.count工作节点数量根据业务负载决定。class节点规格类guaranteed-small对应 2 vCPU、8GB 内存。还有guaranteed-medium、guaranteed-large等。storageClass存储类对应之前配置的存储策略。distribution.versionKubernetes 版本必须是 Supervisor Cluster 支持的版本。settings.network.cni.name容器网络接口vSphere 7 默认用 Antrea。services.cidrBlocks和pods.cidrBlocksService 和 Pod 的 IP 段不能与现有网络冲突。第四步应用 YAML 并观察创建过程。kubectl apply -f tkc-dev-01.yaml kubectl get tkc -n dev-team-a -w-w参数会持续观察资源状态。你会看到状态从Creating变成Running这个过程通常需要 10 到 20 分钟。第五步获取 TKC 的 kubeconfig。TKC 创建完成后可以通过 Supervisor Cluster 获取它的 kubeconfigkubectl get secret tkc-dev-01-kubeconfig -n dev-team-a -o jsonpath{.data.value} | base64 -d ~/.kube/tkc-dev-01-config export KUBECONFIG~/.kube/tkc-dev-01-config kubectl get nodes如果一切正常你应该能看到 1 个控制面节点和 3 个工作节点状态都是Ready。3.2 网络配置的细节与参数计算网络是 TKC 里最容易出问题的部分。我见过太多因为 CIDR 冲突导致 Pod 起不来的案例。这里把网络配置的几个关键点展开说一下。Pod CIDR 和 Service CIDR 的规划Pod CIDR 是分配给 Pod 的 IP 段默认是192.168.0.0/16。这个段不能与节点网络、Service CIDR 以及外部网络冲突。Service CIDR 是分配给 Service 的 IP 段默认是10.96.0.0/12。这个段也不能与节点网络和 Pod CIDR 冲突。如果你有多个 TKC每个 TKC 的 Pod CIDR 和 Service CIDR 必须不同否则跨集群通信会出问题。一个实际的规划示例假设你的节点网络是172.16.0.0/24那么可以这样规划集群名称Pod CIDRService CIDRtkc-dev-01192.168.0.0/1610.96.0.0/12tkc-dev-02192.169.0.0/1610.100.0.0/12tkc-prod-01192.170.0.0/1610.104.0.0/12这样每个集群的 IP 段都是独立的不会冲突。Antrea CNI 的工作模式Antrea 是 vSphere 7 默认的 CNI它支持两种模式encap和noEncap。encap模式下Pod 之间的流量会被封装在 VXLAN 里适合跨子网通信noEncap模式下Pod 流量直接走底层网络性能更好但要求所有节点在同一个子网里。实操心得如果节点都在同一个子网建议用noEncap模式性能提升明显。如果节点跨子网只能用encap。切换模式需要在 TKC 的 YAML 里修改settings.network.cni配置但修改后需要重建 TKC不能原地切换。3.3 存储配置与持久卷的使用TKC 的存储分为两部分节点存储和持久卷存储。节点存储是虚拟机磁盘在创建 TKC 时通过storageClass指定。持久卷存储是给 Pod 用的通过 Kubernetes 的 StorageClass 和 PVC 来管理。创建 StorageClass在 TKC 里StorageClass 是由 Supervisor Cluster 自动同步过来的。你可以在 TKC 里直接查看kubectl get storageclass应该能看到一个或多个 StorageClass名称与 Supervisor Cluster 上配置的存储策略对应。创建 PVC 并使用下面是一个创建 PVC 的示例apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadWriteOnce storageClassName: vsan-default resources: requests: storage: 10Gi应用后Kubernetes 会自动在 vSphere 上创建一个虚拟磁盘并挂载到 Pod 里。存储性能的考量如果底层是 vSAN建议为持久卷单独创建一个存储策略比如设置 RAID 级别为 RAID-5 或 RAID-6而不是默认的 RAID-1。这样可以在容量和性能之间取得平衡。如果底层是 NFS要注意 NFS 服务器的 IOPS 上限。多个 Pod 同时读写同一个 NFS 卷时性能可能成为瓶颈。持久卷的大小一旦创建就不能缩小只能扩大。所以规划时要留有余量。我踩过的一个坑是创建 PVC 时选了ReadWriteMany访问模式但底层存储策略不支持导致 PVC 一直处于Pending状态。排查后发现是 vSAN 默认策略只支持ReadWriteOnce。解决办法是改用 NFS 存储策略或者把访问模式改成ReadWriteOnce。4. 常见问题与排查技巧实录4.1 TKC 创建失败的常见原因与排查路径TKC 创建失败是新手最常遇到的问题。根据我的经验失败原因大致可以分为四类资源不足、网络配置错误、存储策略不匹配、版本不兼容。资源不足症状TKC 状态一直停留在Creating或者直接变成Failed。排查检查 Supervisor Cluster 的资源池剩余容量以及命名空间的资源配额。解决释放不必要的资源或者扩大资源池和配额。网络配置错误症状TKC 创建成功但节点状态是NotReady或者 Pod 无法启动。排查检查 Pod CIDR 和 Service CIDR 是否与现有网络冲突检查 DNS 配置是否正确检查节点是否能访问外部网络。解决修改 CIDR 配置重建 TKC修复 DNS 配置。存储策略不匹配症状TKC 创建过程中卡在存储卷挂载阶段。排查检查存储策略是否存在以及是否与底层存储兼容。解决创建正确的存储策略或者修改 TKC 的storageClass字段。版本不兼容症状TKC 创建时提示版本不支持。排查检查 Supervisor Cluster 支持的 TKC 版本范围。解决下载并上传对应版本的 OVA 模板。下面是一个常见问题速查表问题现象可能原因排查方法解决方案TKC 状态卡在 Creating资源不足检查资源池和配额释放资源或扩大配额节点 NotReady网络配置错误检查 CIDR 和 DNS修改配置并重建PVC 一直 Pending存储策略不匹配检查 StorageClass创建正确的存储策略创建时提示版本不支持版本不兼容检查支持的版本范围上传对应 OVA 模板控制面节点无法启动共享存储不可用检查存储连通性修复存储配置4.2 网络不通的排查思路与工具网络问题是最难排查的因为涉及多层ESXi 层、Supervisor Cluster 层、TKC 层、Pod 层。我通常按照从下往上的顺序排查。第一层检查 ESXi 主机的网络。确认 ESXi 主机的管理网络和工作负载网络是否正常物理网卡是否 UpVLAN 配置是否正确。第二层检查 Supervisor Cluster 的网络。登录到 Supervisor Cluster 的控制面节点用ping和traceroute检查到外部网络的连通性。第三层检查 TKC 节点的网络。登录到 TKC 的工作节点检查节点的 IP 地址、路由表、DNS 配置。第四层检查 Pod 的网络。在 TKC 里创建一个测试 Pod用kubectl exec进入 Pod检查 Pod 的 IP 地址和到其他 Pod 的连通性。常用的排查命令# 检查节点网络 kubectl get nodes -o wide kubectl describe node node-name # 检查 Pod 网络 kubectl get pods -o wide kubectl exec -it pod-name -- ping target-ip # 检查 DNS kubectl exec -it pod-name -- nslookup kubernetes.default # 检查 CNI 状态 kubectl get pods -n kube-system | grep antrea实操心得如果 Pod 之间不通但节点之间通大概率是 CNI 的问题。可以检查 Antrea 的日志看看有没有 VXLAN 隧道建立失败的报错。如果节点之间都不通那就是底层网络的问题需要检查 ESXi 的虚拟交换机配置。4.3 性能调优的几个关键参数TKC 跑起来之后性能调优是下一步。我总结几个影响最大的参数。控制面节点的规格控制面节点负责 API Server、etcd、Controller Manager、Scheduler。如果 API 请求量大控制面节点容易成为瓶颈。建议生产环境至少用guaranteed-medium4 vCPU、16GB 内存。工作节点的规格工作节点跑业务 Pod规格取决于业务负载。CPU 密集型应用需要更多 vCPU内存密集型应用需要更大内存。建议先用guaranteed-small试跑然后根据监控数据调整。etcd 的磁盘性能etcd 对磁盘延迟非常敏感。如果底层存储的写延迟超过 10msetcd 的性能会明显下降。建议为控制面节点使用高性能存储策略比如 vSAN 的 RAID-1 策略或全闪存 NFS。Antrea 的 encap 模式前面提到过encap模式有封装开销性能比noEncap低 10% 到 20%。如果节点在同一子网强烈建议用noEncap。Pod 的资源限制在 TKC 里建议为每个 Pod 设置resources.requests和resources.limits。这样 Kubernetes 可以更好地调度 Pod避免某个 Pod 吃光节点资源。下面是一个性能调优的对照表调优项默认值建议值影响控制面节点规格guaranteed-smallguaranteed-medium提升 API Server 性能工作节点规格guaranteed-small根据负载调整提升业务性能etcd 存储策略默认策略高性能策略降低 etcd 延迟Antrea 模式encapnoEncap提升网络性能Pod 资源限制无设置 requests/limits提升调度效率4.4 日常运维中的注意事项TKC 跑起来之后日常运维有几个点要特别注意。证书管理TKC 的证书默认有效期是 1 年。到期后需要更新否则 API Server 无法访问。更新证书需要登录到控制面节点手动执行命令。建议在证书到期前 1 个月就安排更新。备份与恢复TKC 的 etcd 数据需要定期备份。vSphere 7 本身不提供 TKC 的备份功能需要自己用工具比如 Velero来备份。备份内容包括 etcd 快照、PVC 数据、Kubernetes 资源定义。监控与告警建议在 TKC 里部署 Prometheus 和 Grafana监控节点资源、Pod 状态、API Server 延迟等指标。同时配置告警规则比如节点 NotReady、Pod 频繁重启、存储空间不足等。日志收集TKC 的节点日志和 Pod 日志需要集中收集。可以用 Fluent Bit 或 Filebeat 把日志发送到外部的日志平台。版本升级前面说过TKC 的版本升级是迁移式的。升级前要做好充分测试确保新版本兼容现有工作负载。升级过程中要保证资源配额足够避免新旧集群同时运行时资源不足。我个人在实际操作中的体会是TKC 这套东西把 Kubernetes 的部署门槛降低了很多但运维的复杂度并没有降低。你仍然需要理解 Kubernetes 的基本概念仍然需要处理网络、存储、证书、监控这些问题。vSphere 7 只是帮你把节点虚拟机管起来了里面的东西还是得自己管。所以如果你的团队没有 Kubernetes 运维经验建议先从小规模测试环境开始跑通了再上生产。 
长河君 · 2026/10/13 12:30:53 · 阅读 1.2k vSphere 7 上部署 Tanzu Kubernetes 集群：架构、实操与运维指南
1. 项目背景与整体设计思路1.1 为什么要在 vSphere 7 上跑 Tanzu Kubernetes 集群先把这个标题拆开看。vSphere 7 是虚拟化层Tanzu Kubernetes 集群后面我统一叫它 TKC也就是 Tanzu Kubernetes Cluster是跑在 vSphere 之上的 Kubernetes 集群。两者结合的核心价值在于你不需要再单独找一堆物理机去搭 Kubernetes而是直接复用现有的 vSphere 资源池在几分钟内拉起一个符合上游社区标准的 K8s 集群。我在实际项目中接触这个组合最初的需求很直接——某公司内部有一个已经跑了多年的 vSphere 环境上面有几百台虚拟机运维团队对 vSphere 的整套体系非常熟悉。现在业务部门要上容器化要求提供 Kubernetes 能力但又不想引入一套完全独立的裸金属 K8s 集群因为那意味着多一套网络方案、多一套存储方案、多一套监控体系。TKGTanzu Kubernetes Grid跑在 vSphere 7 上恰好能把这些统一起来。具体来说vSphere 7 里内置了一个叫Supervisor Cluster主管集群的东西它本质上是一个管理面负责编排 TKC 的生命周期。你在 Supervisor Cluster 上创建一个 TKC它就会自动在指定的资源池里创建若干虚拟机在这些虚拟机里装好 Kubernetes 组件然后把 kubeconfig 交给你。整个过程不需要你手动 SSH 到任何节点上去装 kubelet、装容器运行时。这套方案解决的核心问题是让虚拟化管理员用他们熟悉的方式提供 Kubernetes 服务。适合谁来参考我认为有三类人一是负责 vSphere 基础设施的运维工程师需要了解怎么开启这套能力二是平台工程师需要知道 TKC 的网络、存储、权限怎么配三是应用开发团队的技术负责人需要理解 TKC 和普通 K8s 集群在使用上有什么差异。1.2 整体架构分层与组件关系要理解这套东西怎么跑起来得先把分层搞清楚。从下往上数ESXi 主机层物理资源提供方CPU、内存、存储、网卡都在这里。vCenter Server 层管理 ESXi 主机和虚拟机vSphere 7 的 vCenter 还额外承担了 Supervisor Cluster 的部署入口。Supervisor Cluster 层这是 vSphere 7 引入的新概念它本身是一组运行在 ESXi 上的虚拟机里面跑的是 Kubernetes 控制面组件。它对外暴露 Kubernetes API但它的作用是管理 TKC而不是直接跑你的业务负载。TKC 层真正跑业务容器的工作负载集群。每个 TKC 有自己的控制面节点和工作节点都是虚拟机形态。Namespace 层在 Supervisor Cluster 上资源是按 namespace 划分的。每个 namespace 对应一个资源池、一个存储策略、一个网络配置。你在某个 namespace 里创建 TKC这个 TKC 就继承该 namespace 的资源配额和网络设置。这个分层设计的好处是职责清晰。Supervisor Cluster 的管理员负责分配资源、配置网络和存储策略应用团队在自己的 namespace 里自助创建 TKC不需要关心底层 ESXi 主机在哪、存储卷怎么挂。我见过一些团队把 Supervisor Cluster 和 TKC 混在一起用直接在 Supervisor Cluster 上跑 Pod这是不推荐的——Supervisor Cluster 的资源应该留给管理组件业务负载全部放到 TKC 里。1.3 方案选型的几个关键考量在决定用这套方案之前有几个点值得想清楚。第一网络模式选什么。vSphere 7 的 TKC 支持两种网络模式NSX-T 和 vSphere 网络也叫原生网络。NSX-T 功能更全支持网络策略、负载均衡器、Ingress 等高级能力但前提是你得有一套 NSX-T 环境。如果只是想做基本的 Pod 网络和 Service 访问vSphere 网络也能用但功能受限。我个人的建议是如果已经有 NSX-T那就用 NSX-T如果没有先评估业务是否需要网络策略和高级负载均衡不需要的话 vSphere 网络也能凑合。第二存储策略怎么定。TKC 的节点虚拟机需要存储Pod 的持久卷也需要存储。vSphere 7 里通过存储策略来定义使用哪类数据存储。常见的做法是给 TKC 节点用一个策略比如基于 vSAN 或 iSCSI 的高性能策略给持久卷用另一个策略比如基于 NFS 的大容量策略。这个要在创建 namespace 的时候就规划好后面改起来比较麻烦。第三集群规模怎么估。一个 TKC 默认是 1 个控制面节点加 3 个工作节点。控制面节点默认 2 vCPU、8GB 内存工作节点默认 2 vCPU、8GB 内存。如果你要跑的资源比较多可以在创建时指定更大的规格。但要注意Supervisor Cluster 所在的资源池总容量是有限的所有 TKC 加起来不能超过这个上限。第四版本兼容性。vSphere 7 的不同小版本对 TKC 的支持程度不一样。比如 vSphere 7.0 Update 1 和 Update 2 支持的 Kubernetes 版本就不同。在规划阶段就要确认好 vCenter 的版本以及它支持的 TKC 版本范围。我踩过的坑是vCenter 升级到某个版本后旧的 TKC 模板可能不再兼容需要重新下载新的 OVA 模板。2. 核心细节解析与实操要点2.1 启用 Supervisor Cluster 的前置条件在 vSphere 7 里启用 Supervisor Cluster 不是点一个按钮就完事的需要满足一系列前置条件。我把这些条件分成三类来说。硬件和网络条件至少 3 台 ESXi 主机加入同一个 vCenter 集群且集群开启了 vSphere DRS 和 vSphere HA。这是因为 Supervisor Cluster 的控制面节点需要分布在不同的 ESXi 主机上保证高可用。每台 ESXi 主机至少有一个管理网络和一个工作负载网络。管理网络用于 vCenter 和 ESXi 通信工作负载网络用于 TKC 的 Pod 和 Service 流量。如果使用 NSX-T还需要额外的 NSX-T 管理网络和传输网络。所有 ESXi 主机的时间必须同步建议配置 NTP。vCenter 和许可条件vCenter Server 版本必须是 7.0 或更高且部署在 ESXi 主机上或作为 VCSA 运行。需要 vSphere 7 的 Enterprise Plus 许可或者至少是支持 Supervisor Cluster 的许可级别。这一点很容易被忽略我见过有人用 Standard 许可去试结果发现根本找不到启用入口。vCenter 的 SSO 账户需要有管理员权限。存储条件至少有一个共享存储可供 Supervisor Cluster 使用比如 vSAN、iSCSI、NFS 或 Fibre Channel。需要提前创建好存储策略用于 Supervisor Cluster 的控制面节点和 TKC 节点。注意如果你的环境里只有本地存储没有共享存储Supervisor Cluster 是起不来的。因为控制面节点需要跨 ESXi 主机迁移本地存储绑定了主机无法满足这个要求。2.2 创建 Supervisor Cluster 的实操步骤前置条件满足后创建 Supervisor Cluster 的流程大致如下。我以 vSphere 网络模式为例NSX-T 模式在步骤上类似只是多了一些网络配置项。第一步在 vCenter 里启用 Supervisor Cluster。登录 vCenter进入集群视图在“配置”选项卡里找到“Supervisor Cluster”部分点击“启用”。这时候会弹出一个向导。第二步选择网络模式。向导会让你选“NSX-T”还是“vSphere 网络”。选 vSphere 网络的话需要指定一个管理网络和一个工作负载网络。管理网络用于 Supervisor Cluster 控制面节点的管理流量工作负载网络用于 TKC 的 Pod 和 Service 流量。第三步配置控制面节点规格。默认是 3 个控制面节点每个 2 vCPU、8GB 内存、16GB 磁盘。如果环境规模较大可以适当调大。但要注意控制面节点不是越多越好3 个是标准配置再多也不会提升性能。第四步选择存储策略。这里要选一个存储策略用于控制面节点的虚拟机磁盘。建议选一个基于共享存储的策略比如 vSAN 默认策略或 iSCSI 策略。第五步指定管理网络的具体参数。包括 IP 地址段、子网掩码、网关、DNS 服务器等。这些参数会用于 Supervisor Cluster 控制面节点的管理网卡。第六步确认并启动。向导会显示一个摘要确认无误后点击“完成”。vCenter 会开始部署 Supervisor Cluster这个过程通常需要 15 到 30 分钟。部署完成后你会在集群的“主机和集群”视图里看到一个新的“Supervisor Cluster”对象。实操心得部署过程中如果卡在某个步骤超过 40 分钟大概率是网络或存储配置有问题。我遇到过一次是因为 DNS 解析不通导致控制面节点无法注册。排查方法是登录到部署失败的节点上检查 /var/log/ 下的日志重点看 cloud-init 和 kubelet 的日志。2.3 配置 Namespace 与资源配额Supervisor Cluster 部署好之后下一步是创建 Namespace。Namespace 是资源隔离的基本单位每个 Namespace 对应一个资源池、一个存储策略、一个网络配置。创建 Namespace 的步骤在 vCenter 里进入 Supervisor Cluster 的“命名空间”视图点击“新建命名空间”。输入命名空间名称比如“dev-team-a”。选择权限模型。可以选择“专属”或“共享”。专属模式下只有被授权的用户才能访问这个命名空间共享模式下所有登录用户都能看到。生产环境建议用专属模式。配置资源配额。包括 CPU 限制、内存限制、存储限制、Pod 数量限制等。这些配额决定了这个命名空间里所有 TKC 能使用的资源总量。选择存储策略。这里选的存储策略会用于该命名空间下 TKC 的持久卷。配置网络。如果用的是 vSphere 网络需要指定一个网络段如果用的是 NSX-T需要指定一个 NSX-T 分段。资源配额的计算方法假设你要在一个命名空间里跑 3 个 TKC每个 TKC 有 1 个控制面节点2 vCPU、8GB和 3 个工作节点2 vCPU、8GB。那么总需求是CPU(13) × 2 vCPU × 3 24 vCPU内存(13) × 8GB × 3 96GB存储每个节点 16GB 磁盘总共 (13) × 16GB × 3 192GB再加上 Pod 持久卷的需求比如每个 TKC 需要 100GB 持久卷3 个就是 300GB。所以存储配额至少要给 500GB。注意资源配额是硬限制超过配额后创建 TKC 会失败。但配额也不能给太大否则一个命名空间可能把整个 Supervisor Cluster 的资源吃光。建议按照“实际需求 × 1.5”来设置。2.4 TKC 的版本管理与模板更新TKC 的版本管理是一个容易被忽视但很重要的环节。vSphere 7 里的 TKC 是通过 OVA 模板来部署的每个 Kubernetes 版本对应一个 OVA 模板。这些模板需要从官方渠道下载然后上传到 vCenter 的内容库中。模板更新的流程确认当前 Supervisor Cluster 支持的 TKC 版本范围。可以在 vCenter 的 Supervisor Cluster 配置页面查看。下载对应版本的 OVA 模板。通常是一个几百 MB 到 1 GB 的文件。将 OVA 导入到 vCenter 的内容库。导入过程可能需要 10 到 20 分钟取决于网络速度。在 Supervisor Cluster 的配置里将新模板标记为可用。创建新的 TKC 时就可以选择新版本了。版本升级的注意事项TKC 的版本升级不是原地升级而是创建一个新版本的 TKC然后把工作负载迁移过去。这是因为 TKC 的节点是虚拟机原地升级风险较大。升级前要确认新版本的 Kubernetes API 是否兼容现有工作负载。比如从 1.19 升级到 1.20有些废弃的 API 可能就不能用了。升级过程中旧 TKC 和新 TKC 会同时存在需要确保资源配额足够。我个人的经验是不要频繁升级 TKC 版本除非有明确的安全补丁或功能需求。每次升级都是一次完整的迁移涉及网络、存储、权限的重新配置工作量不小。3. 实操过程与核心环节实现3.1 创建一个 TKC 集群的完整流程前面把前置条件、Supervisor Cluster、Namespace 都准备好了现在可以真正创建一个 TKC 了。我以命令行方式为例因为图形界面虽然直观但命令行更适合自动化和批量操作。第一步获取 Supervisor Cluster 的 kubeconfig。在 vCenter 里进入 Supervisor Cluster 的“概览”页面点击“下载 kubeconfig”。这个 kubeconfig 是用于访问 Supervisor Cluster API 的不是 TKC 的。下载后保存到本地比如~/.kube/supervisor-config。第二步配置 kubectl 使用 Supervisor Cluster 的 kubeconfig。export KUBECONFIG~/.kube/supervisor-config kubectl get namespaces如果配置正确你应该能看到 Supervisor Cluster 上的所有命名空间包括你之前创建的那个。第三步在命名空间里创建 TKC 的 YAML 定义。TKC 是通过一个自定义资源Custom Resource来定义的这个资源的类型叫TanzuKubernetesCluster。下面是一个示例 YAMLapiVersion: run.tanzu.vmware.com/v1alpha1 kind: TanzuKubernetesCluster metadata: name: tkc-dev-01 namespace: dev-team-a spec: topology: controlPlane: count: 1 class: guaranteed-small storageClass: vsan-default workers: count: 3 class: guaranteed-small storageClass: vsan-default distribution: version: v1.19.3 settings: network: cni: name: antrea services: cidrBlocks: [10.96.0.0/12] pods: cidrBlocks: [192.168.0.0/16]这个 YAML 里几个关键字段解释一下topology.controlPlane.count控制面节点数量通常为 1 或 3。1 个用于测试3 个用于生产。topology.workers.count工作节点数量根据业务负载决定。class节点规格类guaranteed-small对应 2 vCPU、8GB 内存。还有guaranteed-medium、guaranteed-large等。storageClass存储类对应之前配置的存储策略。distribution.versionKubernetes 版本必须是 Supervisor Cluster 支持的版本。settings.network.cni.name容器网络接口vSphere 7 默认用 Antrea。services.cidrBlocks和pods.cidrBlocksService 和 Pod 的 IP 段不能与现有网络冲突。第四步应用 YAML 并观察创建过程。kubectl apply -f tkc-dev-01.yaml kubectl get tkc -n dev-team-a -w-w参数会持续观察资源状态。你会看到状态从Creating变成Running这个过程通常需要 10 到 20 分钟。第五步获取 TKC 的 kubeconfig。TKC 创建完成后可以通过 Supervisor Cluster 获取它的 kubeconfigkubectl get secret tkc-dev-01-kubeconfig -n dev-team-a -o jsonpath{.data.value} | base64 -d ~/.kube/tkc-dev-01-config export KUBECONFIG~/.kube/tkc-dev-01-config kubectl get nodes如果一切正常你应该能看到 1 个控制面节点和 3 个工作节点状态都是Ready。3.2 网络配置的细节与参数计算网络是 TKC 里最容易出问题的部分。我见过太多因为 CIDR 冲突导致 Pod 起不来的案例。这里把网络配置的几个关键点展开说一下。Pod CIDR 和 Service CIDR 的规划Pod CIDR 是分配给 Pod 的 IP 段默认是192.168.0.0/16。这个段不能与节点网络、Service CIDR 以及外部网络冲突。Service CIDR 是分配给 Service 的 IP 段默认是10.96.0.0/12。这个段也不能与节点网络和 Pod CIDR 冲突。如果你有多个 TKC每个 TKC 的 Pod CIDR 和 Service CIDR 必须不同否则跨集群通信会出问题。一个实际的规划示例假设你的节点网络是172.16.0.0/24那么可以这样规划集群名称Pod CIDRService CIDRtkc-dev-01192.168.0.0/1610.96.0.0/12tkc-dev-02192.169.0.0/1610.100.0.0/12tkc-prod-01192.170.0.0/1610.104.0.0/12这样每个集群的 IP 段都是独立的不会冲突。Antrea CNI 的工作模式Antrea 是 vSphere 7 默认的 CNI它支持两种模式encap和noEncap。encap模式下Pod 之间的流量会被封装在 VXLAN 里适合跨子网通信noEncap模式下Pod 流量直接走底层网络性能更好但要求所有节点在同一个子网里。实操心得如果节点都在同一个子网建议用noEncap模式性能提升明显。如果节点跨子网只能用encap。切换模式需要在 TKC 的 YAML 里修改settings.network.cni配置但修改后需要重建 TKC不能原地切换。3.3 存储配置与持久卷的使用TKC 的存储分为两部分节点存储和持久卷存储。节点存储是虚拟机磁盘在创建 TKC 时通过storageClass指定。持久卷存储是给 Pod 用的通过 Kubernetes 的 StorageClass 和 PVC 来管理。创建 StorageClass在 TKC 里StorageClass 是由 Supervisor Cluster 自动同步过来的。你可以在 TKC 里直接查看kubectl get storageclass应该能看到一个或多个 StorageClass名称与 Supervisor Cluster 上配置的存储策略对应。创建 PVC 并使用下面是一个创建 PVC 的示例apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadWriteOnce storageClassName: vsan-default resources: requests: storage: 10Gi应用后Kubernetes 会自动在 vSphere 上创建一个虚拟磁盘并挂载到 Pod 里。存储性能的考量如果底层是 vSAN建议为持久卷单独创建一个存储策略比如设置 RAID 级别为 RAID-5 或 RAID-6而不是默认的 RAID-1。这样可以在容量和性能之间取得平衡。如果底层是 NFS要注意 NFS 服务器的 IOPS 上限。多个 Pod 同时读写同一个 NFS 卷时性能可能成为瓶颈。持久卷的大小一旦创建就不能缩小只能扩大。所以规划时要留有余量。我踩过的一个坑是创建 PVC 时选了ReadWriteMany访问模式但底层存储策略不支持导致 PVC 一直处于Pending状态。排查后发现是 vSAN 默认策略只支持ReadWriteOnce。解决办法是改用 NFS 存储策略或者把访问模式改成ReadWriteOnce。4. 常见问题与排查技巧实录4.1 TKC 创建失败的常见原因与排查路径TKC 创建失败是新手最常遇到的问题。根据我的经验失败原因大致可以分为四类资源不足、网络配置错误、存储策略不匹配、版本不兼容。资源不足症状TKC 状态一直停留在Creating或者直接变成Failed。排查检查 Supervisor Cluster 的资源池剩余容量以及命名空间的资源配额。解决释放不必要的资源或者扩大资源池和配额。网络配置错误症状TKC 创建成功但节点状态是NotReady或者 Pod 无法启动。排查检查 Pod CIDR 和 Service CIDR 是否与现有网络冲突检查 DNS 配置是否正确检查节点是否能访问外部网络。解决修改 CIDR 配置重建 TKC修复 DNS 配置。存储策略不匹配症状TKC 创建过程中卡在存储卷挂载阶段。排查检查存储策略是否存在以及是否与底层存储兼容。解决创建正确的存储策略或者修改 TKC 的storageClass字段。版本不兼容症状TKC 创建时提示版本不支持。排查检查 Supervisor Cluster 支持的 TKC 版本范围。解决下载并上传对应版本的 OVA 模板。下面是一个常见问题速查表问题现象可能原因排查方法解决方案TKC 状态卡在 Creating资源不足检查资源池和配额释放资源或扩大配额节点 NotReady网络配置错误检查 CIDR 和 DNS修改配置并重建PVC 一直 Pending存储策略不匹配检查 StorageClass创建正确的存储策略创建时提示版本不支持版本不兼容检查支持的版本范围上传对应 OVA 模板控制面节点无法启动共享存储不可用检查存储连通性修复存储配置4.2 网络不通的排查思路与工具网络问题是最难排查的因为涉及多层ESXi 层、Supervisor Cluster 层、TKC 层、Pod 层。我通常按照从下往上的顺序排查。第一层检查 ESXi 主机的网络。确认 ESXi 主机的管理网络和工作负载网络是否正常物理网卡是否 UpVLAN 配置是否正确。第二层检查 Supervisor Cluster 的网络。登录到 Supervisor Cluster 的控制面节点用ping和traceroute检查到外部网络的连通性。第三层检查 TKC 节点的网络。登录到 TKC 的工作节点检查节点的 IP 地址、路由表、DNS 配置。第四层检查 Pod 的网络。在 TKC 里创建一个测试 Pod用kubectl exec进入 Pod检查 Pod 的 IP 地址和到其他 Pod 的连通性。常用的排查命令# 检查节点网络 kubectl get nodes -o wide kubectl describe node node-name # 检查 Pod 网络 kubectl get pods -o wide kubectl exec -it pod-name -- ping target-ip # 检查 DNS kubectl exec -it pod-name -- nslookup kubernetes.default # 检查 CNI 状态 kubectl get pods -n kube-system | grep antrea实操心得如果 Pod 之间不通但节点之间通大概率是 CNI 的问题。可以检查 Antrea 的日志看看有没有 VXLAN 隧道建立失败的报错。如果节点之间都不通那就是底层网络的问题需要检查 ESXi 的虚拟交换机配置。4.3 性能调优的几个关键参数TKC 跑起来之后性能调优是下一步。我总结几个影响最大的参数。控制面节点的规格控制面节点负责 API Server、etcd、Controller Manager、Scheduler。如果 API 请求量大控制面节点容易成为瓶颈。建议生产环境至少用guaranteed-medium4 vCPU、16GB 内存。工作节点的规格工作节点跑业务 Pod规格取决于业务负载。CPU 密集型应用需要更多 vCPU内存密集型应用需要更大内存。建议先用guaranteed-small试跑然后根据监控数据调整。etcd 的磁盘性能etcd 对磁盘延迟非常敏感。如果底层存储的写延迟超过 10msetcd 的性能会明显下降。建议为控制面节点使用高性能存储策略比如 vSAN 的 RAID-1 策略或全闪存 NFS。Antrea 的 encap 模式前面提到过encap模式有封装开销性能比noEncap低 10% 到 20%。如果节点在同一子网强烈建议用noEncap。Pod 的资源限制在 TKC 里建议为每个 Pod 设置resources.requests和resources.limits。这样 Kubernetes 可以更好地调度 Pod避免某个 Pod 吃光节点资源。下面是一个性能调优的对照表调优项默认值建议值影响控制面节点规格guaranteed-smallguaranteed-medium提升 API Server 性能工作节点规格guaranteed-small根据负载调整提升业务性能etcd 存储策略默认策略高性能策略降低 etcd 延迟Antrea 模式encapnoEncap提升网络性能Pod 资源限制无设置 requests/limits提升调度效率4.4 日常运维中的注意事项TKC 跑起来之后日常运维有几个点要特别注意。证书管理TKC 的证书默认有效期是 1 年。到期后需要更新否则 API Server 无法访问。更新证书需要登录到控制面节点手动执行命令。建议在证书到期前 1 个月就安排更新。备份与恢复TKC 的 etcd 数据需要定期备份。vSphere 7 本身不提供 TKC 的备份功能需要自己用工具比如 Velero来备份。备份内容包括 etcd 快照、PVC 数据、Kubernetes 资源定义。监控与告警建议在 TKC 里部署 Prometheus 和 Grafana监控节点资源、Pod 状态、API Server 延迟等指标。同时配置告警规则比如节点 NotReady、Pod 频繁重启、存储空间不足等。日志收集TKC 的节点日志和 Pod 日志需要集中收集。可以用 Fluent Bit 或 Filebeat 把日志发送到外部的日志平台。版本升级前面说过TKC 的版本升级是迁移式的。升级前要做好充分测试确保新版本兼容现有工作负载。升级过程中要保证资源配额足够避免新旧集群同时运行时资源不足。我个人在实际操作中的体会是TKC 这套东西把 Kubernetes 的部署门槛降低了很多但运维的复杂度并没有降低。你仍然需要理解 Kubernetes 的基本概念仍然需要处理网络、存储、证书、监控这些问题。vSphere 7 只是帮你把节点虚拟机管起来了里面的东西还是得自己管。所以如果你的团队没有 Kubernetes 运维经验建议先从小规模测试环境开始跑通了再上生产。