用client-go管理Service需显式指定命名空间，Create要求Name和Namespace非空，Update需带ResourceVersion；Service类型应按环境动态设置，避免硬编码LoadBalancer；Endpoints可绕过kube-proxy但需手动维护；Watch监听时需处理clusterIP延迟就绪问题。
用 client-go 创建和更新 Service 资源
直接调用 Kubernetes API 管理 Service，核心是用 client-go 的 CoreV1().Services() 接口。注意命名空间必须显式指定，空字符串或 default 都会失败 —— 这是新手最常卡住的地方。
关键点：
-
Create()要求ObjectMeta.Name和ObjectMeta.Namespace都非空，否则报错Service "xxx" is invalid: metadata.name: Required value -
Update()必须带上完整的ResourceVersion，否则返回409 Conflict；建议先Get()再改字段再Update() - 若仅想更新
spec.ports或spec.selector，不要覆盖整个spec，避免意外清空clusterIP或type
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{})
Service 类型选型：ClusterIP / NodePort / LoadBalancer 的实际约束
Go 程序里写死 Type: corev1.ServiceTypeLoadBalancer 很危险 —— 它依赖云厂商控制器，本地 kind 或 minikube 环境根本不会分配 ExternalIP，Status.LoadBalancer.Ingress 会长期为空。
更稳妥的做法是按环境动态设置：
立即学习“go语言免费学习笔记（深入）”；
- 开发/测试环境用
ClusterIP+kubectl port-forward调试 - CI 流水线部署用
NodePort，但需检查NodePort范围（默认30000–32767），避免硬编码冲突 -
LoadBalancer必须配合云平台注解（如service.beta.kubernetes.io/aws-load-balancer-type），且 Go 代码里不应等待Ingress.IP就绪 —— 它可能几分钟才出现
通过 Endpoints 直接路由到 Pod（绕过 kube-proxy）
当需要精细控制流量（比如灰度发布、故障注入），可跳过 Service 的 iptables/IPVS 规则，直接操作 Endpoints 对象。但要注意：Endpoints 不是 CRD，不能用 client-go 的泛型客户端，必须用 CoreV1().Endpoints()。
常见陷阱：
-
Endpoints.Subsets里每个Address必须带IP字段，TargetRef可选；填错格式（如写成127.0.0.1）会导致连接拒绝 - 手动管理
Endpoints时，Service的selector字段会被忽略 —— 即使你删了selector，kube-controller-manager 也不会自动同步Endpoints - 如果同时存在同名
Service和Endpoints，Kubernetes 不会报错，但行为未定义（实际以Endpoints为准）
监听 Service 变更做动态路由更新
用 Watch() 实时响应 Service 变更比轮询高效得多，但要注意事件类型和重连逻辑：
-
watch.Event.Type是字符串"ADDED"/"MODIFIED"/"DELETED"，不是枚举，别用switch event.Type直接比对常量 - Watch 连接断开后，
event.Object可能是*unstructured.Unstructured，需用runtime.DefaultUnstructuredConverter.FromUnstructured()转为*corev1.Service - 不要在
Watch回调里直接调用阻塞操作（如 HTTP 请求），应发消息到 channel 由 worker 处理，否则会卡住整个 watch stream
真正难处理的是 Service 的 clusterIP 字段：它在 ADDED 事件中可能是 "None"（Headless Service）或空字符串，要等 MODIFIED 事件才稳定。硬编码假设 clusterIP != "" 会导致路由配置失败。
