036.集群网络-K8S网络模型及Linux基础网络

一 kubernetes网络模型概述

1.1 kubernetes网络模型

kubernetes网络模型设计的一个基础原则是：每个pod都拥有一个独立的ip地址，并假定所有pod都在一个可以直接连通的、扁平的网络空间中。所以不管它们是否运行在同一个node（宿主机）中，都要求它们可以直接通过对方的ip进行访问。设计这个原则的原因是，用户不需要额外考虑如何建立pod之间的连接，也不需要考虑如何将容器端口映射到主机端口等问题。

实际上，在kubernetes的集群里，ip是以pod为单位进行分配的。一个pod内部的所有容器共享一个网络堆栈（相当于一个网络命名空间，它们的ip地址、网络设备、配置等都是共享的）。按照这个网络原则抽象出来的为每个pod都设置一个ip地址的模型也被称作ip-per-pod模型。

由于kubernetes的网络模型假设pod之间访问时使用的是对方pod的实际地址，所以一个pod内部的应用程序看到的自己的ip地址和端口与集群内其他pod看到的一样。它们都是pod实际分配的ip地址。将ip地址和端口在pod内部和外部都保持一致，也就不需要使用nat来进行地址转换了。

kubernetes的网络之所以这么设计，主要原因就是可以兼容过去的应用。当然，我们使用linux命令“ipaddrshow”也能看到这些地址，和程序看到的没有什么区别。所以这种ip-per-pod的方案很好地利用了现有的各种域名解析和发现机制。

为每个pod都设置一个ip地址的模型还有另外一层含义，那就是同一个pod内的不同容器会共享同一个网络命名空间，也就是同一个linux网络协议栈。这就意味着同一个pod内的容器可以通过localhost来连接对方的端口。这种关系和同一个vm内的进程之间的关系是一样的，看起来pod内容器之间的隔离性减小了，而且pod内不同容器之间的端口是共享的，就没有所谓的私有端口的概念了。如果应用必须要使用一些特定的端口范围，那么也可以为这些应用单独创建一些pod。反之，对那些没有特殊需要的应用，由于pod内的容器是共享部分资源的，所以可以通过共享资源互相通信，这显然更加容易和高效。针对这些应用，虽然损失了可接受范围内的部分隔离性，却也是值得的。

ip-per-pod模式和docker原生的通过动态端口映射方式实现的多节点访问模式有如下差别：

• 主要区别是后者的动态端口映射会引入端口管理的复杂性，而且访问者看到的ip地址和端口与服务提供者实际绑定的不同（因为nat的缘故，它们都被映射成新的地址或端口了），这也会引起应用配置的复杂化。
• 同时，标准的dns等名字解析服务也不适用了，甚至服务注册和发现机制都比较复杂，因为在端口映射情况下，服务自身很难知道自己对外暴露的真实的服务ip和端口，外部应用也无法通过服务所在容器的私有ip地址和端口来访问服务。

总的来说，ip-per-pod模型是一个简单的兼容性较好的模型。从该模型的网络的端口分配、域名解析、服务发现、负载均衡、应用配置和迁移等角度来看，pod都能够被看作一*立的虚拟机或物理机。

按照这个网络抽象原则，kubernetes对网络有如下要求。

1. 所有容器都可以在不用nat的方式下同别的容器通信。
2. 所有节点都可以在不用nat的方式下同所有容器通信，反之亦然。
3. 容器的地址和别人看到的地址是同一个地址。

这些基本要求意味着并不是只要两台机器都运行docker，kubernetes就可以工作了。具体的集群网络实现必须满足上述基本要求，原生的docker网络目前还不能很好地支持这些要求。

实际上，这些对网络模型的要求并没有降低整个网络系统的复杂度。如果程序原来在vm上运行，而那些vm拥有独立ip，并且它们之间可以直接透明地通信，那么kubernetes的网络模型就和vm使用的网络模型一样。所以使用这种模型可以很容易地将已有的应用程序从vm或者物理机迁移到容器上。

当然，谷歌设计kubernetes的一个主要运行基础就是其公有云gce，gce默认支持这些网络要求。另外，常见的其他公有云服务商如亚马逊等，其公有云环境也支持这些网络要求。

