kubectl exec 配置崩溃

在 kubectl v1.37.1 中执行 kubectl config set users.foo.exec x，可能直接报 panic: unrecognized type: <nil>，退出码为 2。即使指定的 kubeconfig 尚不存在，也能触发这条客户端路径；先升级 API Server 或修改集群权限没有针对性。

exec 是一组凭据插件配置，不是可以整体设成字符串 x 的字段。该版本的通用 config set 在递归处理这种指针字段时没有返回正常错误，而是落到了 panic。应改用专门的 config set-credentials 配置插件。

先选定配置文件

确认报错来自 users.<名称>.exec 或类似结构字段，并核对实际执行的 kubectl 客户端版本。修改前保存受保护的 kubeconfig 副本，随后显式指定同一个 --kubeconfig 文件，避免多文件合并让目标不清楚。

备份和诊断记录中可能含凭据，不把完整原始配置复制到共享日志。现有 cluster、context 与 user 的关联需要保留，不能为消除 panic 先删除整组用户配置。

使用专用命令

下面示例仅适用于已经安装、可信、支持 client.authentication.k8s.io/v1 且不需要标准输入的凭据插件。用户名称和命令路径要换成实际值：

kubectl --kubeconfig ./kubeconfig config set-credentials foo \
  --exec-command=/path/to/credential-plugin \
  --exec-api-version=client.authentication.k8s.io/v1 \
  --exec-interactive-mode=Never

插件返回的 ExecCredential 版本必须与配置一致。需要交互的插件应按其要求采用 IfAvailable 或 Always，不能为了让命令通过就统一填 Never。v1 配置要求明确的 interactiveMode。

还有一个容易漏掉的行为：在这个版本中，提供 --exec-command 会清空原来的 exec 参数。若插件需要参数，必须在同次修改中用重复的 --exec-arg 完整补回，即使命令路径没有改变。也要核对原有环境变量、集群信息需求和插件自己的认证参数，不能只看到命令成功就认为配置完整。

分开验配置和认证

专用命令修改的是本地文件。配置写入成功后，下一次使用该用户发起请求，才会运行凭据插件并尝试认证。用获准的只读请求核对目标 context、身份及实际返回结果；随后出现插件不存在、API 版本不匹配或认证失败，应沿各自原因处理，不继续增加 RBAC 权限。

截至核对的 v1.37.1，通用设置路径仍存在上述 panic。针对错误提示的修复也不会让 exec x 变成合法插件配置。