kubernetes 网络模型

　　简单介绍：
　　　　Kubernetes 的网络模型假定了所有 Pod 都在一个可以直接连通的扁网络空间中。这个 GCE 里面是现成的网络模型，Kubernetes 假定这个网络已存在。而在私有云里搭建 Kubernetes 集群，就不能假定这种网络已经存在了。我们需要自己实现这个网络假设，将跨主机容器网络部署完成，再运行容器应用。

　　1）Flannel插件的原理及部署

　　Flannel之所以可以搭建 Kubernetes 依赖的底层网络，是因为它能实现以下两点：

　　　1，它能协助 Kubernetes，给每一个 Node 上的 Docker 容器都分配互不冲突的 IP 地址。

　　　2，它能在这些 IP 地址之间建立一个覆盖网络（Overlay Network），通过这个覆盖网络，将数据包原封不动地传递到目标容器内

　　

 

 

 

　　2）Calico 插件的原理及部署

　　Calico 是一个基于 BGP 的纯三层的网络方案，与 OpenStack 、Kubernetes、AWS、GCE等云平台都能够良好的集成。Calico 在每一个计算节点都利用 Linux Kernel 实现一个高效的 vRouter 来负责数据转发。每个 vRouter 都通过 BGPI 协议吧在本节点上运行的容器的路由信息向整个Calico 网络广播，并自动设置到达其他节点的路由规则。 Calico 保证所有容器之间的数据流量都是通过 IP 路由的方式完成互联互通的。Calico 节点网络可以直接利用数据中心的网络结构，不需要额外的NAT、隧道或者 Overlay Network，没有额外的封包解包，能够节约CPU运算，提高网络效率。calico是一个纯三层的虚拟网络，它没有复用docker的docker0网桥，而是自己实现的，calico网络不对数据包进行额外封装，不需要NAT和端口映射，扩展性和性能都很好。Calico网络提供了DockerDNS服务，容器之间可以通过hostname访问，Calico在每一个计算节点利用Linux Kernel实现了一个高效的vRouter（虚拟路由）来负责数据转发，它会为每个容器分配一个ip，每个节点都是路由，把不同host的容器连接起来，从而实现跨主机间容器通信。而每个vRouter通过BGP协议（边界网关协议）负责把自己节点的路由信息向整个Calico网络内传播——小规模部署可以直接互联，大规模下可通过指定的BGProute reflector来完成；Calico基于iptables还提供了丰富而灵活的网络策略，保证通过各个节点上的ACLs来提供多租户隔离、安全组以及其他可达性限制等功能。

　　Calico是一种非常复杂的网络组件，它需要自己的etcd数据库集群来存储自己通过BGP协议获取的路由等各种所需要持久保存的网络数据信息，因此在部署Calico时，早期是需要单独为Calico部署etcd集群的，因为在k8s中，访问etcd集群只有APIServer可以对etcd进行读写，其它所有组件都必须通过APIServer作为入口，将请求发给APIServer，由APIServer来从etcd获取必要信息来返回给请求者，但Caclico需要自己写，因此就有两种部署Calico网络插件的方式，一种是部署两套etcd，另一种就是Calico不直接写，而是通过APIServer做为代理，来存储自己需要存储的数据。通常第二种使用的较多，这样可降低系统复杂度。

　　当然由于Calico本身很复杂，但由于很多k8s系统可能存在的问题是，早期由于各种原因使用了flannel来作为网络插件(flannel会讲解原因)。

　　Calico 组成：　　

　　calico包括如下重要组件：Felix，etcd，BGP Client，BGP Route Reflector。下面分别说明一下这些组件：

　　Felix：主要负责路由配置以及ACLS规则的配置以及下发，它存在在每个node节点上。
　　etcd：分布式键值存储，主要负责网络元数据一致性，确保Calico网络状态的准确性，可以与kubernetes共用；
　　BGPClient(BIRD):主要负责把 Felix写入 kernel的路由信息分发到当前 Calico网络，确保 workload间的通信的有效性；
　　BGPRoute Reflector(BIRD):大规模部署时使用，摒弃所有节点互联的mesh模式，通过一个或者多个 BGPRoute Reflector 来完成集中式的路由分发；

 

 

 　　Calico的网络插件包含两种网络模型：

　　　　IPIP模型：

　　　　BGP模型：