Docker网络管理（bridge、docker自定义网络以及Flannel方案）-笔记4

时间 2019-11-08

标签 docker 网络管理 bridge 自定义网络以及 flannel 方案笔记栏目 Docker 繁體版

原文原文链接

一、容器内部通讯python

Docker容器和服务如此强大的缘由之一是在经过网络能够将它们链接在一块儿，或者将它们链接到非Docker工做负载。Docker容器和服务甚至不须要知道它们部署在Docker上，或者它们的对等体是否也是Docker工做负载。linux

Docker的网络子系统是可插拔的，使用驱动程序。默认状况下存在多个驱动程序，并提供核心网络功能：nginx

bridge：默认网络驱动程序。当你的应用程序在须要通讯的独立容器中运行时，一般会使用桥接网络。
host：对于独立容器，删除容器和Docker主机之间的网络隔离，并直接使用主机的网络。
container：能够多个容器共用一个网络。
overlay：覆盖网络将多个Docker守护程序链接在一块儿，并使群集服务可以相互通讯。还可使用覆盖网络来促进群集服务和独立容器之间的通讯，或者在不一样Docker守护程序上的两个独立容器之间进行通讯。
macvlan：Macvlan网络容许您为容器分配MAC地址，使其显示为网络上的物理设备。Docker守护程序经过其MAC地址将流量路由到容器。macvlan 在处理指望直接链接到物理网络的传统应用程序时，使用驱动程序有时是最佳选择，而不是经过Docker主机的网络堆叠进行路由。
none：对于此容器，禁用全部网络。
network plugins：使用Docker安装和使用第三方网络插件。这些插件可从Docker Store或第三方供应商处得到。

bridge网络docker

如图，默认docker主机会存在三种类型的网络。centos

如图，docker主机会有一个默认使用的桥接网卡bridge0，它是在运行docker容器时，若是不指定网络，默认使用的网络。网络

当运行一个容器时，咱们能够看到在docker主机上多了一个网卡，并且master指向docker0架构

这时候咱们在查看该容器的网络信息（ip地址和网关）。发现它的ip地址和docker0一个网段，网关则是docker0的地址
ide

bridge网络的特色
工具

使用一个 linux bridge，默认为 docker0
使用veth 对，一头在容器的网络 namespace中，一头在docker0上
该模式下Docker Container不具备一个公有IP，由于宿主机的IP地址与veth pair的IP地址不在同一个网段内
Docker采用NAT方式，将容器内部的服务监听的端口与宿主机的某一个端口进行“绑定”，使得宿主机之外的世界能够主动将网络报文发送至容器内部
外界访问容器内的服务时，须要访问宿主机的 IP 以及宿主机的端口 port
NAT 模式因为是在三层网络上的实现手段，故确定会影响网络的传输效率。
容器拥有独立、隔离的网络栈；让容器和宿主机之外的世界经过NAT创建通讯

咱们查看iptables的nat表，能够看到，在POSTROUTING链上作了一个MASQUERADE，源是172.17.0.0/16，目标是全部网段。这样的转换后，容器就能够经过SNAT访问到外网实现通讯了。oop

host网络

Host模式并无为容器建立一个隔离的网络环境。该模式下的Docker容器会和host宿主机共享同一个网络namespace，因此容器能够和宿主机同样，使用宿主机的eth0，实现和外界的通讯。

特色：

这种模式下的容器没有隔离的network namespace
容器的IP地址同 Docker主机的IP地址
须要注意容器中服务的端口号不能与Docker主机上已经使用的端口号相冲突
host模式可以和其它模式共存

首先我经过ss查看一下，个人docker主机80端口并无使用。当我启动一个提供nginx应用的容器时，在查看发现个人主机使用了80端口。

咱们还能够经过docker inspect nginx001查看它的网络信息。发现IP地址和网关处根本没有值。由于使用了host网络，它是共用了docker主机的网络。

None模式

网络模式为 none，即不为Docker容器构造任何网络环境，不会为容器建立网络接口，一旦Docker容器采用了none网络模式，那么容器内部就只能使用loop back网络设备，不会再有其余的网络资源。

Container共享模式

这个模式指定新建立的容器和已经存在的一个容器共享一个 Network Namespace，而不是和宿主机共享。新建立的容器不会建立本身的网卡，配置本身的 IP，而是和一个指定的容器共享 IP、端口范围等。一样，两个容器除了网络方面，其余的如文件系统、进程列表等仍是隔离的。两个容器的进程能够经过 lo 网卡设备通讯

