网易云社区

个人签名

162篇博客

【杭研大咖说】张小刚:PaaS on Kubernetes即将大规模应用

网易云社区2019-12-31 10:52

互联网团队已经习惯了通过流程化、标准化、自动化、平台化解决性能、可靠性、稳定性、灵活性等问题,缩减开发和运维成本,面向应用和中间件的PaaS,对于开发人员运行和管理应用、专注业务逻辑尤为重要,而在云原生趋势不可逆转的今天,PaaS服务的容器化改造是需要思考的课题。在这个领域,网易杭州研究院(网易杭研)的探索较早,目前已经在网易云音乐、网易传媒等多个业务陆续上线。在本期“杭研大咖说”中,网易杭研云计算技术部架构师、中间件组负责人张小刚解读了PaaS服务容器化(Paas on Kubernates)的价值所在,PaaS on Kubernetes在网易内部落地的进展,以及实施PaaS on Kubernetes需要关注的核心问题。

成长于实践的架构师

与网易杭研众多核心技术人员相似,张小刚也是一位从项目实战中逐步成长起来的架构师。自加入网易杭研,他曾参与Pomelo开源框架、易信开放平台、网易云负载均衡、消息推送平台、网易云DNS,工业互联网等项目,并作为架构师,推动了PaaS服务完成VPC适配,推动了云计算完成多Region和多AZ支持,也作为负责人推动了LB项目1.0到2.0落地,这些项目在考拉海购大促等业务场景下得到了验证。

在张小刚看来,这些工作的推进,或顺利,或艰难,但都是他个人不断成长的过程,例如:

1.负责推动LB服务从1.0到2.0演进,加深了他对LB服务和VPC服务的理解。
2.深入参加LB,NCR(缓存服务),推送,UAS,DNS,云监控,IP管理,证书管理等服务设计研发和重构,加深了他对PaaS和横向服务的理解,提高了业务优化和重构能力。
3.负责PaaS服务VPC整体适配推进,加深对VPC服务,使得他对Paas服务有了整体理解和认识。
4.推进云计算多Region和多AZ支持,通过深度参与所有服务(Paas,横向,Iaas)的多AZ设计,进一步锻炼了他整体的架构设计,规划和协调能力,获取了对Paas服务的整体理解和规划能力。
5.深度参与云计算平台的重大技术决策和技术评审,让他获取了对大部分模块的深入理解和架构指导能力。

PaaS on K8S:相同的人可以做更多的事

推行技术革新应当保证收益大于成本,解决业务痛点,这是张小刚一以贯之的原则之一。在他看来,此时此刻实施PaaS on Kubernetes,是非常合乎这条原则的。

对于互联网业务创新而言,不论着眼于当前还是未来,PaaS on Kubernetes都有不可忽视的收益,主要包括如下四个方面:

1.从PaaS研发侧看:最直接的收益,通过把基础能力下沉到Kubernetes,大幅度降低了PaaS服务的研发维护门槛,相同规模的团队,在相同的时间内,可以支撑更多的PaaS服务。而通过与社区保持兼容,可以直接使用优秀的开源方案。
2.从用户成本角度:容器模式损耗更低,性能更好,亦即可以用更少的物理节点支撑相同规模的服务。
3.从用户使用角度:PaaS on Kubernetes提供一套统一的运维API和界面,无论是运维人员,还是一般用户,都可以降低学习成本;对于研发人员,则可以减少前端重复建设的成本。
4.从底层支撑看:可以把业务统一到Kubernetes编排框架下,实现了底层隔离,摆脱了厂商依赖;还可以支撑如多云部署、离线在线混部等高级云原生特性。


当然,为了实现对应的能力,团队也需要付出一定的成本:

1.基于Kubernetes构建服务生态成本:这块从头研发成本比较大,建议采用现成的解决方案。
2.业务容器化成本:容器化本身会带来一定的迁移成本。
3.Kubernetes的学习成本:Kubernetes是比较新的技术,需要学习和使用。
4.服务研发成本:对于遗留的PaaS服务,当前并没有特别成熟的解决方案,需要投入一定的研发成本。

在张小刚看来,两相比较,“收益>成本”的公式是成立的,实际上,从前期的研发效果和业务采用情况看,是“收益>>成本”。对于大部分企业来说,他们不仅有开源技术方案可以使用,也有大型企业的实践可以学习,这使得成本可以降低。

PaaS on K8S在网易:大规模应用前夜

谈到网易内部落地 PaaS on Kubernetes 的进展,张小刚用一句话来总结:“现在处于大规模应用的前夜。”

据他介绍,网易第一批的几个PaaS服务,如Redis,Kafka等已经完成了一期研发和交付,已经在陆续应用在线上。而第二批PaaS服务已经在并行开始,当前就有多个小组同时在进行多个不同PaaS服务的研发。他还透露,明年预计会有更多的服务迁移到K8S上,除了服务端中间件外,还会包括大数据、AI平台的PaaS on K8S工作。

