k8s 网络模型解析之原理
今天研究了一下k8s的网络模型，该解析基于flannel vxlan+ kubeproxy iptables 模式。
一.Docker
首先分析一下Docker层面的网络模型，我们知道容器是基于内核的namespace机制去实现资源的隔离的。network是众多namespace中的一个，那么如何保证一个节点上容器之间的通信呢？Docker的做法是通过虚拟网桥来桥接虚拟网卡。下面具体解释一下。
首先每一个容器在默认情况下都是在自己的network namespace里面的，也就是说默认情况下它只有一个自己独立的localhost网络(或者是什么网络设备也没有？TBD)，无法与外部进行通信。为了解决这个问题，Docker创建了一对veth pair, 这个veth pair总是承兑出现，可以理解为一对端口，所有从一头进去的数据都会从另一头出来。然后docker 会把这对veth pair的一头加入到容器的namespace中，另一头桥接到一个虚拟网桥上， 这个虚拟网桥实际上就是宿主机上的docker0网卡，我们可以通过以下指令来观察：
[wlh@meizu storage]$ brctl show
bridge name bridge id STP enabled interfaces
docker0 .02422551422b no veth43dc241
veth551eae5
veth844b02c
vethd06364a
vethe95e44c
上图可以看到docker0上面桥接的各个容器的veth设备，这样容器内的通信就可以沿着vethA-1 -> vethA-2 -> docker0 -> vethB-2 -> vethB-1流动了
2. Flannel
Docker实现了同一节点上容器之间的通信，那么k8s作为一个容器编排平台，如何实现不同节点上容器的通信呢？这需要第三方插件的支持，目前有多种overlay network解决方案，这里介绍其中比较简单的一种, flannel。flannel目前支持三种工作模式：vxlan, udp, host-gw，其中udp和vxlan比较像，udp是flannel程序自己在用户态下将报文封装，而vxlan是内核对报文进行处理，因此udp会比较慢。所以udp不推荐在生产环境下使用，只是用于debug。而host-gw模式需要所有节点与其他任一节点间都有直接路由（具体可以查阅相关文章）， 这里我们使用vxlan作为工作模式进行讲解。
在工作的时候，flannel会从k8s的etcd存储中同步数据，包括使用的工作模式和集群中其它节点的子网。例如，在我的机器上，其etcd中存储的数据为：
[wlh@xiaomi xuexi]$ etcdctl ls /kube-fujitsu/network
/kube-fujitsu/network/config
/kube-fujitsu/network/subnets [wlh@xiaomi xuexi]$ etcdctl get /kube-fujitsu/network/config
{"Network":"172.30.0.0/16","SubnetLen":,"Backend":{"Type":"vxlan"}} [wlh@xiaomi xuexi]$ etcdctl ls /kube-fujitsu/network/subnets
/kube-fujitsu/network/subnets/172.30.20.0-
/kube-fujitsu/network/subnets/172.30.44.0-
/kube-fujitsu/network/subnets/172.30.83.0- [wlh@xiaomi xuexi]$ etcdctl get /kube-fujitsu/network/subnets/172.30.83.0-
{"PublicIP":"10.167.226.38","BackendType":"vxlan","BackendData":{"VtepMAC":"b6:c7:0f:7f:66:a7"}}
这里第6行中的172.30.0.0/16表示的是整个集群的子网段， 而8/9/10三行分别代表了三个节点，每创建一个新的节点，都会从172.30.0.0/16中再分配一个子网给它。各个节点上的flannel进程读取etcd中的这些配置，然后修改自己节点上的docker进程的启动参数，在其中添加一个--bip=172.30.20.1/24，这样该节点上docker启动的所有容器都会在这个子网段里。通过这些设定，保证了集群中所有的容器之间ip地址是不会重复的。
解决了容器ip地址重复的问题后，下面就是实现容器跨节点通信了。在vxlan模式下，flannel会在节点上创建一个虚拟网卡叫flannel.1，它的MAC地址就是上面输出中的VtepMAC。同样的节点的路由表也会被修改，如下图所示：
[wlh@meizu storage]$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
//....more
172.30.20.0 0.0.0.0 255.255.255.0 U docker0
172.30.44.0 172.30.44.0 255.255.255.0 UG flannel.
172.30.83.0 172.30.83.0 255.255.255.0 UG flannel.
这里可以看到，目的地址为172.30.20.0/24的都会被发到docker0，这其实就是本主机上的容器。而其他节点上的容器则会被路由到flannel.1网卡上进行处理。flannel将flannel.1网卡上收到的数据进行处理，加上flannel规定好的报文头，然后从绑定的网卡中发出去。这个封装好的报文是udp协议，目标地址是容器所在的节点的物理地址，并且其默认端口是8472(udp模式的默认端口是8285)。也就是说vxlan模式的底层实现也是用udp报文发送的，只是vxlan模式中报文封装是在内核态中完成，而udp模式中报文封装是在用户态完成。目标容器所在的主机上，flannel会监听8472端口，去掉报文的flannel头，然后传送给docker0网卡，docker0网卡收到的就是普通的容器通信的报文，不会感知到底层的这些处理。
3. kube-proxy
我们知道，k8s中有service的概念，它拥有自己的ip地址。那么对service的访问是如何分发给后端的pod呢。这些工作是由kube-proxy完成的，它有三种工作模式，userspace(older), iptables(faster),ipvs(experimental)。其中userspace是早期的模式，它本质上是利用kube-proxy做一个代理，所有对service的访问都会转发给kube-proxy组件，然后由它再分发请求到pod。显然这种模式对于一个大规模集群来说是一个速度瓶颈。iptables模式是通修改iptable来实现请求分发的。ipvs模式不太了解。
下面以一个例子来具体说明iptables模式。首先创建下面列出的deployment和service:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
labels:
name: nginx
spec:
selector:
matchLabels:
name: nginx1
replicas:
template:
metadata:
labels:
name: nginx1
spec:
nodeName: meizu
containers:
- name: nginx
image: nginx
ports:
- containerPort:
---
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
name: nginx1
spec:
ports:
- port:
targetPort:
selector:
name: nginx1
[wlh@xiaomi xuexi]$ kubectl get pod -o wide|grep nginx
nginx-cb648c7f5-c8h26 1/1 Running 0 24m 172.30.20.7 meizu <none> <none>
nginx-cb648c7f5-pptl9 1/1 Running 0 40m 172.30.20.6 meizu <none> <none>
nginx-cb648c7f5-zbsvz 1/1 Running 0 24m 172.30.20.8 meizu <none> <none> [wlh@xiaomi xuexi]$ kubectl get svc -o wide
nginx ClusterIP 10.254.40.119 <none> 4432/TCP 38m name=nginx1
这里创建一个service，在4432端口向外提供简单的nginx service。观察到这些资源被创建以后，kube-proxy会在节点上的iptables的NAT表中添加以下规则：
[wlh@meizu storage]$ sudo iptables-save|grep nginx
-A KUBE-SERVICES ! -s 10.254.0.0/ -d 10.254.40.119/ -p tcp -m comment --comment "default/nginx: cluster IP" -m tcp --dport -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 10.254.40.119/ -p tcp -m comment --comment "default/nginx: cluster IP" -m tcp --dport -j KUBE-SVC-4N57TFCL4MD7ZTDA
[wlh@meizu storage]$ sudo iptables-save|grep 0x4000/0x4000
-A KUBE-MARK-MASQ -j MARK --set-xmark 0x4000/0x4000
-A KUBE-POSTROUTING -m comment --comment "kubernetes service traffic requiring SNAT" -m mark --mark 0x4000/0x4000 -j MASQUERADE
-A KUBE-FORWARD -m comment --comment "kubernetes forwarding rules" -m mark --mark 0x4000/0x4000 -j ACCEPT
输出的第一行是做一个标记，意思是所有发往10.254.40.118:4432(nginx服务)的请求（除了source ip 为10.254.0.0/16的报文）都会被打上一个标记，这个报文被打上这个标记后会在filter表中进行后续处理。在filter表中会对打上标记的报文进行MASQUERADE处理，实际上就是SNAT，将报文的source ip地址转化为本地主机物理网卡的地址，然后再发出去，否则如果直接用容器的ip地址的话，物理网络很显然是不会认识这个地址的。
输出的第二行的作用是所有发往10.254.40.119:4432(也就是service) 的地址，全部跳到KUBE-SVC-4N57TFCL4MD7ZTDA进行处理，那么这个KUBE-SVC-4N57TFCL4MD7ZTDA 是啥呢？
[wlh@xiaomi prensentation]$ sudo iptables-save|grep KUBE-SVC-4N57TFCL4MD7ZTDA
:KUBE-SVC-4N57TFCL4MD7ZTDA - [:]
-A KUBE-SERVICES -d 10.254.40.119/ -p tcp -m comment --comment "default/nginx: cluster IP" -m tcp --dport -j KUBE-SVC-4N57TFCL4MD7ZTDA
-A KUBE-SVC-4N57TFCL4MD7ZTDA -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-TMIUL2YW4YRKUWF7
-A KUBE-SVC-4N57TFCL4MD7ZTDA -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-H2SQHV5FZD5TQOIZ
-A KUBE-SVC-4N57TFCL4MD7ZTDA -j KUBE-SEP-GK74E3IZTU4ZAMUJ
这里的输出中，第二行是统计流量的，和我们本篇文章关系不大。第三行之前分析过了， 第四五六行实际上就是load balance, 这里集群启动了三个pod作为这个service的后端，对应的有三个服务节点，分别被赋予了访问概率。四五六行中最后的KUBE-SEP自然就是对应了各自的pod了。以第四行为例：
[wlh@xiaomi prensentation]$ sudo iptables-save|grep KUBE-SEP-TMIUL2YW4YRKUWF7
:KUBE-SEP-TMIUL2YW4YRKUWF7 - [:]
-A KUBE-SEP-TMIUL2YW4YRKUWF7 -s 172.30.20.6/ -j KUBE-MARK-MASQ
-A KUBE-SEP-TMIUL2YW4YRKUWF7 -p tcp -m tcp -j DNAT --to-destination 172.30.20.6:
-A KUBE-SVC-4N57TFCL4MD7ZTDA -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-TMIUL2YW4YRKUWF7
第四行定义了具体的下一跳，这边的意思是所有跳到这里的请求全部进行DNAT操作，将目标地址改为172.30.20.6:80。这样结合前面的利用KUBE-MARK-MASQ打标记然后转换源地址的操作，整个访问就变成：
source ip des ip
pod ip -> service
host ip -> backend pod ip
最新文章
- Ubuntu 14.04安装mysql
- keil 怎样新建工程,编写代码?
- basket.js 源码分析
- nginx 服务器重启命令，关闭 (转)
- Open vSwitch使用案例扩展实验
- threading模块和queue模块实现程序并发功能和消息队列
- hdu1828(线段树+扫描线)
- Linux 中/etc/profile、~/.bash_profile 等几个环境配置文件的执行过程
- OpenJudge/Poj 1207 The 3n + 1 problem
- Java 编程的动态性，第3部分: 应用反射--转载
- java 7K交通灯管理系统面试题
- Unity插件系列之二维码
- JDK1.8源码(十)——java.util.LinkedHashSet类
- 在vim下打开终端
- Android TextView 跑马灯效果 - 2018年6月19日
- HTM L百度地图API 自定义工具地图实例
- C#中的命名空间namespace与Java中的包package之间的区别
- C++ vs Python向量运算速度评测
- count(*) count(1) count(column)区别
- 锁机制(Lock) 信号量机制(Semaphore) 事件机制(Event)