kubectl插件需以“kubectl-”命名、放入PATH，用Cobra解析命令、client-go交互集群；必须导入auth插件支持exec凭据，通过clientcmd.NewNonInteractiveDeferredLoadingClientConfig处理多上下文，CRD/Metrics等非标API需动态客户端或手动注册Scheme，交叉编译注意平台兼容性及退出码规范。
用 Cobra + client-go 写一个可执行的 kubectl 插件
Go 写的 kubectl 插件本质就是一个命名形如 kubectl-xxx 的可执行文件，放在 $PATH 里，kubectl 运行时会自动发现并调用它。核心就两块：命令行解析用 Cobra，K8s API 交互用 client-go。
常见错误是直接用 go run 测试，但 kubectl 只认二进制；或者没导入 auth 插件，导致 kubeconfig 里带 exec 类型凭据（比如 aws-iam-authenticator）时 panic。
- 必须在 main 包里加
import _ "k8s.io/client-go/plugin/pkg/client/auth"，否则无法处理云厂商或 OIDC 类凭据 - 命令名必须以
kubectl-开头，比如kubectl-nodestatus，编译后记得chmod +x - 读取 kubeconfig 推荐用
clientcmd.RESTConfigFromKubeConfig或BuildConfigFromFlags("", "")，后者会自动找$KUBECONFIG或~/.kube/config - 别在插件里硬编码
https://localhost:8443——要复用用户当前上下文的 server 地址和证书
如何让插件支持多集群上下文切换
用户可能同时连着 dev/staging/prod 多个集群，插件默认只用当前 kubectl config current-context 对应的配置。不显式处理的话，所有操作都跑在“当前上下文”，容易误操作。
关键不是自己解析 ~/.kube/config，而是复用 client-go 的 rest.InClusterConfig() 和 clientcmd.NewDefaultClientConfigLoadingRules() 组合逻辑。
立即学习“go语言免费学习笔记（深入）”；
- 用
clientcmd.NewNonInteractiveDeferredLoadingClientConfig加载规则，再调RawConfig()拿到所有 context 列表 - 通过
--contextflag 显式传入上下文名，比依赖当前环境更可靠，尤其在 CI 脚本里 - 如果插件需要跨集群同步资源（比如把某 namespace 下的 Secret 复制到另一集群），每个集群都要单独建
*rest.Config，不能共用 clientset - 注意
client-go的rest.Config不是线程安全的，多 goroutine 并发调用不同集群时，别共享同一个 config 实例
插件中调用非标准 API（如 CRD、Metrics Server）的坑
标准资源（Pod、Deployment）走 clientset.CoreV1() 没问题，但一碰到自定义资源或 Metrics API，就会报 the server could not find the requested resource 或 no matches for kind。
根本原因是 client-go 默认不注册这些 group/version/kind，得手动加 Scheme 或用动态客户端。
- 对已知 CRD：用
scheme := runtime.NewScheme()+mycrd.AddToScheme(scheme)（需提前go get对应 CRD 的 Go 客户端库） - 对未知或动态 CRD：改用
dynamic.Client，通过dynamic.NewForConfig(cfg)获取，再用Resource(schema.GroupVersionResource).Namespace(ns).List() - Metrics API（如
/apis/metrics.k8s.io/v1beta1）必须单独构造metricsclientset，不能塞进 corev1 clientset —— 它们是独立的 API 组 - 调用前先用
discovery.NewDiscoveryClientForConfig检查目标 API 是否可用，避免静默失败
交叉编译与发布时权限和路径问题
Go 编译出来的插件二进制，在 macOS/Linux 上能跑，Windows 用户却提示 command not found，或者 Linux 上执行时报 permission denied——这往往不是代码问题，而是分发环节失控。
尤其要注意 kubectl 在不同系统上调用插件的方式差异：Linux/macOS 用 exec.LookPath 查找，Windows 会额外尝试加 .exe 后缀。
- 发布前必须用
GOOS=linux GOARCH=amd64 go build -o kubectl-myplugin等方式交叉编译，别只 build 本地平台 - 二进制文件名必须全小写、无空格、无下划线（
kubectl-myplugin✅，kubectl_myplugin❌），否则 Windows 下找不到 - 不要把插件放到
/usr/local/bin然后用sudo执行——kubectl是普通用户进程，插件也以同一用户身份运行，权限过高反而触发 SELinux/AppArmor 拦截 - 如果插件内部要执行
kubectl apply或调用其他 CLI 工具，务必用绝对路径（/usr/bin/kubectl）或先exec.LookPath("kubectl")查找，避免 PATH 不一致
最易被忽略的是插件退出码：只要不是 0，kubectl 就认为执行失败并打印 stderr。但很多 Go 新手用 log.Fatal，它会直接 os.Exit(1)，没机会清理资源或打印结构化错误。应该统一用 os.Exit(0/1) 控制，并把错误详情写到 stdout 或 stderr，保持和原生 kubectl 行为一致。