由于部署私有云的场景也非常普遍，所以在私有云中运行kubernetes+docker集群之前，需要自己搭建出符合kubernetes要求的网络环境。有很多开源组件可以帮助我们打通docker容器和容器之间的网络，实现满足kubernetes要求的网络模型。当然，每种方案都有适合的场景，需要根据自己的实际需要进行选择。

提示：kubernetes的网络依赖于docker，docker的网络又离不开linux操作系统内核特性的支持。

二 docker网络基础

docker本身的技术依赖于近年来linux内核虚拟化技术的发展，所以docker对linux内核的特性有很强的依赖。docker通常使用到的与linux网络有关的主要技术有：网络命名空间（network namespace）、veth设备对、网桥、ipatables和路由。

2.1 网络命名空间

为了支持网络协议栈的多个实例，linux在网络栈中引入了网络命名空间，这些独立的协议栈被隔离到不同的命名空间中。

处于不同命名空间中的网络栈是完全隔离的，彼此之间无法通信。通过对网络资源的隔离，就能在一个宿主机上虚拟多个不同的网络环境。docker正是利用了网络的命名空间特性，实现了不同容器之间的网络隔离。在linux的网络命名空间中可以有自己独立的路由表及独立的iptables设置来提供包转发、nat及ip包过滤等功能。

为了隔离出独立的协议栈，需要纳入命名空间的元素有进程、套接字、网络设备等。进程创建的套接字必须属于某个命名空间，套接字的操作也必须在命名空间中进行。同样，网络设备也必须属于某个命名空间。因为网络设备属于公共资源，所以可以通过修改属性实现在命名空间之间移动。

• 网络命名空间的实现

linux的网络协议栈相对复杂，为了支持独立的协议栈，相关的这些全局变量都必须被修改为协议栈私有。最好的办法就是让这些全局变量成为一个net namespace变量的成员，然后为协议栈的函数调用加入一个namespace参数。这就是linux实现网络命名空间的核心。

同时，为了保证对已经开发的应用程序及内核代码的兼容性，内核代码隐式地使用了命名空间中的变量。程序如果没有对命名空间有特殊需求，就不需要编写额外的代码，网络命名空间对应用程序而言是透明的。

在建立了新的网络命名空间，并将某个进程关联到这个网络命名空间后，就出现了类似于下图所示的内核数据结构，所有网站栈变量都被放入了网络命名空间的数据结构中。这个网络命名空间是其进程组私有的，和其他进程组不冲突。

在新生成的私有命名空间中只有回环设备（名为“lo”且是停止状态），其他设备默认都不存在，若需要其他设备，则要手工建立。

从网络角度，每个namespace提供了一份独立的网络协议栈（网络设备接口、ipv4、ipv6、ip路由、防火墙规则、sockets等）。一个设备（linux device）只能位于一个namespace中，不同namespace中的设备可以利用veth pair进行桥接。

namespace可实现隔离的资源：

资源	含义
uts_ns	uts为unix timessharing system的简称，包含内存名称、脚本、版本、底层体系结构等信息。
ipc_ns	所有与进程通信（ipc）有关的信心。
nmt_ns	当前装载的文件系统。
pid_ns	有关进程id的信息。
user_ns	资源配额的信息。
net_ns	网络信息。

docker容器中的各类网络栈设备都是docker daemon在启动时自动创建和配置的。

所有的网络设备（物理的或虚拟接口、桥等在内核里都叫作netdevice）都只能属于一个命名空间。

注意，物理设备（连接实际硬件的设备）通常只能关联到root这个命名空间中。虚拟的网络设备（虚拟的以太网接口或者虚拟网口对）则可以被创建并关联到一个给定的命名空间中，而且可以在这些命名空间之间移动。

同时，由于网络命名空间代表的是一个独立的协议栈，所以它们之间是相互隔离的，彼此无法通信，在协议栈内部都看不到对方。

