精华内容
下载资源
问答
  • 本文试图从Kubernetes当中容器跨节点网络通信方案Flannel的实际应用场景出发,带领读者梳理Kubernetes当中容器跨节点网络通信的实现过程以及背后的实现原理。 |Kubernetes网络模型 通过上一篇文章《深入浅出K...

    曾记得有一位哲人说过:“在云计算当中,计算最基础,存储最重要,网络最复杂”,而PaaS云平台Kubernetes的出现也使得网络的应用场景变得更加复杂多变。本文试图从Kubernetes当中容器跨节点网络通信方案Flannel的实际应用场景出发,带领读者梳理Kubernetes当中容器跨节点网络通信的实现过程以及背后的实现原理。

    | Kubernetes网络模型

    通过上一篇文章《深入浅出Kubernetes网络:容器网络初探》我们知道了Docker通过VEth虚拟网络设备以及Linux bridge实现了同一台主机上的容器网络通信,再通过iptables进行NAT实现了容器和外部网络的通信。

    这对于简单部署的应用已经能够满足网络通信的需求了,但是Kubernetes作为一个容器编排平台,要处理的是生产环境当中高并发大规模的弹性扩展问题,首先要解决的就是整个集群当中所有节点上的容器网络通信问题。

    为了解决Kubernetes当中网络通信的问题,Kubernetes作为一个容器编排平台提出了Kubernetes网络模型,但是并没有自己去实现,具体网络通信方案通过网络插件来实现。

    其实Kubernetes网络模型当中总共只作了三点要求:

    1. 运行在一个节点当中的Pod能在不经过NAT的情况下跟集群中所有的Pod进行通信

    2. 节点当中的客户端(system daemon、kubelet)能跟该节点当中的所有Pod进行通信

    3. 以host network模式运行在一个节点上的Pod能跟集群中所有的Pod进行通信

    从Kubernetes的网络模型我们可以看出来,在Kubernetes当中希望做到的是每一个Pod都有一个在集群当中独一无二的IP,并且可以通过这个IP直接跟集群当中的其他Pod以及节点自身的网络进行通信,一句话概括就是Kubernetes当中希望网络是扁平化的。

    针对Kubernetes网络模型也涌现出了许多的实现方案,例如Calico、Flannel、Weave等等,虽然实现原理各有千秋,但都围绕着同一个问题即如何实现Kubernetes当中的扁平网络进行展开。Kubernetes只需要负责编排调度相关的事情,修桥铺路的事情交给相应的网络插件即可。

    | Flannel简介

    Flannel项目为CoreOS团队对Kubernetes网络设计实现的一种三层网络通信方案,安装部署方式可以参考官方示例文档:https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml,故关于Flannel的安装部署部分这里暂时不进行赘述,有兴趣的同学可以参考官方文档进行部署测试。

    为了便于理解和说明,以下内容将用一个1(master)+2(work node)的Kubernetes集群进行举例说明。 

    在安装部署完成之后应该能看到在各个节点上通过DaemonSet的方式运行了一个Flannel的Pod。

    [root@10-10-88-192 ~]# kubectl get daemonset -n kube-system -l app=flannel
    NAME              DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR                   AGE
    kube-flannel-ds   3         3         3         3            3           beta.kubernetes.io/arch=amd64   135d
    [root@10-10-88-192 ~]#
    
    [root@10-10-88-192 ~]#
    [root@10-10-88-192 ~]# kubectl get pod -n kube-system -o wide -l app=flannel
    NAME                    READY     STATUS    RESTARTS   AGE       IP               NODE
    kube-flannel-ds-npcxv   1/1       Running   0          2h        172.16.130.164   10-10-88-170
    kube-flannel-ds-rv8wv   1/1       Running   0          2h        172.16.130.244   10-10-88-192
    kube-flannel-ds-t5zlv   1/1       Running   0          2h        172.16.130.140   10-10-88-195
    [root@10-10-88-192 ~]#

    每一个Flannel的Pod当中都运行了一个flanneld进程,且flanneld的配置文件以ConfigMap的形式挂载到容器内的/etc/kube-flannel/目录供flanneld使用。

    [root@10-10-88-192 ~]# kubectl get cm -n kube-system -l app=flannel
    NAME               DATA      AGE
    kube-flannel-cfg   2         137d
    [root@10-10-88-192 ~]#

    | Flannel Backend

    Flannel通过在每一个节点上启动一个叫flanneld的进程,负责每一个节点上的子网划分,并将相关的配置信息如各个节点的子网网段、外部IP等保存到etcd当中,而具体的网络包转发交给具体的Backend来实现。

    flanneld可以在启动的时候通过配置文件来指定不同的Backend来进行网络通信,目前比较成熟的Backend有VXLAN、host-gw以及UDP三种方式,也已经有诸如AWS,GCE and AliVPC这些还在实验阶段的Backend。VXLAN是目前官方最推崇的一种Backend实现方式,host-gw一般用于对网络性能要求比较高的场景,但需要基础架构本身的支持,UDP则一般用于Debug和一些比较老的不支持VXLAN的Linux内核。

    这里只展开讲讲最成熟也是最通用的三种Backend网络通信实现流程:

    • UDP

    • VXLAN

    • host-gw

    UDP

    由于UDP模式相对容易理解,故这里先采用UDP这种Backend模式进行举例说明然后再对其他Backend模式进行展开讲解。

    采用UDP模式时需要在flanneld的配置文件当中指定Backend type为UDP,可以通过直接修改flanneld的ConfigMap的方式实现,配置修改完成之后如下:

    [root@10-10-88-192 ~]# kubectl get cm -n kube-system -o yaml kube-flannel-cfg
    apiVersion: v1
    data:
      cni-conf.json: |
    {
      "name": "cbr0",
      "type": "flannel",
      "delegate": {
        "isDefaultGateway": true
      }
    }
      net-conf.json: |
    {
      "Network": "10.244.0.0/16",
      "Backend": {
        "Type": "udp"
      }
    }
    kind: ConfigMap
    metadata:
      creationTimestamp: 2018-10-30T08:34:01Z
      labels:
    app: flannel
    tier: node
      name: kube-flannel-cfg
      namespace: kube-system
      resourceVersion: "33718154"
      selfLink: /api/v1/namespaces/kube-system/configmaps/kube-flannel-cfg
      uid: 8d981eff-dc1e-11e8-8103-fa900126bc00
    [root@10-10-88-192 ~]#

    关键字段为Backend当中的Type字段,采用UDP模式时Backend Port默认为8285,即flanneld的监听端口。

    flanneld的ConfigMap更新完成之后delete flannel pod进行配置更新:

    [root@10-10-88-192 ~]# kubectl delete pod -n kube-system -l app=flannel
    pod "kube-flannel-ds-npcxv" deleted
    pod "kube-flannel-ds-rv8wv" deleted
    pod "kube-flannel-ds-t5zlv" deleted
    [root@10-10-88-192 ~]#

    当采用UDP模式时,flanneld进程在启动时会通过打开/dev/net/tun的方式生成一个TUN设备,TUN设备可以简单理解为Linux当中提供的一种内核网络与用户空间(应用程序)通信的一种机制,即应用可以通过直接读写tun设备的方式收发RAW IP包。

    flanneld进程启动后通过ip a命令可以发现节点当中已经多了一个叫flannel0的网络接口:

    [root@10-10-88-192 ~]# ip a
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    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 state UP qlen 1000
    link/ether fa:90:01:26:bc:00 brd ff:ff:ff:ff:ff:ff
    inet 10.10.88.192/24 brd 10.10.88.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::f890:1ff:fe26:bc00/64 scope link
       valid_lft forever preferred_lft forever
    3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether fa:86:b8:79:70:01 brd ff:ff:ff:ff:ff:ff
    inet 172.16.130.244/24 brd 172.16.130.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::f886:b8ff:fe79:7001/64 scope link
       valid_lft forever preferred_lft forever
    4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
    link/ether 02:42:ae:dd:19:83 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 scope global docker0
       valid_lft forever preferred_lft forever
    5: flannel0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1472 qdisc pfifo_fast state UNKNOWN qlen 500
    link/none
    inet 10.244.0.0/16 scope global flannel0
       valid_lft forever preferred_lft forever
    inet6 fe80::969a:a8eb:e4da:308b/64 scope link flags 800
       valid_lft forever preferred_lft forever
    6: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1472 qdisc noqueue state UP qlen 1000
    link/ether 0a:58:0a:f4:00:01 brd ff:ff:ff:ff:ff:ff
    inet 10.244.0.1/24 scope global cni0
       valid_lft forever preferred_lft forever
    inet6 fe80::3428:a4ff:fe6c:bb77/64 scope link
       valid_lft forever preferred_lft forever

    细心的同学就会发现此时flannel0这个网络接口上的MTU为1472,相比Kubernetes集群网络接口eth1小了28个字节,为什么呢?

    通过可以ip -d link show flannel0可以看到这是一个tun设备:

    [root@10-10-88-192 ~]# ip -d link show flannel0
    5: flannel0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1472 qdisc pfifo_fast state UNKNOWN mode DEFAULT qlen 500
    link/none  promiscuity 0
    tun
    [root@10-10-88-192 ~]#

    通过netstat -ulnp命令可以看到此时flanneld进程监听在8285端口:

    [root@10-10-88-192 ~]# netstat -ulnp | grep flanneld
    udp        0      0 172.16.130.140:8285     0.0.0.0:*                           2373/flanneld
    [root@10-10-88-192 ~]#

    容器跨节点通信实现流程:

    假设在节点A上有容器A(10.244.1.96),在节点B上有容器B(10.244.2.194),此时容器A向容器发送一个ICMP请求报文(ping),我们来逐步分析一下ICMP报文是如何从容器A到达容器B的。 

    1、容器A当中发出ICMP请求报文,通过IP封装后形式为:10.244.1.96 -> 10.244.2.194,此时通过容器A内的路由表匹配到应该将IP包发送到网关10.244.1.1(cni0网桥)。

    完整的帧格式为: 

    2、此时到达cni0的IP包目的地IP 10.244.2.194匹配到节点A上第一条路由规则(10.244.0.0),内核将RAW IP包发送给flannel0接口。

    3、flannel0为tun设备,发送给flannel0接口的RAW IP包(无MAC信息)将被flanneld进程接收到,flanneld进程接收到RAW IP包后在原有的基础上进行UDP封包,UDP封包的形式为:172.16.130.140:src port -> 172.16.130.164:8285。

    这里有一个问题就是flanneld怎么知道10.244.2.194这个容器到底是在哪个节点上呢?

    flanneld在启动时会将该节点的网络信息通过api-server保存到etcd当中,故在发送报文时可以通过查询etcd得到10.244.2.194这个容器的IP属于host B,且host B的IP为172.16.130.164。

    RAW IP包示例:

    4、flanneld将封装好的UDP报文经eth1发出,从这里可以看出网络包在通过eth1发出前先是加上了UDP头(8个字节),再然后加上了IP头(20个字节)进行封装,这也是为什么flannel0的MTU要比eth1的MTU小28个字节的原因(防止封装后的以太网帧超过eth1的MTU而在经过eth1时被丢弃)。

    此时完整的以太网帧格式为:

    5、网络包经节点A和节点B之间的网络连接到达host B。

    6、host B收到UDP报文后经Linux内核通过UDP端口号8285将包交给正在监听的应用flanneld。

    7、运行在host B当中的flanneld将UDP包解包后得到RAW IP包:10.244.1.96 -> 10.244.2.194。

    8、解封后的RAW IP包匹配到host B上的路由规则(10.244.2.0),内核将RAW IP包发送到cni0。

    此时的完整的以太网帧格式为: 

    9、cni0将IP包转发给连接在cni0网桥上的container B,而flanneld在整个过程中主要主要负责两个工作:

    • UDP封包解包

    • 节点上的路由表的动态更新

    从上面虚线部分就可以看到container A和container B虽然在物理网络上并没有直接相连,但在逻辑上就好像是处于同一个三层网络当中,这种基于底下的物理网络设备通过Flannel等软件定义网络技术实现的网络我们称之为Overlay网络。

    那么上面通过UDP这种Backend实现的网络传输过程有没有问题呢?最明显的问题就是,网络数据包先是通过tun设备从内核当中复制到用户态的应用,然后再由用户态的应用复制到内核,仅一次网络传输就进行了两次用户态和内核态的切换,显然这种效率是不会很高的。那么有没有高效一点的办法呢?当然,最简单的方式就是把封包解包这些事情都交给内核去干好了,事实上Linux内核本身也提供了比较成熟的网络封包解包(隧道传输)实现方案VXLAN,下面我们就来看看通过内核的VXLAN跟flanneld自己通过UDP封装网络包在实现上有什么差别。

    VXLAN

    VXLAN简介

    VXLAN全称Virtual Extensible LAN,是一种虚拟化隧道通信技术,主要是为了突破VLAN的最多4096个子网的数量限制,以满足大规模云计算数据中心的需求。VLAN技术的缺陷是VLAN Header预留的长度只有12 bit,故最多只能支持2的12次方即4096个子网的划分,无法满足云计算场景下主机数量日益增长的需求。当前VXLAN的报文Header内有24 bit,可以支持2的24次方个子网,并通过VNI(Virtual Network Identifier)来区分不同的子网,相当于VLAN当中的VLAN ID。

    不同于其他隧道协议,VXLAN是一个一对多的网络,并不仅仅是一对一的隧道协议。一个VXLAN设备能通过像网桥一样的学习方式学习到其他对端的IP地址,也可以直接配置静态转发表。

    VXLAN包格式: 

    从VXLAN的包格式就可以看到原本的二层以太网帧被放在VXLAN包头里进行封装,VXLAN实际实现的是一个二层网络的隧道,通过VXLAN让处于同一个VXLAN网络(VNI相同则为同一个VXLAN网络)当中的机器看似处在同一个二层网络当中(逻辑上处于同一个二层网络),而网络包转发的方式也类似二层网络当中的交换机(这样虽然不是很准确,但更便于理解)。

    当采用VXLAN模式时,flanneld在启动时会通过Netlink机制与Linux内核通信,建立一个VTEP(Virtual Tunnel Access End Point)设备flannel.1 (命名规则为flannel.[VNI],VNI默认为1),类似于交换机当中的一个网口。

    可以通过ip -d link查看VTEP设备flannel.1的配置信息,从以下输出可以看到,VTEP的local IP为172.16.130.244,destination port为8472。

    [root@10-10-88-192 ~]# ip -d link show flannel.1
    5: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN mode DEFAULT
    link/ether a2:5e:b0:43:09:a7 brd ff:ff:ff:ff:ff:ff promiscuity 0
    vxlan id 1 local 172.16.130.244 dev eth1 srcport 0 0 dstport 8472 nolearning ageing 300 addrgenmode eui64
    [root@10-10-88-192 ~]#

    在UDP模式下由flanneld进程进行网络包的封包和解包的工作,而在VXLAN模式下解封包的事情交由内核处理,那么此时FlannnelD的作用是什么呢?带着这个疑问我们先来简单看一下VXLAN Backend是如何工作的。

    VXLAN Backend工作原理

    Flannel当中对VXLAN Backend的实现经过了几个版本的改进之后目前最新版本的flanneld当中的处理流程为:

    当flanneld启动时将创建VTEP设备(默认为flannel.1,若已经创建则跳过),并将VTEP设备的相关信息上报到etcd当中,而当在Flannel网络中有新的节点发现时,各个节点上的flanneld将依次执行以下流程:

    在节点当中创建一条该节点所属网段的路由表,主要是能让Pod当中的流量路由到flannel.1接口。

    通过route -n可以查看到节点当中已经有两条flannel.1接口的路由:

    [root@10-10-88-192 ~]# route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    0.0.0.0         10.10.88.254    0.0.0.0         UG    0      0        0 eth0
    10.10.88.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0
    10.244.0.0      0.0.0.0         255.255.255.0   U     0      0        0 cni0
    10.244.1.0      10.244.1.0      255.255.255.0   UG    0      0        0 flannel.1
    10.244.2.0      10.244.2.0      255.255.255.0   UG    0      0        0 flannel.1
    169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
    169.254.0.0     0.0.0.0         255.255.0.0     U     1003   0        0 eth1
    172.16.130.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1
    172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
    [root@10-10-88-192 ~]#

    在节点当中添加一条该节点的IP以及VTEP设备的静态ARP缓存。

    可通过arp -n命令查看到master节点当中已经缓存了另外两个节点以及VTEP的ARP信息(已删除无关ARP缓存信息)。

    [root@10-10-88-192 ~]# arp -n
    Address                  HWtype  HWaddress           Flags Mask            Iface
    10.244.2.0               ether   42:7f:69:c7:cd:37   CM                    flannel.1
    10.244.1.0               ether   7a:2c:d0:7f:48:3f   CM                    flannel.1
    172.16.130.140           ether   fa:89:cf:03:e3:01   C                     eth1
    172.16.130.164           ether   fa:88:2a:44:2b:01   C                     eth1

    在节点当中添加一条该节点的转发表。

    通过bridge命令查看节点上的VXLAN转发表(FDB entry),MAC为对端VTEP设备即flannel.1的MAC,IP为VTEP对应的对外IP(可通过flanneld的启动参数--iface=eth1指定,若不指定则按默认网关查找网络接口对应的IP),可以看到已经有两条转发表。

    [root@10-10-88-192 ~]# bridge fdb show dev flannel.1
    42:7f:69:c7:cd:37 dst 172.16.130.164 self permanent
    7a:2c:d0:7f:48:3f dst 172.16.130.140 self permanent
    [root@10-10-88-192 ~]#

    VXLAN Backend配置

    跟UDP Backend一样,将Flannel Backend修改为VXLAN只需要将Flannel ConfigMap当中的Backend type字段修改为VXLAN即可。由于VXLAN类型相对UDP复杂并且有较好的灵活性,这里简单说一下VXLAN当中的几个配置选项:

    • VNI(Number):VXLAN Identifier,默认为1

    • Port(Number):用于发送VXLAN UDP报文的端口,默认为8472

    • DirectRouting(Boolean):当两台主机处于同一个网段当中时,启用后将采用直接路由的方式进行跨节点网络通信(此时工作模式跟后面要讲的host-gw Backend一样),只有当两台主机处于不同的网段当中时才会采用VXLAN进行封包,默认为关闭状态。

    修改完成后的ConfigMap如下:

    [root@10-10-88-192 ~]# kubectl get cm -o yaml -n kube-system kube-flannel-cfg
    apiVersion: v1
    data:
      cni-conf.json: |
    {
      "name": "cbr0",
      "type": "flannel",
      "delegate": {
        "isDefaultGateway": true
      }
    }
      net-conf.json: |
    {
      "Network": "10.244.0.0/16",
      "Backend": {
        "Type": "vxlan"
      }
    }
    kind: ConfigMap
    metadata:
      creationTimestamp: 2018-10-30T08:34:01Z
      labels:
    app: flannel
    tier: node
      name: kube-flannel-cfg
      namespace: kube-system
      resourceVersion: "33872104"
      selfLink: /api/v1/namespaces/kube-system/configmaps/kube-flannel-cfg
      uid: 8d981eff-dc1e-11e8-8103-fa900126bc00
    [root@10-10-88-192 ~]#

    同样在更新配置后delete pod使配置生效,并可以通过Flannel的日志查看到Backend已经更新为VXLAN模式:

    [root@10-10-88-192 ~]# kubectl logs -f -n kube-system kube-flannel-ds-7bjfm
    I0318 03:24:02.148654       1 main.go:487] Using interface with name eth1 and address 172.16.130.244
    I0318 03:24:02.148754       1 main.go:504] Defaulting external address to interface address (172.16.130.244)
    I0318 03:24:02.207525       1 kube.go:130] Waiting 10m0s for node controller to sync
    I0318 03:24:02.207596       1 kube.go:283] Starting kube subnet manager
    I0318 03:24:03.207695       1 kube.go:137] Node controller sync successful
    I0318 03:24:03.207729       1 main.go:234] Created subnet manager: Kubernetes Subnet Manager - 10-10-88-192
    I0318 03:24:03.207735       1 main.go:237] Installing signal handlers
    I0318 03:24:03.207812       1 main.go:352] Found network config - Backend type: vxlan
    I0318 03:24:03.227332       1 vxlan.go:119] VXLAN config: VNI=1 Port=0 GBP=false DirectRouting=false
    I0318 03:24:03.587362       1 main.go:299] Wrote subnet file to /run/flannel/subnet.env
    I0318 03:24:03.587379       1 main.go:303] Running backend.
    I0318 03:24:03.587390       1 main.go:321] Waiting for all goroutines to exit
    I0318 03:24:03.587418       1 vxlan_network.go:56] watching for new subnet leases

    同样可以通过netstat -ulnp命令查看VXLAN监听的端口:

    [root@10-10-88-192 ~]# netstat -ulnp | grep 8472
    udp        0      0 0.0.0.0:8472            0.0.0.0:*                           -
    [root@10-10-88-192 ~]#

    但跟UDP模式下查看flanneld监听的端口的区别为,最后一栏显示的不是进程的ID和名称,而是一个破折号“-”,这说明UDP的8472端口不是由用户态的进程在监听的,也证实了VXLAN模块工作在内核态模式下。 

    此时容器跨节点网络通信实现流程为:

    1. 同UDP Backend模式,容器A当中的IP包通过容器A内的路由表被发送到cni0

    2. 到达cni0当中的IP包通过匹配host A当中的路由表发现通往10.244.2.194的IP包应该交给flannel.1接口

    3. flannel.1作为一个VTEP设备,收到报文后将按照VTEP的配置进行封包,首先通过etcd得知10.244.2.194属于节点B,并得到节点B的IP,通过节点A当中的转发表得到节点B对应的VTEP的MAC,根据flannel.1设备创建时的设置的参数(VNI、local IP、Port)进行VXLAN封包

    4. 通过host A跟host B之间的网络连接,VXLAN包到达host B的eth1接口

    5. 通过端口8472,VXLAN包被转发给VTEP设备flannel.1进行解包

    6. 解封装后的IP包匹配host B当中的路由表(10.244.2.0),内核将IP包转发给cni0

    7. cni0将IP包转发给连接在cni0上的容器B

    这么一看是不是觉得相比UDP模式单单从步骤上就少了很多步?VXLAN模式相比UDP模式高效也就不足为奇了。

    host-gw

    host-gw即Host Gateway,从名字中就可以想到这种方式是通过把主机当作网关来实现跨节点网络通信的。那么具体如何实现跨节点通信呢?

    同理UDP模式和VXLAN模式,首先将Backend中的type改为host-gw,这里就不再赘述,只讲一下网络通信的实现流程。

    采用host-gw模式后flanneld的唯一作用就是负责主机上路由表的动态更新, 想一下这样会不会有什么问题?

    使用host-gw Backend的Flannel网络的网络包传输过程如下图所示: 

    1. 同UDP、VXLAN模式一致,通过容器A的路由表IP包到达cni0

    2. 到达cni0的IP包匹配到host A当中的路由规则(10.244.2.0),并且网关为172.16.130.164,即host B,所以内核将IP包发送给host B(172.16.130.164)

    3. IP包通过物理网络到达host B的eth1

    4. 到达host B eth1的IP包匹配到host B当中的路由表(10.244.2.0),IP包被转发给cni0

    5. cni0将IP包转发给连接在cni0上的容器B

    host-gw模式其中一个局限性就是,由于是通过节点上的路由表来实现各个节点之间的跨节点网络通信,那么就得保证两个节点是可以直接路由过去的。按照内核当中的路由规则,网关必须在跟主机当中至少一个IP处于同一网段,故造成的结果就是采用host-gw这种Backend方式时则集群中所有的节点必须处于同一个网络当中,这对于集群规模比较大时需要对节点进行网段划分的话会存在一定的局限性。另外一个则是随着集群当中节点规模的增大,flanneld需要维护主机上成千上万条路由表的动态更新也是一个不小的压力。

    | 后记

    本文主要讲述了Flannel当中UDP、VXLAN、host-gw三种Backend的跨节点网络通信实现流程,并作了简单的分析对比,跨节点网络通信的流程从UDP到VXLAN再到host-gw依次变得简单,效率也逐步提升。这一切还是离不开Linux的设计哲学:Less Is More。

    在Kubernetes当中往往很多问题都是出在网络层面,如何在出现问题时能快速地定位到问题原因需要我们对Kubernetes的网络模型有一个熟悉的认知。很多事物的出现都有他的历史原因,永远没有适合各种场景的最好的方案,只有某些应用场景最合适的方案,网络选型还是得根据自身情况进行决定。

    | 作者简介

    叶龙宇·沃趣科技研发工程师

    主要负责公司基于Kubernetes的RDS平台QFusion的研发, 熟悉云计算及Kubernetes技术体系。

    展开全文
  • 社交网络节点理论

    千次阅读 2015-12-14 22:01:27
    但是类似微博这类新兴媒体更的是兴趣导向,信息的爆炸传播,弱关系链更容易突破顿巴数的限制,达到社交圈的快速增长。 5.二八定律(巴莱多定律) 社交网络中除了有强弱关系链分析,还有重要和不重要之分...

    1.顿巴数

    每个人的朋友圈子对多能达到150个人。(密友3-5人,好友30-50人,其他100-150人)
    纵使高科技带来的人际圈越来越大,但是人脑的容量是有限的,你也不可能和这么多人维持一定的人际关系(没有人能这么情感泛滥!)

    2.六度人脉理论

    地球上的所有人都能通过五层以上的熟人和其他人联系起来,即一个人和任何一个陌生人之间所间的间隔不会超过六个。通俗地说,就是通过六个人就可以认识任何一个陌生人。

    3.贝肯数

    贝肯原来是好莱坞电影的一个演员配角,贝肯数刻画的他要通过几个人才能和其他主角演员形成联系。实验表明,平均贝肯数是2.6~3.

       这个数字体现在网络上有两个表现:

    (1)如果想进入网络的链接中心,并不一定要成为一个“ 大人物”,只要成为一个“永不退场的配角”也可以非常接近网络的中心。

    (2)一个网络社区的兴旺还是崩溃,其实不会因为多少普通用户的进入或流失而发生。但是,“贝肯”这样高链接的节点用户丢失,就会造成整个社区的崩溃。

      其实贝肯节点更直观的描述就是,虽然六度人脉理论将我们大多数人相连,但是总有那些掌握着重要人脉的节点,通过他们,六度空间才能顺利形成通路。
    中间人的重要性。

    4.强弱关系链

    人有亲疏远近,节点关系亦然。
    我们所知的熟人关系网络构成强关系网络,通过兴趣,爱好等形成起来的关系链称为弱关系链。这里将关系强度等级划分与定义:
    (1)强关系,你基本上每天都能接触或是一个星期至少有2-3次来往的人。
    (2)弱关系,不是每天接触的人,但基本上是曾经的朋友,同学,同事,亲戚。
    (3)微关系,通过共同的兴趣、爱好、经历形成的泛泛之交。
    在不同应用场景下,强弱关系链有着明显的差异。在手机同步通信、IM异步通信的场景下,强关系链发挥了主导作用。但是类似微博这类新兴媒体更多的是兴趣导向,信息的爆炸传播,弱关系链更容易突破顿巴数的限制,达到社交圈的快速增长。

    5.二八定律(巴莱多定律)

    社交网络中除了有强弱关系链分析,还有重要和不重要之分。
    二八定律最早在经济学领域提出,是指二成的人拥有八成的人的财富。后来延伸到各个领域,包括人脉。
    在任何一组东西中,最重要的只占其中一小部分,约20%,其余80%的尽管是多数,却是次要的,因此又称二八法则。

    6.马太效应

    “富者越富,贫者越贫”
    马太效应揭示了一个大概率事件:社交网络中,重要的节点很可能会越来越重要,而位于网络边缘的节点,可能会越来越被弱化。社会交往中,那些长于交际朋友多的人会借助频繁的交往,认识更多的朋友;那些内向沉默的人则会越来越孤独。
    马太效应是个悖论,在受欢迎的社交网络中作为强者的节点泄露隐私的风险越大。

    7.长尾效应

    并不是八成不重要的节点就没有用。
    虽然社交网络中存在不太重要的节点,但是对于一个覆盖面很广的社交网络来说,八成重要性并不是最重要的节点也有其商业开发的价值,互联网的浪潮已经将商品成本降至极低,长尾理论将发挥巨大的价值。

    8.羊群效应

      羊群效应是指人们经常受到多数人影响,而跟从大众的思想或行为,也被称为“从众效应”。人们会追随大众所同意的,自己并不会思考事件的意义。
        社交网络中的节点都会互相影响,每个个体都会偏向大多数人的判断,每个个体都有从众的趋向性

    9.马斯洛需求模型

    社交网络中的节点是千差万别的,节点间的联系是多种多样的,但归根结底,社交网络是因为满足每个个体的需求而存在,并基于需求模型而发展演变




    展开全文
  • 密集波分复用(DWDM)技术为通信网络提供了巨大的传输容量,逐步成为主流传输技术。伴随着DWDM技术的成熟和传输容量的快速增长,传统的电子交换系统承受的压力日趋增大,光交换技术的引入日显迫切。  与光信号的3种...
  • 各种新技术层出不穷,来自中国的玩家开发团队,利用虚拟币技术开发并构建了一个独立于互联网的虚拟去中心化的影子网络BitNet,根据公布的白皮书透露,新技术利用了比特币的等加密货币软件节点计算机进行组网,...


    随着比特币技术发展,各种新技术层出不穷,来自中国的玩家开发团队,利用虚拟币技术开发并构建了一个独立于互联网的虚拟去中心化的影子网络BitNet,根据公布的白皮书透露,新技术利用了比特币的等加密货币软件节点计算机进行组网,小编下载测试,发现在这个软件中还内置了自己的Web服务器,根据开发团队透露,这是为了方便用户,在BitNet网络中架设网站,软件甚至还可以将网站架设到内部局域网中。这一技术,将会让虚拟币技术进一步进入实用化阶段,开发团队预测,他们这一技术,将会产生很好商业价值。


    BitNet网络中,拥有自己的独立域名系统,这个域名系统,将传统的域名系统进行了升级扩展,使它成为了一个去中心化的分布式域名系统,新技术可以让网站的域名由任何字符串构成,例如一个人名或是经典的诗词名句等。对于商业用户来说,可以申请更加有特色的域名,不在局限于传统的带有后缀的域名格式,作家可以架设以自己书名为域名的网站,游戏公司可以架设以游戏名称为域名的网站等,为了验证这一技术,小编故意在测试时,使用了五个ASCII码形式的小星星符号做为域名,并且指向到自己的微博上,当小编开启软件后,在浏览器输入这些符号时,发现可以正常访问网站。


    目前官方已经开发完成了第二个测试版本,目前属于试运行阶段,官方第一期计划发展1万用户,目前已经达到了1000多用户,这将产生很高的商业价值,在官方发布的论坛贴中,小编发现受到了许多的用户好评,认为这是一个创新和突破,更有人认为这将是虚拟币界的又一次革命。按照官方的开发计划安排,在下一个版本中,还将引入比特币、莱特币、狗币等其它数字货币节点进行组网,来进一步壮大BitNet网络,让空跑的钱包节点,变得更加有社会价值,官方计划是,打造一个以虚拟币为基础,自成体系的绿色互联网络生态系统。在这个生态系统,用户分享资源,并由此获得收入,由于全部采用虚拟币进行结算,所以不存在现实中任何货币手续费等问题。这意味,网站运营价格更加低良,为了鼓励新户的认识,官方提供长达55页的中英文说明书。


       有兴趣读者,可以通过百度,搜索了解。


    
    展开全文
  • ChinaNet--中国公用Internet骨干网,ChinaNet是邮电部门经营管理的基于Internet网络技术的中国公用计算机互联网,是国际计算机互联网(Internet)的一部分,是中国的Internet骨干网。通过Chinanet的灵活接入方式...

    ChinaNet--中国公用Internet骨干网,ChinaNet是邮电部门经营管理的基于Internet网络技术的中国公用计算机互联网,是国际计算机互联网(Internet)的一部分,是中国的Internet骨干网。通过Chinanet的灵活接入方式,用户可以方便地接入全球Internet,享用Chinanet及全球Internet上的丰富资源和各种服务。 



    CHINANET由国家电信部门负责经营管理, TCP/IP 协议,通过高速数据专线实现国内各节点互联,拥有国际专线。用户可以通过电话网、综合业务数据网、数字数据网等其它公用网络,以拨号或专线的方式接入CHINANET,并使用CHINANET上开放的网络浏览、电子邮件、信息服务等多种业务服务。 使用CHINANET几乎可以从网上与整个世界发生联系,享受INTERNET浩如烟海的信息资源。CHINANET也已成为中国规模最大,技术、业务发展最快的公用数据网之一。 



    谈到CHINANET就不可能不谈到TCP/IP。CHINANET是一个连接计算机网络的网络,它是一个开放的系统,任何一台使用其协议的计算机都可连入其中, 这个通信协议就是TCP/IP协议簇 。使用开放的TCP/IP协议是INTERNET迅速成长的奥秘。 TCP/IP协议是包括传输控制协议(TCP)和互联网络协议(IP)在内的一组共同工作的协议簇 。它们负责在INTERNET上传递数据与信息。IP协议决定了INTERNET上各主机或网络的地址格式,及数据包在INTERNET上传递所选用的路径。而TCP协议负责确保被分割打包的数据段,能还原成原来顺序的数据,并进行传输过程中端对端的差错控制、拥塞控制等。 



    CHINANET是国内最早的互联网络之一,截止到2003 年7 月31 日物理节点覆盖全国31 个省(市、区)的200 多个城市,业务范围覆盖所有电话通达的地区。CHINANET骨干网由北京、上海、广州、沈阳、南京、武汉、成都、西安等8 个核心节点组成的核心层和其它54 个汇接节点组成的汇接层组成。全网有3 个国际出口,通过京、沪、穗的路由器完成。国际路由器与国内路由器独立设置,并负责实现各国际策略及安全性限制。CHINANET 网络节点间的中继电路采用基于SDH 和DWDM 的光纤网络,网络总带宽超过800G,国际出口总带宽已超过5000Mbps,实现了宽带化、高速化,是目前国内传输带宽最宽、覆盖范围最广、网络性能最稳定、信息资源最丰富、网络功能最先进、用户数量最多的计算机互联网。 

    CHINANET的负责范围 

    根据安排CHINANET的国际出口带宽会有大幅度的提高,因此路由政策也需要有相应的调整,根据目前所掌握的流量情况,原有的负责范围调整如下: 

    北京负责地区 北京、河北、内蒙、山西、沈阳、河南、吉林、黑龙江、山东 

    上海负责地区 上海、浙江、江苏、安徽、湖北、天津、江西、陕西、甘肃、青海、宁夏、新疆、广西 

    广州负责地区 广东、福建、湖南、海南、四川、云南、贵州、西藏、重庆 

    CHINANET骨干网结构概述 

    CHINANET骨干网的拓扑结构逻辑上分为两层,即核心层和大区层。 

    核心层 

    核心层由北京、上海、广州、沈阳、南京、武汉、成都、西安等8个城市的核心节点组成。 

    核心层的功能主要是提供与国际internet的互联,以及提供大区之间信息交换的通路。其中北京、上海、广州核心层节点各设有两台国际出口路由器,负责与国际internet互联,以及两台核心路由器与其他核心节点互联;其他核心节点各设一台核心路由器。 

    核心节点之间为不完全网状结构。以北京、上海、广州为中心的三中心结构,其他核心节点分别以至少两条高速ATM链路与这三个中心相连。 

    大区层 

    全国31个省会城市按照行政区划,以上述8个核心节点为中心划分为8个大区网络,这8个大区网共同构成了大区层。每个大区设两个大区出口,大区内其它非出口节点分别与两个出口相连。 

    大区层主要提供大区内的信息交换以及接入网接入chinanet的信息通路。 

    大区之间通信必须经过核心层。 

    互联互通 

    其实,中国的互联网原本是一张网。4年以前,中国电信几乎垄断着全国的固话网络,新兴的宽带互联网自然也是由电信"独家"经营。但是,中国电信的南北分拆打破了这一局面。 

    2002年5月,国内电信业大重组,原中国电信北方10个省份正式划入中国网通集团,南方21个省份重组为新的中国电信。这次"大分家"把中国的互联网人为地一分为二。 

    两大宽带运营商南北各自称雄,旗下都汇聚了大批网站和用户,势均力敌。尽管互相也深入对方地盘发展,但是,南电信、北网通的格局短期内还无法打破。而网间互联互通的问题却接踵而至。 

    两大运营商年报数据表明,2005年中国电信宽带接入用户达2102万户,中国网通达1148万户。根据信产部的相关规定,电信运营商之间的互联电路是免费的,即双方都无需向对方支付接入费用。据消息人士透露,网通与电信在集团层面就此问题进行过多次蹉商,但在互联带宽的拓宽问题上并没有取得突破性的进展。 

    展开全文
  • 而无线自组织网络不需要固定设备支持,各节点即用户终端自行组网,通信时,由其他用户节点进行数据的转发。这种网络形式突破了传统无线蜂窝网络的地理局限性,能够更加快速、便捷、高效地部署,适合于一些紧急场合的...
  • 而无线自组织网络不需要固定设备支持,各节点即用户终端自行组网,通信时,由其他用户节点进行数据的转发。这种网络形式突破了传统无线蜂窝网络的地理局限性,能够更加快速、便捷、高效地部署,适合于一些紧急场合的...
  • BU Firework超级节点实时竞选系统 简介 动机和目标 角色说明 竞选系统 Firework共识 架构 社区治理 生态节点 竞选 准入细则 评估维度 竞选流程 退出和作恶惩罚 投票 投票准则 投票...
  • 网管顾名思义,就是天天管着网络、想尽各种手段限制我们上网的人。在网络中订立种种规则,不许下载、不许用IM、不许访问受限...想不想神不知归不觉的突破这些限制,在网管眼皮子底下自由自在的上网呢?用The
  • 在此基础上给出了关键网络传输技术在未来实现突破的方向,即低延时的实时MAC技术,低延时、低能耗的路由关键技术,多媒体信息安全技术,面向多核和众核的多媒体终端设备的研制和模态软件构件技术的研究以及高压缩...
  • 一种节点组重要性排序方法

    千次阅读 2020-05-17 21:00:00
    网络科学中关于节点重要性排序方法很,譬如节点度(degree),中心度(K-shell)即核数(coreness),介数(betweenness),H-index,还有 Page-Ra...
  • 近年来电力线载波技术突破了仅限于单片机应用的限制,已经进入了数字化时代,并且随着电力线载波技术的不断发展和社会的需要中/低压电力载波通信的技术开发及应用亦出现了方兴未艾的局面。  目前,配电网通信是实现...
  • 据了解,该网络由700个光纤量子密钥分发(QKD)链路的大规模光纤网络,以及2个高速卫星对地自由空间QKD链路组成。地面光纤网络采用可信的中继结构,覆盖2000公里,提供了实际的安全性、可靠性和稳定性。 同时,...
  • 摘要:网络编码是近年来通信领域的重大突破,其基本思想是网络节点不仅参与数据转发,还参与数据处理,这样可...
  • 突破Java面试

    千次阅读 2019-05-18 14:52:01
    2、怎么才能够突破单机瓶颈,让redis支撑海量数据? 3、redis的集群架构 redis cluster 支撑N个redis master node,每个master node都可以挂载个slave node 读写分离的架构,对于每个master来说,写就写到master.....
  • 关于区块链的各大技术突破。业内总在不断的提出最新模式。 今年6月起,一个新的名词“超级节点”引起了圈内人士的关注。最早是EOS依靠“社区超级节点竞选”赢得一波关注。随之各大知名区块链项目方如EULO、波场等,...
  • 虽然相当适合用来进行序列建模,但深度递归神经网络体系结构缺乏直观的高阶时空架构。计算机视觉领域的许多问题都固有存在高阶架构,所以我们思考从这方面进行提高。在解决现实世界中的高阶直觉计算方面,时空领域...
  • Zookeeper分布式锁,小小节点真奇妙

    千次阅读 2020-10-05 21:57:22
    文章目录一、前言二、从锁到分布式锁zookeeper是如何基于节点去实现各种分布式锁的? 一、前言 二、从锁到分布式锁 分布式相关技术:分布式部署导致分布式锁、分布式事务、分布式登录(单点登录)、HDFS四个技术的...
  • 题记:在RAC数据库的故障当中,节点重启的现象很常见,在这种问题的处理当中,有一定的规律性。为了更好的说明这个问题的处理过程,保证出现该类问题的时候,能够有序的进行处理,特编写此文档。 问题现象描述 此...
  • 随着AI从云到边缘的发展,使得这一观点正在迅速改变,AI计算引擎使MCU能够突破嵌入式应用可能的极限,嵌入式设计已经能够提高网络攻击的实时响应能力和设备安全性。云计算推动了对具有AI功能的MCU的需求;它减少了...
  • 近日,BUMO 发布Oribts链技术MVP版本,该技术可大幅提高公链的扩展性和性能并突破“不可能三角”,所谓的区块链“不可能三角”,也称为“三元悖论”,就是指区块链网络无论采用哪种共识机制来决定新区块的生成方式...
  • 值得一提的是,目前 Plato 的算法库中的图特征、节点中心性指标、连通图和社团识别等多种算法都已经开源,未来还将进一步开源更的算法。 性能对比 据腾讯官方介绍,Plato 的计算性能遥遥领先于主流的分布式图...
  • 图神经网络(GNN)的简介

    万次阅读 多人点赞 2019-10-09 17:21:06
    GNN在对图节点之间依赖关系进行建模的强大功能,使得与图分析相关的研究领域取得了突破。本文介绍了图神经网络的基本原理,以及两种高级的算法,DeepWalk和GraphSage。 图(Graph) 在讨论GNN之前,我们先来了解一下...
  • 尽管当前数据中心融合了巨大的网络基础设施与众多相互连接的商用 CPU 服务器,可用于处理网络服务等大量交易型工作负载。但面对下一代人工智能和科学应用程序,这些数据中心的效率变得捉襟见肘。因为这些新型应用...
  • 然后,作者阐述了基于同样的网络结构如何来突破谷歌验证码识别系统的准确率。 为了亲身体验神经网络的实现,我决定尝试设计一个可以解决类似问题的系统:国内车牌号自动识别系统。设计这样一个系统的原因有3点: 我...
  • 现实世界中的大量问题都可以抽象成图模型(Graph Model),也就是节点和连边的集合。从知识图谱到概率图模型,从蛋白质相互作用网络到社交网络,从基本的逻辑线路到巨大的Internet,图与网络无处不在。然而传统的...
  • 分析了区块链的经典应用...随后,从公链的区块链底层架构系统性开发,到主节点系统、侧链、跨链、混合共识机制等技术实现,探讨公链架构设计思路以及实践中难点攻破,并结合Ulord公链搭建开发的实践案例进行分享。
  • 英文论文链接:http://research.microsoft.com/apps/pubs/default.aspx?id=240715翻译:卜居转载请注明出处:http://blog.csdn.net/kkk584520/article/details/47711755【摘要】最近在多层卷积神经网络突破导致了...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 32,406
精华内容 12,962
关键字:

多节点网络突破