创建Service报“metadata.name: Required value”是因为Create()要求ObjectMeta.Name和Namespace均非空且显式指定，空字符串或default均非法；Update()需先Get()获取ResourceVersion再修改字段，否则409冲突；LoadBalancer类型在非云环境无ExternalIP，应按环境动态设Type。
直接用 client-go 管理 Kubernetes Service 资源完全可行，但必须显式指定命名空间、带 ResourceVersion 更新、避免硬编码 Type —— 否则会创建失败、更新冲突或在非云环境卡死。
创建 Service 时为什么总报 "metadata.name: Required value"？
这是最常卡住的点：Create() 要求 ObjectMeta.Name 和 ObjectMeta.Namespace 都非空，且不能传空字符串或 nil。常见错误包括：
- 漏写
Namespace字段，导致 client 默认用"default"（但实际未显式设值，API Server 拒收） - 用
CoreV1().Services("").Create()，空字符串不等于 “所有命名空间”，而是非法参数 - 结构体字段名拼错，比如写成
Namesapce（少个c），Go 不报错但 JSON 序列化后字段丢失
正确做法是显式初始化整个 corev1.Service，确保 Name 和 Namespace 都赋值：
svc := &corev1.Service{
ObjectMeta: metav1.ObjectMeta{
Name: "my-app",
Namespace: "production", // 必须非空
},
Spec: corev1.ServiceSpec{
Selector: map[string]string{"app": "my-app"},
Ports: []corev1.ServicePort{{
Port: 80,
TargetPort: intstr.FromInt(8080),
}},
Type: corev1.ServiceTypeClusterIP,
},
}
_, err := clientset.CoreV1().Services("production").Create(ctx, svc, metav1.CreateOptions{})
Update Service 为什么总是返回 409 Conflict？
因为 Update() 是乐观并发控制，必须带上当前对象的 ResourceVersion。直接构造新对象调用 Update() 而不先 Get()，必然失败。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 不要手动填
ResourceVersion字符串 —— 它由 API Server 动态生成，不可预测 - 正确流程：先
Get(ctx, name, opts)拿到完整对象 → 修改需要的字段（如Spec.Ports或Spec.Selector）→ 再Update() - 只改部分字段，别覆盖整个
Spec，否则可能清空clusterIP或误删ExternalIPs
LoadBalancer 类型在本地环境为什么一直没 ExternalIP？
ServiceTypeLoadBalancer 依赖云厂商控制器（如 AWS ALB Controller、GCP L7 Load Balancer），在 kind、minikube 或裸机集群中不会分配 Status.LoadBalancer.Ingress。硬编码该类型会导致：
- Service 创建成功，但
Status.LoadBalancer.Ingress长期为空 - 上层逻辑等待
Ingress.IP就绪，造成超时或假死 - CI 流水线在不同环境行为不一致（云上 OK，本地挂起）
更稳妥的做法是按运行环境动态设置 Type：
- 开发/测试：用
ServiceTypeClusterIP+kubectl port-forward调试 - CI 部署：用
ServiceTypeNodePort，并检查端口是否在30000–32767范围内 - 生产云环境：用
ServiceTypeLoadBalancer，但需配套注解（如service.beta.kubernetes.io/aws-load-balancer-type），且绝不阻塞等待Ingress就绪
想绕过 kube-proxy 直连 Pod，该操作哪个资源？
用 Endpoints 对象，不是 EndpointSlice（后者是 v1.21+ 默认启用的替代品，但 client-go 仍需显式调用 CoreV1().Endpoints()）。注意：
-
Endpoints不是 CRD，不能用 dynamic client，必须走CoreV1().Endpoints(namespace) - 它没有
Spec字段，子对象是Subsets，每个Subset包含Addresses（Pod IP）和Ports - 手动维护
Endpoints意味着你要自己监听Pod事件、过滤标签、同步 IP 列表 —— 容易出错，仅适用于灰度、故障注入等强控场景 - 若集群启用了
EndpointSlice，API Server 会自动同步Endpoints，但反向不成立；直接写Endpoints不会触发EndpointSlice更新
真正难的不是调哪个接口，而是判断什么时候该用 Service，什么时候该切到 Endpoints —— 前者是声明式抽象，后者是命令式控制，混用极易引发流量黑洞。
