go项目不部署kube-cni，因其并非kubernetes官方或社区标准cni插件；kubelet仅调用如calico、flannel等真实插件二进制，而“kube-cni”多为混淆名称或自定义脚本。
Go 项目本身不部署或运行 kube-cni——它不存在这个组件。Kubernetes 中负责容器网络的是 CNI 插件（如 calico、cilium、bridge），而 kube-cni 并非官方或社区标准插件名，很可能是混淆了 kubelet 的 --cni-bin-dir 配置或误传的名称。
为什么找不到 kube-cni 二进制
这是最常卡住的第一步：你执行 ls /opt/cni/bin 或查文档时搜 kube-cni，结果为空。因为：
- Kubernetes 不自带 CNI 插件，
kubelet只是按 CNI 规范调用外部二进制（如calico-ipam、ptp、host-local） - 没有叫
kube-cni的上游项目；常见拼写错误包括把kube-router、kube-ovn或cni-plugins包名记串 - 如果你从某教程看到
kube-cni，大概率是作者自定义的 wrapper 脚本，不是通用组件
Go 程序该不该直接调用 CNI 二进制
绝大多数 Go 应用完全不需要碰 CNI。只有两类角色会真正调用：
-
CNI 插件开发者：用 Go 写符合 CNI SPEC 的程序（如
plugins/main/bridge），接收 stdin JSON，返回 IP 和路由 -
轻量级 runtime 或测试工具作者：比如用
exec.Command("calico-ipam", "--conf-file=...")主动申请 IP，但前提是你的程序替代了kubelet的网络初始化逻辑
普通业务 Go 服务只需通过 DNS 访问 my-svc.default.svc.cluster.local，或用 client-go 查 EndpointSlice，和 CNI 无任何直接交互。
验证 CNI 是否生效的关键检查点
当你部署完集群（如 kubeadm + calico），想确认 Go 容器网络是否通，别查 kube-cni，盯这几个真实信号：
- Pod 的
status.phase是Running，且status.containerStatuses[0].ready == true - Pod 的
status.podIP不为空，且能 ping 通同节点其他 Pod 的podIP -
ip link show在容器内能看到eth0，且ip addr show eth0有合法 CIDR 分配（如10.244.1.3/24） - 访问
http://kubernetes.default.svc能通（证明 Service 网络 + kube-proxy 工作正常）
Go 服务在 Kubernetes 里真正要配置的网络相关项
你控制的只有这些，它们和 CNI 插件无关，但决定网络行为是否符合预期：
-
Service.spec.type：选ClusterIP（默认）、NodePort或LoadBalancer，直接影响流量入口 -
Pod.spec.containers.ports.containerPort：必须和 Go 程序实际监听的端口一致（如http.ListenAndServe(":8080")→ 这里填8080） -
Pod.spec.dnsPolicy：保持默认ClusterFirst，否则 DNS 解析会失败 -
Pod.spec.hostNetwork：设为true会绕过 CNI，直接用宿主机网络——仅调试用，生产禁用
真正容易被忽略的是：Go HTTP server 启动时机与 readiness probe 的竞争。用 http.ListenAndServe 直接阻塞，会导致 probe 在 listener 绑定前就失败。正确做法是先 net.Listen("tcp", ":8080")，再传给 http.Server.Serve(lis)，确保端口就绪后再接受 probe 请求。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
