Go项目不部署CNI，因CNI是kubelet调用的节点级网络插件；Go应用只需适配已配置CNI的集群，通过DNS、Service、Ingress等Kubernetes原语实现通信，仅当开发CNI插件或控制器时才需直接交互。
Go 项目本身不部署或管理 kube-cni；CNI 是 Kubernetes 节点级网络插件，由 kubelet 调用，不是 Go 应用要“部署”的组件。 你在 Go 项目里写代码，无法、也不该去“部署 CNI”。真正要做的，是让 Go 应用能正确运行在已配置好 CNI 的集群中，并按需与之交互（比如开发 CNI 插件、调用 client-go 管理 NetworkPolicy、或做服务发现）。
为什么不能在 Go 项目里“部署 kube-cni”
所谓 “kube-cni” 并不是一个可安装的独立服务，而是指符合 CNI 规范的一类插件（如 calico、cilium、flannel）——它们由 kubelet 在容器创建/销毁时通过 exec 调用，操作宿主机网络设备（veth、bridge、iptables/eBPF）。Go 程序若非作为 CNI 插件二进制本身，就没有权限和上下文去执行这些动作。
- Go 应用默认运行在 Pod 内，只有受限的 netns 和 CAP_NET_ADMIN（通常被禁用），无法配置宿主机网络
- 部署 CNI 是集群管理员行为：需在每个节点上放置插件二进制 + 配置文件（
/etc/cni/net.d/*.conflist），并确保kubelet --cni-bin-dir指向正确路径 - 试图在 Go 项目里
exec.Command("calico-node")或写入/etc/cni属于越权操作，会失败或引发安全策略拒绝（如 PSP / PodSecurityPolicy）
Go 程序真正需要关心的网络互通场景
你的 Go 服务要实现 Pod 间通信或跨服务调用，关键不是“部署 CNI”，而是确认环境就绪 + 正确使用 Kubernetes 原语：
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 确保集群已部署支持
NetworkPolicy的 CNI（如calico），且NetworkPolicyAPI 已启用（--runtime-config=networking.k8s.io/v1=true） - 同命名空间内访问其他 Service：直接用 DNS 名，如
http://redis:6379—— 不需要任何 Go 代码干预 - 跨命名空间：用完整域名
http://api.default.svc.cluster.local:8080 - 需要客户端负载均衡（如 gRPC）时，用
client-go主动查EndpointSlice，而非依赖 DNS 轮询 - 若服务需暴露给外部，靠
Service（NodePort/LoadBalancer）或Ingress，不是改 CNI
什么时候 Go 代码真要和 CNI 打交道
仅当你的 Go 项目是 CNI 插件本身，或配套控制器：
立即学习“go语言免费学习笔记（深入）”；
- 编写 CNI 插件：接收 stdin 的 JSON（含
container_id、netns、ifname），返回 IP、路由、DNS；用github.com/containernetworking/plugins/pkg/ns进入容器 netns；典型流程是create veth pair → move one end to netns → ip addr add → ip link set up - 开发网络策略控制器：用
client-gowatchNetworkPolicy资源变更，再调用 Cilium API 或生成 Calico CRD 同步规则 - 调试时检查 CNI 状态：Go 程序可读取
/proc/sys/net/ipv4/ip_forward或执行ip link show（需securityContext.capabilities.add: ["NET_ADMIN"]，但生产环境应避免）
最容易被忽略的一点：CNI 插件是否生效，跟你的 Go 代码完全无关；它只取决于节点上二进制、配置、kubelet 参数三者是否匹配。如果你的 Pod 无法互通，先 kubectl get nodes -o wide 看 Ready 状态，再 ssh 到节点查 ls /opt/cni/bin/ 和 cat /etc/cni/net.d/*.conflist，而不是翻 Go 项目的 Dockerfile。
