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

互联网团队已经习惯了通过流程化、标准化、自动化、平台化解决性能、可靠性、稳定性、灵活性等问题，缩减开发和运维成本，面向应用和中间件的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研发流程，体系化的提高效率的过程。