首先我运行一个容器，执行ip a查看到ip地址为172.17.0.2。

再运行一个容器，指定network类型为container，共享centos01的网络。

链接centos02，查看ip地址。发现centos02和centos01的地址是同样的。

二、外部网络访问容器内应用

-P随机指定一个docker主机端口给容器中的端口作映射

-p将docker主机的一个端口映射容器的一个端口

访问网站测试（个人docker主机的地址为192.168.44.131，记住要在docker主机上放行32768和8000端口）

首先访问32768端口

访问8000端口。（均可以正常提供服务）

三、用户自定义网络

经过docker network create --driver network_type network_name命令便可建立自定义网络。其中--driver后面支持的类型有三种：bridge、macvlan、overlay。

经过docker network inspect network_name能够查看该网络的信息

[root@docker001 ~]# docker network inspect my_bridge 
[
    {
        "Name": "my_bridge",
        "Id": "897ea2a24517f23144b0deab471ceefc6ee910840d2631d9429305036de075c6",
        "Created": "2018-08-19T15:16:25.49887066+08:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "172.19.0.0/16",
                    "Gateway": "172.19.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {},
        "Options": {},
        "Labels": {}
    }
]

并且经过ip addr能够看到自动在docker主机上建立了一个网卡。

再次查看咱们nat表，也能够看到在POSTROUTING上作的MASQUERADE

这样咱们就能够运行容器使用该网络了。

四、docker network管理命令的使用

分别以下。

显示一个网络的信息（只截取了一部分）

五、跨主机docker容器通讯方案介绍

基于实现方式的分类

隧道方案（Overlay Networking）：
Weave：UDP广播，本机创建新的BR，经过PCAP互通。
Open vSwitch(OVS)：基于VxLAN和GRE协议，可是性能方面损失比较严重。
Flannel：UDP广播，VxLan。

路由方案：
Calico：基于BGP协议的路由方案，支持很细致的ACL控制，对混合云亲和度比较
高。
Macvlan：从逻辑和Kernel层来看隔离性和性能最优的方案，基于二层隔离，因此
须要二层路由器支持，大多数云服务商不支持，因此混合云上比较难以实现。

基于网络模型分类

Docker Libnetwork Container Network Model(CNM)：
Docker Swarm overlay
Macvlan & IP network drivers
Calico
Contiv（from Cisco）
##Docker Libnetwork的优点就是原生，并且和Docker容器生命周期结合紧密；缺点也能够理解为是原生，被Docker“绑架”。

Container Network Interface(CNI)：
Kubernetes
Weave
Macvlan
Flannel
Calico
Contiv
Mesos CNI
##CNI的优点是兼容其余容器技术(e.g. rkt)及上层编排系统(Kuberneres & Mesos)，并且社区活
跃势头迅猛，Kubernetes加上CoreOS主推；缺点是非Docker原生。

详解：

以Flannel方案为例

Flannel以前的名字是Rudder，它是由CoreOS团队针对Kubernetes设计的一个重载网络工具，它的主要思路是：预先留出一个网段，每一个主机使用其中一部分，而后每一个容器被分配不一样的ip；让全部的容器认为你们在同一个直连的网络，底层经过UDP/VxLAN等进行报文的封装和转发

下面这张是Flannel网络的经典架构图（从网上找的）

1. 容器直接使用目标容器的ip访问，默认经过容器内部的eth0发送出去。 
2. 报文经过veth pair被发送到vethXXX。 
3. vethXXX是直接链接到虚拟交换机docker0的，报文经过虚拟bridge docker0发送出去。 
4. 查找路由表，外部容器ip的报文都会转发到flannel0虚拟网卡，这是一个P2P的虚拟网卡，而后报文就被转发到监听在另外一端的flanneld。 
5. flanneld经过etcd维护了各个节点之间的路由表，把原来的报文UDP封装一层，经过配置的iface发送出去。 
6. 报文经过主机之间的网络找到目标主机。 
7. 报文继续往上，到传输层，交给监听在8285端口的flanneld程序处理。 
8. 数据被解包，而后发送给flannel0虚拟网卡。 
9. 查找路由表，发现对应容器的报文要交给docker0。 
10. docker0找到连到本身的容器，把报文发送过去。