滴普技术荟-云原生基座OpenKube开放容器实践（二）：理解linux虚拟网络设备veth

前言

前面介绍了linux network namespace，接着介绍一下如何让一个独立的网络命名空间和主机的网络互通，这里我们需要用到linux虚拟网络设备veth。

veth设备

veth是linux的一种虚拟网络设备，它有点类似于两张网卡中间用一条网线连着，veth设备总是成对出现，通常用来连接不同网络命名空间（下面开始简称NS），一端连着NS1的内核协议栈，另一端连着NS2的内核协议栈，一端发送的数据会立刻被另一端接收。

接下来我们通过一些示例来理解veth设备，我们创建一个新的NS，然后跟主机的NS连接起来通过下面的命令可以创建一对veth设备：

然后创建一个名为ns1的network namespace ：

然后把刚创建的veth1网卡的其中一端转到ns1，这就好像一端插到ns1上，另一端插在主机的ns上：

给veth的两端都配置个IP，设置veth0时，要用ip netns exec ns1，因为veth0此时在ns1中：

此时的状态如下：

这时候主机和ns1已经可以相互ping通了：

如果我们进到ns1中发现ping localhost不通的话，有可能只是因为lo网卡没有启动起来

如果我们进到ns1中发现ping localhost不通的话，有可能只是因为lo网卡没有启动起来

这条路由指示以后凡是往192.168.10.0/24这个网段的地址都给veth1,这显然不是我们想要的结果，因为其它的ns并没有连在veth1上。在k8s的节点上，相同主机的pod通常会在同一个子网段里，前面那条路由就相当于把这个主机的全部pod的通信都引到了veth1上，这就有问题了。其实，我们是可以不在veth1上配置IP的，上面的示例只是为了让大家可以对veth连接的效果有个认识，因为veth1连的是主机的内核协议栈，主机上已经有很多个IP了，只是因为当前ns1中没有默认路由，去主机的IP的话是不通的（当然如果你的主机的网段本来就是192.168.10.0/24网段，那又是能通的），所以如果不配置veth1端的IP的话，只要加上默认路由就可以了，下面我们演示一个更实用的场景。

另一种方法

直接上命令，跟上面的差不多，也是建一对veth网卡，一端转到新的ns上，在这就不一句句解释了：

打开主机这一端veth3的arp代答：

给ns2加上默认路由：

在主机上添加去往ns2路由：

为什么ns2的默认路由是个这么奇怪的IP？后面会解释。
此时整个状态如下图：

这时候ping一下ns2，发现通了：

那ns1和ns2能不能相互ping通呢？行的，不过要先打开veth1的arp代答，并给ns1配个默认网关

如无意外，在ns1上ping ns2应该是通了，记得要打开主机的路由转发功能：

简单解释一下为什么给ns2设置的默认网关是169.2.2.2,其实默认网关的IP在整个通信的过程中都不会用到，想一下数据包发送流程，当ns2的要发一个包去主机时，封完IP头后，到了链路层，协议栈的路由判决已经决定了下一跳为默认网关，这时候邻居子系统会从ns1的邻居表（也就是ARP表）查找下一跳IP的MAC地址，找不到就会发送ARP请求，这时候ARP请求到了对端veth3，因为veth3开启了arp代答，所以会直接把自己的MAC地址返回去，这样ns2的邻居子系统会以为自己得到了网关的MAC地址，于是完成MAC头的封装，把数据包发送到veth1，所以其实在这里的默认网关的IP可以随便写一个非当前网段的地址。

总结

上面介绍了在主机与容器相互连接的两种方法，还有第三种方法就是用linux bridge，下一章介绍linux bridge。

欢迎关注滴普科技官网 http://datasink-sensors.deepexi.top/t/ka