容器云将来：Kubernetes、Istio 和 Knative

导读

目前以Kubernetes为基础构建的容器生态逐渐完善，这其中Kubernetes、Istio、Knative三个独立项目被愈来愈多的人说起，而且已经开始尝试大规模落地实践，它们刚好构成了容器云的将来拼图。今天与你们一块儿分享下，这三个项目究竟解决了什么问题，为何它们可以一举成名。

随着微服务理念不断深刻人心，愈来愈多的企业把本身的应用逐步由单体转变成微服务架构，Container容器技术的出现偏偏加速了这个转移过程，由于它有效地解决了N多服务的快速部署问题。可是随着服务数目的增多，愈来愈多的企业但愿可以把相关服务有效地“聚合”在一块儿，方便统一部署与管理。Kubenretes的出现偏偏解决了大规模微服务编排部署所带来的挑战，让整个行业意识到PaaS的落地能够成为现实。

当随着微服务体系下的服务数目愈来愈多，服务运维成为必然要解决的问题，因而Istio出现了，基于网络代理与控制相分离的实现策略，容许对服务控制策略进行有效合理的管控。

到这里彷佛到了很美好的阶段：
微服务：解决应用内聚、臃肿的问题。
Container：解决服务运行环境统一，和部署问题。
Kubernetes：解决大量微服务有效“聚合”部署问题。
Istio：解决服务上线面临的一系列治理问题。

这个阶段乍一看来，构建容器云彷佛有了一个完整的链路和解决方式，一切都将变得那么“完美”。

如今让咱们回过头来深刻分析一下，微服务体系下的服务交互，目前是否存在问题。

首先，不管是http，仍是rpc，本质上都是服务与服务的远程调用。开发应用程序中，没法作到服务与服务间的彼此透明。这样会致使一个问题：不管微服务业务拆分多么“精细”，本质上业务单元之间仍是不可以独立运行和发展。同时在面向不一样开发领域的衍生，没法选择最合适的实现方式。所以咱们但愿可以基于不一样的“模板”+“配置”的方式可以把开发环境标准化处理，同时提供“事件”机制，将服务与服务交互的耦合度降到最低。

其次，服务线上运行的动态伸缩问题。当下kubernetes环境下的弹性伸缩，须要由客户搜集监测数据，并自主手动来实现，可是咱们更但愿服务线上可以更加自动化和智能化。

最后，服务标准化问题。咱们但愿服务内部的模型是标准的、可以快速复制和快速构建的；服务通讯是标准的：协议标准，格式标准；运行环境是标准的：快速部署，快速迁移。

Knative的出现刚好解决远程直接调用，服务线上自动管理以及一些列标准化问题。

下面咱们来看一下三者的关联：

Kubernetes和Istio相信你们比较熟悉了，这里不作过多介绍，有须要的同窗能够关注下咱们以前发布的相关文章，这里咱们重点来看一下Knative。

Knative是谷歌开源的serverless架构方案，旨在提供一套简单易用的serverless方案，把serverless标准化。目前参与的公司主要是Google、Pivotal、IBM、Red Hat，于2018年7月份对外发布，目前处于快速发展阶段。

Knative组成

Build
构建系统：把用户定义的应用构建成容器镜像，面向kubernetes的标准化构建，区别于Dockerfile镜像构建，重点解决kubernetes环境的构建标准化问题。

Serving
服务系统：利用Istio的部分功能，来配置应用路由，升级以及弹性伸缩。Serving中包括容器生命周期管理，容器外围对象（service，ingres）生成（恰到好处的把服务实例与访问统一在一块儿），监控应用请求，自动弹性负载，而且利用Virtual service和destination配置服务访问规则。只有这样才能保证服务呈现一致性以及服务运行自动化管理。

Eventing
事件系统：用于自动完成事件的绑定与触发。事件系统与直接调用最大的区别在于响应式设计，它容许运行服务自己不须要屏蔽了调用方与被调用方的关系。从而在业务层面可以实现业务的快速聚合，或许为后续业务编排创新提供事件。

如今咱们换一个角度，聚焦应用服务生命周期：
**Knative 解决应用模板+面向统一环境的标准化构建场景；
Kubernetes做为基础设施，解决应用编排和运行环境场景；
Isito做为通讯基础设施层，保证应用服务运行可检测、可配置、可追踪问题。**

这三者贯穿应用服务生命周期全过程，容器云偏偏也是管理应用服务的控制平台，这就可以很好地解释，为何Kubernetes，Istio，Knative在将来会成为构建容器云的三驾马车。