精华内容
下载资源
问答
  • 容器网络

    2017-11-09 15:05:44
    1:不同的容器共享同一host的内核协议栈;...3:创建容器的时候,会生成一对veth对,其中一个挂载host的default网络空间,一个挂载容器内的网络空间;4:容器网络空间与host的default网络空间通过bridge连接起来;...

    1:不同的容器共享同一host的内核协议栈;

    2:不同的容器,拥有各自独立的网络命令空间;

    3:创建容器的时候,会生成一对veth对,其中一个挂载host的default网络空间,一个挂载容器内的网络空间;

    4:容器的网络空间与host的default网络空间通过bridge连接起来;



    展开全文
  • Docker 容器技术 — 容器网络

    千次阅读 多人点赞 2020-10-02 10:39:47
    文章目录目录容器网络容器网络类型bridge 模式host 模式Container 模式none 模式容器端口映射容器跨主机通信 容器网络 容器网络类型 Docker 提供几种类型的网络,它决定容器之间、容器与外界之前的通信方式。 查看...

    目录

    容器网络的发展趋势

    在这里插入图片描述

    CNI

    CNI(Container Network Interface,容器网络接口)是 Google 和 CoreOS 主导制定的容器网络标准,它是在 RKT 网络提议的基础上发展起来的,综合考虑了灵活性、扩展性、IP 分配、多网卡等因素。

    CNI 旨在为容器平台提供网络的标准化,不同的容器平台(e.g. Kubernetes、Mesos 和 RKT)能够通过相同的接口调用不同的网络组件。这个协议连接了两个组件:

    1. 容器管理系统
    2. 网络插件

    具体的事情都是插件来实现的,包括:创建容器网络空间(network namespace)、把网络接口(interface)放到对应的网络空间、给网络接口分配 IP 等。

    目前采用 CNI 提供的方案一般分为两种

    1. 隧道方案
    2. 路由方案

    具体为:Flannel,Callico,Weave 和 macvlan 网络方案。从难易度上来讲,Callico 最简单,其次 Flannel,Weave 最复杂,从网络技术来看,Weave 和 Flannel 都是网络封装隧道技术,区别在于封装的位置在网络设备上还是主机上。

    在这里插入图片描述

    Flannel

    在这里插入图片描述

    Flannel 是 CoreOS 提出用于解决容器集群跨主机通讯的网络解决方案。Flannel 实质上是一种 Overlay 网络,也就是将 TCP 数据包装在另一种网络包里面进行路由转发和通信,目前已支持 UDP、VXLAN、AWS VPC、GCE 路由等数据转发方式,其中以 VXLAN 技术最为流行,很多数据中心在考虑引入容器时,也考虑将网络切换到 Flannel 的 VXLAN 网络中来。

    Flannel 为每个主机分配一个 Subnet,容器从此 Subnet 中分配 IP,这些 IP 可在主机间路由,容器间无需 NAT 和端口映射就可以跨主机通讯。Flannel 让集群中不同节点主机创建容器时都具有全集群唯一虚拟 IP 地址,并连通主机节点网络。Flannel 可为集群中所有节点重新规划 IP 地址使用规则,从而使得不同节点上的容器能够获得 “同属一个内网” 且 “不重复的” 的 IP 地址,让不同节点上的容器能够直接通过内网 IP 通信,网络封装部分对容器是不可见的。源主机服务将原本数据内容 UDP 封装后根据自己的路由表投递给目的节点,数据到达以后被解包,然后直接进入目的节点虚拟网卡,然后直接达到目的主机容器虚拟网卡,实现网络通信目的。

    Flannel 虽然对网络要求较高,要引入封装技术,转发效率也受到影响,但是却可以平滑过渡到 SDN 网络,VXLAN 技术可以和 SDN 很好地结合起来,值得整个网络实现自动化部署,智能化运维和管理,较适合于新建数据中心网络部署。

    Callico

    在这里插入图片描述

    Callico 容器网络和其他虚拟网络最大的不同是:它没有采用 Overlay 网络做报文转发,提供了纯三层网络模型。三层通信模型表示每个容器都通过 IP 直接通信,要想路由工作能够正常,每个容器所在的主机节点必须有某种方法知道整个集群的路由信息,Callico 采用 BGP 路由协议,使得全网所有的 Node 和网络设备都记录到全网路由。

    然而这种方式会产生很多的无效路由,对网络设备路由规格要求较大,整网不能有路由规格低的设备。另外,Callico 实现了从源容器经过源宿主机,经过数据中心路由,然后到达目的宿主机,最后分配到目的容器,整个过程中始终都是根据 BGP 协议进行路由转发,并没有进行封包,解包过程,这样转发效率就会快得多,这是 Callico 容器网络的技术优势。

    Weave

    在这里插入图片描述

    Weave 实质上也是 Overlay 网络,Weave 可以把不同主机上容器互相连接的网络虚拟成一个类似于本地网络的网络,不同主机之间都使用自己的私有 IP 地址,当容器分布在多个不同的主机上时,通过 Weave 可以简化这些容器之间的通信。

    Weave 网络中的容器使用标准的端口提供服务(e.g. MySQL 默认使用 3306),管理微服务是十分直接简单的。每个容器都可以通过域名来与另外的容器通信,也可以直接通信而无需使用 NAT,也不需要使用端口映射或者复杂的联接。

    部署 Weave 容器网络最大的好处是无需修改你的应用代码。Weave 通过在容器集群的每个主机上启动虚拟路由器,将主机作为路由器,形成互联互通的网络拓扑,在此基础上,实现容器的跨主机通信。

    要部署 Weave 需要确保主机 Linux 内核版本在 3.8 以上,Docker1.10 以上,主机间访问如果有防火墙,则防火墙必须彼此放行 TCP 6783 和 UDP 6783/6784 这些端口号,这些是 Weave 控制和数据端口,主机名不能相同,Weave 要通过主机名识别子网。

    Weave 网络类似于主机 Overlay 技术,直接在主机上进行报文流量的封装,从而实现主机到主机的跨 Underlay 三层网络的互访,这是和 Flannel 网络的最大区别,Flannel 是一种网络 Overlay 方案。

    Macvlan

    Macvlan 是 Linux Kernel 比较新的特性,允许在主机的一个网络接口上配置多个虚拟的网络接口,这些网络 interface 有自己独立的 MAC 地址,也可以配置上 IP 地址进行通信。macvlan 下的虚拟机或者容器网络和主机在同一个网段中,共享同一个广播域。macvlan 和 bridge 比较相似,但因为它省去了 bridge 的存在,所以配置和调试起来比较简单,而且效率也相对高。除此之外,macvlan 自身也完美支持 VLAN。

    ServiceMesh + CNI

    在这里插入图片描述

    ServiceMesh 和 CNI 是组合的关系,ServiceMesh 并不会替代 CNI,他们工作在不同的 SDN 层次,CNI 更多工作在 L2-4 层,ServiceMesh 在 L5-7 层 Application SDN。ServiceMesh 不能独立于 CNI 部署,与 CNI 一起提供层次化微服务应用所需要的网络服务。根据 Gartner 报告指出,在 2020 年,几乎 100% 容器云都将内置 ServiceMesh 技术。而目前开源的Istio 仅提供单一 Kubernetes 集群内部微服务治理,缺失异构容器云,跨云能力。

    CNI 需要交付给容器云 L2-4 层细化至微服务内部的每个 POD 容器。应用终端交付所需要的 L2 网络连接,L3 路由,L2-4 层安全隔离,容器云整体安全,负载均衡等。

    ServiceMesh 更多的致力于微服务应用层面的服务治理,致力于 L5-7 层网络服务,服务网格在每一个应用容器前部署一个 Sidecar Envoy 应用代理,提供微服务间的智能路由,分布式负载均衡,流量管理,蓝绿,金丝雀发布,微服务弹性,限流熔断,超时重试,微服务间的可视化,安全等等。
    ·

    Docker 容器网络

    Docker 提供几种类型的网络,它决定容器之间、容器与外界之前的通信方式。

    • 基础网络类型
      在这里插入图片描述

    • 查看所有容器网络类型:

    $ docker network ls
    NETWORK ID          NAME                DRIVER              SCOPE
    c79756cf9cde        bridge              bridge              local
    204025a5abbc        host                host                local
    9b9024f5ac40        macvlan             macvlan             local
    6478888548d8        none                null                local
    p2e02u1zhn8x        overlay             overlay             swarm
    

    bridge 模式

    bridge 模式的 Docker 网络基于 Linux 的虚拟网络技术来实现。Docker Container 的网络接口默认都是虚拟接口,可以充分发挥数据在不同 Container 之间或跨主机的 Container 之间的转发效率。这是因为 Linux 虚拟网络技术通过在内核中的数据复制来实现虚拟接口之间的数据转发,即:发送接口的发送缓存中的数据包将被直接复制到接收接口的接收缓存中,而无需通过外部物理网络设备进行交换。

    当 Docker Daemon 启动后,会在宿主机上创建一个名为 docker0 的 Linux Bridge,在此宿主机上启动的 Docker Container 都会连接到这个虚拟网桥上。Docker Daemon 会从 docker0(一个虚拟的 L2 网络)子网中分配一个 IP 给 Container 使用,并设置 docker0 的 IP 地址为 Container 的默认网关。同时,在宿主机上创建一对 veth pair 虚拟网线设备,Docker Daemon 将 veth pair 设备的一端插入新建的 Container 中,并命名为eth0(容器的网卡),另一端插入 docker0 Linux Bridge 中,以 vethxxx 格式命名。

    在这个网络的容器之间可以相互通信,外界想要访问到这个网络中的 Containers 也同样需要接入 bridge 网络并通过 iptables 做了 DNAT 规则,实现内外部地址转换。

    在这里插入图片描述

    $ ip a
    3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
        link/ether 02:42:46:c3:00:eb brd ff:ff:ff:ff:ff:ff
        inet 172.17.0.1/16 scope global docker0
           valid_lft forever preferred_lft forever
        inet6 fe80::42:46ff:fec3:eb/64 scope link
           valid_lft forever preferred_lft forever
    
    $ docker run -itd --name box1 busybox
    
    $ docker exec -it box1 sh
    
    / # ip a
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        inet 127.0.0.1/8 scope host lo
           valid_lft forever preferred_lft forever
        inet6 ::1/128 scope host
           valid_lft forever preferred_lft forever
    6: eth0@if7: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
        link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
        inet 172.17.0.2/16 scope global eth0
           valid_lft forever preferred_lft forever
        inet6 fe80::42:acff:fe11:2/64 scope link
           valid_lft forever preferred_lft forever
    
    / # ip r
    default via 172.17.0.1 dev eth0
    172.17.0.0/16 dev eth0 scope link  src 172.17.0.2
    
    $ brctl show
    bridge name	bridge id		STP enabled	interfaces
    docker0		8000.024246c300eb	no		vethd4ae072
    

    host 模式

    如果启动 Container 的时候使用 host 模式,那么这个容器将不会获得一个独立的 Network Namespace,而是和宿主机共用一个 Network Namespace。也就是说 Container 不会虚拟出自己的网卡,配置自己的 IP 等,而是直接使用宿主机的 IP 和端口。

    当然,Container 的其他方面,如:文件系统、进程列表等还是和宿主机隔离的。只用这种网络的容器会使用主机的网络,这种网络对外界是完全开放的,能够访问到主机,就能访问到容器。

    $ docker run -itd --network host --name box2 busybox
    
    $ docker exec -it box2 sh
    
    / # ip a
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        inet 127.0.0.1/8 scope host lo
           valid_lft forever preferred_lft forever
        inet6 ::1/128 scope host
           valid_lft forever preferred_lft forever
    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
        link/ether fa:16:3e:94:84:10 brd ff:ff:ff:ff:ff:ff
        inet 172.18.22.204/24 brd 172.18.22.255 scope global dynamic eth0
           valid_lft 48054sec preferred_lft 48054sec
        inet6 fe80::f816:3eff:fe94:8410/64 scope link
           valid_lft forever preferred_lft forever
    3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
        link/ether 02:42:46:c3:00:eb brd ff:ff:ff:ff:ff:ff
        inet 172.17.0.1/16 scope global docker0
           valid_lft forever preferred_lft forever
        inet6 fe80::42:46ff:fec3:eb/64 scope link
           valid_lft forever preferred_lft forever
    7: vethd4ae072@if6: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue master docker0
        link/ether ce:95:19:64:d0:d4 brd ff:ff:ff:ff:ff:ff
        inet6 fe80::cc95:19ff:fe64:d0d4/64 scope link
           valid_lft forever preferred_lft forever
    

    macvlan 模式

    对于某些应用程序,比如需要监视网络流量,期望直接连接到物理网络,这种情况下,可以使用 macvlan 的网络模式,macvlan 驱动程序不仅将 IP 地址分配给容器,而且还将物理 MAC 地址分配给容器。通过 macvlan 还可以实现跨主机容器之前的通信。

    1. 创建一个 macvlan 网络:
    docker network create -d macvlan --subnet=172.16.86.0/24 --gateway=172.16.86.1 -o parent=eth0 macvlan1
    
    1. 设置网卡为混杂模式:
    ip link set eth0 promisc on
    
    1. 创建使用 macvlan 网络的容器:
    docker run -it --network macvlan1  --ip=172.16.86.2 busybox /bash
    

    Container 模式

    Container 模式,又称为 Docker links,是一种 Docker Container 之间的通信机制。如果一个新容器链接到一个已有容器,新容器将会通过环境变量获得已有容器的链接信息。通过提供给信任容器有关已有容器的链接信息,实现容器间的通信。

    Container 模式和 host 模式很类似,只是 Container 模式创建容器共享的是其他容器的 IP 和 Port 而不是物理机的,此模式容器自身是不会配置网络和端口,创建此模式的容器进去后会发现里边的 IP 是你所指定的那个容器 IP 并且 Port 也是共享的。当然,其它还是互相隔离的,如进程等。

    docker run -it --network container:<container ID>
    

    在这里插入图片描述

    none 模式

    使用 none 模式 Container 会拥有自己的 Network Namespace,但是,并不为 Container 进行任何网络配置。也就是说,这个 Container 不会具有网卡、IP、路由等信息。需要手动的为 Container 添加网卡、配置 IP 等。使用此种网络的容器会完全隔离。

    使用的 none 模式后,这个容器就是封闭的,不会去参与网络通信,这样就能够保证容器的安全性。

    $ docker run -itd --network none --name box3 busybox
    
    $ docker exec -it box3 sh
    
    / # ip a
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        inet 127.0.0.1/8 scope host lo
           valid_lft forever preferred_lft forever
        inet6 ::1/128 scope host
           valid_lft forever preferred_lft forever
    

    Overlay 模式

    Overlay 模式使用在 Swarm 集群中,用于连接跨主机 Docker Container,允许不同宿主机上的容器相互通信。Overlay 模式在 Docker 集群节点间加入了一层虚拟网络,它有独立的虚拟网段,因此 Container 发送的内容,会先发送到虚拟子网,再由虚拟子网包装为宿主机的真实网址进行发送。

    在这里插入图片描述

    # 初始化 manager node。
    $ docker swarm init
    
    # 添加 worker node 到 manager。
    $ docker swarm join --token <token> <manager_host>:2377
    
    # 新建一个 Overlay 网络
    $ docker network create --driver=overlay --attachable overlay
    
    # 分别在不同的 worker node 上启动一个 busybox 容器,并连接到 Overlay 网络
    $ docker run -it --network overlay --name box4 sh
    

    如此的,在同一个 Overlay 网络上的跨主机 Container 就可以互相通信了。

    基于 Swarm 我们还可以管理 Containers 集群服务,例如:创建一个具有五副本的连接到 Overlay 网络的 Nginx Cluster,暴露端口为 80:

    $ docker service create --name my-nginx --publish target=80,published=80 --replicas=5 --network overlay nginx
    

    在这个 Nginx Cluster 中,如果任一节点结束一个副本,那么集群服务就会重启一个新的副本,以此保持所有 Worker Node 中的 Nginx 副本数量为五个。

    容器端口映射

    核心选项:

    • -p 宿主机端口:将容器内应用监听端口映射到物理宿主机的特定端口上。

    示例:

    • 自定义映射:
    docker run -d -p 8888:80  nginx:latest 
    

    在这里插入图片描述

    • 随机映射
    # 需要镜像支持
    docker run -P
    
    展开全文
  • Flannel容器网络方案 Flannel共有三个容器网络方案:Flannel UDP、Flannel VXLAN旧和Flannel VXLAN新。 Flannel UDP方案 Flannel UDP数据面如下: 同节点容器通信 容器A访问容器B,数据面流程如下: 容器A和容器B...

    Flannel容器网络方案

    Flannel共有三个容器网络方案:Flannel UDP、Flannel VXLAN旧和Flannel VXLAN新。

    Flannel UDP方案

    Flannel UDP数据面如下:
    在这里插入图片描述

    同节点容器通信

    容器A访问容器B,数据面流程如下:

    1. 容器A和容器B在相同网络,直接发送
    2. 容器A向容器B发送ARP请求,br0交换机flood该ARP请求
    3. 容器B接收到ARP请求,并响应
    4. br0交换机flood该ARP响应
    5. 容器A接收到ARP响应,封装二层报文并发出
    6. br0交换机直接转发报文到容器B
    7. 容器B接收到报文

    跨节点容器通信

    容器A访问容器D,数据面流程如下:

    1. 容器A和容器D在不同网络,通过网关转发
    2. 容器A发送ARP请求给网关(10.10.1.1)
    3. 节点1内核响应ARP请求,并发送到br0口
    4. br0交换机转发ARP响应给容器A
    5. 容器A收到ARP请求,封装二层报文(目的MAC为网关的MAC),并发出报文
    6. 报文通过veth设备到达br0,并通过br0接口上送至节点内核
    7. Host1内核根据报文目的IP地址,判断需要路由转发,查找路由表并匹配,通过tunX设备直接送达
    8. Host1内核发送ARP请求给容器D,并发送到tunX设备上
    9. flanneld创建了tunX设备的socket,flanned收到ARP请求报文
    10. flanneld响应ARP请求,并通过tunX socket发送ARP响应,该响应报文会被tunX设备接收并进入协议栈
    11. Host1内核收到ARP响应后,修改报文二层头,并发送给tunXX设备
    12. flanneld收到该报文,并根据拓扑信息,把该报文封装在UDP中,flanneld发送UDP报文给Host2
    13. Host2接收到UDP报文,经过协议栈上送给flanneld进程
    14. flanneld解封外层报文,并把内层报文通过tunXX设备发送给内核
    15. Host2内核根据报文的目的IP地址,查找路由,发现通过br0可以直达
    16. Host2内核发送ARP请求给容器D,并发送给br0接口
    17. br0交换机转发ARP请求给容器D,容器D响应ARP请求,ARP响应通过br0接口上送到协议栈
    18. Host2内核更新报文的二层头,并发送报文到br0接口
    19. br0交换机转发报文给容器D
    20. 容器D接收到报文

    flanneld接收到ARP请求后如何响应,有两种做法:

    • 以对端tunXX设备的MAC地址响应
    • 固定tunXX设备的MAC地址,并且以该地址来响应

    Flannel UDP方案总结

    • 网络性能差
      • 使用socket机制报文转发过程中,会从内核态切换到用户态;
      • 对数据进行了外层封装,内核对UDP封装没有优化;
    • 可以支持数据加密
      • flanneld可以做很多定制化的工作,容易扩展

    Flannel VXLAN旧版方案

    Flannel VXLAN旧版数据面如下:
    在这里插入图片描述

    同节点容器通信

    容器A访问容器B,数据面流程如下(同Flannel UDP):

    1. 容器A和容器B在相同网络,直接发送
    2. 容器A向容器B发送ARP请求,br0交换机flood该ARP请求
    3. 容器B接收到ARP请求,并响应
    4. br0交换机flood该ARP响应
    5. 容器A接收到ARP响应,封装二层报文并发出
    6. br0交换机直接转发报文到容器B
    7. 容器B接收到报文

    跨节点容器通信

    容器A访问容器D,数据面流程如下:

    1. 容器A和容器D在同一个网络
    2. 容器A直接发送ARP请求
    3. br0交换机flood ARP请求
    4. vxlan设备接收到ARP请求
    5. 由于vxlan设备配置了arp proxy,查找内核ARP表项,如果未找到,则上报L3MISS
    6. flanneld接收到L3MISS,根据拓扑信息向内核中添加ARP表项
    7. 容器A由于未收到ARP响应,将会再次发送ARP请求,此时vxlan设备能够响应该ARP请求(内核已添加该ARP表项)
    8. 容器A收到ARP响应,封装二层报文,并发送
    9. br0转发该报文到vxlan端口
    10. vxlan封装外层vxlan头,udp头,IP头,mac头,其中目的IP需要根据内层报文目的MAC来获取
    11. vxlan设备在内核FDB转发表查找目的MAC的转发项,未找到,则上报L2MISS
    12. flanneld接收到L2MISS信息,根据拓扑信息,向内核中添加FDB表项
    13. 此报文未成功发送,容器A重发报文
    14. vxlan设备此时能够正确地封装外层报文,并发送报文
    15. Host2接收到报文,通过UDP Socket,并进入到VXLAN解包处理,最终作为vxlan设备收包处理,vxlan设备挂载到br0交换机
    16. br0交换机转发报文给容器D

    由于L3MISS和L2MISS何时上报与网上的文档刚好相反,代码是最有说服力的,如下是VXLAN设备处理ARP请求的代码片段:

    	n = neigh_lookup(&arp_tbl, &tip, dev);	//查找本地ARP表项
    
    	if (n) {
    		struct vxlan_fdb *f;
    		struct sk_buff	*reply;
    
    		......
    
    		if (netif_rx_ni(reply) == NET_RX_DROP)	
    			dev->stats.rx_dropped++;
    	} else if (vxlan->flags & VXLAN_F_L3MISS) {
    		union vxlan_addr ipa = {
    			.sin.sin_addr.s_addr = tip,
    			.sin.sin_family = AF_INET,
    		};
    
    		vxlan_ip_miss(dev, &ipa);
    	}
    

    如下代码是VXLAN设备封装外层IP头时,获取目的IP的代码片段:

    	f = vxlan_find_mac(vxlan, eth->h_dest);  //以目的mac查找FDB表
    	did_rsc = false;
    
    	if (f && (f->flags & NTF_ROUTER) && (vxlan->flags & VXLAN_F_RSC) &&
    	    (ntohs(eth->h_proto) == ETH_P_IP ||
    	     ntohs(eth->h_proto) == ETH_P_IPV6)) {
    		did_rsc = route_shortcircuit(dev, skb);
    		if (did_rsc)
    			f = vxlan_find_mac(vxlan, eth->h_dest);
    	}
    
    	if (f == NULL) {
    		f = vxlan_find_mac(vxlan, all_zeros_mac);  //以全零mac查找FDB表
    		if (f == NULL) {
    			if ((vxlan->flags & VXLAN_F_L2MISS) &&
    			    !is_multicast_ether_addr(eth->h_dest))
    				vxlan_fdb_miss(vxlan, eth->h_dest);	    //上报L2MISS
    
    			dev->stats.tx_dropped++;
    			kfree_skb(skb);
    			return NETDEV_TX_OK;
    		}
    	}
    

    Flannel VXLAN旧版方案总结

    • 采用L2MISS和L3MISS机制,首包将会被丢弃,严重影响首包的延时
    • L2MISS和L3MISS采用network link机制,性能低
    • 容器为大二层网络,不支持多个网络
    • 对节点网络无依赖(已经被封装到节点网络)
    • 仅需要一个vtep设备,通过FDB表确定目标vtep设备
    • 每个容器有一条ARP记录,大规模时节点上的ARP表项过多
    • FDB记录数与容器数量成正比,大规模时节点上的FDB表项过多

    Flannel VXLAN新版方案

    Flannel VXLAN新版数据面如下:
    在这里插入图片描述

    同节点容器通信

    容器A访问容器B,数据面流程如下(同Flannel UDP):

    1. 容器A和容器B在相同网络,直接发送
    2. 容器A向容器B发送ARP请求,br0交换机flood该ARP请求
    3. 容器B接收到ARP请求,并响应
    4. br0交换机flood该ARP响应
    5. 容器A接收到ARP响应,封装二层报文并发出
    6. br0交换机直接转发报文到容器B
    7. 容器B接收到报文

    跨节点容器通信

    容器A访问容器D,数据面流程如下:

    1. 容器A和容器D在不同网络,通过网关转发
    2. 容器A发送ARP请求给网关(10.10.1.1)
    3. 节点1内核响应ARP请求,并发送到br0接口
    4. br0交换机转发ARP响应给容器A
    5. 容器A收到ARP请求,封装二层报文(目的MAC为网关的MAC),并发出报文
    6. br0交换机转发报文给br0接口,并进入到协议栈
    7. Host1内核查找路由表,需要10.10.2.0转发,并且是通过vtep0设备
    8. Host1内核查找ARP表项,发现了10.10.2.0的MAC表项,直接封装二层报文,并发送到vtep0设备
    9. vtep0设备查找FDB表,发现10.10.2.0MAC的表项
    10. vtep0封装外层vxlan头,udp头,ip头,mac头(由于节点在同一个网络,mac可以通过ARP请求获取)
    11. vtep0发送报文
    12. Host2接收到报文,通过UDP Socket,并进入到VXLAN解包处理,最终以vtep0收包并进入到协议栈
    13. Host2内核查找路由表,发现通过br0可以直接到达
    14. Host2内核发送ARP请求给容器D,并发送给br0接口
    15. br0交换机转发ARP请求给容器D,容器D响应ARP请求,ARP响应通过br0接口上送到协议栈
    16. Host2收到ARP响应,修改报文的二层头,并发送到br0接口
    17. br0交换机转发报文给容器D
    18. 容器D接收到报文

    其中目的vtep设备的MAC地址,FDB表项都需要flanneld来预置

    Flannel VXLAN新版方案总结

    • 每个节点分配一个网络CIDR
    • 不支持创建容器时指定IP地址
    • 节点的路由表数量较少,和节点数成正比
    • 对节点网络无依赖(已经被封装到节点网络)
    • 每个节点仅需要一个vtep设备,通过FDB表确定目标vtep设备
    展开全文
  • Calico容器网络方案 Calico共有两个容器网络方案:Calico BGP和Calico IPIP。 Calico BGP方案 Calico BGP数据面如下: 同节点容器通信 容器A访问容器B,数据面流程如下: 容器A内的calic0设备的掩码长度为32,即与...

    Calico容器网络方案

    Calico共有两个容器网络方案:Calico BGP和Calico IPIP。

    Calico BGP方案

    Calico BGP数据面如下:
    在这里插入图片描述

    同节点容器通信

    容器A访问容器B,数据面流程如下:

    1. 容器A内的calic0设备的掩码长度为32,即与容器B属于不同网络,需要通过网关进行通信
    2. 容器A查找路由表,存在default路由,下一跳为169.254.1.1,且169.254.1.1可通过cali0直达
    3. 容器A发送ARP请求给169.254.1.1,ARP请求报文到达veth设备的另一端califXXX接收
    4. 由于califXXX设备使能了ARP proxy,Linux内核会以califXXX的MAC地址来响应ARP请求,并从califXXX发出;
    5. 容器A收到ARP响应后,得到169.254.1.1的MAC地址,封装二层报文,发送报文给169.254.1.1,报文从cali0设备发出
    6. 报文通过veth设备进入Host内核协议栈;
    7. 由于目的IP不在本节点,Host内核会进行报文转发(ip_forward已开启)
    8. Host内核超找路由表,发现路由条目,通过califYYYYYY设备可以直达
    9. Host内核发送ARP请求给容器B,通过califYYYYYY设备发出
    10. ARP请求报文通过veth设备到达容器B,容器B响应ARP请求,ARP响应通过veth设备到达Host内核
    11. Host内核更新报文的二层头,从califYYYYYY设备发出
    12. 报文通过veth设备到达容器B

    Host的本地路由在创建容器的时候就能够建立,不依赖BGP

    跨节点容器通信

    容器A访问容器D,数据面流程如下:

    1. 容器A内的calic0设备的掩码长度为32,即与容器B属于不同网络,需要通过网关进行通信
    2. 容器A查找路由表,存在default路由,下一跳为169.254.1.1,且169.254.1.1可通过cali0直达
    3. 容器A发送ARP请求给169.254.1.1,ARP请求报文到达veth设备的另一端califXXX接收
    4. 由于califXXX设备使能了ARP proxy,Linux内核会以califXXX的MAC地址来响应ARP请求,并从califXXX发出;
    5. 容器A收到ARP响应后,得到169.254.1.1的MAC地址,封装二层报文,发送报文给169.254.1.1,报文从cali0设备发出
    6. 报文通过veth设备进入Host1内核协议栈;
    7. 由于目的IP不在本节点,Host1内核会进行报文转发(ip_forward已开启)
    8. Host1内核查找路由表,发现路由条目,通过下一跳192.168.0.102(Host2)可以到达,而192.168.0.102可以直达
    9. Host1内核发送ARP请求给Host2,通过eth0设备发出
    10. ARP请求报文通过底层网络到达Host2,Host2响应ARP请求,通过底层网络到达Host1
    11. Host1内核修改报文二层头,发送报文给Host2
    12. Host2收包报文,由于目的IP不在本节点,Host2内核会进行报文转发(ip_forward已开启)
    13. Host2查找路由表,发现路由条目,通过califYYYYY设备可以直达
    14. Host2内核发送ARP请求给容器D,通过califYYYYY设备发出
    15. ARP请求报文通过veth设备到达容器D,容器B响应ARP请求,ARP响应通过veth设备到达Host2内核
    16. Host2内核更新报文的二层头,从califYYYYY设备发出
    17. 报文通过veth设备到达容器D

    Host1中关于容器D的路由信息是如何获取的? 这就是Calico BGP方案的核心,答案是通过BIRD在节点间同步得到

    Calico BGP数据面总结

    • 方案基本原理
      • 容器IP的掩码是32位,强制走三层转发
      • 同步各节点的路由信息,使所有节点掌握全局的网络转发规则
    • 方案优势
      • 方案不依赖底层网络,只要求底层三层能通即可
      • 支持按节点分配IP网段,同时还可以自定义容器IP(路由通过网络长度优先匹配)
    • 方案劣势
      • 本节点也需要通过路由转发,性能较差
      • 路由通过BIRD同步,属于异步同步方式,容器创建后立即通信可能存在路由未同步的风险
      • 在底层网络中暴露了容器网络地址
      • 当节点之间二层不可达时,需要在路由器上发布路由,否则容器之间无法通信
    • 改进想法
      • 避免169.254.1.1的ARP请求
        • 可以固定califXX设备的MAC地址
        • 容器内固化ARP表项
      • 使用etcd同步路由信息,去除对BGP的依赖

    Calico IPIP方案

    由于Calico BGP方案把容器网络暴露到了底层网络中, 而Calico IPIP方案把容器网络信息通过IP隧道屏蔽了,而且通过IPIP方案可以提供加密传输的功能,防止报文被窃听

    Calicao IPIP数据面如下:
    在这里插入图片描述

    同节点容器通信

    容器A访问容器B,数据面流程如下(同Calico BGP):

    1. 容器A内的calic0设备的掩码长度为32,即与容器B属于不同网络,需要通过网关进行通信
    2. 容器A查找路由表,存在default路由,下一跳为169.254.1.1,且169.254.1.1可通过cali0直达
    3. 容器A发送ARP请求给169.254.1.1,ARP请求报文到达veth设备的另一端califXXX接收
    4. 由于califXXX设备使能了ARP proxy,Linux内核会以califXXX的MAC地址来响应ARP请求,并从califXXX发出;
    5. 容器A收到ARP响应后,得到169.254.1.1的MAC地址,封装二层报文,发送报文给169.254.1.1,报文从cali0设备发出
    6. 报文通过veth设备进入Host内核协议栈;
    7. 由于目的IP不在本节点,Host内核会进行报文转发(ip_forward已开启)
    8. Host内核超找路由表,发现路由条目,通过califYYYYYY设备可以直达
    9. Host内核发送ARP请求给容器B,通过califYYYYYY设备发出
    10. ARP请求报文通过veth设备到达容器B,容器B响应ARP请求,ARP响应通过veth设备到达Host内核
    11. Host内核更新报文的二层头,从califYYYYYY设备发出
    12. 报文通过veth设备到达容器B

    Host的本地路由在创建容器的时候就能够建立,不依赖BGP

    跨节点容器通信

    容器A访问容器D,数据面流程如下:

    1. 容器A内的calic0设备的掩码长度为32,即与容器B属于不同网络,需要通过网关进行通信
    2. 容器A查找路由表,存在default路由,下一跳为169.254.1.1,且169.254.1.1可通过cali0直达
    3. 容器A发送ARP请求给169.254.1.1,ARP请求报文到达veth设备的另一端califXXX接收
    4. 由于califXXX设备使能了ARP proxy,Linux内核会以califXXX的MAC地址来响应ARP请求,并从califXXX发出;
    5. 容器A收到ARP响应后,得到169.254.1.1的MAC地址,封装二层报文,发送报文给169.254.1.1,报文从cali0设备发出
    6. 报文通过veth设备进入Host1内核协议栈;
    7. 由于目的IP不在本节点,Host1内核会进行报文转发(ip_forward已开启)
    8. Host1内核查找路由表,发现路由条目,通过下一跳192.168.0.102(Host2)可以到达,而192.168.0.102可以直达
    9. Host内核发送ARP请求给Host2,通过eth0设备发出
    10. ARP请求报文通过底层网络到达Host2,Host2响应ARP请求,通过底层网络到达Host1
    11. Host1内核发送报文给TUN10设备(因为IPIP是三层设备,不需要二层头,所以不会向192.168.0.102发送ARP请求)
    12. IPIP设备封装外层IP头(IPIP设备是端到端设备,创建时指定了对端)
    13. IPIP设备封装外层MAC头,并从eth0发出报文
    14. Host2接收到IPIP报文,交给ipip协议进行收包处理
    15. ipip协议处理完成后,最终进行ip_forward处理
    16. Host2查找路由表,发现路由条目,通过califYYYYY设备可以直达
    17. Host2内核发送ARP请求给容器D,通过califYYYYY设备发出
    18. ARP请求报文通过veth设备到达容器D,容器B响应ARP请求,ARP响应通过veth设备到达Host2内核
    19. Host2内核更新报文的二层头,从califYYYYY设备发出
    20. 报文通过veth设备到达容器D

    Calico IPIP数据面总结

    • 由于IPIP为管道设备,当节点数量增加时,IPIP设备也同步增加
      • 可以使用VXLAN设备来代替IPIP设备,但是性能有损失
    • 对节点外的设备,屏蔽了容器网络信息,对底层网络无依赖
    展开全文
  • docker容器网络

    2020-07-15 17:13:36
    docker容器网络docker容器网络docker容器网络docker的4种网络模式bridge模式container模式host模式none模式 docker容器网络 docker容器网络 Docker在安装后自动提供3种网络,可以使用docker network ls命令查看 ...
  • macvlan容器网络方案 macvlan是Linux自带的虚拟网卡,基于同一个底层网卡的macvlan设备会形成一个逻辑的交换机,提供交换能力,性能优化linux bridge。 macvlan方案 macvlan数据面如下: 同节点容器通信 容器A访问...
  • kubernetes容器网络

    2020-05-26 20:45:56
    而kubernetes本身并没有自己实现容器网络,而是通过插件化的方式自由接入进来。在容器网络接入进来需要满足如下基本原则: pod无论运行在任何节点都可以互相直接通信,而不需要借助NAT地址转换实现。 node与pod可以...
  • docker 容器网络2.1 docker 的分层存储2.2 docker 容器的读写过程2.3 容器网络 一. docker 容器的迁移处理 在业务的开发过程当中我们会面临,多个不同的系统或平台的环境统一的问题,比如本地开发的环境需要迁移到...
  • 文章目录背景知识容器网络论文内容摘要引言背景和动机容器网络容器网络挑战假设和威胁模型容器网络接口插件的限制BASTION设计BASTION MANAGER容器信息收集BASTION网络栈管理Network Visibility ServiceDirect ARP ...
  • docker容器网络更改

    千次阅读 2020-08-17 12:38:45
    由于粗心大意导致在创建容器时候把网络指定错了 如何在不删除容器的情况下更改容器网络呢 更改网络 ###解除容器绑定的网络 网络名词mynetwork 容器名称 lnmp [root@lnmp tp6cms]# docker network disconnect ...
  • Windows容器网络

    2017-09-20 14:00:00
    本文讲的是Windows容器网络,【编者的话】下面请允许我激动的介绍Windows容器以及微软和Docker的合作。我们团队投入大量资源研发出Windows Server Technical Preview 5容器网络堆栈,除借鉴Docker的管理经验外,还...
  • 容器网络性能分析

    千次阅读 2019-04-06 14:26:54
    文章目录译注摘要I 引言II 单机上的容器网络None mode桥接模式容器模式Host模式总结III 多机上的容器网络Host模式NAT模式Overlay网络Docker原生overlay网络WeaveFlannelCalicoRouting网络总结IV 容器网络的性能实验...
  • Docker容器网络

    千次阅读 2016-06-10 16:55:30
    Docker容器网络网络提供了容器间的完全的隔离,因此控制应用运行的网络很重要。 容器网络(Docker Container networks)就提供了这种控制。默认网络安装Docker时,它默认会创建三种网络:bridge、none、host。
  • 随着容器技术的成熟和普及,容器技术正在改变传统应用和软件开发与部署方式。相比传统技术,容器技术提供了更好的标准性、隔离性,对...容器网络分为单机容器网络和跨宿主机容器网络,下面从这两方面进行一下简单的...
  • docker 容器网络配置

    2019-12-15 02:19:04
    一、容器网络模型 容器网络实质上也是由 docker 为应用程序所创造的虚拟环境的一部分,它能让应用从宿主机操作系统的网络环境中独立出来,形成容器自有的网络设备、IP 协议栈、端口套接字、IP 路由表、防火墙等等与...
  • 容器网络相关知识

    2020-05-09 19:46:18
    容器化是目前的趋势,而容器网络是一块很重要的知识点,也是比较难的内容,涉及到底层的计算机网络等知识,之前实习的时候学过一点,现在整理一下。 a、docker的原生网络 docker提供三种原生网络,在安装的时候就会...
  • k8s网络-容器网络

    2018-02-28 16:14:47
    容器网络 pod每个POD分配单独的Ip地址,IP-pre-Pod模型(IP以Pod为单位进行分配的,一个Pod一个IP的设计模型)每个容器也可以称为pod,pod中有个pause容器,pause可以接入网络,并且共享网络给pod中其他容器,每个...
  • 需要明确的是,CNM和CNI只是容器网络的规范,并不是网络实现,它们只是容器网络的规范,从开发者的角度看,就是一堆接口,底层用Flannel也好,用Calico也罢,他们并不关心。 Kubernetes作为容器的编排框架,在网络...
  • docker网络详解一、docker网络概述二、docker原生...外部网络访问容器五、跨主机的容器网络macvlan网络方案的实现 一、docker网络概述 Docker作为目前最火的轻量级容器技术,牛逼的功能,如Docker的镜像管理,不足的
  • 随着容器技术的发展成熟,越来越多的组件迁移到容器,在技术迁移过程中,数据库,游戏,AI 这些组件对容器网络性能(时延,吞吐,稳定性)提出了更高的要求。为了得到更优的时延和吞吐表现,各大云厂商都在致力于...
  • docker 容器网络方案:calico 网络模型

    千次阅读 2018-12-11 21:13:53
    2017-10-19 / blog&nbsp;...docker 容器网络方案:calico 网络模型 ...calico 简介calico 是容器网络的又一种解决方案,和其他虚拟网络最大的不同是,它没有采用 overlay 网络做报文的转发,提供了纯 3 层的...
  • Docker容器网络通过网络名称空间隔离,之后会将名称空间 封闭容器 不创建任何网络设备,只有lo作为容器内部通信使用,无法与容器之外进行通信 桥接容器 默认的网络模型为桥接 桥接的时候,创建一对虚拟网络...
  • 理解Docker单机容器网络

    千次阅读 2017-11-26 10:40:35
    http://tonybai.com/2016/01/15/understanding-container-networking-on-single-host/一、目标Docker实质上是汇集了linux容器(各种... 其默认容器网络的建立和控制是一种结合了network namespace、iptables、l...
  • 使用 Docker 容器网络

    2017-06-27 15:14:53
    要构建具有安全的一致行为的 Web 应用程序,可以使用 Docker 网络特性。根据定义,网络为容器实现了完全隔离。因此,控制您的应用程序...Docker 容器网络为您提供了这种控制能力。 本文将概述 Docker 引擎交
  • 跨主机容器网络方案

    2018-11-27 12:10:35
    跨主机容器网络方案 在Kubernetes体系中,Kubernetes网络模型设计的一个基本原则:每个Pod都拥有一个独立的IP地址,而且假定所有的Pod都在一个可以直接联通的、扁平的网络空间中,不管他们是否运行在同一个Node(宿...
  • 如果你通过 Docker 提供的用户指南,你应该已经完成了构建你的第一...使用默认网络来运行一个容器Docker 能够支持通过network drivers来使用网络容器。在默认的情况下,Docker 为你提供了 2 个网络驱动:bridge和o...
  • 三种容器网络方案

    2017-10-12 15:09:00
    本文讲的是三种容器网络方案【编者的话】本文是TheNewStack容器电子书的一部分,着重介绍了容器的网络互联方案。有兴趣的同学可以关注下电子书。任何云端部署容器的关键之一是管理容器间的网络。在研究编写我们最新...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 20,330
精华内容 8,132
关键字:

容器网络