剖析 Docker Swarm 操作对容器端口影响
一、背景阐述
在使用 Docker Swarm 构建集群环境过程中，于 ts3 节点出现了原有的容器端口全部失效，手动重启后才恢复的情况。期间涉及 docker swarm init --advertise-addr=172.16.10.110 以及 docker swarm join --token <MANAGER-TOKEN> <MANAGER-IP>:<MANAGER-PORT> 等操作，下面深入探究为何会出现端口失效及恢复的现象。
| 角色 | IP | hostname |
|---|---|---|
| Manager1 | 172.16.10.110 | ts3 |
| Manager2 | 172.16.10.111 | ts4 |
| Worker1 | 172.16.10.120 | harbor |
手动重启容器后才恢复的情况
二、端口失效原因剖析
（一）网络配置变更因素
- 覆盖网络创建影响
- 当执行
docker swarm init或docker swarm join操作时，Docker 为保障 Swarm 集群内部高效通信，会创建新的覆盖网络（overlay network）。此网络构建过程涉及复杂的网络配置调整。 - 例如，新覆盖网络的创建需要分配新的网络段、子网掩码等参数，这些参数的变更直接影响到节点的网络拓扑结构。原有的容器若依赖于之前的网络配置，如静态 IP 地址绑定、基于旧网络段的端口映射规则，在新覆盖网络生成后就会失效。
- 当执行
- iptables 规则动态调整
- Docker 在 Swarm 操作期间会动态修改 iptables 规则。iptables 作为 Linux 系统下强大的防火墙工具，管控着网络流量的流入、流出以及端口转发等操作。
- 比如，初始化 Swarm 时，为实现集群内服务间的负载均衡与通信隔离，Docker 会新增一系列允许或限制特定端口、IP 段流量的规则。这些新规则可能与原容器端口映射所依赖的 iptables 旧规则冲突，致使原容器端口无法正常对外提供服务，出现端口失效现象。
（二）服务发现与 DNS 变更因素
- 服务发现机制更新
- Swarm 集群拥有自身一套完备的服务发现机制，旨在让集群内各个服务、容器能精准定位彼此。当节点执行 Swarm 相关操作时，这套服务发现机制会被重新配置。
- 例如，原本容器依靠基于节点主机名或自定义服务名的发现规则来建立网络连接，在 Swarm 初始化或节点加入后，服务发现规则转变为基于 Swarm 内部生成的唯一服务 ID 或虚拟 IP 地址。容器若未及时适应这种变化，仍按旧规则寻找服务或端口，必然导致通信失败，端口映射看似失效。
- DNS 配置重新加载
- 伴随 Swarm 操作，DNS 配置同步更新。在集群环境下，DNS 用于解析服务名、容器名等标识到对应的 IP 地址，确保网络通信顺畅。
- 例如，新加入 Swarm 的节点可能会从管理节点获取全新的 DNS 服务器地址与解析策略。容器启动时依据的是旧 DNS 配置，运行过程中未能及时刷新 DNS 信息，那么在尝试通过域名访问其他服务时，就无法正确解析，使得依赖于域名解析的端口通信受阻，端口失效。
（三）资源重新分配因素
- IP 地址动态调配
- 在 Swarm 集群搭建与节点加入过程中，IP 地址常常会被重新分配。这是为了满足集群统一管理、资源优化配置的需求。
- 例如，原容器绑定了特定的 IP 地址，在节点加入 Swarm 后，根据集群的 IP 管理策略，该 IP 地址可能被回收并重新分配给其他服务或容器。此时，原容器基于旧 IP 地址的端口映射自然失效，若不重启容器获取新 IP 地址，端口将无法正常工作。
- 网络命名空间更迭
- 每次 Swarm 操作都可能引发网络命名空间的更迭。网络命名空间是 Linux 系统中隔离网络资源的一种机制，不同的网络命名空间拥有独立的网络配置、路由表等。
- 比如，新加入 Swarm 的节点会被分配新的网络命名空间，原容器所在的旧网络命名空间被关闭或修改。容器依赖旧网络命名空间内的网络连接与端口映射规则，在命名空间变更后，就如同进入一个全新且陌生的网络环境，端口失效在所难免。
三、总结
通过对上述各因素的详细剖析可知，docker swarm init 与 docker swarm join 操作绝非孤立地改变节点的某一特性，而是从网络配置、服务发现、DNS 以及资源分配等多维度重塑节点运行环境。这些深层次变革在带来集群强大功能与高效管理的同时，也不可避免地对原有的容器端口映射造成冲击，致使端口失效。唯有深入理解这些内在原理，才能在遭遇问题时精准施策，保障 Docker Swarm 集群稳定运行。