Docker 网络 IP 地址冲突了,该怎么办呢?

Docker 网络 IP 地址冲突这个问题其实稍微有一点点麻烦,网上也没有看到有比较全面正确的文章, 值得单独写一篇记录一下。

1前置知识

因为交换机的能力有限制,以及网线的连接不可能无限长, 所以我们不可能把所有的主机都连到同一个交换机上,然后处于同一个二层网络中。

就算能,主机间的 ARP 广播也会让这个网络瞬间瘫痪。

所以我们得把主机拆分到一个个的小的子网里,然后通过路由器再并成三层网络。

我们俗称的 IP 地址其实由两个部分组成,网络地址和主机地址。比如 10.0.0.1/8 中,第一个 10 是网络地址,后面的 0.0.1 是主机地址。那我怎么知道怎么去拆分这两段呢?靠的就是子网掩码,也就是那个 /8

IP 其实是由 32 位的二进制组成的,x.x.x.x 只是为了方便人类阅读将其转成了十进制。有个简单粗暴的办法就是可以认为每一段都是 8 位,所以 /8 就代表第一段是网络地址。

同理,/16 就代表前两段都是网络地址,10.0.0.0/16 中, 网络地址是 10.0,后两位 0.0 代表每个子网中的主机地址。

比如 10.0.0.1/16 和 10.0.0.2/16 是同一个子网的两个主机。10.0.0.1/16 和 10.1.0.1/16 是不同的子网的两个主机。另外,搜索公众号后端架构师后台回复“架构整洁”,获取一份惊喜礼包。

这里只是简单粗暴的介绍下,更多的信息还是自己去查资料了解学习。

2问题表现

  • docker 进程无法启动

  • 容器端口无法访问,抓包显示为有入站但是没有出站

3排查

此处针对的是 dockerd 无法启动的情况,如果 dockerd 能启动,可以直接跳到解决一节

首先是看下日志

$ systemctl status docker
$ journalctl -u docker
$ dmesg | grep docker

一般能看到如下日志:

docker0: link is not ready
docker_gwbridge: link is not ready

或者更简单的排查方法,直接手动启动 dockerd 看看。启动方法可以通过 grep ExecStart /usr/lib/systemd/system/docker.service 查看。

一般来说按如下执行就行:

$ /usr/bin/dockerd --debug

然后能看到最后输出:

INFO[2021-07-29T02:25:55.811673622Z] stopping event stream following graceful shutdown  error="<nil>" module=libcontainerd namespace=moby
failed to start daemon: Error initializing network controller: list bridge addresses failed: PredefinedLocalScopeDefaultNetworks List: [10.252.0.0/24 10.252.1.0/24 10.252.2.0/24]: no available network

这时候可以看下 ip addr,是否有 docker0 和 docker_gwbridge

如果发现没有 docker0,那基本可以肯定是 docker0 无法创建导致 dockerd 启动失败了。

4解决

找到占用的网段

默认的 docker0 网段是 172.17.0.0/16,docker_gwbridge 网段是 172.18.0.0/24,你需要确认下这两个网段是否被占用了。

最简单的方法就是 ping 一下,如果无响应的话,那么就说明没有被占用。

其次就是看一下本机的路由表 route -n,确认一下有没有冲突的段。一般来说,你会发现相关网段要么已经被占用,要么是路由表里存在冲突。

案例

比如在我的环境里,我给 docker0 配置为 10.252.0/24,然后 dockerd 起不来。

排查后发现 route -n 里有这么一条:

10.0.0.0        172.21.0.1      255.0.0.0       UG    0      0        0 eth0

也就是说 10/8 被占用了,导致和我的 10.252.0/24 冲突。后来联系网管删除了这条 10/8 的路由后解

修改 docker 占用的网段

以下操作需要先停止 docker 进程

$ systemctl stop docker

如果你用 docker service,那么 docker 会占用四个网段:

  1. docker0

  2. docker_gwbridge

  3. ucp(docker engine 占用,不常见)

  4. ingress

其中前三个的网段可以通过配置文件配置,第四个只能手动创建。

前三个网段会读取 /etc/docker/daemon.json 这个配置文件, 这个文件默认是没有的,需要手动创建。

