docker swarm网络问题

Posted 2023-04-16

参考技术A docker主机内部网络正常，与其它主机的连接失效，其它主机不能连接docker主机上映射的端口，docker内部也无法连接外部主机。

添加配置

执行 sysctl -p 生效

再次查看docker info，警告消失，主机上的docker网络恢复正常。

我所使用的服务器是阿里云服务器
如果你的集群使用的默认端口4789，那么你可能遇到跟我一样的问题。

阿里云的帮助文档中有这样一句话：

在19.03及之后的版本，docker在swarm init之上增加了–data-path-port uint32 的配置项用于更改docker swarm的VXLAN端口。
修改端口之后成功解决问题

查看docker日志（journalctl -u docker -n 20 -f ）发现 ：

出现这个原因是因为宿主机没有加载ip_vs模块。在各个节点加载ip_vs模块后重启docker即可。

Docker swarm中的LB和服务发现详解

参考技术A

Docker 提供了 overlay driver，使用户可以创建基于 VxLAN 的 overlay 网络。VxLAN 可将二层数据封装到 UDP 进行传输，VxLAN 提供与 VLAN 相同的以太网二层服务，但是拥有更强的扩展性和灵活性。linux下是使用了net namespace来隔离docker创建的overlay网络。

Docker 网络模型如下：

一个Sandbox包含了一个容器网络栈的配置。其中包括了对容器的网卡，路由表以及对DNS设置的管理。通常，一个Sandbox的实现可以是一个Linux Network Namespace，一个FreeBSD Jail或者其他类似的东西。一个Sandbox可以包含多个处于不同Network的Endpoint。

Endpoint将一个Sandbox加入一个Network。Endpoint的实现可以是一个veth对，一个Open vSwitch internal port或者其他类似的东西。一个Endpoint只能属于一个Network和一个Sandbox。

Network是一个能够互相通信的Endpoint的集合。Network的实现可以是一个Linux网桥，一个VLAN等等。

上图展示了task1.client请求两个不同资源dns返回的不同结果

环境：
swarm-a(manager node)：10.10.8.92

swarm-b(work node)：10.10.8.93

swarm-c(work node)：10.10.8.94

在docker swarm集群创建的开始，docker 会给每台host创建除了docker0以外的两个网络，分是bridge类型(docker_gwbridge网桥)和overlay类型(ingress)的网络，以及一个过度的命名空间ingress_sbox，我们可以使用如下命令自建overlay网络，结果如下：

docker network create --driver overlay mynet （后续会有用到）

注意1：要是想看到容器创建的两个Net Namespace需要执行
ln -s /var/run/docker/netns /var/run/netns

1)、部署一个service使用默认的ingress网络：

docker service create --name web_ingress_lb --replicas=2 --publish 8090:80 httpd

2)、Ingress Load Balancing实现方式：

这样一来即使容器的副本没有落到host上我们仍可以通过这种转发方式来访问到服务。这应该就是routing mesh吧！

1)、部署一个service使用我们自己创建的mynet网络：

docker service create --name web_mynet --replicas=2 --network=mynet --publish 8080:80 httpd
部署的两个容器分别处在a和c节点上：

结合例子如下：

2)、查看web_mynet.1容器和mynet网络命名空间的网卡情况：

3)、查看web_mynet.1容器和ingress\\ingress_sbox网络命名空间的网卡对应情况：

可以看mynet网络下vlan-id 为4097，ingress网络空间同样操作可以得到vlan-id为4096

swarm-c节点上的情况也是差不多就不操作了，好了我们来画下网络连接的大致图：

可以看到这里ingress_sbox和创建容器的ns共用一个ingress网络空间。

4)、 Internal Load Balancing实现方式：

有两种实现方式dns rr和vip形式，在dns rr 的情况下可能会存在一定是的问题，当容器重启后dns的解析会存在一定时间的延迟。vip则是由vip+内核ipvs来实现。docker swarm默认使用的是vip，这里就以vip的形式来解析。（想要了解dns rr的可以看文章后面的参考链接都是大牛写的）

VIP形式下的流量路径：

操作流程如下：
通过busybox服务做dns解析，可以发现该服务后端挂载的容器和该服务对应的
VIP地址。web_mynet服务对应的VIP为10.0.0.6。

在Internal Load Balancing也就是文中我们自建的mynet overlay网络中，我们会看到创
建的service会同时应用到两个网络环境里面去，为何要这样呢？

原因是swarm自带ingress不具备有服务发现的功能，而容器的生命周期又是不固定的，
service每次的消亡和启用都会改变容器内部的ip地址以及vip地址，那么集群中服务之间
的通信势必会造成问题，这里有人会说，要使多个service之间能够互相通信可以将所有
的service都publish出去，然后通过routing mesh 访问，这样是没错也能行得通，但是存
在一个缺点，那就是不安全，我们仅仅只需要的是将最终提供服务的端口publish即可。
那么不publish所有的service需要做到以下几点：

这里我理解的是ingress是单单提供LB实现routing mesh而mynet是服务发现和LB的结合

所以上文中Internal Load Balancing中的数据流应该分成两种情景如下：

1、当一个外部请求到主机端口8080之后， 数据包的流向如下所示：
主机端口8080 => Ingress-sbox-VIP:8080 => 容器Ingress-sbox => IPVS分发到containers。

2、处于 同mynet网络的service内部通信时：
处于 同mynet网络的test service(busybox容器)发起访问web_mynet域名的请求=>请求转发到docker engine内置的DNS解析web_mynet的vip=>web_mynet(容器)在其ns中将
VIP数据包打上标签，并通过ipvs来负载到后端对应的容器=>数据包通过vip地址路由到
mynet的ns，由mynet中的fdb来做转发走tunnel出去。

https://zhuanlan.zhihu.com/p/25954203

https://www.jianshu.com/p/4433f4c70cf0

https://docs.docker.com/network/overlay/

http://julyerr.club/2018/03/20/docker-swarm/