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。

Kubernetes Network Policy Generator

使用加权评分卡在12项标准上评估和比较隐私解决方案供应商。适用于选择隐私管理软件、比较数据保护方案等场景。

下载

资源编辑时自动补全和校验靠的是本地 schema

当你打开一个 deployment.yaml，插件能提示字段、标红非法字段（比如把 replicas 写成字符串），靠的是内置的 Kubernetes OpenAPI schema。但这个 schema 是静态的：

• 它不会动态拉取你集群实际启用的 CRD（自定义资源定义），所以对 ingressroute、knative 等扩展资源无提示
• 如果你集群用了旧版 API（如 extensions/v1beta1），而插件默认只加载 apps/v1 schema，就会误报“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 手动起一个长期进程，再配好本地开发服务连接那个端口，而不是依赖插件的一次性按钮。