网易蜂巢基于万节点Kubernetes(k8s)支撑大规模云应用实践

  categories:资料  author:

本文整理自刘超在ArchSummit2016全球架构师峰会(北京站)的演讲。

网易蜂巢是做容器Docker的,用Kubernetes来管理容器。现在蜂巢已经支撑了内部、外部很大规模的云计算应用,所以我们这个题目有两个关键,一个是Kubernetes和容器,另外一个是大规模云应用。

网易蜂巢的大规模容器平台

 

20161226220145

 

上图展示了蜂巢发展历程。其实很早就开始做蜂巢了,一开始从私有云开始建设。发展分成两层:应用层、平台层。进行了四个方面的转变,一是从虚拟机进展到容器。因为虚拟机仅仅是资源平台的弹性,并没有实现到应用级别的弹性,实现容器后对应用层要有一定的关心、改造、架构梳理。在应用层我们要做微服务化的改造以及开发流程DevOps的改造,我们还经历了从私有云到公有云的转化。2014年95%的应用移到平台上来,2015年容器云平台才正式对外开放。很多应用都是我们自己支撑地比较好以后才作为容器云平台开放,对外进行服务。2016年主要是DevOps微服务帮助用户真正改变流程,改进架构。

 

20161226220204

 

上图是蜂巢上大规模的云应用,从最早的邮箱,到后来互联网应用产生了一个爆发的阶段,很多logo大家都认识,比如说笔记、云音乐、考拉海购等等。我们很骄傲的是,其中考拉海购和网易云音乐都部署在蜂巢平台上面,它们扛过了“双十一”。虽然我们的音乐产品推出时间比较晚,但是用户量很快激增,对整个架构也是一个很大的挑战。

 

20161226220215

 

蜂巢大规模容器平台整个架构如图所示。我们原来做过私有云、IaaS平台,IaaS平台其实是比较费力的,尤其是对网络方面的优化和存储方面的优化。到了容器平台以后,容器本身对CPU隔离、内存隔离、应用隔离做得不错,但是对跨主机网络隔离、统一存储支持做得不够,尽管有一些开源解决方案可以做这个事情,但我觉得对IaaS平台做的一些优化是能够帮助容器层来提供高性能的网络和存储服务,所以我们的容器平台和IaaS平台有深度结合。在右图的KVM,因为我们做的是公有云,最关注的就是安全问题。容器隔离性其实本身做得没有那么好,容器的权限不知道开的高还是低,如果开的低用起来很别扭,因为很多权限没有给它,但是开的高的话就可能在同一个主机上还有其他人的应用。 在公有云平台上,采取的策略是不同的租户不共享主机、不共享虚拟机,这样就能实现比较好的隔离性。

私有云平台建设

 

20161226220226

 

这是私有云平台资源弹性架构图。网易数据中心开始建立起来时就是朝着五星级数据中心建立的,所以硬件层非常好,实现了全万兆互联、全SSD存储。如果在蜂巢平台上订购一个容器,存储都是SSD的,性能非常棒。计算虚拟化、网络虚拟化、存储虚拟化,基本的OpenStack都会做这三层。把KVM作为计算存储化、OpenVswitch作为网络存储化、存储虚拟化方面做了很多改进。基于OpenStack之上是PaaS平台,PaaS平台有数据库、对象存储、负载均衡、缓存服务、CDN、安全服务。这些服务发展的整个历程比云平台还要早,因为像数据库、对象存储、缓存服务是在网易研究院一开始成立时,这方面的技术就已经开始积累了。

 

20161226220235

 

再往上是应用层。这是应用层的架构雏形,是一个电商网站。一般一开始应用层构建时都是单机模式的,这不能说架构师一开始设计时没有设计好。其实现在互联网的应用,我们遇到好多的客户最想要的点就是上线速度快。现在有很多应用就是半年过一茬,如果赶不上这个风口,可能就飞不起来,就会被竞争对手落下,这样架构再好也没有用,所以一般不会一开始就把应用层拆得七零八落的。

 

