Go不直接管理Docker容器网络，仅能通过Docker API或系统命令间接操作；自定义网络需用netlink库直接配置内核网络对象，但复杂操作应交由Docker SDK完成。

Go 语言本身不直接管理 Docker 容器网络，真正起作用的是 dockerd 的内置网络驱动（如 bridge、overlay）和 Linux 内核的网络栈；Go 只能通过调用 Docker API 或执行 ip、iptables、nsenter 等命令间接操作。硬要在 Go 里“实现容器网络管理”，本质是封装对底层网络设施的控制逻辑。

用 github.com/docker/docker/api/types/network 创建/删除 Docker 网络

Docker SDK for Go 提供了标准接口，但仅限于调用 dockerd 已支持的网络功能，无法自定义数据面行为（比如实现一个新驱动）。创建网络时，Driver 字段决定底层行为："bridge" 会自动配置 docker0 和 veth 对，"host" 则跳过网络命名空间隔离。

• IPAM.Config 必须显式指定 Subnet，否则默认使用 172.17.0.0/16，容易与已有网段冲突
• 若指定 EnableIPv6: true，需确保 dockerd 启动时带 --ipv6 --fixed-cidr-v6=... 参数，否则创建失败并报错 "IPv6 enabled, but no IPv6 subnet configured"
• 删除网络前必须确保无容器连接，否则返回 "network xxx has active endpoints"，需先调用 ContainerList + NetworkDisconnect

networkCreateResp, err := cli.NetworkCreate(ctx, "mynet", types.NetworkCreate{
	Driver: "bridge",
	IPAM: &network.IPAM{
		Config: []network.IPAMConfig{{
			Subnet: "192.168.100.0/24",
		}},
	},
})

用 netlink 库在 Go 中直接配置 veth、namespace 和路由

绕过 Docker API，直接操作内核网络对象，适用于定制化网络方案（如 CNI 插件）。核心依赖是 github.com/vishvananda/netlink 和 github.com/vishvananda/netns，它们封装了 netlink socket 调用。

• veth pair 创建后，必须手动将一端移入目标 network namespace，否则无法生效；常用方式是用 netns.GetFromPath("/proc//ns/net") 获取 ns 句柄，再调用 netlink.LinkSetNsFd()
• 在容器 netns 内配置 IP 和路由，需用 netns.Set() 切换上下文，否则所有 netlink 操作仍在 host namespace 执行
• 忘记执行 netlink.LinkSetUp() 会导致接口处于 DOWN 状态，ping 不通 —— 这是最常被忽略的一步

link := &netlink.Veth{
	Name:  "veth0",
	PeerName: "veth1",
}
if err := netlink.LinkAdd(link); err != nil {
	return err
}
// link.Attrs().Index 是 veth0 的 ifindex
// link.PeerIndex 是 veth1 的 ifindex

处理容器启动后网络就绪的竞态问题

容器进程启动快于网络配置完成（尤其在自定义 CNI 流程中），导致应用读取 /etc/resolv.conf 失败或连不上 DNS。不能依赖固定 sleep，而应检测关键信号：

• 检查 /sys/class/net/eth0/carrier 是否为 1（表示链路已 up）
• 用 netlink.AddrList() 查询 eth0 是否已分配 IPv4 地址，避免只看接口状态
• DNS 就绪需额外验证：在容器 netns 内执行 dig +short google.com @8.8.8.8，超时则重试

为什么不要在 Go 里重复实现 docker network connect 的逻辑

看似只是“把容器加进网络”，实际涉及多步原子操作：查找容器 netns、创建 veth pair、移动 peer 端、设置 IP、添加 iptables 规则、更新 dockerd 内部状态。SDK 调用 NetworkConnect 是唯一安全方式；自己手撸容易漏掉 ebtables 防护规则或 docker0 的 MAC 地址学习刷新，导致跨容器通信异常或 ARP 泛洪。

真正需要 Go 控制的，是网络策略下发（如用 gobgp 设置 BGP）、IPAM 分配决策（对接 Consul 或 Etcd），或者调试时进入容器 netns 抓包 —— 这些才是 Go 发挥作用的合理边界。