VSCode Kubernetes插件仅是可视化辅助工具，依赖本地kubectl和kubeconfig文件，不自带运行时能力；需验证右下角context显示及Pod日志是否正常调用kubectl。
Kubernetes 插件在 VSCode 里不能直接操作集群，它只是个可视化辅助工具——真正执行 kubectl 命令的还是你本地已配置好的 CLI 环境。
插件依赖 kubectl 和 kubeconfig 文件
VSCode 的 Kubernetes 插件（Microsoft 官方维护）本身不带任何 Kubernetes 运行时能力。它启动时会主动查找：
- 系统 PATH 中是否存在可执行的
kubectl（版本需 ≥1.18） - 环境变量
KUBECONFIG指向的文件，或默认路径~/.kube/config是否存在且格式合法
如果任一缺失，插件侧边栏只会显示 “No clusters available”，点开也看不到任何资源列表。这不是插件坏了，是它根本没拿到上下文。
如何验证插件是否真正连上集群
别只看侧边栏有没有节点展开图标，要确认两点：
- 右下角状态栏出现当前 context 名称（如
minikube或gke_xxx），鼠标悬停能看到 cluster server 地址 - 在资源树中右键某个 Pod → 选择
View Logs，能正常弹出日志窗口并实时刷新；若报错command 'kubectl.logs' not found，说明插件没调通kubectl
常见干扰项：kubectl 装在 WSL 里但 VSCode 运行在 Windows 主系统 → 插件找不到命令。此时要么把 WSL 的 kubectl 软链进 Windows PATH，要么改用 Remote-WSL 扩展在 WSL 环境中打开 VSCode。
资源编辑时自动补全和校验靠的是本地 schema
当你打开一个 deployment.yaml，插件能提示字段、标红非法字段（比如把 replicas 写成字符串），靠的是内置的 Kubernetes OpenAPI schema。但这个 schema 是静态的：
- 它不会动态拉取你集群实际启用的 CRD（自定义资源定义），所以对
ingressroute、knative等扩展资源无提示 - 如果你集群用了旧版 API（如
extensions/v1beta1），而插件默认只加载apps/v1schema，就会误报“unknown field” - 可通过设置
"kubernetes.schemaLocation"指向自定义 OpenAPI spec JSON 文件来覆盖
调试容器时别指望插件启动 port-forward
点击 Pod 上的 Port Forward 按钮，插件只是后台执行一条 kubectl port-forward 命令，并把 stdout/stderr 输出到 VSCode 的 OUTPUT 面板。这意味着：
- 端口冲突时不会自动换端口，而是直接失败并报错
error: unable to listen on port - VSCode 关闭后，该
kubectl进程不会自动终止，得手动pkill -f "port-forward"清理 - 转发会话不支持复用 —— 每次点击都启新进程，容易堆积多个重复转发
真正稳定的调试流，建议用 kubectl port-forward 手动起一个长期进程，再配好本地开发服务连接那个端口，而不是依赖插件的一次性按钮。
