企业官网建设流程全解析

上周五晚上清理测试用的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

但实际排查时不能只看它。一个删除操作会横跨多个服务，我用下面这张表把职责理清楚：

比如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 root@<vcenter-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删除卡住都会按这个顺序走一遍。

有了这个模板，即使中途换人接手，也能快速接上状态，不会重复翻一遍日志。

5.3 日志正常却仍卡住

最后一种情况最磨人：日志里没有ERROR，所有服务都在正常输出，任务进度就是不走。这时先检查vCenter自身的磁盘空间和健康状态，尤其是/var/log分区写满以后，日志和任务都会出现诡异的悬挂，这是低成本高回报的检查。如果磁盘正常，再确认vCenter和ESXi的时间是否同步，时钟偏移会让WCP的超时判断错乱。这些都排除了，就把导出的支持包、操作时间线、已经做过的处置发给官方支持，附上一步到位的证据比让对方来回要日志要快得多。

VSphere的Supervisor移除故障处理得多了，我最大的体会是：不要和界面较劲，日志才是唯一诚实的那一方。最后再分享一个小习惯——每次动手删Supervisor之前，我都会先把所有命名空间里的工作负载过一遍，确保没有遗留的Finalizer型服务，并把要删除的集群任务ID抄在记事本上。这个习惯帮我省掉了很多不必要的夜间折腾。下次你遇到进度条卡住，别急着关页面试试，先打开wcpsvc.log。