kubernets的网络插件:flannel

伊布 · · 2605 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

kubernets的网络,从设计上来讲是“扁平、直接”的,即要求:

  • 所有容器可以不使用NAT技术就可以与其他容器通信
  • 所有节点(物理机 虚拟机 容器)都可以不使用NAT同容器通信
  • 容器看到的IP地址和别的机器看到的IP是一致的

docker的网络方案

docker的网络支持如下四种:

  • none
  • host,与宿主机共享,占用宿主机资源
  • container,使用某容器的namespace,例如k8s的同一pod内的各个容器
  • bridge,挂到网桥docker0上,走iptables做NAT

实际上还有一种方法:先以none的方式run起来容器,然后使用pipework为容器增加一个veth网卡,该veth的另一端挂到新建的网桥br0上;再将宿主机的物理网卡挂到该网桥br0上:

[容器内eth0]--veth--br0--en0-->

需要注意这种方法与bridge的不同。docker0的网段是172.17.0.1/16,当bridge模式时,容器的ip地址均为此网段下的,报文是走NAT出去的。但pipework自定义网络时,br0、[eth0]均与宿主机的en0同一网段,报文走网桥转发出去。

docker的网络能否满足需求呢?

bridge模式下,不同物理机的容器ip是完全的平行空间,可能相同,不能满足k8s扁平的要求;pipework方式能够满足k8s的要求,但是需要为每个容器都指定ip地址,比较啰嗦。

k8s的flannel模式

k8s本身并不提供网络方案,而是交给flannel,ovs等add-on来处理。这里只对flannel做说明。

flannel模式原理

flannel是一种over-lay网络。简单来说,over-lay即报文在进入实际物理网络之前,会经过一层UDP封装,作为payload到达对端;对端拿到UDP报文后解包,得到真实的用户报文后,再转到真实的接收方。

o

以绿色线的一个具体报文来说:

1、Pod内的一个容器使用pod的网络namespace,发送报文;该网络namespace上的网卡类型为veth,其pair网卡为宿主机网络namespace空间上的veth网卡veth0。veth是一种类似管道的网络设备,总是成对出现,报文从一端的veth网卡发送后,另一端的veth网卡会收到该报文。通常容器、虚拟机,会创建一对veth网卡,并将其中一端加到自己的namespace中。因此,宿主机的veth0网卡会收到容器发出的报文。

2、veth0拿到后,由于目的地址10.1.20.x与veth不在同一网段,因此会将报文交给网桥来转发。官方图示为docker0,但出于网络地址规划的原因,实际在k8s上会新建一个cni0网桥,cni0网桥负责本node容器的ip分配(24位掩码)。 这里有一个问题:各个node都有自己的cni0网桥,怎么保证地址不会分配重复呢?这里就是靠flannel了,flannel会根据全局统一的etcd来为每个node分配全集群唯一的网段,避免地址分配冲突。 cnio拿到报文后,查询本机路由,匹配的是16位掩码的flannel.1,因此将报文丢给flannel.1。

