5种场景容器网络技术方案选型推荐.docx

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工具，即可实现容器网络的要求。kubenetkubenet是kubelet内置的网络插件中的一个，它非常的简单，会根据当前服务器对应的Node资源上的PodCIDR字段所设的IP段，配置一个本地的网络接口cbr0，在新的Pod启动时，从IP段中分配一个空闲的IP，用它创建容器的网络接口，再将控制权交还给kubelet，完成后续的Pod创建流程。由于kubenet会自己管理容器网络接口，所以使用kubenet时，不需要修改任何的Docker配置，仅需要在启动kubelet时，传入–network-plugin=kubenet 参数即可。allocate-node-cidrsallocate-node-cidrs是controlle