若需要打破这种限制，让处于不同命名空间的网络相互通信，甚至和外部的网络进行通信，则需要应用veth设备对。veth设备对的一个重要作用就是打通互相看不到的协议栈之间的壁垒，类似一个通道，一端连着这个网络命名空间的协议栈，一端连着另一个网络命名空间的协议栈。所以如果想在两个命名空间之间通信，就必须有一个veth设备对。

• 网络命名空间操作

如下命令需要使用root用户执行，同时需要iproute软件包提供相关命令。

  1 [root@k8smaster01 ~]# ip netns add mytestns			#创建命名空间
  2 [root@k8smaster01 ~]# ip netns exec mytestns <command>	#进入命名空间bash
  3 [root@k8smaster01 ~]# ip netns exec mytestns bash		#进入命名空间bash
  4 [root@k8smaster01 ~]# exit					#退出命名空间
  5 [root@k8smaster01 ~]# ip link set <device> netns mytestns	#转移设备

注意：因为一个设备只能属于一个命名空间，所以转移后在这个命名空间中就看不到这个设备了。在设备里面有一个重要的属性：netif_f_etns_local，如果这个属性为on，就不能被转移到其他命名空间中。veth设备属于可以转移的设备，而很多其他设备如lo设备、vxlan设备、ppp设备、bridge设备等都是不可以转移的。

2.2 veth设备对

引入veth设备对是为了在不同的网络命名空间之间通信，利用它可以直接将两个网络命名空间连接起来。由于要连接两个网络命名空间，所以veth设备都是成对出现的，很像一对以太网卡，并且中间有一根直连的网线。通常将其中一端称为另一端的peer。

在veth设备的一端发送数据时，它会将数据直接发送到另一端，并触发另一端的接收操作。veth设备对的示意图如下：

• veth pair操作

  1 [root@k8smaster01 ~]# ip link add veth0 type veth peer name veth1	#创建veth设备对
  2 [root@k8smaster01 ~]# ip link show | grep veth			#当前查看veth
  3 [root@k8smaster01 ~]# ip netns add ns0
  4 [root@k8smaster01 ~]# ip netns add ns1				#创建命名空间
  5 [root@k8smaster01 ~]# ip link set veth0 netns ns0
  6 [root@k8smaster01 ~]# ip link set veth1 netns ns1			#veth移入命名空间
  7 [root@k8smaster01 ~]# ip netns exec ns0 ip link show		#进入命名空间查看veth
  8 [root@k8smaster01 ~]# ip netns exec ns0 ip addr add local 192.168.10.1/24 dev veth0
  9 [root@k8smaster01 ~]# ip netns exec ns1 ip addr add local 192.168.10.2/24 dev veth1	#设置对应的ip
 10 [root@k8smaster01 ~]# ip netns exec ns0 ifconfig veth0 up
 11 [root@k8smaster01 ~]# ip netns exec ns1 ifconfig veth1 up		#开启设备
 12 [root@k8smaster01 ~]# ip netns exec ns0 ping 192.168.10.2		#连通性测试

提示：在docker内部，veth设备对也是连通容器与宿主机的主要网络设备。

  1 [root@k8smaster01 ~]# ip netns exec ns0 ethtool -s veth0
  2 nic statistics:
  3      peer_ifindex: 9
  4 [root@k8smaster01 ~]# ip netns exec ns1 ip link | grep 9

2.3 网桥

linux可以支持多个不同的网络，它们之间能够相互通信，可通过网桥将这些网络连接起来并实现各网络中主机的相互通信。

网桥是一个二层的虚拟网络设备，把若干个网络接口“连接”起来，以使得网络接口之间的报文能够互相转发。网桥能够解析收发的报文，读取目标mac地址的信息，和自己记录的mac表结合，来决策报文的转发目标网络接口。

为了实现转发功能，网桥学习源mac地址（二层网桥转发的依据就是mac地址）。在转发报文时，网桥只需要向特定的网口进行转发，来避免不必要的网络交互。如果接受到未学习到的地址，就无法知道这个报文应该向哪个网络接口转发，就将报文广播给所有的网络接口（报文来源的网络接口除外）。

