一个Docker附加参数引起的网络服务异常

《一个Docker附加参数引起的网络服务异常》要点：
本文介绍了一个Docker附加参数引起的网络服务异常，希望对您有用。如果有疑问，可以联系我们。

1.?事件

背景

事发在线上环境,OpenStack由容器化部署方案Kolla提供,各主要软件版本如下：

时间线

2017/3/17： 测试完成修复方案,上线更新；

2017/3/15： 找到root cause,确定触发场景,确定修复方案；

2017/3/14： 找到neutron产生无限多tap的场景2,能够在模拟条件下复现问题,与环境日志记录匹配；

2017/3/13： 找到neutron产生无限多tap的场景1,但对比环境日志并不完全匹配,而且模拟条件的出现概率非常低,排除；

……

2017/3/11

09:00:00： 在控制节点恢复网络服务(neutron-metadata-agent、neutron-dhcp-agent)；

08:00:00： 自动化脚本清理完成所有无效tap设备,控制节点成功启动neutron-*-agent,虚拟网络服务能力恢复；

……

2017/3/10

22:00:00： 运行脚本自动化清理控制节点的无效tap设备

21:30:00： 原控制节点所属(6台)虚拟机恢复访问在其他节点(nc05、nc03)恢复原控制节点的虚拟机

21:00:00： 环境更新包功能还原在其他节点(nc05)成功启动neutron-metadata-agent

20:30:00： 整体环境新建虚机分配网络还原在其他节点(nc05)成功启动?neutron-dhcp-agent

18:30:00： 放弃在控制节点还原网络服务,尝试在其他节点还原网络服务；

18:00:00： 尝试删除tap设备,但进度较慢；尝试在代码去掉neutron-openvsiwtch-agent中关于tap设备的预读过程,因涉及点太多放弃在线修改；

17:00:00： 发现控制节点存在10000+tap设备,link状态为DOWN(导致neutorn-openvswitch-agent启动失败) ；

16:40:00： 整体环境新建虚拟机分配网络失效,处理人忙乱之中再次重启neutron-dhcp-agent,发现循环错误,neutron-dhcp-agent重启失败；

16:30:00： 控制节点所属(6台)虚拟机网络失效怀疑是控制节点流表未刷新原因,开发同事尝试重启控制节点的neutron-openvsiwtch-agent刷新,但重启失败；

16:25:00： 开发开始定位处理开发同事检查虚拟机创建成功,但新建虚拟机无法获取neutron-metadata服务接口,导致业务集群配置失败；

16:10:00： 线上环境更新包功能失效项目维护同事反映培训环境更新业务应用集群失效；

2.?分析

2.1.不正常的循环

经过内部环境反复测试与现场日志对比,发现实际产生10000多个tap设备的循环位于neutron-dhcp-agent服务的定时同步功能函数中

下面这段整体逻辑由于一个设置namespace的异常而不断重试循环：

1)?Neutron-dhcp-agent循环监听是否存在更新需求(need_resunc_reasons)；

2)?每次循环延迟间隔conf.resync_interval秒；

3)?setup_dhcp_port()方法中申请一个新的Port(新的tapid产生)；

4)?add_veth()方法创建veth设备(新的tap设备产生)；

5)?ensure_namespace()方法中确认namespace,如不存在则创建；

6)?set_netns()方法设置tap设备的network namespace,设置失败；

7)?跳转到第一步循环；

可以看到,这段逻辑本身有一定缺陷

1)?设置namespace失败后,没有正确的try…catch流程删除之前创建的设备,导致失败的tap设备积累越来越多

2)?ensure_namespace()方法只检查namespace是否存在,没有深入检查namespace权限等可能导致后续设置失败的属性

接下来的问题是(可能也是neutron在最后一步不设防的原因)：namespace是neutron-dhcp-agent进程自身创建的,tap设备也是neutron-dhcp-agent进程自身创建的,为什么设置时会失败呢?

2.2.为什么没有权限

容器服务的隔离与共享

其中各容器共享主机的Network namespace,但每个容器具备非共享的Mount namespace；在各自独立的Mount namespace中,共享主机/run/netns目录,用于共享虚拟网络的network namespace操作入口.

Mount

而在Docker实现中,(共享)使用外部存储空间、数据卷功能都最终会依赖mount系统调用,代码片段：

Docker对附加传入的private、shared等不同属性的处理,实际对应执行mount系统调用时传入不同flags,不同的flags对应到不同的Mount Propagation Type：

MS_SHARED

This mount point shares mount and unmount events with other mount points that are members of its “peer group”. When a mount point is added or removed under this mount point,this change will propagate to the peer group,so that the mount or unmount will also take place under each of the peer mount points. Propagation also occurs in the reverse direction,so that mount and unmount events on a peer mount will also propagate to this mount point.

MS_PRIVATE

This is the converse of a shared mount point. The mount point does not propagate events to any peers,and does not receive propagation events from any peers.

MS_SLAVE

This propagation type sits midway between shared and private. A slave mount has a master—a shared peer group whose members propagate mount and unmount events to the slave mount. However,the slave mount does not propagate events to the master peer group.

MS_UNBINDABLE

（编辑：东莞站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!