【编者的话】本文比较了Kubernetes和Docker的网络模型，并对Kubernetes的网络模拟作了重点阐述，对Kubernetes的网络插件做了比较。git
容器编排技术是当今最火的IT技术之一。不能否认，Docker技术促进了数据中心的发展，并为微服务架构在开发和运维中的实践奠基了基础。github
工做在Sun公司的John Gage 曾说：“ 网络就是计算机。” 为了能充分发挥计算机的功能，必须让计算机之间互相链接。所以，除非你的服务是简单的而且不须要扩容，容器编排技术是一个不错的容器管理技术。在容器编排技术领域，有两个主要的公司Docker和Google， 每一个公司都有用略微不一样的方式实现容器编排的产品。后端
开箱即用的Dcoker容器被绑定到一个独立的机器上。虽然能够在已创建的端口部署服务，可是当将应用程序扩展时，这很快将会是一项枯燥的任务。当将每台机器做为独立单元处理时，灵活的自动扩展服务将困难的多。安全
对于任何的编排业务，必须为集群选择合适的网络模型，由于这是系统的可配置部分而且一般是不可变的。读完这篇文章，但愿你能对容器的网络模型作出选择。网络
Google的Kubernetes是一个公认的，通过实战考验的，比较成熟的容器编排技术。它是一个在集群环境中用于管理应用程序的开源容器编排工具。最近发布的1.6版本，加强了在集群环境中多用户多重负载的可部署性。经过使用minikube简化了测试环境的搭建，minikube是在host上启动了一个all in one的虚拟机来运行Kubernets集群。可是，这样的集群受限于一个节点，除了用做测试工具，没有办法去尝试多节点业务流程。因此，须要用适当的网络模型创建多节点集群。为了能更好的理解Kubernetes的网络模型，先看下集群中可能遇到的场景。架构
Kubernetes 网络有四种组件网络场景：负载均衡
这发生于Pod 内，能够认为是本地host的流量。然而，这种场景，并无任何网络特性，本文不作阐述。运维
Pod是能够被Kubernetes建立和管理的最小可部署的计算单元。在Kubernetes集群中每一个pod被分配一个IP地址，Pod中的container共享网络命名空间。这构成了一个pod间能够相互通讯的网络场景。分布式
在Pod和Service间通讯场景中，service被分配一个客户端能够访问的IP地址。而后，它们被透明的代理到被Service管理的一组Pod。发给Service的IP的请求会被运行在每一个host上的kube-proxy 处理，来选择去往正确的pod的路由。微服务
容许外部流量进入集群，主要是经过映射外部的负载均衡器显示的发现集群中的服务。该映射容许Kube-intermediary使用集群的pod网络对适当的pod进行外部请求。当流量到达一个节点后，经过kube-proxy路由到正确的后端服务。
Docker Swarm，是Kubernetes的主要竞争对手，自从Docker 1.12版本（2016.6）后，已经成为Docker Engine的组成单元。在这以前，Docker Swarm 做为一个独立的产品，是一个轻量级的容器编排工具。
让咱们将所熟知的Kubernetes与Docker容许的容器网络方案进行比较。为了保证在不影响主机网络接口前提下，容器能够相互通讯，Docker 用了一个叫Docker0 的虚拟网桥。Docker0 被分配子网，每一个container经过内部的网络接口（一般是eht0）和 Docker0 通讯。这意味着容器只在一个Docker节点联网。
若是多个节点通讯，则须要一种不一样的方法。一个可使用部署Docker Swarm 用于overlay的网络（经过key,vlaue的存储模式进行管理，如：etcd或Consul）或者用运行在Docker Engine的网络插件。
有许多标准能够成为容器网络的解决方案。Docker和Kubernetes在容器网络标准化方面的工做也有所增长。Docker建立了容器网络模型（CNM），而在同一时间CoreOS也开发了容器网络接口（CNI）。
CNM由Docker引入，CNM有IP 地址管理（IPAM）和网络插件功能。IPAM插件能够建立IP地址池并分配，删除和释放容器IP。网络插件API用于建立/删除网络，并从网络中添加/删除容器。Docker的libnetwork为CNM的实现提供了基础。内置的Docker驱动程序能够在第三方插件帮助下被替换。
由于CNM是在考虑Docker运行时设计的，Kubernetes决定使用容器网络接口（CNI）做为其网络插件而不是开发本身的网络标准。
CNI 分配IP地址给容器网络接口，而不是像CNM中的etcd或Consul的分布式键值存储。这使CNI 提供了一个简单的网络接口集能够从网络中增长或删除容器。最新的CNI支持定义IPAM插件，它能够在须要的CNI插件的帮助下被控制。这容许单独的网络和IPAM插件并帮助网络驱动程序调用IPAM插件。
下面列出的插件是专门为Kubernetes开发的。
Kubenet是专门用于单节点环境，它能够经过与设定规则的云平台一块儿使用来实现节点间的通讯。Kubenet是一个很是基本的网络插件，若是你正在寻找跨节点的网络策略，Kubenet没有任何帮助。
Flannel是一个被CoreOS开发的，专门为Kubernetes设计的overlay网络方案。Flannel的主要优势是它通过了良好的测试而且成本很低。Flannel 为整个集群的提供分布式处理。Kubernetes为正确的通讯和服务，进行端口映射和分配惟一的IP地址给每一个pod。若是你用Google Compute，它将很是兼容。然而，若是你用其余的云服务商，可能会遇到不少困难。Flannel正解决这个问题。
Weave是由Weavenetwork开发，用于链接、监视、可视化和监控Kubernetes。经过Weave，能够建立网络，更快的部署防火墙，并经过自动化的故障排除，提升网络运维效率。
OpenVSwitch用于跨节点创建网络。隧道类型能够是VxLAN或GRE（通用的路由封装）。GRE用于在IP网络上进行数据帧的隧道化。在VXLAN的一帧数据中，包括了原来的2层数据包头，被封装的一个IP包头，一个UDP包头和一个VXLAN包头。VXLAN更适用于要进行大规模网络隔离的大型数据中心。值得注意的是，OpenVSwitch也是Xen默认的网络方案，一样也适用于像KVM，VIrtualBox，Proxmox VE或OpenStack等平台。
从Kubernetes 1.0开始， Calico为Kubernetes pod提供了三层网络。Calico提供了简单的，可扩展的，安全的虚拟网络。它用边界网关协议（BGP）为每一个Pod提供根分布，并可以使用IT基础设施集成Kubernetes集群。Calico能够几乎与全部的云平台兼容，在Kubernetes环境下，具备高可扩展性。除了Kubernetes，Calico 还支持OpenStack，Mesos和Docker。
尽管容器的发展极大的改变了敏捷和持续交付的环境，但容器网络技术仍然在发展。在充满活力的社区中，有些基于SDN技术的项目很快的将走向成熟，如Neutron和NSX。目前来说，Kubernetes提供了更普遍的网络模型而且彷佛已成为容器编排方案的标准。
原文连接：Networking in Kubernetes（翻译：范浩）