K8S网络组件
网络组建解决的问题，将不同节点上的Docker容器之间的互相访问先打通，使整个k8s集群互通。
目前已经有多个开源组件支持容器网络模型。本节介绍几个常见的网络组件及其安装配置方法，包括Flannel、Open vSwitch、直接路由和Calico。
Docker的网络模型
默认的Docker网络模型提供了一个IP地址段是172.17.0.0/16的docker0网桥。每个容器都会在这个子网内获得IP地址，并且将docker0网桥的IP地址（172.17.42.1）作为其默认网关。
使用ifconfig看一下
1 | docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 |
需要注意的是，Docker宿主机外面的网络不需要知道任何关于这个172.17.0.0/16的信息或者知道如何连接到其内部，因为Docker的宿主机针对容器发出的数据，在物理网卡地址后面都做了IP伪装MASQUERADE（隐含NAT）。也就是说，在网络上看到的任何容器数据流都来源于那台Docker节点的物理IP地址。这里所说的网络都指连接这些主机的物理网络。
这个模型便于使用，但是并不完美，需要依赖端口映射的机制。
在Kubernetes的网络模型中，每台主机上的docker0网桥都是可以被路由到的。也就是说，在部署了一个Pod时，在同一个集群内，各主机都可以访问其他主机上的Pod IP，并不需要在主机上做端口映射。
也就是说k8s的网络组建做了这层路由功能。
Flannel
Flannel之所以可以搭建Kubernetes依赖的底层网络，是因为它能实现以下两点。
（1）它能协助Kubernetes，给每一个Node上的Docker容器都分配互相不冲突的IP地址。
（2）它能在这些IP地址之间建立一个覆盖网络（Overlay Network），通过这个覆盖网络，将数据包原封不动地传递到目标容器内。
现在，通过下图来看看Flannel是如何实现这两点的。
可以看到，Flannel首先创建了一个名为flannel0的网桥，而且这个网桥的一端连接docker0网桥，另一端连接一个叫作flanneld的服务进程。
flanneld进程并不简单，它上连etcd，利用etcd来管理可分配的IP地址段资源，同时监控etcd中每个Pod的实际地址，并在内存中建立了一个Pod节点路由表；它下连docker0和物理网络，使用内存中的Pod节点路由表，将docker0发给它的数据包包装起来，利用物理网络的连接将数据包投递到目标flanneld上，从而完成Pod到Pod之间的直接地址通信。
Flannel之间的底层通信协议的可选技术包括UDP、VxLan、AWS VPC等多种方式。通过源flanneld封包、目标flanneld解包，最终docker0收到的就是原始的数据，对容器应用来说是透明的，感觉不到中间Flannel的存在。
我们看一下Flannel是如何做到为不同Node上的Pod分配的IP不产生冲突的。其实想到Flannel使用了集中的etcd存储就很容易理解了。它每次分配的地址段都在同一个公共区域获取，这样大家自然能够互相协调，不产生冲突了。而且在Flannel分配好地址段后，后面的事情是由Docker完成的，Flannel通过修改Docker的启动参数将分配给它的地址段传递进去：
–bip 172.17.18.1/24
通过这些操作，Flannel就控制了每个Node上的docker0地址段的地址，也就保障了所有Pod的IP地址在同一个水平网络中且不产生冲突了。
Flannel完美地实现了对Kubernetes网络的支持，但是它引入了多个网络组件，在网络通信时需要转到flannel0网络接口，再转到用户态的flanneld程序，到对端后还需要走这个过程的反过程，所以也会引入一些网络的时延损耗。
另外，Flannel模型默认采用了UDP作为底层传输协议，UDP本身是非可靠协议，虽然两端的TCP实现了可靠传输，但在大流量、高并发的应用场景下还需要反复测试，确保没有问题。
Open vSwitch
在了解了Flannel后，我们再看看Open vSwitch是怎么解决上述两个问题的。
Open vSwitch是一个开源的虚拟交换机软件，有点儿像Linux中的bridge，但是功能要复杂得多。Open vSwitch的网桥可以直接建立多种通信通道（隧道），例如Open vSwitch with GRE/VxLAN。这些通道的建立可以很容易地通过OVS的配置命令实现。在Kubernetes、Docker场景下，我们主要是建立L3到L3的隧道。举个例子来看看Open vSwitch with GRE/VxLAN的网络架构如下图：
首先，为了避免Docker创建的docker0地址产生冲突（因为Docker Daemon启动且给docker0选择子网地址时只有几个备选列表，很容易产生冲突），我们可以将docker0网桥删除，手动建立一个Linux网桥，然后手动给这个网桥配置IP地址范围。
其次，建立Open vSwitch的网桥ovs，使用ovs-vsctl命令给ovs网桥增加gre端口，在添加gre端口时要将目标连接的NodeIP地址设置为对端的IP地址。对每一个对端IP地址都需要这么操作（对于大型集群网络，这可是个体力活，要做自动化脚本来完成）。
最后，将ovs的网桥作为网络接口，加入Docker的网桥上（docker0或者自己手工建立的新网桥）。
重启ovs网桥和Docker的网桥，并添加一个Docker的地址段到Docker网桥的路由规则项，就可以将两个容器的网络连接起来了。
1.网络通信过程
当容器内的应用访问另一个容器的地址时，数据包会通过容器内的默认路由发送给docker0网桥。ovs的网桥是作为docker0网桥的端口存在的，它会将数据发送给ovs网桥。ovs网络已经通过配置建立了和其他ovs网桥的GRE/VxLAN隧道，自然能将数据送达对端的Node，并送往docker0及Pod。
通过新增的路由项，Node本身的应用数据也被路由到docker0网桥上，和刚才的通信过程一样，自然也可以访问其他Node上的Pod。
2.OVS with GRE/VxLAN组网方式的特点
OVS的优势是，作为开源虚拟交换机软件，它相对成熟和稳定，而且支持各类网络隧道协议，通过了OpenStack等项目的考验。
另一方面，在前面介绍Flannel时可知，Flannel除了支持建立覆盖网络，保证Pod到Pod的无缝通信，还和Kubernetes、Docker架构体系紧密结合。Flannel能够感知Kubernetes的Service，动态维护自己的路由表，还通过etcd来协助Docker对整个Kubernetes集群中docker0的子网地址分配。而我们在使用OVS时，很多事情就需要手工完成。
无论事OVS还是Flannel，通过覆盖网络提供的Pod到Pod通信都会引入一些额外的通信开销，如果是对网络依赖特别重的应用，则需要评估对业务的影响。
直接路由
我们知道，docker0网桥上的IP地址在Node网络上是看不到的。从一个Node到一个Node内的docker0是不通的，因为它不知道某个IP地址在哪里。如果能够让这些机器知道对端docker0地址在哪里，就可以让这些docker0互相通信了。这样，在所有Node上运行的Pod就都可以互相通信了。
我们可以通过部署MultiLayer Switch（MLS）来实现这一点，在MLS中配置每个docker0子网地址到Node地址的路由项，通过MLS将docker0的IP寻址定向到对应的Node上。
另外，我们可以将这些docker0和Node的匹配关系配置在Linux操作系统的路由项中，这样通信发起的Node就能够根据这些路由信息直接找到目标Pod所在的Node，将数据传输过去。
我们在每个Node的路由表中增加对方所有docker0的路由项。
在大规模集群中，在每个Node上都需要配置到其他docker0/Node的路由项，这会带来很大的工作量；并且在新增机器时，对所有Node都需要修改配置；在重启机器时，如果docker0的地址有变化，则也需要修改所有Node的配置，这显然是非常复杂的。
为了管理这些动态变化的docker0地址，动态地让其他Node都感知到它，还可以使用动态路由发现协议来同步这些变化。在运行动态路由发现协议代理的Node时，会将本机LOCAL路由表的IP地址通过组播协议发布出去，同时监听其他Node的组播包。通过这样的信息交换，Node上的路由规则就都能够相互学习。当然，路由发现协议本身还是很复杂的，感兴趣的话，可以查阅相关规范。在实现这些动态路由发现协议的开源软件中，常用的有Quagga（http://www.quagga.net）、Zebra等。
Calico
Calico是一个基于BGP的纯三层的网络方案，与OpenStack、Kubernetes、AWS、GCE等云平台都能够良好地集成。Calico在每个计算节点都利用Linux Kernel实现了一个高效的vRouter来负责数据转发。每个vRouter都通过BGP1协议把在本节点上运行的容器的路由信息向整个Calico网络广播，并自动设置到达其他节点的路由转发规则。Calico保证所有容器之间的数据流量都是通过IP路由的方式完成互联互通的。Calico节点组网时可以直接利用数据中心的网络结构（L2或者L3），不需要额外的NAT、隧道或者Overlay Network，没有额外的封包解包，能够节约CPU运算，提高网络效率。
Calico在小规模集群中可以直接互联，在大规模集群中可以通过额外的BGP route reflector来完成。
此外，Calico基于iptables还提供了丰富的网络策略，实现了Kubernetes的Network Policy策略，提供容器间网络可达性限制的功能。
Calico的系统架构如下图所示：
Calico的主要组件如下。
- Felix：Calico Agent，运行在每个Node上，负责为容器设置网络资源（IP地址、路由规则、iptables规则等），保证跨主机容器网络互通。
- etcd：Calico使用的后端存储。
- BGP Client：负责把Felix在各Node上设置的路由信息通过BGP协议广播到Calico网络。
- Route Reflector：通过一个或者多个BGP Route Reflector来完成大规模集群的分级路由分发。
- CalicoCtl：Calico命令行管理工具。
IP Pool可以使用两种模式：BGP或IPIP。使用IPIP模式时，设置CALICO_IPV4POOL_IPIP=”always”，不使用IPIP模式时，设置CALICO_IPV4POOL_IPIP=”off”，此时将使用BGP模式。
IPIP是一种将各Node的路由之间做一个tunnel，再把两个网络连接起来的模式，启用IPIP模式时，Calico将在各Node上创建一个名为tunl0的虚拟网络接口。
BGP模式则直接使用物理机作为虚拟路由器（vRouter），不再创建额外的tunnel。
如果使用的是overlay，podip是不能被外界访问到的。
如果没有使用overlay网络，podip能不能被外界访问取决于使用何种CNI网络接口插件