在实际的网络中，网络拓扑若出现改变，如设备被移动到另一个端口上，却没有发送任何数据，网桥设备就无法感知到这个变化，网桥还是向原来的端口转发数据包，在这种情况下数据就会丢失。所以网桥还要对学习到的mac地址表加上超时时间（默认为5min）。如果网桥收到了对应端口mac地址回发的包，则重置超时时间，否则过了超时时间后，就认为设备已经不在那个端口上了，它就会重新广播发送。

对于多网卡、多虚拟的设备，linux的网桥提供了在这些设备之间互相转发数据的二层设备。linux内核支持网口的桥接（目前只支持以太网接口）。但是与单纯的交换机不同，交换机只是一个二层设备，对于接收到的报文，要么转发，要么丢弃。运行着linux内核的机器本身就是一台主机，有可能是网络报文的目的地，其收到的报文除了转发和丢弃，还可能被送到网络协议栈的上层（网络层），从而被自己（这台主机本身的协议栈）消化，所以既可以把网桥看作一个二层设备，也可以把它看作一个三层设备。

• linux网桥的实现

linux内核是通过一个虚拟的网桥设备（net device）来实现桥接的。这个虚拟设备可以绑定若干个以太网接口设备，从而将它们桥接起来。如下图所示，这种net device网桥和普通的设备不同，最明显的一个特性是还可以有一个ip地址。

如上图所示，网桥设备br0绑定了eth0和eth1。对于网络协议栈的上层来说，只看得到br0就行。因为桥接是在数据链路层实现的，上层不需要关心桥接的细节，所以协议栈上层需要发送的报文被送到br0，网桥设备的处理代码判断报文该被转发到eth0还是eth1，或者两者皆转发；反之，从eth0或从eth1接收到的报文被提交给网桥的处理代码，在这里会判断报文应该被转发、丢弃还是被提交到协议栈上层。而有时eth0、eth1也可能会作为报文的源地址或目的地址，直接参与报文的发送与接收，从而绕过网桥。

• 网桥的常用操作命令

docker自动完成了对网桥的创建和维护。

新增一个网桥设备：

[root@k8smaster01 ~]# brctl #查看brctl模块

提示：可通过# yum -y install bridge-utils安装brctl。

为网桥增加网口，在linux中，一个网口其实就是一个物理网卡。

  1 [root@k8smaster01 ~]# ip link add tap1 type veth peer name tap1_peer
  2 [root@k8smaster01 ~]# ip link add tap2 type veth peer name tap2_peer
  3 [root@k8smaster01 ~]# ip link add tap3 type veth peer name tap3_peer
  4 [root@k8smaster01 ~]# ip link add tap4 type veth peer name tap4_peer
  5 #创建veth pair
  6 [root@k8smaster01 ~]# ip netns add ns1
  7 [root@k8smaster01 ~]# ip netns add ns2
  8 [root@k8smaster01 ~]# ip netns add ns3
  9 [root@k8smaster01 ~]# ip netns add ns4
 10 #创建namespace
 11 [root@k8smaster01 ~]# ip link set tap1 netns ns1
 12 [root@k8smaster01 ~]# ip link set tap2 netns ns2
 13 [root@k8smaster01 ~]# ip link set tap3 netns ns3
 14 [root@k8smaster01 ~]# ip link set tap4 netns ns4
 15 #tap和namespace关联
 16 [root@k8smaster01 ~]# brctl addbr br1		#创建桥
 17 [root@k8smaster01 ~]# brctl addif br1 tap1_peer
 18 [root@k8smaster01 ~]# brctl addif br1 tap2_peer
 19 [root@k8smaster01 ~]# brctl addif br1 tap3_peer
 20 [root@k8smaster01 ~]# brctl addif br1 tap4_peer
 21 #把相应的tap添加至bright中
 22 [root@k8smaster01 ~]# ip netns exec ns1 ip addr add local 192.168.20.1/24 dev tap1
 23 [root@k8smaster01 ~]# ip netns exec ns2 ip addr add local 192.168.20.2/24 dev tap2
 24 [root@k8smaster01 ~]# ip netns exec ns3 ip addr add local 192.168.20.3/24 dev tap3
 25 [root@k8smaster01 ~]# ip netns exec ns4 ip addr add local 192.168.20.4/24 dev tap4
 26 #配置相应ip地址
 27 [root@k8smaster01 ~]# ip link set br1 up
 28 [root@k8smaster01 ~]# ip link set tap1_peer up
 29 [root@k8smaster01 ~]# ip link set tap2_peer up
 30 [root@k8smaster01 ~]# ip link set tap3_peer up
 31 [root@k8smaster01 ~]# ip link set tap4_peer up
 32 [root@k8smaster01 ~]# ip netns exec ns1 ip link set tap1 up
 33 [root@k8smaster01 ~]# ip netns exec ns2 ip link set tap2 up
 34 [root@k8smaster01 ~]# ip netns exec ns3 ip link set tap3 up
 35 [root@k8smaster01 ~]# ip netns exec ns4 ip link set tap4 up
 36 #将bright和tap设置为up
 37 [root@k8smaster01 ~]# ip netns exec ns1 ping 192.168.20.2		#互ping

