用client-go+kyaml导出YAML需先获取unstructured.Unstructured对象，再清理metadata中creationTimestamp、resourceVersion、uid等runtime字段，最后用kyaml.Marshal序列化，避免kubectl命令依赖和status干扰。
用 client-go + kyaml 能导出干净、可控的 YAML，但必须手动剥离 runtime 无关字段，否则会混入 creationTimestamp、resourceVersion、uid 等不可复用字段。
用 client-go 获取资源对象再序列化为 YAML
client-go 本身不直接提供“导出 YAML”接口，得先调用 List 或 Get 拿到 *unstructured.Unstructured 或具体类型（如 *corev1.ConfigMap），再用 yaml.Marshal 或 kyaml 库转成字节流。关键点在于：不能直接 marshal 原始对象，否则会带一堆 runtime 字段。
- 推荐用
unstructured.Unstructured统一处理所有资源类型，避免为每种资源写单独逻辑 - 拿到对象后，调用
obj.UnstructuredContent()得到 map[string]interface{}，这是可安全序列化的原始结构 - 务必在 Marshal 前删掉
metadata.managedFields、metadata.uid、metadata.resourceVersion、metadata.creationTimestamp、metadata.generation等字段——它们在 apply 时会被 API Server 忽略或覆盖，保留反而导致 diff 失真 - 如果需要保留
annotations和labels，只过滤掉上述 runtime 字段即可；kubectl get -o yaml默认也保留这些
用 kyaml 替代标准 yaml.Marshal 提升兼容性
kyaml（即 sigs.k8s.io/kustomize/kyaml）比标准 gopkg.in/yaml.v2 更懂 Kubernetes 的 YAML 规范，比如能正确处理 intstr.IntOrString、metav1.Time、resource.Quantity 等特殊类型，避免序列化成空值或 panic。
- 用
kyaml/yaml.Marshal替代yaml.Marshal，传入的是unstructured.Unstructured实例本身，不是UnstructuredContent()返回的 map - 它会自动跳过零值字段（如空
spec.selector.matchLabels），更接近kubectl apply的行为 - 若需控制缩进、是否折叠多行字符串等格式细节，得用
kyaml/yaml.Node手动构建，但日常导出没必要
导出时忽略 namespace 或 cluster-scoped 字段的技巧
有些场景要导出跨 namespace 的资源做模板，或者想把 namespaced 资源变成 cluster-scoped（比如把 Namespace 里定义的 RoleBinding 改成 ClusterRoleBinding），不能靠简单替换字符串。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 修改
obj.Object["kind"]同时必须同步改obj.Object["apiVersion"]（例如rbac.authorization.k8s.io/v1→rbac.authorization.k8s.io/v1不变，但kind从RoleBinding改成ClusterRoleBinding） - 删掉
obj.Object["metadata"]["namespace"]字段，否则ClusterRoleBinding会因含 namespace 字段被 API Server 拒绝 - 对
ServiceAccount这类资源，若要泛化使用，建议删掉secrets字段（它由 controller 动态注入，导出后 apply 会失败）
为什么不用 kubectl exec 或 shell 命令调用
在 Go 程序里执行 exec.Command("kubectl", "get", "cm", "-o", "yaml") 看似简单，但实际埋了几个坑：
- 依赖本地
kubectl二进制和 kubeconfig，无法嵌入容器或 air-gapped 环境 - 输出包含
status字段（如ConfigMap的status总是空，但某些 CRD 有真实 status），而apply会忽略status，导出它纯属干扰 - 无法控制字段裁剪粒度——
--export参数在 1.22+ 已废弃，--output-version也不再支持降级 apiVersion - 错误处理弱：
kubectl出错时返回非零码，但 stderr 内容格式不稳定，难做结构化解析
真正可控的 YAML 导出，绕不开 client-go + unstructured + kyaml 这个组合。最易被忽略的是：runtime 字段清理必须在序列化前完成，而不是靠 post-process 字符串替换——后者容易漏掉嵌套结构里的 resourceVersion（比如 ownerReferences 里也有）。