{
    "bip": "",
    "default-address-pools": [
        {"base": "10.252.0.0/24", "size": 24},
        {"base": "10.252.1.0/24", "size": 24},
        {"base": "10.252.2.0/24", "size": 24}
    ]
}

注意这个 default-address-pools 至少要有两项,按顺序依次为:

  1. docker0

  2. docker_gwbridge

  3. ucp

以防万一的话,配置三个是最好的😄。

接下来是修改 ingress,这个比较麻烦,需要手动创建。

我的办法是在初始化 docker swarm 以后,启动 docker stack/service 以前,执行以下脚本:

  1. 删除 ingress

  2. 删除 my-ingress(不一定存在,不存在就忽略)

  3. 新建 my-ingress

$ yes 'y' | docker network rm ingress
$ yes 'y' | docker network rm my-ingress 2>&1 | true
$ docker network create \
  --driver overlay \
  --ingress \
  --subnet=10.252.3.0/24 \  # 指定 ingress 的网段,不要和上面 daemon.json 的网段冲突
  --gateway=10.252.3.2 \
  --opt com.docker.network.driver.mtu=1200 \
  my-ingress

ingress 是默认名,之所以新建一个名字不一样的,是因为删除 ingress 是异步的。如果你删除 ingress 后立刻新建一个也叫 ingress 的网络,很可能会报一个重名的错误。

重启 docker 前,最好先清理一下 docker 的缓存:

$ ip link del dev docker0
$ ip link del dev docker_gwbridge
$ rm -rf /var/lib/docker/network

另一种粗糙简单的解决办法

另一种粗糙简单的解决办法就是干脆直接手动创建一个 docker0。

这种解决方法最简单,但是机器 reboot 后 docker0 会自动被删掉, 所以这方法并不持久。

而且,实际上也不一定能解决网段冲突的问题,只是说 docker 能启动了而已。

ip link add name docker0 type bridge
ip addr add dev docker0 10.252.0.1/24
### Docker Swarm 中 IP 冲突的原因分析 在 Docker Swarm 集群中,IP 地址冲突可能源于多个方面。例如,当网络配置不当或者节点间的通信出现问题时,可能会导致容器被分配到重复的 IP 地址[^1]。此外,如果集群内的覆盖网络(Overlay Network)未正确设置,也可能引发此类问题。 以下是可能导致 IP 冲突的一些常见原因及其解决方案: #### 原因一:覆盖网络子网重叠 Docker 默认会为每个覆盖网络分配一个独立的子网范围。然而,如果没有显式指定子网,则可能存在其他网络或外部网络发生地址空间重叠的情况[^2]。 ##### 解决方案: 创建新的覆盖网络时,应手动定义唯一的 CIDR 子网范围以防止潜在冲突。 ```bash docker network create --subnet=192.168.0.0/24 -d overlay my_overlay_network ``` --- #### 原因二:服务扩展过程中产生的临时状态不一致 当大规模部署的服务快速扩容或缩容时,某些情况下可能出现短暂的状态同步延迟,从而造成新实例获取已存在的 IP 地址[^3]。 ##### 解决方法: 清理无用镜像和僵尸容器有助于减少环境混乱程度,并降低这类风险的发生概率。 ```bash docker system prune -f docker rmi $(docker images | grep "<none>" | awk '{print $3}') ``` 另外还可以尝试重启整个 Swarm 模式重新初始化全局视图一致性。 ```bash docker swarm leave --force && docker swarm init ``` --- #### 原因三:底层驱动参数调整不足 默认情况下,MPLS 或 VXLAN 封装技术用于实现跨主机间的数据包转发功能。但如果 MTU 设置不合理的话,也有可能间接影响 ARP 表项更新效率进而诱发异常现象[^4]。 ##### 调优建议: 确认各成员服务器物理接口实际支持的最大传输单元大小后再做相应修改操作如下所示: ```bash ip link set dev eth0 mtu 1450 sysctl net.ipv4.ip_forward=1 ``` 最后记得验证更改效果是否有效解决了原有难题! --- ### 总结 综上所述,针对上述提到的各种情形采取对应的预防措施能够显著改善整体稳定性表现水平。当然除了以上列举出来的几个典型场景之外还有其他因素同样值得重视比如防火墙策略限制等等都需要逐一排查清楚才能彻底根除隐患所在之处。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值