提示：若物理网卡作为网桥的一个网口，则此物理网卡将在链路层工作（是一个纯链路层设备），就不再需要ip地址了，可以取消物理网卡的ip，给网桥配置一个ip地址。

2.4 iptables和netfilter

linux提供了一套机制来为用户实现自定义的数据包处理过程。在linux网络协议栈中有一组回调函数挂接点，通过这些挂接点挂接的钩子函数可以在linux网络栈处理数据包的过程中对数据包进行一些操作，例如过滤、修改、丢弃等。

整个挂接点技术叫作netfilter和iptables。netfilter负责在内核中执行各种挂接的规则，运行在内核模式中；而iptables是在用户模式下运行的进程，负责协助和维护内核中netfilter的各种规则表。二者互相配合来实现整个linux网络协议栈中灵活的数据包处理机制。

• iptables规则

iptables内置三张表：filter、nat和mangle。

• filter：实现防火墙功能；
• nat：实现nat功能；
• mangle：实现流量整形。

iptables三张表，或三条链（chain），也是三种策略（policy）。这类策略，由不同规则（rule）串联而成。

提示：更多iptables知识参考：https://wiki.archlinux.org/index.php/iptables_(%e7%ae%80%e4%bd%93%e4%b8%ad%e6%96%87)。

规则示例：iptables - a input - i etho -p icmp -j accept

解释：允许所有从 etho 端口进入且协议是 icmp 的报文可以接受（可以进入下一个流程）。

规则的本质是对进入的ip报文进行说明，如：符合什么样的条件（比如本条命令的条件是“允许所有从eth0端口进入且协议是 icpm 的报文”）、做什么样的处理（比如本条命令的处理是“接受”，可以进入下一个流程）。

查看系统中已有规则的方法如下。

• iptables-save： 按照命令的方式打印iptables的内容。
• iptables-vnl： 以另一种格式显示netfilter表的内容。

• netfilter规则

iptables可以定义多种策略／规则，所有规则最终会传递到内核netfilter模块，netfilter模块会根据这些规则做相应的处理。

netfilter的处理方式是：从报文进入本机（ linux host 或 vm）的那一刻起，到报文离开本机的那一刻止，中间这段时间（或者是发自本机的报文，从报文准备发送的那一刻，到报文离开本机的那一刻止，中间这段时间），netfilter 会在abcde时刻点插入处理模块，这些处理模块根据相应的策略／规则对报文进行处理。

对于 nat 、 filter 、 mangle 三张表也可以这么理解：仅仅是为了达到不同的目的（功能）而实现的三个模块而已 。

netfilter可以挂接的规则点有5个，如下图所示：

在这些时刻点中，iptables三张表（模块）并不是所有的时刻都全部进行处理。在同一个时刻点，也可以有多个模块进行处理，对于不同模块谁先处理，谁后处理，可参考如下顺序。

解释：