20161226220244

 

虚拟机层面部署方式一般会采取通过脚本或者自动化配置的工具来进行应用的部署,这里经常用的是Puppet Chef Ansible。虚拟机能实现的资源层面比较弹性,比如说“双十一”原来有5个节点,卡一下变成10个节点,很快可以部署出来,但是另外5个节点里面是空的,怎么办呢?并不能很好实现应用弹性,所以就需要自动化的工具,除了调IaaS平台把虚拟机创建出来以外,还要进行部署。应用部署上去之后,如果变化比较慢是没有任何问题的,脚本是固定的只需要写一次就可以了,但是现在应用变化非常快,需要不断调整脚本,运维成本还是相对比较大的。

随着业务发展,应用层的架构就会越来越复杂。比如说用户的管理,要不要给用户做一些活动,用户浏览时要不要提供搜索推荐,要不要做积分,商户要不要管理自己的供应商,和客户有矛盾的话要不要有仲裁,支付需不需要对账,商品配送要不要物流管理,包括对接银联、支付宝支付等等,所有的功能都加进来了。如果还是加到同样一个应用里的话,整个架构就太复杂了。这个时候架构就会面临着三个方面的问题:

  • 时间的灵活性。一个新的活动要上线的时候,能否尽快实现它的快速迭代。
  • 空间的灵活性。能否实现非常快的弹性伸缩。
  • 管理的灵活性。比如说有一个服务挂了,怎么样把它尽快接起来,和原来应用进行一定程度的关联。

从虚拟机到容器

接下来是一个从虚拟机过渡到容器的时代。这个时代主要有以下几个方面的不同:

  • 原来以资源为核心,现在以应用为核心。运维人员不能再认为不关心应用,只要虚拟机不挂就没有问题。这个时候开发人员和运维人员已经不再是两个独立的实体,现在流行的概念就是DevOps。
  • 有状态容器。为什么要支持有状态容器?从虚拟机到容器的演化过程,容器其实比较适用于部署一些无状态的东西,最好是挂了以后再起,只有商务逻辑并没有数据。虽然在哪个机器上重启都是可以的,但是我们发现中间还是有很大沟壑的,用习惯虚拟机的用户不适应一旦切换到容器,应用就马上进行无状态,所以我们采取了一定的技术,下面也会分享如何实现有状态的容器。
  • 容器跨主机互联和容器使用云盘存储。它对于计算的隔离比较好,但是对于网络互联、共享云盘,虽然业界有开源的方案,但是这种方案还是有问题的,一个是性能问题,一个是二次虚拟化的问题,一般采取公有云创建虚拟机的时候,虚拟机之间的互联已经有了一个层次的虚拟化,这个时候容器之间的跨主机互联还要再做一次虚拟化,这样一层一层套性能就大幅度降低。云盘存储也是,如果要在IaaS层之外再做一层集群,还是会有二次虚拟化,本来下面就是一个虚拟的存储,创建出云盘,云盘再打出集群,这种二次虚拟化存储基本不可以使用了。

去状态化

去状态化

 

所谓的去状态化,就是应用程序一开始会有很多的数据,比如有些数据是保存在内存里,像会话的数据,有的是保存在本地文件系统、本地库里,像照片。去状态化做的事情没有那么难,把这些数据外置化就可以了,可以把会话放在缓存里,可以把用户数据放在数据库里,可以把照片保存在远程的分布式存储里面。仅仅包括商务逻辑、算法的应用扩展起来就非常方便,一变三、三变五,可以比较好地分担整个应用。其他有状态的事情就交给外面的缓存、数据库和分布式存储来做。开源软件和互联网软件发展到今天,外部的缓存、数据库和分布式存储都已经有了自己的集群模式,所以把它外置出来并不担心丢失。

 

容器化

容器化

 

阅读全文



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