2017 年是 Kubernetes 的胜利之年，很多人还不明白这意味着什么。但如果看一下云计算业界的动向，你会发现，Kubernetes 的影响正在扩散。
在本文中我将分享我们的发现，并试图说服你：基于容器 +Kubernetes 的新型 PaaS 将会成为云计算的主流。
我将引用很多内容，包含国内外专家的真知灼见，让你看到专家是如何看待此事的，以及分享我们自己做的调研和采访，看看业界实际在发生什么。
Kubernetes（k8s）在很短的一段时间内走过了很长的一段路。仅仅两年以前，它还需要与 CoreOS 的 Fleet、Docker Swarm、Cloud Foundry Diego、HashiCorp 的 Nomad、Kontena、Rancher 的 Cattle、Apache Mesos、Amazon ECS 等进行竞争，来证明自己比那些产品都要优秀。而现如今已经是完全不同的一幅景象了。其中的一些公司公开宣布了项目的终止并且开始加入到 Kubernetes 阵营中，还有一些公司没有公开宣布自己项目的失败，而是在战略上宣布了对 Kubernetes 的部分支持或者完全整合，这也就意味着他们的容器编排工具将会安静而缓慢地死掉。不论是哪一种情况，k8s 都是最后一个活下来的平台。除此之外，不仅仅是用户和白金赞助商们，越来越多的大公司都将继续加入到 Kubernetes 的生态系统中，将自己的业务完全押注于 Kubernetes 的成功。我们首先能想到的有 Google 的 Kubernetes Engine、Red Hat 的 OpenShift、Microsoft 的 Azure Container Service、IBM 的 Cloud Container Service、Oracle 的 Container Engine。
但是这些意味着什么呢？首先，这意味着开发人员必须要掌握一个与 90% 的容器工作相关的容器编排平台。这是一个学习 Kubernetes 很好的理由。同时这还意味着我们已经深深地依赖于 Kubernetes，Kubernetes 就像容器领域中的 Amazon。在 Kubernetes 上进行设计、实现和运行应用程序可以让你在不同的云提供商、Kubernetes 发行版和服务提供商之间自由地对应用程序进行迁移。它能让你有机会找到 Kubernetes 认证的开发人员，让他们来开发项目并且在以后持续提供支持。Kubernetes 不是 VM，也不是 JVM，它是全新的应用程序可移植层，它是大家共同的选择。——Bilgin Ibryam，Red Hat 首席架构师
基于“容器 +k8s”的新型 PaaS
Kubernetes 并不是传统意义上的 PaaS，事实上，传统 PaaS 可以基于 Kubernetes 构建。
在过去，PaaS 经历了这样的发展：
第一代：如最早的 Heroku，严格限定的运行时，不可修改的环境。对于 Ruby on Rails 这种小型单体应用来说很合适。
第二代：Cloud Foundry (DEA 版本) ，可以简单的自定义环境，包括云端构建。也开始对多服务的应用有所支持。
第三代：Cloud Foundry (Diego 版本)，如当前版本的 GAE 和 AWS Elastic Beanstalk，它们都经过之前两代 PaaS 迭代而来。在这个版本里增加了对容器的支持，更自由的环境配置，对微服务的支持更强大。
第四代：Kubernetes 以及其它容器编排引擎。这一代的平台变成了 Kubernetes 本身，它是面向云原生应用计算的、彻底基于分布式和容器的计算平台。
第四代 PaaS 的关注点也和之前不一样，我们可以把前三代 PaaS 称为应用级 PaaS（Application PaaS），它们关注的是应用的运行，第四代称为容器 PaaS，或者 CaaS、KaaS，它们关注的是应用的打包和分发。
第四代 PaaS 当然也可以使用其它的技术达到类似的效果，但就像前面所说的，Kubernetes 赢得了这场竞争。
从下面的 PaaS 平台架构图中可以看到，我用了 Docker+Kubernetes 层来做了一个“技术缓冲层”。也就是说，如果没有 Docker 和 Kubernetes，构建 PaaS 将会复杂很多。当然，如果你正在开发一个类似 PaaS 的平台，那么你会发现自己开发出来的东西会跟 Docker 和 Kubernetes 非常像。相信我，最终你还是会放弃自己的轮子而采用 Docker+Kubernetes 的。——陈皓 《洞悉 PaaS 平台的本质》
这是一个大而全的 PaaS 平台架构，实际中可以根据需求进行裁剪。
业界趋势：全在做 PaaS
如果我们看一下业界，会发现，从公有云到私有云，从传统企业到互联网新贵，都在拥抱 Kubernetes，都在做 PaaS。
公有云全在做 k8s 和容器
从 AWS 到 Google Cloud、微软 Azure，到国内的腾讯云、华为云等，都在提供 k8s 容器服务。如果一个公有云到现在还没有提供 k8s 服务，或者没有计划做，那么可以认为它的技术已经落后于时代了。
公有云提供的 k8s 和容器服务，具体来说分为两类：
一类是提供多租户的单容器实例，这种其实类似于上面提到的第三类 PaaS，用户创建的是单个容器，值得一提的是，这类 PaaS 仍可构建于 k8s 之上，并且不少云计算厂商已经采用这种方案。另外，由 KataContainer 技术逐渐应用到生产环境，带来将无服务器概念和容器结合的 Serverless Container Cloud 理念，让容器也能兼具传统虚拟化的优点，让这类服务的未来充满了想象空间。
Kubernetes 所要扮演的角色，乃是取代传统的 Infrastructure Layer 并鼓励技术人员进行上层的“二次创新”，而并不是直接面对最终用户。真正为最终用户提供云服务的，很大概率应该是构建于 Kubernetes 之上的、更加简洁高效的服务型 API，而 Serverless，尤其是 Serverless Container Cloud 的设计，正是这种需求下最为贴切的实现方式之一。——张磊，浙江大学博士研究员，Hyper 项目成员，Kubernetes 项目资深成员与社区维护者。
另一类是提供 Kubernetes 引擎，这种情况下用户创建的是 Kubernetes 集群，如 GKE、Azure AKS、腾讯云 CCS 等。
第二类服务是目前公有云研发的重点，发布的时间基本集中在去年下半年到现在，我们采访和调研了微软 Azure、腾讯云、华为云，情况基本类似，具体内容可进一步阅读：
剑指 Kubernetes 揭秘腾讯云的 PaaS 技术选型策略
k8s 将成私有云的标准解法
私有云的情况分为两类，一类是企业搭建数据中心和私有云自用，另一类是服务提供商，为客户提供私有云解决方案。在这两类情况中我们都看到 Kubernetes 被使用的越来越多，并且无论是企业、服务提供商，还是客户都尝到了 Kubernetes PaaS 的甜头。
对于自用型私有云来说，系统的演进是一个复杂的问题，盲目采用新技术有时不仅无助于业务，还造成资源浪费。k8s 的表现如何呢？我们让京东的经验来说话吧：
(采用容器和 Kubernetes 的)JDOS 2.0 接入了包含大数据、Web 利用、深度学习等多种类型的利用，并为每一种利用依据类型采取了不同的资源限制方式，并打上了 Kubernetes 的不同标签。基于多样的标签，我们实现了更加多样和灵便的调度方式，并在部份 IDC 试验性地混合部署了在线任务和离线任务。相较于 1.0，总体资源应用率提升了约 30%。——鲍永成，京东基础平台部技术总监
对于服务提供商来说，Kubernetes 健康的生态可以保证它们有大量的第三方软件和工具使用，同时 PaaS 易于开发和代码 / 应用复用的特性，也降低了它们交付项目的成本，并缩短了交付周期。
对于客户来说，基于 Kubernetes 的 PaaS 可以实现应用自由迁移，这使企业可以采用多重云策略，并变相提升了对供应商的议价能力。
云计算经过了十多年的发展，已然进入的云原生的新阶段，企业应用优先考虑部署在云环境，如何顺应云原生的大潮，使用容器和 Kubernetes 构建云原生平台，践行 DevOps 理念和敏捷 IT，开源软件和社区如何助力 IT 转型，所有这些问题的解决方案就是 PaaS 平台，其对于企业的重要性不言而喻。——宋净超 TalkingData 容器平台负责人
一些业界的经验可参考：
京东如何从 OpenStack 迁移至 Kubernetes
运维也需要 PaaS
腾讯互娱的运维团队，需要为公司的在线游戏提供运维能力，这可能是中国挑战最大要求最高的运维服务，因此他们有数百人的研发团队，他们的做法可以很大程度上代表运维的发展方向，而不断思考和迭代的结果就是自研了一套 PaaS 平台蓝鲸。蓝鲸本身不使用 Docker、Kubernetes 等，完全自研，但我们可以看到，运维的发展方向就是 PaaS。
PaaS 本身与 DevOps 的理念完全契合，它改变了传统运维的职责，让他们变成运维开发，为企业研发运维工具乃至是 PaaS 平台。而对于没有蓝鲸团队开发能力的人，容器和 Kubernetes 能为他们提供弯道超车的捷径。
京东金融的运维团队就采用了 Kubernetes 来搭建他们的 PaaS 平台：
PasS 平台化将问题的关注点从基础资源上升到了应用层面，目标是提供一个帮助开发人员运行、管理应用的平台，让使用者更关注运行的代码（业务逻辑）。
PaaS 能解决的问题：
应用聚合：如开发需要一个 Redis，直接启动一个 Redis 容器即可
服务发现、快速伸缩、状态管理等
服务监控、恢复、容灾
费用统计：提供计算资源信息汇总，针对不同项目收费
安全管控：不管什么平台，安全都非常重要，例如 A 应用可以访问 B,B 不允许访问 A 以及安全审计等。
快速部署。
随着 Docker 容器技术的出现，让我们有了更合适的工具建设 PaaS 平台，具备了基于应用构建服务的能力。在 Docker 容器调度框架上，我们又选择了 Kubernetes 平台。——张龙，京东金融 PE
为什么 PaaS 会成为云计算主流？
除了上面的这些，我们还可以看到，PaaS 是 SaaS 服务发展到一定程度后必然会做的事情，这么做不仅可以满足客户更全面、定制化的需求，也让 SaaS 厂商可以向更多领域拓展。如果要举一个例子的话，大家想想微信和小程序就能理解。
而为什么 Kubernetes 会成为 PaaS 的选择，为什么 PaaS 会成为云计算的主流，是因为容器和 Kubernetes 是今日云原生概念的核心和基础。云计算诞生到现在有十来年了，但云时代的应用应该长什么样子，过去一直没有人能说清楚，直到容器诞生后，我们终于离想象中的云时代稍微近了一些。
通过了解软件工程的这三个本质，你会发现，我们上面所说的那些分布式的技术点是高度一致的，也就是下面这三个方面的能力。
分布式多层的系统架构。
服务化的能力供应。
自动化的运维能力。
只有做到了这些，我们才能够真正拥有云计算的威力。这就是所谓的 Cloud Native。而这些目标都完美地体现在 PaaS 平台上。前面讲述的分布式系统关键技术和软件工程的本质，都可以在 PaaS 平台上得到完全体现。——陈皓 《洞悉 PaaS 平台的本质》
云计算的未来
过去几年云计算的发展令人眼花缭乱，想要预测它的未来无疑是极为困难的，但只要把握住 Kubernetes 这条主线，理解从虚拟化到容器再到两者融合的发展路线，在短期内我们还是能做一些预测。
这个问题（Kubernetes 在五年后会变成怎样）很好。我希望，在接下来的五年中，我们对 Kubernetes 的讨论不比对 Linux 内核的讨论多。它真的应该成为所有工作的基础。如果我们接下来的行为正确，我认为，有些事情就会成真。
大多数开源和 ISV（软件供应商）的安装指令都是始于“选择一个经过认证的 Kubernetes 集群”。第 2 步将是“运行这个 kubectl 命令”。Kubernetes 将让第三方软件不再忧虑开发针对无数平台的版本，让那些供应商更容易提供云提供商托管服务之外的方案。在许多情况下，使用云服务并没什么不对，但是，你应该从你自己的基础设施上也能获得类似的体验。
我相信，对于开发流程，我们将从封闭的 PaaS 服务，转向企业可以使用一流组件组装类似 PaaS 功能。其中，有些可能是领域专属的，只在一个特定的行业里应用。企业能够快速组装一个完整的解决方案，提供从代码到有强大防护的生产环境的简单路径，也提供在需要时“打破玻璃”运行自定义功能的能力。——Craig McLuckie，Kubernetes 创始人
Kubernetes 已经胜利，但基于 Kubernetes 的各类组件、工作流并不成熟，就像 Kubernetes 创始人 McLuckie 所说的，Kubernetes 需要成为讨论的“背景”，我们讨论的将是基于容器编排的各种创新和应用，比如 Service Mesh。
在我看来，在三到五年之后， Kubernetes 会成为服务器端的标准环境， 就像现在的 Linux，而 Service Mesh 就是运行在 Kubernetes 上的分布式应用的动态链接器，届时开发一个分布式应用将会像开发单机程序一样简单，业界在分布式操作系统上长达三十多年的努力将以这种方式告一段落。——宋潇男，普元信息云计算架构师