[root@note2 ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.181.254 0.0.0.0         UG    100    0        0 eno16780032
10.1.0.0        0.0.0.0         255.255.0.0     U     0      0        0 flannel.1
10.1.15.0       0.0.0.0         255.255.255.0   U     0      0        0 cni0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.181.0   0.0.0.0         255.255.255.0   U     100    0        0 eno16780032

3、flannel.1是个什么类型的网卡呢?图示的下一跳是flanneld,一个用户态进程(当然,这个进程已经包装在docker容器里了),这是怎么实现的呢? 这里需要重提一下linux上用户态和内核态通信的手段。一般来说,有以下几种:

  • netlink socket
  • syscall,例如调用用户态的read/write接口
  • IOCTL
  • procfs,例如读取/proc目录下的ip统计计数

还有一种手段,使用TUN/TAP接口

tun/tap驱动程序实现了虚拟网卡的功能,tun表示虚拟的是点对点设备,tap表示虚拟的是以太网设备,这两种设备针对网络包实施不同的封装。利用tun/tap驱动,可以将tcp/ip协议栈处理好的网络分包传给任何一个使用tun/tap驱动的进程,由进程重新处理后再发到物理链路中。开源项目openvpn( http://openvpn.sourceforge.net)和Vtun( http://vtun.sourceforge.net)都是利用tun/tap驱动实现的隧道封装

具体到k8s上,flanneld包装在flannel-git容器中,该容器与宿主机是同一网络namespace;flanneld启动时会创建flannel.1网卡,用来接收所有发送到10.1.0.0/16网络的报文;上面第2步报文转给flannel.1后,内核会将报文上送给flanneld。

[root@node1 ~]# docker ps
92197740eeef        quay.io/coreos/flannel-git:v0.6.1-62-g6d631ba-amd64   "/opt/bin/flanneld --"   22 hours ago        Up 22 hours                             k8s_kube-flannel.135690a3_kube-flannel-ds-ze30q_kube-system_ce4936c7-dd2c-11e6-9af1-000c29906342_1faf7ca4

4、flanneld维护了一份全局的node网络信息,根据报文目的地址查询得到该地址对应的node信息后,将报文封装到udp中(新报文的目的地址为对应node的地址),再将封装后的udp报文查询路由后经过物理网络(eno16780032)发送给目的node。

5、对端node收到报文后,走普通的查询路由为本机后上送用户态流程,封装报文交给flanneld。之后,报文解包、根据新包目的地址查路由,交给目的pod的容器。

[root@node1 ~]# netstat -anup|more
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
udp        0      0 0.0.0.0:8472            0.0.0.0:*   

flannel模式的优缺点

最大的缺点是,所有报文都需要走flanneld这个用户态进程进行一次封装后,才能出去。当网络流量较大时,flanneld将会成为瓶颈;相对来说,open vswitch可能稳定性、可靠性会更好一些。 但flannel也有ovs所不具备的优点:flannel能够通过etcd感知k8s的service变动,动态维护自己的路由表(第4步)。

部署及验证

1、部署 flannel部署比较简单。在master上kubeadm init完成后,执行下面的命令。该yaml定义了flannel容器以及相关的配置容器。有一些材料没有使用容器部署,相对来说复杂一点。

kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

之后查看kube-flannel的状态,Running则成功。此时k8s集群只有master一台机器,再登陆到2个node上,执行kubeadm join --token={token_id} master_ip将node加入到k8s集群中。最终在master上查看结果如下。

[root@localhost k8s]# kubectl get nodes
NAME                    STATUS    AGE
localhost.localdomain   Ready     1d
node1                   Ready     23h
note2                   Ready     23h
[root@localhost k8s]#
[root@localhost k8s]# kubectl get pods -n kube-system
NAME                                            READY     STATUS    RESTARTS   AGE
dummy-2088944543-vafe7                          1/1       Running   0          1d
etcd-localhost.localdomain                      1/1       Running   1          1d
kube-apiserver-localhost.localdomain            1/1       Running   1          1d
kube-controller-manager-localhost.localdomain   1/1       Running   0          1d
kube-discovery-982812725-5j9ri                  1/1       Running   0          1d
kube-dns-2247936740-gqifl                       3/3       Running   0          1d
kube-flannel-ds-kfcpe                           2/2       Running   0          1d
kube-flannel-ds-klmfz                           2/2       Running   7          23h
kube-flannel-ds-ze30q                           2/2       Running   4          23h
kube-proxy-amd64-2yx0g                          1/1       Running   0          1d
kube-proxy-amd64-hcj9t                          1/1       Running   0          23h
kube-proxy-amd64-vhevz                          1/1       Running   0          23h
kube-scheduler-localhost.localdomain            1/1       Running   1          1d

在node上,可以看到flannel.1等网卡信息。

2、验证

将下面的RC保存为alpine.yaml。

apiVersion: v1
kind: ReplicationController
metadata:
  name: alpine
  labels:
    name: alpine
spec:
  replicas: 2
  selector:
    name: alpine
  template:
    metadata:
      labels:
        name: alpine
    spec:
      containers:
        - image: mritd/alpine:3.4
          imagePullPolicy: Always
          name: alpine
          command:
            - "bash"
            - "-c"
            - "while true;do echo test;done"
          ports:
            - containerPort: 8080
              name: alpine

并创建namespace、apply。

kubectl create namespace alpine
kubectl apply -n alpine -f alpine.yml

等待一段时间后,在master上查看apply情况(-o wide可以看到更多信息,即IP/node):

[root@localhost k8s]# kubectl get pods -n alpine -o wide
NAME           READY     STATUS    RESTARTS   AGE       IP           NODE
alpine-4zmey   1/1       Running   0          23h       10.244.1.2   note2
alpine-55zej   1/1       Running   0          23h       10.244.2.2   node1

2个pod分别跑在2个node上(前面yml定义的replicas为2)。

登陆到其中一个node上,进入对应的容器docker exec -it {docker_id} bash,ping对端的ip地址看是否通。如果不通,可能你使用的也是CentOS操作系统,它的iptables默认会丢弃所有报文并回复icmp-host-prohibited,所以需要将flanneld监听的8472端口/udp协议的报文加到INPUT链上,各个物理node上都要执行。 当然,我觉得更好的做法是flannel自己来加这条规则。

[root@node1 ~]# iptables -I INPUT -p udp -m udp --dport 8472 -j ACCEPT
[root@node1 ~]#
[root@node1 ~]# iptables -L -n|more
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:8472
...
REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

在物理网卡上抓了个包,可以看到该UDP包的payload中黑色横线标记的2个ip地址。

包

以上。



有疑问加站长微信联系(非本文作者)

本文来自:ieevee.com

感谢作者:伊布

查看原文:kubernets的网络插件:flannel

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

2605 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传
X
登录和大家一起探讨吧