SDN是Software-defined networking的缩写。在许多介绍Kubernetes的文档，特别是安装文档中， 当介绍到Kubernetes所需的容器网络时常常会提到这个缩写，告知用户需要使用某种SDN技术用以解决“每个Pod有独立IP， Pod之间可以不经过NAT直接互访”这一Kubernetes集群最基本的技术要求。

大多数非网络工程师背景的技术人员对SDN这个概念会比较陌生，当读到这个段落时，往往会选择把它当作Kubernetes的底层依赖， 照着文档所推荐的流程安装一款SDN工具，比如Flannel，Calico，Weave等。由于不了解这些工具的原理，同时 缺乏实际的使用经验， 当出现文档以外的异常情况时，整个安装流程就卡住了。SDN俨然成为了Kubernetes大规模普及的拦路虎。

那些按照文档顺利搭建起来的集群当中，还有不少使用了并不适合该集群所处环境的SDN技术，造成了额外的运维负担以及潜在的安全风险。 让我们不得不思考一个问题，怎样才是正确的在Kubernetes集群中使用SDN技术的方法？

今天我们来详细聊聊这个话题。

结论先行

在大多数的Kubernetes集群中，都不需要使用SDN技术，Kubernetes的容器网络要求可以使用更加简单易懂的技术来实现， 只有当企业有特定的安全或者配置要求时，才需要使用SDN技术。SDN应当作为一个附加选项，用以解决特定的技术问题。

理解Kubernetes的容器网络

下图是一张Kubernetes容器网络的示意图

可以看到在图中，每台服务器上的容器有自己独立的IP段，各个服务器之间的容器可以根据目标容器的IP地址进行访问。

为了实现这一目标，重点解决以下这两点：

• 各台服务器上的容器IP段不能重叠，所以需要有某种IP段分配机制，为各台服务器分配独立的IP段
• 从某个Pod发出的流量到达其所在服务器时，服务器网络层应当具备根据目标IP地址将流量转发到该IP所属IP段所对应的目标服务器的能力。

总结起来，实现Kubernetes的容器网络重点需要关注两方面，分配和路由。

Flannel的工作方式

这里我们以比较常见的Flannel为例子，看看SDN系统是如何解决分配和路由的问题的。

下图是Flannel的架构示意图

可以看到Flannel依赖etcd实现了统一的配置管理机制。当一台服务器上的Flannel启动时，它会连接所配置的etcd集群， 从中取到当前的网络配置以及其他已有服务器已经分配的IP段，并从未分配的IP段中选取其中之一作为自己的IP段。 当它将自己的分配记录写入etcd之后，其他的服务器会收到这条新记录，并更新本地的IP段映射表。

Flannel的IP段分配发生在各台服务器上，由flannel进程将结果写入到etcd中。路由也由Flannel完成，网络流量先进入Flannel控制的Tunnel中， 由Flannel根据当前的IP段映射表转发到对应的服务器上。

需要指出的是Flannel有多种backend，另外新增的kube-subnet-mgr参数会导致Flannel的工作方式有所不同，在这里就不详细展开了。 有兴趣的朋友可以去查阅Flannel的文档以及源代码了解更多的细节。

更见简化的网络配置方法

Flannel的工作方式有2点是需要注意的。一是所有服务器上运行的Flannel均需要etcd的读写权限，不利于权限的隔离和安全防护。 二是许多教程中所使用的默认backend类型为vxlan，虽然它使用了内核中的vxlan模块，造成的性能损失并不大， 但是在常见的二层网络的环境中，其实并不需要使用Tunnel技术，直接利用路由就可以实现流量的转发， 这时使用hostgw模式就可以达成目标。

大部分的Kubernetes集群服务器数量并不会超过100台，不论是在物理机房当中或是利用IaaS提供的VPC技术，我们会把这些服务器均放在同一个网段， 这时我们可以去掉Flannel这一层，直接使用Kubernetes内置的kubenet功能，配合上我们为Kubernetes定制的hostroutes工具， 即可实现容器网络的要求。

kubenet

kubenet是kubelet内置的网络插件中的一个，它非常的简单，会根据当前服务器对应的Node资源上的PodCIDR字段所设的IP段，配置一个本地的网络接口cbr0， 在新的Pod启动时，从IP段中分配一个空闲的IP，用它创建容器的网络接口，再将控制权交还给kubelet，完成后续的Pod创建流程。

由于kubenet会自己管理容器网络接口，所以使用kubenet时，不需要修改任何的Docker配置，仅需要在启动kubelet时，传入–network-plugin=kubenet 参数即可。

allocate-node-cidrs

allocate-node-cidrs是controller-manager的一个参数，当它和cluster-cidr参数共同使用的时候，controller-manager会为所有的Node资源分配容器IP段， 并将结果写入到PodCIDR字段。

hostroutes

hostroutes是我们为kubenet开发的一个配套小工具，它也非常的简单，它会watch所有的Node资源的变化，用所有Node资源的PodCIDR字段来配置服务器本地路由表。 这时所有Pod发出的流量将通过Linux自带的路由功能进行转发，性能优异。Linux的路由功能也是大部分技术人员已经掌握的技能，理解维护起来没有任何负担。

在这一简化的模式下，controller-manager负责分配容器IP段，kubenet负责本地网络接口的控制，hostroutes负责路由。 我们最大程度使用了Kubernetes已有的功能，并且用hostroutes来解决kubenet只管网络接口不管路由的问题。整个方案中， 需要写入权限的仅有部署在master节点的controller-manager，运行在Node节点上的kubenet和hostroutes均只需要读取权限即可，增强了安全性。 另外此方案将Kubernetes作为唯一的配置来源，去除了对etcd的依赖，简化了配置，降低了运维负担和安全风险。

不同的技术方案虽说实现细节不同，但是只要围绕着分配和路由这两个关键点进行比较，我们就可以更加明确的在不同方案之间进行选择。

容器网络技术方案选型推荐

任何的技术方案都离不开场景，在这里我们根据不同的场景给大家推荐几种技术方案：

• 单服务器：不需要网络组件，使用Docker自带的网络即可
• 小规模集群：使用kubenet + hostroutes，简单、易配合管理
• 云环境中的小规模集群：使用kubenet + master组件上运行的网络控制器，充分利用IaaS所提供的VPC环境中的路由功能，简化网络配置
• 服务器不在一个网段的集群：使用Flannel提供的vxlan或者其他类似的Tunnel技术
• 安全要求高的集群：使用Calico或者Open vSwitch等支持Policy的SDN技术

总结

在本篇文章中，我们探讨了Kubernetes的容器网络的工具方式，并以Flannel为案例分析了已有的SDN解决方案，并提出了适合小规模集群的kubenet +hostroutes的解决方案。希望可以帮助读者理清在Kubernetes集群搭建过程中容器网络这一部分的思路，不再因为容器网络影响了Kubernetes的整体使用。

在实际工作中，各个企业对集群的要求都有自己的特点，技术人员需要根据企业的需要，充分比较现有的各种方案的优劣，选择最适合的方案。 直接照抄教程的搭建方式会为将来的运行埋下隐患，应当尽可能的避免。

本文转自中文社区-正确的在Kubernetes集群中使用SDN技术方法