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