Go不直接管理容器网络，而是通过集成Kubernetes原生机制实现：依赖CNI插件处理Pod网络、kube-proxy或eBPF方案实现Service负载均衡；业务应用优先使用DNS服务发现，必要时用client-go查询EndpointSlice；开发CNI插件则需遵循规范操作网络设备。
在 Go 语言中直接“管理容器网络”或“实现 Pod 间通信和服务发现”并不是标准做法——这些能力由 Kubernetes（K8s）自身提供，Go 更多是用于编写与之交互的控制器、Operator、CNI 插件或服务端程序。如果你正在用 Go 开发 Kubernetes 相关组件，关键不是从零造轮子，而是正确集成和利用 K8s 原生机制。
理解底层依赖：CNI 和 kube-proxy 是核心
Kubernetes 不自己实现网络，而是通过 CNI（Container Network Interface） 插件（如 Calico、Cilium、Flannel）为 Pod 分配 IP 并建立跨节点通信；kube-proxy（或基于 eBPF 的替代方案如 Cilium Agent）负责 Service 的集群内负载均衡与服务发现。
- Go 程序无需手动配置 iptables 或 BPF map，但可调用 CNI 插件二进制（如 exec.Command 调用
calico-ipam）来申请/释放 IP，前提是你的程序是 CNI 插件的一部分 - 若开发自定义网络控制器，应 watch Node、Pod、EndpointSlice 资源，根据其状态变化触发网络策略同步（例如调用 Cilium API 更新 NetworkPolicy）
在 Go 中访问 Pod 网络和服务：用 client-go + DNS
业务 Pod 中的 Go 应用要实现服务发现，最简单可靠的方式就是走 Kubernetes 内置 DNS：
- 访问同命名空间服务：
http://my-service:8080 - 跨命名空间：
http://my-service.myns.svc.cluster.local:8080 - 用 client-go 主动查询 Endpoints 或 EndpointSlice，适用于需要绕过 DNS 或做客户端负载均衡的场景（如 gRPC 连接池）
示例：用 client-go 获取 service 对应的就绪 endpoints
立即学习“go语言免费学习笔记（深入）”；
endpoints, err := clientset.CoreV1().Endpoints("default").Get(context.TODO(), "my-service", metav1.GetOptions{})
// 检查 subsets[0].addresses 中 Ready 状态的 IP+Port
编写 CNI 插件：Go 是主流选择之一
如果你真要“管理容器网络”，大概率是在写 CNI 插件。Go 因其静态编译、无依赖、并发友好，被多数 CNI 插件采用（如 Calico 的 plugins、Cilium 的 cni-install）。
- 遵循 CNI 规范：接收 stdin 的 JSON 配置（如
container_id,netns,ifname），返回分配的 IP、路由、DNS 等 - 典型流程：创建 veth pair → 将一端放入容器 netns → 配置 IP 和路由 → 设置 hairpin / ARP proxy（如需）→ 返回结果
- 使用
github.com/containernetworking/plugins/pkg/ns安全进入 netns，用github.com/vishvananda/netlink操作网络设备
服务发现进阶：用 EndpointSlice + informer 实时感知
原生 Endpoints 在大规模集群中性能差，Kubernetes 推荐用 EndpointSlice。Go 程序可通过 informer 高效监听其变更：
- 初始化 sharedInformerFactory，启动 EndpointSlice informer
- 注册 AddFunc/UpdateFunc，解析
endpoint.slices.k8s.io中的addressType: IPv4和conditions.ready == true的 endpoint - 结合 service label selector 动态构建后端列表，支持平滑增删实例
这比轮询 API 更轻量，也避免 DNS 缓存延迟问题，适合对一致性要求高的控制平面组件。
