用 client-go 连不上集群时，本地调试需用 clientcmd.BuildConfigFromFlags() 替代 rest.InClusterConfig()，后者仅适用于 Pod 内且有 RBAC 的场景；批量 Patch Deployment 需手动循环并控制并发，不可直接 goroutine 泛滥。
用 client-go 连不上集群？检查 rest.InClusterConfig() 和 rest.InClusterConfig() 的适用场景
本地调试时直接用 rest.InClusterConfig() 会 panic：「unable to load in-cluster configuration」。这个函数只在 Pod 内部运行且 ServiceAccount 有对应 RBAC 时才有效。本地跑脚本必须用 rest.InClusterConfig() 的替代方案 —— rest.InClusterConfig() 不行，得换 clientcmd.BuildConfigFromFlags()。
常见错误是硬编码 kubeconfig 路径或忽略 --kubeconfig 参数支持。实操建议：
- 始终通过
flag.String("kubeconfig", "", "Path to kubeconfig file")接收配置路径，空值时 fallback 到os.Getenv("KUBECONFIG")或默认"$HOME/.kube/config" - 构造 config 时加错误 wrap：
config, err := clientcmd.BuildConfigFromFlags("", *kubeconfigFlag)，别漏掉err != nil检查 - 若脚本部署到集群内（如 Job），才用
rest.InClusterConfig()，且确保容器里挂载了/var/run/secrets/kubernetes.io/serviceaccount
批量 Patch 多个 Deployment 时，为什么 clientset.AppsV1().Deployments(ns).Patch() 一次只能改一个？
因为 Kubernetes API 本身不支持跨资源批量 Patch —— Patch() 是单对象操作。想“批量”，得自己循环，但要注意并发控制和错误处理。
容易踩的坑：
立即学习“go语言免费学习笔记（深入）”；
- 直接用
for range启 goroutine 发起 Patch，没加限流，触发 apiserver 的429 Too Many Requests - 用
strategic merge patch时写错 path（比如把spec.replicas写成replicas），Patch 成功但没生效 - 没检查
metav1.PatchType类型：修改 spec 推荐用types.StrategicMergePatchType，改 annotation/label 用types.MergePatchType
示例片段（带并发限制）：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
sem := make(chan struct{}, 5) // 限 5 并发
var wg sync.WaitGroup
for _, d := range deployments {
wg.Add(1)
go func(dep v1.Deployment) {
defer wg.Done()
sem <- struct{}{}
defer func() { <-sem }()
patchData, _ := json.Marshal(map[string]interface{}{
"spec": map[string]interface{}{"replicas": int32(2)},
})
_, err := clientset.AppsV1().Deployments(dep.Namespace).Patch(
context.TODO(),
dep.Name,
types.StrategicMergePatchType,
patchData,
metav1.PatchOptions{},
)
if err != nil {
log.Printf("fail to patch %s/%s: %v", dep.Namespace, dep.Name, err)
}
}(d)
}
wg.Wait()
如何安全地批量删除资源并避免误删？
clientset.CoreV1().Pods(ns).DeleteCollection() 看似方便，但它不校验 label selector 是否匹配预期数量，也不提供 dry-run 支持（v1.22+ 的 server-side dry-run 在 client-go 中需手动构造 metav1.DeleteOptions{DryRun: []string{metav1.DryRunAll}}）。
实操关键点：
- 删除前必先
List()，打印匹配数 + 前 3 个名字，加--dry-run=client开关逻辑（用 flag 控制） - 对
DeleteCollection()，必须显式传metav1.DeleteOptions{PropagationPolicy: &prop}，否则默认Background，可能残留 orphaned pods - 若要级联删除（如删 Deployment 同时删其 Pods），别依赖
PropagationPolicy，应先删 owner（Deployment），再等ReplicaSet自动消失，或用ownerReferences反查后删
脚本运行慢、OOM 或被 apiserver 断连？关注 context 和 RestClient 配置
client-go 默认的 rest.Config 没设 timeout，List 大量资源（如全集群 Pods）时卡住、内存暴涨很常见。这不是代码逻辑问题，是 HTTP 客户端没调优。
必须做的配置：
- 给
rest.Config显式设Timeout: 30 * time.Second - 所有 List/Get/Patch 调用都传带 cancel 的
context.WithTimeout(context.Background(), 60*time.Second)，别用context.Background()直接传 - 如果 List 结果超 500 条，务必加
Limit和Continue分页（listOptions.Limit = 500，循环取list.Continue），否则 etcd 压力大且 client 内存爆
这些不是“可选优化”，是生产脚本的底线配置。少一个，上线后就可能半夜被 call。
