京东618:容器技法日趋娴熟,60%业务已切换至Kubernetes

  categories:资料  author:

容器技术火遍技术界,很多公司包括传统行业企业都已经从观望者转变为采用者。作为最早期采用容器技术的一批先锋者,京东从 2015 年的 9 千多实例扩大到如今容器作为业务上线默认选项,支撑全部业务运行以及中间件、数据库等。此外,在经历了从 OpenStack 到 Kubernetes 的迁移转变之后,京东容器引擎平台已经从 1.0 迭代到 2.0 版本,并且于今年陆续开源数个项目。

罗马不是一天建成的。

积累如此久并且支撑过 618 大促的京东容器技术是怎样的?有哪些革新又有哪些值得业界学习呢?已经开源的项目是怎样的呢?

容器技术整体概况

今年随着京东业务的飞速发展,京东容器数量上也对应迅速增加。不仅在去年完成京东业务全面运行在 JDOS 容器之上,并且在数据库,中间件等系统也全面容器化。同时,在这一年,京东上线了 JDOS 2.0 系统,开始了从 OpenStack 向 Kubernetes 的迁移。截止到 6 月 7 日,已经有 60% 的业务运行在了 JDOS 2.0 平台中。
此外不得不提及发生的主要变化:业务系统全面基于容器镜像全量上线发布;全面使用集群编排;在生产环境尝试和运行抢占式调度,并自研单层单体全局调度器 SchedulerX;让业务系统与硬件解耦与资源完全解耦,海量资源,从容大促。

自研单层单体全局调度器

阅读全文

正确的在Kubernetes集群中使用SDN技术方法

  categories:资料  author:

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容器网络的示意图

20170204140136

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

为了实现这一目标,重点解决以下这两点:

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

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

Flannel的工作方式

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

下图是Flannel的架构示意图

20170204140223

可以看到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创建流程。… 阅读全文




快乐成长 每天进步一点点      京ICP备18032580号-1