Kubernetes运维脚本用Go编写，核心是配置、资源路径、参数和状态确认四点全对：Pod内必须用rest.InClusterConfig()，本地调试须用clientcmd.BuildConfigFromFlags；Deployment属apps/v1而非CoreV1；namespace、ResourceVersion、selector需显式传入且准确；变更后须轮询检查UpdatedReplicas与AvailableReplicas是否达标，并设超时与重试。
用 Go 写 Kubernetes 运维脚本，核心不是“会不会调 API”，而是配置、资源路径、参数和状态确认这四点全对了，才能稳定跑起来。错一个，403 Forbidden、no Auth Provider found for name "oidc"、NotFound 或静默失败就立刻出现。
怎么初始化 client-go 的 config 才不 panic
本地调试和 Pod 内运行必须用不同方式初始化配置，混用必崩。
- 在 Pod 里跑？必须用
rest.InClusterConfig()——它读/var/run/secrets/kubernetes.io/serviceaccount/下的token和ca.crt；用clientcmd.BuildConfigFromFlags会直接 panic：open /root/.kube/config: no such file or directory - 本地调试？必须用
clientcmd.BuildConfigFromFlags("", "/path/to/kubeconfig")；InClusterConfig()在本地永远失败，别试 - 如果
kubeconfig有多个 context，得显式加载并指定：clientcmd.NewNonInteractiveDeferredLoadingClientConfig(clientcmd.NewDefaultClientConfigLoadingRules(), &clientcmd.ConfigOverrides{CurrentContext: "prod-cluster"}) - 务必校验 config 是否有效：调一次
clientset.CoreV1().Namespaces().List(ctx, metav1.ListOptions{})，失败就提前退出，避免后续所有 API 调用都静默失败
为什么 Deployment 总是 404 或 403
Deployment 不在 CoreV1，它属于 apps/v1，用错 client 就白忙活。
- 错误写法：
clientset.CoreV1().Deployments("default").List()→ 编译不过或 panic - 正确写法：
clientset.AppsV1().Deployments("default").List() - 其他常见 GroupVersion 映射：
Ingress是networking.k8s.io/v1（1.19+），HorizontalPodAutoscaler是autoscaling/v2，CRD 则完全取决于其spec.group和spec.versions[0].name - RBAC 权限必须精确匹配：
apps/v1 deployments的权限不能靠core/v1 pods权限替代
namespace、ResourceVersion、selector 这三个参数漏一个就出事
namespace 必须显式传，ResourceVersion 更新时必须带，selector 用 labels.Set 构造才可靠。
立即学习“go语言免费学习笔记（深入）”；
-
clientset.CoreV1().Pods("default")和clientset.CoreV1().Pods("")行为完全不同；空字符串不等于 “所有命名空间” —— 它是明确语义的metav1.NamespaceAll - 查所有命名空间的 Pod：
clientset.CoreV1().Pods(metav1.NamespaceAll).List(ctx, opts)，不是Pods("") - 创建 Pod 时没设
ObjectMeta.Namespace，默认落到default，哪怕你调用的是Pods("myns")—— 接口只控制请求路径，不覆盖对象字段 - Update/Delete 必须带
ResourceVersion，否则可能因乐观锁失败；建议先Get再改再Update - 按 label 查询资源（如找某类 Pod）时，手拼字符串 selector 容易出错；用
labels.Set{"app": "myapp"}.AsSelector()更可靠
滚动发布后怎么确认成功，而不是发完就走
Kubernetes 所有变更都是异步的。Deployment 更新后，Pod 启动、就绪、旧 Pod 终止都需要时间。Go 脚本必须轮询确认最终状态。
- 检查
dep.Status.UpdatedReplicas == *dep.Spec.Replicas且dep.Status.AvailableReplicas == *dep.Spec.Replicas - 加超时控制（建议 300 秒内）和重试间隔（2–5 秒），失败时返回明确
error，便于上层触发回滚 - 可选监听事件流：
clientset.CoreV1().Events(ns).Watch()，捕获Warning级别异常（如ImagePullBackOff、FailedScheduling） - 别在代码里硬编码 YAML；应使用官方类型（如
appsv1.Deployment、v1.Service）构造对象，字段清晰、IDE 可提示、编译期可校验
最常被忽略的是：更新资源时用 Update() 或 Patch()，而不是 Create() 全量覆盖——后者会意外丢失注解、ownerReferences 或 status 字段；还有就是 spec.selector 和 template.metadata.labels 必须严格一致，差一个字符就导致 Deployment 卡住不动。
