前面的文章讲到k8s基本概念中的网络和存储部分是比较难的，今天我们来啃下网络这个硬骨头。
Kubernetes（k8s）是用来搭建服务集群的，而k8s只是搭建在有限的物理机或者虚拟机上面，服务器提供的IP是有限的，而k8s集群支持分布式服务、支持服务的弹性伸缩，这一切都利用了容器化技术，从以主机为中心的基础架构转移到以容器为中心的基础架构。
我们已经知道Pod 是 Kubernetes 的基本构建块，它是 Kubernetes 对象模型中创建或部署的最小和最简单的单元，而pod是有生命周期的，它们可以被创建，也可以被销毁，然而一旦被销毁生命就永远结束。每个pod被创建的时候都有ip，但是这些ip是不稳定的，因为pod被销毁的时候ip就被释放了，就算是重建该pod，pod的ip也会发生改变。
正是k8s这样的特性，这里带来了两个问题：
如何管理IP，宿主node节点的ip是有限的，如何保证分配给pod的ip是唯一的并且和宿主node的ip不冲突？
如果一组 Pod（称为 backend）为其它 Pod （称为 frontend）提供服务，那么那些 frontend 该如何发现，并连接到这组 Pod 中的哪些 backend 呢？
kubernetes网络模型
在Kubernetes网络中存在两种IP（Pod IP和Service Cluster IP），Pod IP 地址是实际存在于某个网卡(可以是虚拟设备)上的，Service Cluster IP它是一个虚拟IP，是由kube-proxy使用Iptables规则重新定向到其本地端口，再均衡到后端Pod的。
-
网络基本原则
每个Pod都拥有一个独立的IP地址（IP Per Pod），而且假定所有的pod都在一个可以直接连通的、扁平的网络空间中，即pod之间的ip可以直接相互通信，就好比在一个局域网中。
网络要求
所有的容器都可以在不用NAT的方式下同别的容器通讯；所有节点都可在不用NAT的方式下同所有容器通讯；容器的地址和别人看到的地址是同一个地址。
网络发展现状
容器网络发展到现在，形成了两大阵营，就是Docker的CNM和Google、CoreOS、Kuberenetes主导的CNI。需要注意的是，CNM和CNI并不是网络实现，他们是网络规范和网络体系，类似jdbc规范，j2ee规范其实就是一堆接口，你底层是用Flannel也好、用Calico也好都是可以的，CNM和CNI关心的是网络管理的问题，即能满足网络模型即可。
CNM（Docker LibnetworkContainer Network Model）我们这里就不介绍了，因为在很长的时间内docker就没有好好的规划网络这块，导致大规模使用docker提供服务编排存在很多难点，这也是k8s流行起来的原因。
CNI（Container NetworkInterface）：CNI是兼容容器技术及上层编排系统，特别在k8s中发展势头迅猛，在k8s中以网络插件的方式存在，有很多非常好的实现。下面这些都是CNI的实现。
Kube-route
Weave
Macvlan
Calico
Flannel
Canal
Cilium
Romana
AWS VPC
Contiv-VPP
这些实现中Flannel和Calico是两个比较典型且优秀的。
Flannel容器网络
Flannel之所以可以搭建kubernets依赖的底层网络，是因为它可以实现以下两点：
它给每个node上的docker容器分配相互不想冲突的IP地址；
它能给这些IP地址之间建立一个覆盖网络，同过覆盖网络，将数据包原封不动的传递到目标容器内。
Flannel介绍
Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。
在默认的Docker配置中，每个节点上的Docker服务会分别负责所在节点容器的IP分配。这样导致的一个问题是，不同节点上容器可能获得相同的内外IP地址。并使这些容器之间能够之间通过IP地址相互找到，也就是相互ping通。
Flannel的设计目的就是为集群中的所有节点重新规划IP地址的使用规则，从而使得不同节点上的容器能够获得“同属一个内网”且”不重复的”IP地址，并让属于不同节点上的容器能够直接通过内网IP通信。
Flannel实质上是一种“覆盖网络(overlaynetwork)”，也就是将TCP数据包装在另一种网络包里面进行路由转发和通信，目前已经支持udp、vxlan、host-gw、aws-vpc、gce和alloc路由等数据转发方式，默认的节点间数据通信方式是UDP转发。
Calico容器网络：
Calico是一个纯3层的数据中心网络方案，而且无缝集成像OpenStack这种IaaS云架构，能够提供可控的VM、容器、裸机之间的IP通信。Calico不使用重叠网络比如flannel和libnetwork重叠网络驱动，它是一个纯三层的方法，使用虚拟路由代替虚拟交换，每一台虚拟路由通过BGP协议传播可达信息（路由）到剩余数据中心。
Calico在每一个计算节点利用Linux Kernel实现了一个高效的vRouter来负责数据转发，而每个vRouter通过BGP协议负责把自己上运行的workload的路由信息像整个Calico网络内传播——小规模部署可以直接互联，大规模下可通过指定的BGP route reflector来完成。
Calico节点组网可以直接利用数据中心的网络结构（无论是L2或者L3），不需要额外的NAT，隧道或者Overlay Network。
Calico基于iptables还提供了丰富而灵活的网络Policy，保证通过各个节点上的ACLs来提供Workload的多租户隔离、安全组以及其他可达性限制等功能。
Calico架构图