1. prerouting：报文进入网络接口尚未进入路由之前的时刻；
2. input：路由判断是本机接收的报文，准备从内核空间进入到用户空间的时刻；
3. forward：路由判断不是本机接收的报文，需要路由转发，路由转发的那个时刻；
4. output：本机报文需要发出去 经过路由判断选择好端口以后，准备发送的那一刻 ；
5. postrouting：forward/output 已经完成，报文即将出网络接口的那一刻 。

三张表所能对应的时刻点如下：

表名	时刻点
mangle	prerouting, input, forward, output
nat	prerouting, output, postrouting
filter	input, forward, output

2.5 路由

linux系统包含一个完整的路由功能。当ip层在处理数据发送或者转发时，会使用路由表来决定发往哪里。在通常情况下，如果主机与目的主机直接相连，那么主机可以直接发送ip报文到目的主机，这个过程比较简单。例如，通过点对点的链接或网络共享。如果主机与目的主机没有直接相连，那么主机会将ip报文发送给默认的路由器，然后由路由器来决定往哪里发送ip报文。

路由功能由ip层维护的一张路由表来实现。当主机收到数据报文时，它用此表来决策接下来应该做什么操作。当从网络侧接收到数据报文时，ip层首先会检查报文的ip地址是否与主机自身的地址相同。如果数据报文中的ip地址是主机自身的地址，那么报文将被发送到传输层相应的协议中。如果报文中的ip地址不是主机自身的地址，并且主机配置了路由功能，那么报文将被转发，否则，报文将被丢弃。

路由表中的数据一般是以条目形式存在的。一个典型的路由表条目通常包含以下主要的条目项。

1. 目的ip地址：此字段表示目标的ip地址。这个ip地址可以是某主机的地址，也可以是一个网络地址。如果这个条目包含的是一个主机地址，那么它的主机id将被标记为非零；如果这个条目包含的是一个网络地址，那么它的主机id将被标记为零。
2. 下一跳路由器的ip地址：若并非最终目的的路由器，则该条目给出的下一个路由器的地址用来转发在相应接口接收到的ip数据报文。
3. 标志：这个字段提供了另一组重要信息，例如，目的ip地址是一个主机地址还是一个网络地址。此外，从标志中可以得知下一个路由器是一个真实路由器还是一个直接相连的接口。
4. 网络接口规范：为一些数据报文的网络接口规范，该规范将与报文一起被转发。

在通过路由表转发时，如果任何条目的第1个字段完全匹配目的ip地址（主机）或部分匹配条目的ip地址（网络），它将指示下一个路由器的ip地址。条目中的所有其他字段将提供更多的辅助信息来为路由转发做决定。

如果没有找到一个完全匹配的ip，就接着搜索相匹配的网络id。如果找到，那么该数据报文会被转发到指定的路由器上。可以看出，网络上的所有主机都通过这个路由表中的单个（这个）条目进行管理。

如果上述两个条件都不匹配，那么该数据报文将被转发到一个默认的路由器上。

如果上述步骤都失败，默认路由器也不存在，那么该数据报文最终无法被转发。任何无法投递的数据报文都将产生一个icmp主机不可达或icmp网络不可达的错误，并将此错误返回给生成此数据报文的应用程序。

• 路由表的创建

linux的路由表至少包括两个表（当启用策略路由时，还会有其他表）：一个是local，另一个是main。

在local表中会包含所有的本地设备地址。local路由表是在配置网络设备地址时自动创建的。local表用于供linux协议栈识别本地地址，以及进行本地各个不同网络接口之间的数据转发。

[root@k8smaster01 ~]# ip route show table local type local #查看local表的内容

main表用于各类网络ip地址的转发。它的建立既可以使用静态配置生成，也可以使用动态路由发现协议生成。动态路由发现协议一般使用组播功能来通过发送路由发现数据，动态地交换和获取网络的路由信息，并更新到路由表中。

linux下支持路由发现协议的开源软件有许多，常用的有quagga、zebra等。

• 路由表的查看

可以使用ip route list命令查看当前的路由表：

[root@k8smaster01 ~]# ip route list

netstat -rn是另一个查看路由表的工具：

在它显示的信息中，如果标志是u，则说明是可达路由；如果标志是g，则说明这个网络接口连接的是网关，否则说明这个接口直连主机。