1. 问题背景与现象定位
上周在客户现场遇到一个典型的基础设施运维问题：vSphere Supervisor集群在移除节点时卡在"Removing"状态超过2小时。这种场景在大型虚拟化环境中并不罕见，但需要系统化的排查方法。当控制平面组件无法正常完成生命周期管理时，我们需要从底层日志入手进行诊断。
vSphere Supervisor作为集成Kubernetes的管理平面，其节点移除过程涉及多个子系统协同工作：
- 底层ESXi主机的资源释放
- Kubernetes控制平面的成员注销
- 存储卷的解除挂载
- 网络策略的清理
2. 关键日志收集与分析
2.1 日志获取路径
首先通过SSH连接到vCenter Server Appliance，关键日志位于：
code复制/var/log/vmware/vpxd/vpxd.log
/var/log/vmware/vpxd/vpxd-svcs.log
/var/log/vmware/vsan-health/vsan-health.log
对于Supervisor集群本身的日志，需要通过kubectl访问管理平面：
bash复制kubectl -n vmware-system-supervisor logs deploy/supervisor-operator
kubectl -n vmware-system-tkg logs deploy/tkg-controller-manager
2.2 日志过滤技巧
使用grep进行关键事件过滤：
bash复制# 查找节点移除相关操作
grep -i "remove.*node" vpxd.log
# 检查任务超时记录
grep -i "timeout" vpxd-svcs.log
# 检查存储相关错误
grep -E "storage|volume" vsan-health.log
3. 典型故障场景解析
3.1 存储卷卸载失败
在本次案例中，vsan-health.log显示如下关键错误：
code复制2023-08-20T14:22:01.123Z ERROR vsan.volume - Failed to detach volume pvc-xxxx: device busy
这表明Kubernetes PVC仍被某些进程占用。解决方法：
- 检查残留Pod：
bash复制
kubectl get pods -A -o wide | grep <故障节点> - 强制删除残留Pod：
bash复制
kubectl delete pod <pod-name> -n <namespace> --grace-period=0 --force
3.2 网络策略残留
当Calico网络策略未正确清理时，会在tkg-controller-manager日志中看到：
code复制Failed to cleanup network policy for node vm-12345: connection refused
处理步骤：
- 手动删除节点关联策略：
bash复制
calicoctl delete node <node-name> - 重启网络组件：
bash复制
kubectl -n kube-system rollout restart deploy/calico-kube-controllers
4. 高级排查工具
4.1 vSphere诊断包收集
通过vCenter UI生成诊断包：
- 访问"Menu > Administration > Support > Generate Support Bundle"
- 勾选"vCenter Server"和"ESXi Hosts"
- 下载后检查
supervisor/目录下的日志
4.2 Kubernetes事件审计
查看集群级别事件：
bash复制kubectl get events -A --sort-by='.lastTimestamp'
重点关注以下事件类型：
- FailedMount
- NodeNotReady
- NetworkPluginNotReady
5. 手动恢复流程
当自动清理失败时，需要手动介入：
5.1 数据库状态修正
- 连接到vCenter Postgres数据库：
bash复制
/opt/vmware/vpostgres/current/bin/psql -U postgres -d VCDB - 查询卡住的节点记录：
sql复制SELECT id, name, status FROM vpx_host WHERE status = 'removing'; - 手动更新状态：
sql复制UPDATE vpx_host SET status = 'disconnected' WHERE id = 'host-123';
5.2 资源清理脚本
创建自定义清理脚本force_remove.sh：
bash复制#!/bin/bash
NODE_NAME=$1
# 移除节点标签
kubectl label nodes $NODE_NAME vmware.io/role-
# 清理CSI驱动注册
kubectl delete csinode $NODE_NAME
# 强制删除节点对象
kubectl delete node $NODE_NAME
6. 预防措施
为避免类似问题再次发生，建议：
-
预检查清单：
- 确认节点无运行中的Pod
- 验证存储卷已卸载
- 检查网络策略已清理
-
配置调整：
yaml复制# supervisor-operator配置 spec: nodeRemovalTimeout: 3600 # 默认超时延长至1小时 forceRemoval: true # 启用强制移除 -
监控增强：
- 对
node_removal_duration_seconds指标设置告警 - 定期检查
kube_node_status_condition中的NetworkUnavailable状态
- 对
7. 深度问题分析
通过本次排查，发现根本原因是CSI驱动与存储阵列的API交互存在竞争条件。当同时卸载多个卷时，阵列端可能返回错误的"busy"状态。VMware已确认该问题将在vSphere 8.0 Update 2中修复，临时解决方案是在移除节点前手动卸载所有PVC：
bash复制# 批量卸载节点上的卷
for pvc in $(kubectl get pvc -A -o jsonpath='{range .items[?(@.spec.nodeName=="NODE_NAME")]}{.metadata.name}{"\n"}{end}'); do
kubectl delete pvc $pvc --wait=false
done
这种类型的故障排查需要掌握跨领域的知识：
- vSphere底层架构
- Kubernetes节点生命周期管理
- 存储系统交互协议
- 网络插件工作原理
建议运维团队建立完整的排查流程图，并定期更新已知问题库。每次异常处理都是一次系统健壮性提升的机会，通过分析根本原因可以优化运维流程和监控体系。