fake ClientSet是首选方案，因其为client-go官方维护的内存客户端，支持ResourceVersion、watch模拟、label/field selector过滤及namespace隔离，所有调用不发HTTP请求，且返回对象与真实API Server一致。
直接用 fakeclientset.NewSimpleClientset()，别连真实集群、别起 minikube、也别 mock 整个 kubernetes.Interface —— 那是过度设计，且掩盖了 client-go 的真实交互模式。
为什么 fake ClientSet 是首选方案
它不是“随便造个空接口”，而是 client-go 官方维护的、实现了全部核心方法（Create/Get/List/Update 等）的内存客户端。所有调用都走本地对象树，不发 HTTP 请求，也不依赖 kubeconfig 或 API Server。
常见误判是以为 “fake = 功能阉割”，其实它支持：资源版本控制（ResourceVersion）、watch 事件模拟、label/field selector 过滤、甚至 namespace 隔离 —— 只要你传进去的对象带对字段。
- 它不校验 admission webhook、RBAC、validating webhook，但单元测试本就不该测这些
- 它不触发 controller manager 的实际 reconcile，但你可以手动调用你的 reconciler 并传入 fake client
- 它返回的
*v1.Pod等对象和真实 API Server 返回的一致（含ObjectMeta.Generation、CreationTimestamp等），可直接用于逻辑断言
怎么构造带状态的 fake client
关键在初始化时传入预设对象，而不是等测试里再 Create —— 这样能覆盖 “读取已有资源” 场景，比如 Get 一个 node 再更新 label。
立即学习“go语言免费学习笔记（深入）”；
示例：模拟一个带 label 的 Node 和一个 Pending 状态的 Pod
cs := fakeclientset.NewSimpleClientset(
&corev1.Node{
ObjectMeta: metav1.ObjectMeta{
Name: "node-1",
Labels: map[string]string{"disktype": "ssd"},
},
},
&corev1.Pod{
ObjectMeta: metav1.ObjectMeta{
Name: "test-pod",
Namespace: "default",
},
Status: corev1.PodStatus{
Phase: corev1.PodPending,
},
},
)
- 传入对象必须是 pointer（
&corev1.Pod{...}），否则 fake client 会忽略 - 如果测试需要多个 namespace，必须显式传入带
Namespace字段的对象；fake client 不自动创建 namespace 资源 - 时间字段（如
CreationTimestamp）若未设置，fake client 会自动填零值，可能影响基于时间的逻辑判断，建议显式设置
Watch 和 ListOptions 怎么测
fake client 支持 Watch 方法返回 watch.Interface，也支持 ListOptions 中的 LabelSelector 和 FieldSelector。
例如测试按 label 查询 pod：
list, err := cs.CoreV1().Pods("default").List(context.TODO(), metav1.ListOptions{
LabelSelector: "app=nginx",
})
// 只有你传入的 Pod 对象带 labels["app"] == "nginx"，才会出现在 list.Items 中
-
LabelSelector使用labels.Parse()解析，支持app in (nginx,redis)等复杂语法 -
FieldSelector仅支持metadata.name和metadata.namespace，其他字段（如status.phase）会被静默忽略 - Watch 返回的 channel 不会自动关闭，测试中需用
timeout或stopCh控制，避免 goroutine 泄漏
容易被忽略的边界点
fake client 不处理资源冲突的底层细节，比如两个 goroutine 同时 Update 同一个对象时不会报 409 Conflict，而是后写覆盖前写 —— 这和真实 etcd 行为不一致。如果你的代码依赖乐观锁（ResourceVersion 检查），必须手动在测试中构造不同 ResourceVersion 值并验证错误路径。
另一个坑是：fake client 的 UpdateStatus 方法不会自动同步到主资源对象上。比如你调用 podClient.UpdateStatus()，之后再 podClient.Get()，拿到的仍是旧 status —— 除非你把 status 更新也写进初始对象，或手动再 Update 整个对象。
