必须使用 client-go 的 RESTClient + SPDYExecutor 才能实现可控、可调试、适用于服务端的交互式 Pod shell；os/exec 调用 kubectl exec 因依赖 TTY、无法流式传输、权限环境耦合等问题，不适用于嵌入式或生产场景。
直接用 client-go 的 RESTClient + SPDYExecutor 才能真正实现交互式 Pod shell；单纯调 exec.Command("kubectl", "exec", ...) 是黑盒调用，不可控、难调试、不适用于嵌入式或服务端场景。
为什么不能只用 os/exec 调 kubectl exec
很多 Go 项目一开始图省事，用 os/exec.Command("kubectl", "exec", "-it", "pod-name", "--", "/bin/sh") 启动子进程——这看似能用，但实际埋了几个硬伤：
-
-it参数在非 TTY 环境（比如 HTTP 服务、后台任务）下会直接失败，报错unable to upgrade connection: unable to create channel - 无法捕获实时 stdout/stderr 流，只能等命令退出后读
Output()，对长时交互（如top、tail -f）完全失效 - 权限和 kubeconfig 依赖本地环境，部署到容器或无 kubectl 的节点就崩
- 无法感知连接中断、超时、容器重启等状态变化
client-go 中执行 Pod 命令的最小可行路径
核心是构造 rest.Config → 获取 corev1clientset → 创建 PodExecOptions → 用 remotecommand.NewSPDYExecutor 发起流式请求。关键点如下：
- 必须显式设置
Tty: true和Stdin: true，否则/bin/sh启动后立即退出 - 命令参数要拆成字符串切片：
[]string{"/bin/sh", "-c", "ls -l /"}，不要拼"sh -c 'ls -l /'" - 流式传输需同时接管
stdin、stdout、stderr三个io.ReadWriteCloser，顺序不能错（stdin必须第一个） - 务必调用
executor.Stream(remotecommand.StreamOptions{...})，不是.Exec()（后者只返回 error，无流）
示例片段：
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
立即学习“go语言免费学习笔记（深入）”；
config, _ := rest.InClusterConfig() // 或 kubeconfig.BuildConfigFromFlags
clientset := corev1clientset.NewForConfigOrDie(config)
req := clientset.RESTClient().Post().
Resource("pods").
Name("my-pod").
Namespace("default").
SubResource("exec").
Param("container", "main").
Param("command", "/bin/sh").
Param("command", "-c").
Param("command", "echo hello && ls /").
Param("stdin", "true").
Param("stdout", "true").
Param("stderr", "true").
Param("tty", "true")
exec, _ := remotecommand.NewSPDYExecutor(config, "POST", req.URL())
exec.Stream(remotecommand.StreamOptions{
Stdin: os.Stdin,
Stdout: os.Stdout,
Stderr: os.Stderr,
Tty: true,
})
临时容器（ephemeral container）场景下怎么 exec
当目标 Pod 是 distroless 镜像、没有 /bin/sh，或原容器已崩溃时，kubectl exec 会直接报 container not found 或 no such file or directory。此时必须先注入临时容器：
- 调用
corev1clientset.EphemeralContainers(pod.Namespace).Patch(...)添加一个带调试工具的容器（如nicolaka/netshoot:latest） - 临时容器名默认为
debug，后续 exec 必须指定Param("container", "debug") - 注意：Kubernetes v1.25+ 默认禁用
EphemeralContainers特性门控，需确认集群启用：kubectl api-versions | grep ephemeral - 临时容器不支持
initContainer语义，也不参与 readiness/liveness 探针，仅用于调试
容易被忽略的边界情况
真实生产环境里，以下几点经常导致 exec 失败但错误信息极不明确：
- Pod 处于
Pending或ContainerCreating状态时调 exec，会卡住或返回空响应——必须先WaitForPodRunning - namespace 错误或 RBAC 权限不足时，错误可能是
forbidden: User "system:serviceaccount:default:my-sa" cannot post pods/xxx/exec，需确保rolebinding包含["pods/exec"]动词 - 使用自建证书的集群，
rest.InClusterConfig()会自动读取 service account token 和 ca.crt，但若手动构造 config，TLSClientConfig.Insecure设为true会导致 SPDY 协议握手失败 - exec 流未显式关闭（
Close()）时，连接可能长期 hang 在FIN_WAIT2，占用 kube-apiserver 连接数
真正稳定的 Pod shell 实现，从来不是“调通一次”，而是把状态等待、权限校验、流生命周期管理、错误重试都收进封装层里——裸用 SPDYExecutor 只是起点，不是终点。