进一步解释说,从的落地情况看,由于Paas on K8S有着与社区完全兼容的形态,简单易用的运维方式,成本可控,易部署等优势,业务采用还是非常积极的。另外网易内部采用了跨部门合作推进的方式,通过杭研和一个核心业务团队的合作,可以快速验证技术方案,并打消后续业务的应用顾虑。这与之前业务迁移到基于OpenStack的PaaS服务时的迟疑形成了鲜明的对比。

“我们内部也非常看好场景,预计会在未来两年时间,将基本所有平台类服务,迁移到K8S上去,这也是我们集团现在的技术方向。”张小刚信心满满地说。

PaaS on K8S实践:挑战与心得

Kubernetes以应用为核心的设计,是它的价值所在,也造成了实现PaaS on Kubernetes要解决的问题和之前PaaS on OpenStack的完全不同。张小刚介绍,落地 PaaS on Kubernetes的宏观技术挑战主要包括三大类:

Paas研发思路转变:由于Kubernetes设计理念和OpenStack的完全不同,需要研发人员从设计思路上进行转变——基于声明式的API,会带来后端设计的一系列改变,比如自动重试,支持流程重放,保证最终一致性等。
面向失败的设计:Kubernetes不承诺单点高可用,失败时倾向于重建而不是原地恢复,并允许多次失败重试。这就要求面向失败的设计,设计时需要移除所有单点,并考虑系统异常时的重建能力,这对一些强状态的服务如RDS等提出了很高的要求,也需要一些底层设施,如分布式存储等的支持。
生命周期的管理:Kubernetes对服务的管理渗入到了应用层,会接管很多原先由PaaS服务自己做的事情,比如自动扩缩容,节点异常自动拉起等。而对于一些对流程有强把控的PaaS服务来说,原有的机制模式很难满足需求,需要自己控制。特别是对于一些比较老的,没有面向云原生设计的PaaS服务更是如此。


而从具体技术层面解读,则包括如下四个方面的门槛:

对Kubernetes和容器的把控:PaaS服务对调度和底层的压力更大,会对Kubernetes和底层容器,网络,存储等提出了更高的要求,需要团队对相关技术有深入的掌控。
保持社区一致:在满足业务需求的前提下,与社区保持一致,尽量减少定制化开发。
模板化开发:与原有PaaS不同,K8S的Operator机制给PaaS服务提供了一个研发模板,实际上,网易内部几个组件整体架构图就一模一样。因此在设计时需要按照Operator的设计模式来。
语言层面:需要对Go语言的了解和把控,这块对于主要采用Java技术栈的Paas研发人员,还是有一些挑战的。好在云计算这边从几年前就开始进行了Go语言的相关积累,并积累的一定的研发和培训经验,这块才可以较为顺利的解决。


在张小刚看来,这些挑战都有很好的方案:

1.开源Operator SDK:可以大幅降低Operator的开发成本,避免重复造轮子。
2.开源Operator:当前社区非常活跃,有大量开源Operator可以使用。虽然当前大部分组件还在早期阶段,按照其他开源方案发展过程,很快就会形成一些较为成熟的解决方案。对于当前需要使用的用户,开源Operator的价值实现更多是在功能层面,在高可用、运维能力上,还是需要使用方自己做大量扩展。
3.杭研团队开发的商业版的Operator,也将陆续投入生产。

解决了这些技术挑战,张小刚认为,PaaS on Kubernetes的设计比较简单,因为和之前PaaS开发相比,PaaS on Kubernetes有了通用的模式,只需三步即可:

1.明确需求:所有服务研发都是从明确需求开始的。
2.设计CRD:CRD就相当于之前的数据库表设计,PaaS服务的所有能力,用户接口都会在CRD中体现。
3.开发,开发,开发……

不过,由于Kubernetes的不同,张小刚也提醒说,有两个方面需要特别注意:

1.对于有状态服务,如果实现了存储计算分离(采用云盘或者S3等)会简单很多。如果使用本地盘,需要考虑无法原地拉起,异地恢复的情况。因此需要采用多副本模式。
2.关于自动运维:由于K8S自动做了很多异常处理工作,但是某些场景下,与原有Paas服务处理机制是有冲突的,反而会导致一些问题。因此,需要考虑好自动化的范围,在经过充分验证的情况下稳步推进。


由此可见,Kubernetes是核心,但如果传统企业如果已经实施容器化,对 Kubernetes 有一些不同的定制开发,或者采用了非 Kubernetes 技术栈,要想得到PaaS on Kubernetes的好处,是否能够复用网易的经验?对此,张小刚给出了肯定的答案。他表示,杭研的经验,不仅仅是纯技术框架,还包括组织架构和分工的调整,这其实是梳理整个PaaS研发流程,体系化的提高效率的过程。