上周五晚上清理测试用的Supervisor集群点了Delete之后vSphere Client的任务进度停在51%就再也不动了。刷新、取消任务、再点删除全都无效。Supervisor移除卡住这种事处理过几次的人都知道界面上的提示永远只有一句Removing Supervisor Cluster真正卡在哪、接下来会怎么走全部藏在vCenter日志里。这篇就把我这次从任务初步判断、日志取证、关键词定位到最终清理的完整过程拉出来讲一遍主要针对vSphere 7/8里Tanzu工作负载管理的Supervisor集群删除卡住问题适合第一次搭完集群但还没遇到过清理故障的运维也适合那些已经删到一半不敢乱动的同学。1. 问题现场删除Supervisor集群卡住时的典型表现与前置判断1.1 故障现象先说我这次的具体现象。集群是vSphere 8.0管理域里开着一个Supervisor Cluster上面挂着四个Tanzu命名空间。因为测试要回收我在Workload Management界面点了删除。刚开始一切正常任务ID显示SUPERVISOR_MANAGEMENT开头进度从0走到51%然后停住了。等了大概40分钟进度纹丝不动连时间戳都不更新。打开vSphere Client的任务详情发现对象列的Supervisor Cluster旁标着一个警告但没有给出具体的错误信息。接着再看虚拟机清单那台Supervisor Control Plane VM也停留在“正在删除”状态电源仍然开着没有关机动作。这时基本可以断定不是“慢”是“卡”。另一种更常见的表现是命名空间残留。如果你删除Supervisor集群之前还有vSphere Namespace没有删干净任务也会卡住只不过卡的位置会更早可能在19%或者34%之类的地方。日志里能看到WCP在反复尝试清理命名空间却一直等不到Kubernetes层面的确认。这个现象和SCP VM卡住的不同之处在于虚拟机的状态是正常的但命名空间一直处于Terminating。这两种情况在日志里的关键词完全不同排查路径也不一样后面会展开。1.2 先别急着查日志5分钟内完成的任务和事件初筛拿到问题先不要一头扎进日志我用5分钟把vCenter的Task和Event筛一遍能省很多事。因为日志文件非常大没有时间锚点的话grep会淹没在天量的INFO信息里。第一步打开vSphere Client的Recent Tasks找到删除任务点击查看详细信息记录任务ID、对象类型、启动时间、当前状态。第二步切换到同一对象的Events标签搜索关键字Supervisor、Delete、Timeout、Error。第三步判断卡住的时间点任务详情里Status列如果一直显示Running且Last updated时间不再变化说明WCP已经停止推进这个任务。第四步记录下这个不再更新的时间点它就是后面日志排查的终点。这5分钟的价值在于确定排查窗口从任务启动到Last updated不再变化的时间段就是要重点翻日志的时间段。如果任务还在一秒一秒地变动哪怕进度条显示10%也说明底层逻辑还在做事只是慢不算卡死。很多朋友看到进度条一段时间不动就慌了其实先看一眼Last updated是最快的判断方式。1.3 登录异常的干扰项这里顺带说一个容易被绕进去的坑。有几次朋友把问题描述成“Supervisor移除卡住”结果远程一看vSphere Client根本登不进去一直提示“进行身份验证过程中出错返回登录屏幕”。这其实是vCenter客户端证书过期导致的登录异常和Supervisor删除任务不是一回事但很容易被误判成删除失败的连带故障。应急思路是这样直接用vCenter主机名或管理IP打开vSphere Client的UI地址如果浏览器提示证书不受信任选择手动导入vCenter CA链或者用IP方式访问后继续也可以打开5480端口的VAMI界面查看证书有效期和证书类型确认是不是证书过期。如果确实过期需要按VMware知识库的流程重新签署或替换vCenter证书登录恢复正常后再重新评估删除任务。另外像vSphere链接克隆、证书过期应急登录这些搜索过来的词很多都和当前Supervisor删除卡住的底因无关先分清楚症状别让热搜词带偏排查节奏。2. 日志从哪来wcp、vpxd、sps的职责划分与取证路径2.1 wcpsvc.log是主战场但别只看它Supervisor集群的整个生命周期由Workload Management服务习惯叫WCP负责所以删除流程的主日志非常明确就是vCenter上的这个文件/var/log/vmware/wcp/wcpsvc.log但实际排查时不能只看它。一个删除操作会横跨多个服务我用下面这张表把职责理清楚日志文件服务/模块在删除Supervisor中负责什么/var/log/vmware/wcp/wcpsvc.logWCP服务编排删除流程解绑vSphere Namespace、删除命名空间、下电SCP VM、清理集群资源/var/log/vmware/vpxd/vpxd.logvpxd服务承接用户API请求维护任务状态实际调用vSphere对象删除/var/log/vmware/sps/sps.logSPS服务处理存储策略相关检查与清理SCP VM磁盘删除时一定会参与/var/log/vmware/hvc/ 下的日志hvc服务将WCP的Kubernetes操作转发到SCP API命名空间删除会经过它比如vpxd.log记录的是“用户任务如何执行”wcpsvc.log记录的是“Supervisor编排逻辑在做什么”。如果WCP一直等不到某个底层vSphere操作完成那往往是sps或者vpxd那边出了问题。我在实际排查中看过太多人只盯wcpsvc.log结果发现WCP一直在等vpxd的一个删除返回而vpxd的错误只在它自己的日志里才有。2.2 用支持包一次拿全所有日志推荐大家第一步先导出支持包而不是直接SSH上去敲命令。导出支持包有两个好处一是所有日志都会有统一的时间戳和打包格式方便后续传给支持团队二是不用反复登录vCenter。在vSphere Client的System菜单下找到Support Bundle勾选WCP、vpxd、sps、hvc这几个组件后导出即可。如果没有特殊的隐私顾虑保留默认配置就行。注意支持包可能很大动辄几百MB导出时间取决于vCenter的规模。但如果后续要联系官方支持这个包几乎必须给与其到时候再导不如一开始就用它做排查。我一般会把支持包提前拉到本地然后用压缩工具直接在里面解压出要看的日志比SSH来回翻舒服不少。2.3 SSH到vCenter手动取日志如果支持包太大或者你只关心某一段日志SSH上去更轻量。前提是已经启用vCenter的Shell访问在VAMI也就是5480端口的Access设置里打开然后登录ssh rootvcenter-fqdn cd /var/log/vmware/wcp ls -lh wcpsvc.log*wcpsvc.log前面可能带有日期轮转文件比如wcpsvc.log.1、wcpsvc.log.2025-02-13按时间选择即可。首次排查时先用tail -n 500 wcpsvc.log看最近输出再用grep去翻删除时间段。这个日志文件名的格式在vSphere 7和8里基本一致权限要求是root普通用户看不了。3. 日志关键词定位从任务卡住到根因的逐层溯源3.1 确立时间线删除操作的锚点排查日志的第一步永远是找准时间线而不是拿错误关键字满天飞。删除操作启动之前WCP可能还有自己的后台健康检查、证书刷新任务时间窗不对看到的东西都是噪音。我通常这样切时间grep -n 2025-02-14T13: /var/log/vmware/wcp/wcpsvc.log | grep -i supervisor | head -50注意vCenter日志时间默认是UTC如果你的操作发生在北京时间晚上9点要倒8小时。你可以打开vCenter的时间设置确认时区或者直接看任务详情里的UTC时间。先把时间锚点确定下来接下来所有的grep都基于这个时间范围这样能大幅减少无用信息。3.2 抓DeleteSupervisor和错误关键字WCP日志对删除操作通常会有明确的类名和方法名比如SupervisorClusterLifecycle、DeleteSupervisorCluster、deleteNamespace等。我建议分两轮做关键词过滤。第一轮确认删除流程是否启动grep -in delete.*supervisor\|supervisor.*delete /var/log/vmware/wcp/wcpsvc.log | grep 2025-02-14第二轮把错误级别的行拉出来grep -in error\|warn\|timeout\|fail /var/log/vmware/wcp/wcpsvc.log | grep delete\|supervisor实际日志的典型片段是这样的排版有简化[2025-02-14 13:02:15.031 INFO ] SupervisorsClusterLifecycle-143: DeleteSupervisorCluster invoked, id... [2025-02-14 13:02:17.892 INFO ] NamespaceLifecycle-...: Deleting namespace tanzu-dev [2025-02-14 13:05:40.112 ERROR] NamespaceLifecycle-...: Timed out waiting for namespace tanzu-dev deletion看到ERROR之后继续往后面翻几十行通常会有重试或者资源ID信息。比如[2025-02-14 13:05:40.113 WARN ] Retrying namespace deletion, attempt 6/10这就说明卡点非常明确某个命名空间的删除没有完成。如果日志里反复出现同一个命名空间的UUID基本可以直接锁死对象。3.3 真实卡点Namespace Terminating我这次的实际卡点日志里给的信号就是上面这种超时等待。再看Kubernetes侧用kubectl get ns去查会发现那个namespace一直处于Terminating状态。再describe会看到Finalizer列表里有某些自定义资源控制器的清理项没走完。原因是命名空间里曾经部署过带有自定义Finalizer的Tanzu服务底层又已经失联导致Kubernetes永远收不到资源删除确认。这一步不需要动SCP VM只需要把命名空间剩下的资源清掉WCP的重试就能继续。如果你有管理员kubeconfig通常通过kubectl vsphere login或者从SCP VM提取到就能直接看到命名空间内部的真实状态。日志里描述的“Timed out waiting for namespace deletion”和Kubernetes里的Terminating是同一件事的两个侧面。3.4 另一个卡点SCP VM残留还有一类卡点发生在后半段等SCP VM下电和删除。日志特征不太一样常见的是这样[2025-02-14 14:12:03.205 WARN ] Timed out waiting for power off of VirtualMachine vm-504 [2025-02-14 14:12:03.206 INFO ] Retrying power-off operation, attempt 3/5这种情况通常是SCP VM被锁、ESXi上的虚拟机卡在关机流程或者心跳丢失。配合vCenter任务能看到vm-504这个对象上的“关闭电源”任务没有返回。这时候才需要去检查SCP VM本身而不是在命名空间上绕圈。3.5 理解超时与重试最后说一下日志里的timeout和retry这两个词出现不一定代表已经失败。WCP的删除流程设计了重试机制很多临时抖动会被重试掩盖。我一般看三个东西判断严重程度第一是Error还是Warn第二是重试次数是否突破上限第三是同一个错误是否跨越了多个日志轮转文件。只有到FATAL或者Task failed after N attempts这种程度任务状态才会真正变成failed否则很可能一直在内部循环。理解这一点对后续处置很重要不要一看到WARN就去干预否则可能打断WCP自己的重试节奏。4. 几种典型卡住原因与处置手法4.1 命名空间Terminating手动清理命名空间Terminating是Supervisor删除卡住的最常见原因也是最需要在动手前想清楚的场景。在动Kubernetes之前先通过日志确认WCP还在等这个namespace删除再执行清理。下面的操作有风险务必记录原始命名空间内容和YAML建议先在测试环境验证。第一步确认命名空间内残留的API资源kubectl get all --all-namespaces | grep namespace kubectl get crd第二步如果Finalizer指向某个CRD实例先删除对应CRD资源kubectl delete crd-kind -n namespace --all第三步如果命名空间仍然Terminating再强制清Finalizer。先备份原始JSON再编辑后提交到finalize接口kubectl get ns namespace -o json /tmp/ns-backup.json jq del(.metadata.finalizers) /tmp/ns-backup.json /tmp/ns-edited.json kubectl replace --raw /api/v1/namespaces/namespace/finalize -f /tmp/ns-edited.json执行完第三步命名空间会在几秒内消失。然后回到vCenter任务发现WCP的重试会自动推进。整个过程不用重启任何服务这也是为什么这类问题排在处置优先级第一位。注意强制清理Finalizer相当于越过Kubernetes的正常删除协议如果是生产环境必须先确认没有业务还在用这个命名空间。4.2 SCP VM状态异常如果日志显示卡在SCP VM的关机电操作先查vCenter内该虚拟机当前状态。正常情况下应立即变成“已关闭”如果没有说明ESXi主机上有异常任务或者虚拟机锁。此时可以在vCenter里对该SCP VM尝试一次规范的“关闭电源”如果仍然超时再考虑强制关机并等待。有一点必须明确这里说的是“关机”不是“从清单中移除”更不是“从磁盘删除”。SCP VM最终删除应该由WCP流程自己完成。如果你手动把SCP VM从清单删掉vCenter库存和WCP元数据就会不一致后续重试要么一直报找不到对象要么留下一个半残的集群记录。强制关机后WCP通常会在下一次重试里接管继续执行原删除逻辑。我见过有人在卡住时把SCP VM直接删掉最后只能靠快照恢复或官方介入救回来非常被动。4.3 WCP服务重启的适用场景如果wcpsvc日志在某个时间点之后戛然而止没有输出任何日志而vpxd任务也一直挂着可能是WCP服务本身无响应。这时可以考虑重启WCP服务。在vCenter命令行执行service-control --stop vmware-wcp service-control --start vmware-wcp重启的代价是当前所有WCP相关任务都会被中断并重新排队SCP集群的健康检查也会短暂中断。所以重启前一定要先确保日志已导出否则重启可能把线索一起带没。执行后回到vSphere Client观察任务是否再次进入running如果还是卡在同一个位置继续看新日志定位。我这里要再强调一次重启不是第一选择只有明确了WCP进程层面出问题才用。5. 复盘与安全提示任你折腾也要守住的底线5.1 哪些操作绝对不能做处理这种问题最危险的反而不是找不出原因而是病急乱投医。根据我的经验和踩过的坑下面这三件事我坚持不做。第一绝对不直接从vCenter清单里删除SCP VM也不要手动删除vSphere Namespace对应的文件夹和对象。WCP内部的元数据不会因为你在界面上删了就同步更新反而会变成永远删不掉的状态。第二绝对不对vCenter数据库做手工UPDATE。vpxd和WCP的元数据多表关联乱改一条记录可能引发大面积不一致最后只能重新部署vCenter来救。第三不要连续多次重复点删除。卡住的任务在后台可能还在重试你再提交一个Delete只会让WCP的编排线程打架普遍结果是任务列表里多两个相同操作现场更乱。5.2 我的排查清单模板把这次的经验整理成一个固定动作表我每次遇到Supervisor删除卡住都会按这个顺序走一遍。顺序内容产出1记录vCenter版本、构建号、WCP版本判断问题是否已知2记录删除任务ID、开始时间、Last updated时间确定日志时间窗3导出支持包或SSH取关键日志日志证据4按时间线grep wcpsvc.log定位第一个ERROR初步卡点5对照vpxd/sps/hvc日志看底层任务状态区分源头与现象6如果是命名空间检查Kubernetes侧确认Finalizer或残留资源7如果是SCP VM检查虚拟机与ESXi任务确认电源操作状态8处置后回到vCenter观察任务是否恢复验证修复有了这个模板即使中途换人接手也能快速接上状态不会重复翻一遍日志。5.3 日志正常却仍卡住最后一种情况最磨人日志里没有ERROR所有服务都在正常输出任务进度就是不走。这时先检查vCenter自身的磁盘空间和健康状态尤其是/var/log分区写满以后日志和任务都会出现诡异的悬挂这是低成本高回报的检查。如果磁盘正常再确认vCenter和ESXi的时间是否同步时钟偏移会让WCP的超时判断错乱。这些都排除了就把导出的支持包、操作时间线、已经做过的处置发给官方支持附上一步到位的证据比让对方来回要日志要快得多。VSphere的Supervisor移除故障处理得多了我最大的体会是不要和界面较劲日志才是唯一诚实的那一方。最后再分享一个小习惯——每次动手删Supervisor之前我都会先把所有命名空间里的工作负载过一遍确保没有遗留的Finalizer型服务并把要删除的集群任务ID抄在记事本上。这个习惯帮我省掉了很多不必要的夜间折腾。下次你遇到进度条卡住别急着关页面试试先打开wcpsvc.log。