华为/王泽锋

　　5月2日 - 5月4日，容器领域最具影响力的技术峰会之一 KubeCon + CloudNativeCon Europe 2018 在丹麦哥本哈根召开。来自华为、AWS、Azure、Google、IBM、Red Hat、VMWare等IT巨头的专家们分享了各自在Kubernetes、安全、微服务、机器学习、Serverless、DevOps等领域的技术经验。除了技术研讨，本次大会也非常重视客户案例，包括欧洲粒子研究中心(CERN)，Spotify、维基百科、Booking.com、YouTube、NVIDIA、阿迪达斯、金融时报、eBay、挪威税务管理中心等企业客户分享了他们在生产环境中使用容器及其周边技术的实践案例。

　　KubeCon + CloudNativeCon 自2015年11月举办以来，规模持续增大。本届大会议题数量接近300，比去年规模最大的北美峰会多出了近一倍。参会人数更是达到了4300人，几乎是去年柏林那次的3倍。值得一提的是，这一次的峰会，有很大部分与会者都是首次参加。而从活跃度来看，在成立不到3年的时间里，CNCF已经吸引了超过2.2万开发者参与其项目代码贡献，来自155个国家超过2.4万的用户在Edx上注册学习了Kubernetes的教学课程，55个厂商提供了认证的K8S发行版。CNCF的注册会员数也呈现爆发式的增长，从去年的81家，发展到今年的216家(其中包括52家end user成员)。

　　这些惊人的全球增长趋势，令人欣喜之余迫不及待想要看看云原生在未来究竟会发展出怎样一派繁荣的景象。

　　▲

　　▲

　　Kubernetes 商用成熟，多云成为必然趋势

　　Kubernetes作为CNCF的核心项目，也是第一个顺利进入商用Ready的项目，围绕它的生产实践分享成为本次大会的一大焦点。

　　在第一天的Keynote上，来自欧洲核子研究中心(CERN)的生产实践案例分享惊艳了全场。作为世界上最大的粒子物理研究中心，CERN有着非常庞大的计算需求，对撞机每秒可产生PB级的数据，而即使经过了硬件和软件过滤器的两级处理，仍然拥有每秒几个G的数据量。这些数据仍然很庞大，但却已经能够用于分析处理了。

　　在一个自建的数据中心，CERN已经搭建了210多个K8S集群，用来调度、管理拥有32万核、1万多hypervisor的基础设施。这些集群部署规模大小不一，小的只有几十个节点，而最大的已经到了上千节点。该数据中心保存了250PB的数据科研数据，并且保持每年60-70PB的速度增长;服务着3千多个用户，进行4千多个项目的分析和研究。

　　为了便于统一管理这些集群中的工作负载，CERN使用了Kubernetes federation(集群联邦)作为统一的平台入口。同时CERN还在华为伙伴公有云Open Telekom Cloud、Google Cloud、Azure、AWS等云平台上创建K8S集群并接入了他们的平台，以便于快速响应技术峰会等大型活动期间暴涨的计算量。

　　在两个或更多的云平台上创建K8S集群并部署工作负载，已经成为许多K8S采用者的常规做法。较之以往，用户可以相对容易地在多个云平台上同时部署业务，而享受到不同云平台的优势服务。

　　不难发现，当下基于Kubernetes的容器服务，已经几乎成为各家云平台的标配服务。得益于K8S软件一致性认证项目的推动，越来越多的厂商已将提供认证的K8S发行版作为基本要求。多云的支持，已成为必然趋势。而随着Cloud Native的发展，相信在不久的将来，以K8S为核心的云原生平台将真正实现“Cloud Agnostic”。用户可以轻松地完成跨云、跨集群的Workload自由迁移。

　　核心与基础问题已经解决，如何消除Cloud Native背景下的安全焦虑

　　过去的两年是CNCF的创业期，社区以Kubernetes和容器技术为平台核心，围绕可观测性，可运维性，服务发现等领域进行能力补齐，构建了灵活易扩展的基础平台。

　　随着容器、微服务等技术被越来越多地采用实施和运行于生产环境，越来越多的人关注到新兴技术背景下的安全问题。如何消除这些顾虑，也正是CNCF在接下来发力的重点。

　　Runtime方面，Google带来了他们自己的安全容器方案 —— gVisor。gVisor提供新型沙箱容器运行时环境，能够在保证轻量化优势的同时，提供与虚拟机类似的隔离效果。这与去年在Austin的KubeCon上宣布成立的KataContainer项目定位十分类似。

　　KataContainer源自于Intel的Clear Container和hyper的runV，是一种基于轻量级虚拟化的容器技术。它通过在容器外加装一层经过大量裁剪和优化的虚拟化，实现容器间的内核隔离。

　　与KataContainer略微不同，gVisor通过在用户空间内拦截应用程序系统调用并充当访客内核(guest kernel)，来提供强大的隔离边界。另一处不同是gVisor不需要固定资源，它能够随时适应不断变化的资源条件，这一点更像是普通Linux进程。gVisor很像是一种超虚拟化操作系统，其与完整虚拟机相比拥有更灵活的资源利用方式与更低的固定成本，但这种灵活性的代价是其系统调用成本更高且应用程序兼容性略差。

　　gVisor项目为容器安全性提供了新思路，丰富了安全容器技术的生态，虽然距离商用还有一段路要走，但就将安全容器推向主流市场而言，它未来带来的帮助无疑会是巨大的。

　　Kubeflow发布0.1版本，大幅降低机器学习框架部署门槛

　　近年来，机器学习的发展可谓突飞猛进。如何发挥Kubernetes的优势，将其作为部署平台来提供便捷、可扩展的机器学习框架，是其中一个重点话题之一。Kubeflow项目的发起，正是试图找到一种最简便的开源解决方案。

　　自去年北美的KubeCon + CloudNativeCon宣布项目成立之后，Kubeflow已经吸引了来自包括Google、微软、Redhat、华为、阿里云等在内的20多个组织的70多个贡献者贡献了700多条代码提交，并获得了3.1k的star，增长速度之快跃居Github前2%。本次发布的0.1版本提供了一套最精简的软件包，方便用户开发、训练和部署机器学习框架。

　　▲

　　在之后的几个月里，Kubeflow项目将致力于0.2的发布，届时将提供：

　　● 通过引导容器简化设置

　　● 优化GPU集成

　　● 支持更多的机器学习框架，如Spark ML，XGBoost，sklearn

　　● 支持TF服务的自动伸缩

　　● 编程数据转换，如tf.transform

　　而今年年底Kubeflow发布1.0版本之后，kubeflow项目将寻求一个正式的治理社区，托管在CNCF或其他社区下。

　　▲

　　Service Mesh持续走俏，Istio 引领大潮

　　企业上云，容器和微服务是两大利器。容器屏蔽了应用对环境的感知，简化了软件包分发的一致性问题，避免重复劳动。而转向微服务的架构，屏蔽了应用对服务的感知，可以使业务团队更专注于自身专业领域。关于如何做负载均衡、熔断和遥测等等问题，都可以通过Service Mesh卸掉。高度的聚焦可以大幅度提高生产力。

　　Istio作为最有希望成为Service Mesh事实标准的项目，自去年5月份发布以来，凭借与K8S的深度集成、零侵入性、易扩展等优势，加以Google、IBM等大厂商支持，迅速走红。在不到一年的时间里获得了8000+的star，吸引到近200个贡献者参与代码开发，成为去年以来K8S生态中最火热的项目。

　　而在技术上，早期版本的性能问题也得到了一定程度的改善，p99和p99.9时延有10倍左右的提升，2 vCPU下的最大吞吐量也达到了1700 QPS。大部分场景只有10%左右消耗，已经能够为人们接受。

　　本次大会中Istio的一大话题是多云和多集群。K8S在多云之间提供了一致的平台环境，但是如何实现跨云、跨集群的服务发现和流量控制却一直悬而未决。在K8S Federation项目中，有一个简单版的实现——本集群优先路由。而Istio在最新发布的0.8版本中提供了多集群支持的特性，补齐K8S在多集群场景下的服务管理能力。

　　当然，Istio作为一个刚满一年的年轻项目，离生产可用还有一定的距离，但这并不削减人们对其使用的兴趣。有调查显示，已有相当一部分K8S的用户开始在生产中部署使用Istio。相信经过2018年市场的打磨和沉淀，Istio的成熟度会有一个质的飞越。

　　Serverless领域发布事件标准CloudEvents 0.1

　　随着云技术的发展和越来越广泛的采用，应用程序变得越来越分散，集成的数量也在不断增长。人们越来越多地发布事件，在各种环境之间传递事件，利用事件驱动的设计模式构建应用。而另一方面，Serverless概念兴起，各大云平台开始提供函数服务(事件驱动计算服务)，支持的事件类型也在不断增加。然而，各个平台对于事件的描述却各不相同。开发人员不得不学习、适配各个平台特定的术语和语义。由于逻辑和基础设施缺少一致的信息，开发者难以实现对事件的智能决策处理，事件的传递也因此颇受阻碍。

　　为了解决Serverless的互操作性问题，CNCF Serverless工作组自去年年底完成白皮书之后，便致力于Serverless事件标准规范 —— CloudEvents 的制定。开源玩家包括华为，谷歌，微软，IBM，红帽等，都积极投入其中，为该项目做出了巨大的贡献。

　　本次大会上发布的CloudEvents 0.1的范围很简单：提供一组一致的元数据，可以将其包含在事件数据中，使事件更容易适用于发布者、中间件、订阅者和应用程序。简而言之，就是一个标准的事件信封。

　　CloudEvents的通用元数据使得事件更易于路由，扇出，追踪，重放，并且基本保持“在线”。它们更便携，更流畅，更易于跨环境传输。项目同时还在制定适用于每种协议的CloudEvents元数据映射到现有协议的规范。目前，网络带宽，成本和延迟仍然是主要挑战。但CloudEvents简单的元数据定义已经可以在诸多场景中为数据带来不错的可移植性。

　　聚焦K8S加速创新，Cloud Native编程框架应运而生

　　众所周知，Kubernetes早在设计之初就做到了架构上的松耦合，在而后的演进中又进行了多处插件化框架和可扩展性的改进和增强。Operator概念的引入，更是标准化了一大部分对K8S有定制扩展需求的场景。

　　然而，Operator本身的开发、测试、运维等，仍然有一定的门槛。开发者往往是寻找一个现有的Operator实现，刨除原有的业务代码，填入自己应用相关的管理逻辑。完成这个过程往往需要对K8S的API有比较深入的了解，并且具备相当的经验和技术知识。而想要完整地实现Operator的测试和运维，所需的额外工作就更多了。

　　Operator开发框架旨在归纳已有实现中优秀的实践经验，形成一套标准，来帮助降低K8S上应用程序的开发、测试和运维的门槛。开发框架包含3部分 —— SDK、生命周期管理以及监控度量。

　　Operator SDK提供了开发者构建、测试和封装Operators的工具。生命管理组件提供监督跨Kubernetes集群运行的所有Operator(及其关联服务)的生命周期的安装，更新和管理。而未来几个月内将会实现的监控度量组件，则会提供CPU、内存等基础指标以及自定义指标的监控采集。

　　Operator开发运维门槛的降低，对那些苦于业务改造上云后运维难、对K8S有定制需求的企业用户来说，是一大福音。

　　本次KubeCon还带来了一个十分新颖的项目——Ballerina。这是一门用于集成的Cloud Native编程语言。

　　Ballerina的开发者认为，未来人们编写的应用程序会越来越依赖于API， 而集成则是打通各端点间弹性通信的重要规范。因此，他们将分布式系统集成的基本概念融合到语言中，设计了这门编译型、事务性、静态强类型编程语言，并提供了类型安全的并发环境。

　　Ballerina支持文本和图形语法，除常规的文本编写代码外，开发者还可以通过在设计器中编辑图表来组织代码。这更进一步降低了云原生应用的开发门槛，开发者可以轻松地实现具有分布式事务、可靠消息传递、流处理和工作流的微服务。

　　大幕拉开，真正的好戏才刚刚开始

　　过去，面向分布式应用开发，我们看到的是Erlang、容错编程和开发框架等，更多的是绑定于不同的编程社区和软件栈。

　　现在，我们可以欣喜地看到，Kubernetes凭借着它许多惊艳的特性和庞大的生态力量，已经进入与诸多分布式系统走向商业化相似的发展历程——日渐变得适合日常的开发者，适合日常的企业，最终成为被业界普遍采用的横向技术。

　　而在以K8S为核心的基座之上，良好的开发监控和运维体验使得创新越来越快。眼下，诸如在微服务治理、机器学习等领域生态中，我们已经可以见到K8S被用作标配的底座和强力的助推器。

　　在接下来

　　华为/王泽锋

　　5月2日 - 5月4日，容器领域最具影响力的技术峰会之一 KubeCon + CloudNativeCon Europe 2018 在丹麦哥本哈根召开。来自华为、AWS、Azure、Google、IBM、Red Hat、VMWare等IT巨头的专家们分享了各自在Kubernetes、安全、微服务、机器学习、Serverless、DevOps等领域的技术经验。除了技术研讨，本次大会也非常重视客户案例，包括欧洲粒子研究中心(CERN)，Spotify、维基百科、Booking.com、YouTube、NVIDIA、阿迪达斯、金融时报、eBay、挪威税务管理中心等企业客户分享了他们在生产环境中使用容器及其周边技术的实践案例。

　　KubeCon + CloudNativeCon 自2015年11月举办以来，规模持续增大。本届大会议题数量接近300，比去年规模最大的北美峰会多出了近一倍。参会人数更是达到了4300人，几乎是去年柏林那次的3倍。值得一提的是，这一次的峰会，有很大部分与会者都是首次参加。而从活跃度来看，在成立不到3年的时间里，CNCF已经吸引了超过2.2万开发者参与其项目代码贡献，来自155个国家超过2.4万的用户在Edx上注册学习了Kubernetes的教学课程，55个厂商提供了认证的K8S发行版。CNCF的注册会员数也呈现爆发式的增长，从去年的81家，发展到今年的216家(其中包括52家end user成员)。

　　这些惊人的全球增长趋势，令人欣喜之余迫不及待想要看看云原生在未来究竟会发展出怎样一派繁荣的景象。

　　Kubernetes 商用成熟，多云成为必然趋势

　　Kubernetes作为CNCF的核心项目，也是第一个顺利进入商用Ready的项目，围绕它的生产实践分享成为本次大会的一大焦点。

　　在第一天的Keynote上，来自欧洲核子研究中心(CERN)的生产实践案例分享惊艳了全场。作为世界上最大的粒子物理研究中心，CERN有着非常庞大的计算需求，对撞机每秒可产生PB级的数据，而即使经过了硬件和软件过滤器的两级处理，仍然拥有每秒几个G的数据量。这些数据仍然很庞大，但却已经能够用于分析处理了。

　　在一个自建的数据中心，CERN已经搭建了210多个K8S集群，用来调度、管理拥有32万核、1万多hypervisor的基础设施。这些集群部署规模大小不一，小的只有几十个节点，而最大的已经到了上千节点。该数据中心保存了250PB的数据科研数据，并且保持每年60-70PB的速度增长;服务着3千多个用户，进行4千多个项目的分析和研究。

　　为了便于统一管理这些集群中的工作负载，CERN使用了Kubernetes federation(集群联邦)作为统一的平台入口。同时CERN还在华为伙伴公有云Open Telekom Cloud、Google Cloud、Azure、AWS等云平台上创建K8S集群并接入了他们的平台，以便于快速响应技术峰会等大型活动期间暴涨的计算量。

　　在两个或更多的云平台上创建K8S集群并部署工作负载，已经成为许多K8S采用者的常规做法。较之以往，用户可以相对容易地在多个云平台上同时部署业务，而享受到不同云平台的优势服务。

　　不难发现，当下基于Kubernetes的容器服务，已经几乎成为各家云平台的标配服务。得益于K8S软件一致性认证项目的推动，越来越多的厂商已将提供认证的K8S发行版作为基本要求。多云的支持，已成为必然趋势。而随着Cloud Native的发展，相信在不久的将来，以K8S为核心的云原生平台将真正实现“Cloud Agnostic”。用户可以轻松地完成跨云、跨集群的Workload自由迁移。

　　核心与基础问题已经解决，如何消除Cloud Native背景下的安全焦虑

　　过去的两年是CNCF的创业期，社区以Kubernetes和容器技术为平台核心，围绕可观测性，可运维性，服务发现等领域进行能力补齐，构建了灵活易扩展的基础平台。

　　随着容器、微服务等技术被越来越多地采用实施和运行于生产环境，越来越多的人关注到新兴技术背景下的安全问题。如何消除这些顾虑，也正是CNCF在接下来发力的重点。

　　Runtime方面，Google带来了他们自己的安全容器方案 —— gVisor。gVisor提供新型沙箱容器运行时环境，能够在保证轻量化优势的同时，提供与虚拟机类似的隔离效果。这与去年在Austin的KubeCon上宣布成立的KataContainer项目定位十分类似。

　　KataContainer源自于Intel的Clear Container和hyper的runV，是一种基于轻量级虚拟化的容器技术。它通过在容器外加装一层经过大量裁剪和优化的虚拟化，实现容器间的内核隔离。

　　与KataContainer略微不同，gVisor通过在用户空间内拦截应用程序系统调用并充当访客内核(guest kernel)，来提供强大的隔离边界。另一处不同是gVisor不需要固定资源，它能够随时适应不断变化的资源条件，这一点更像是普通Linux进程。gVisor很像是一种超虚拟化操作系统，其与完整虚拟机相比拥有更灵活的资源利用方式与更低的固定成本，但这种灵活性的代价是其系统调用成本更高且应用程序兼容性略差。

　　gVisor项目为容器安全性提供了新思路，丰富了安全容器技术的生态，虽然距离商用还有一段路要走，但就将安全容器推向主流市场而言，它未来带来的帮助无疑会是巨大的。

　　Kubeflow发布0.1版本，大幅降低机器学习框架部署门槛

　　近年来，机器学习的发展可谓突飞猛进。如何发挥Kubernetes的优势，将其作为部署平台来提供便捷、可扩展的机器学习框架，是其中一个重点话题之一。Kubeflow项目的发起，正是试图找到一种最简便的开源解决方案。

　　自去年北美的KubeCon + CloudNativeCon宣布项目成立之后，Kubeflow已经吸引了来自包括Google、微软、Redhat、华为、阿里云等在内的20多个组织的70多个贡献者贡献了700多条代码提交，并获得了3.1k的star，增长速度之快跃居Github前2%。本次发布的0.1版本提供了一套最精简的软件包，方便用户开发、训练和部署机器学习框架。

　　在之后的几个月里，Kubeflow项目将致力于0.2的发布，届时将提供：

　　● 通过引导容器简化设置

　　● 优化GPU集成

　　● 支持更多的机器学习框架，如Spark ML，XGBoost，sklearn

　　● 支持TF服务的自动伸缩

　　● 编程数据转换，如tf.transform

　　而今年年底Kubeflow发布1.0版本之后，kubeflow项目将寻求一个正式的治理社区，托管在CNCF或其他社区下。

　　Service Mesh持续走俏，Istio 引领大潮

　　企业上云，容器和微服务是两大利器。容器屏蔽了应用对环境的感知，简化了软件包分发的一致性问题，避免重复劳动。而转向微服务的架构，屏蔽了应用对服务的感知，可以使业务团队更专注于自身专业领域。关于如何做负载均衡、熔断和遥测等等问题，都可以通过Service Mesh卸掉。高度的聚焦可以大幅度提高生产力。

　　Istio作为最有希望成为Service Mesh事实标准的项目，自去年5月份发布以来，凭借与K8S的深度集成、零侵入性、易扩展等优势，加以Google、IBM等大厂商支持，迅速走红。在不到一年的时间里获得了8000+的star，吸引到近200个贡献者参与代码开发，成为去年以来K8S生态中最火热的项目。

　　而在技术上，早期版本的性能问题也得到了一定程度的改善，p99和p99.9时延有10倍左右的提升，2 vCPU下的最大吞吐量也达到了1700 QPS。大部分场景只有10%左右消耗，已经能够为人们接受。

　　本次大会中Istio的一大话题是多云和多集群。K8S在多云之间提供了一致的平台环境，但是如何实现跨云、跨集群的服务发现和流量控制却一直悬而未决。在K8S Federation项目中，有一个简单版的实现——本集群优先路由。而Istio在最新发布的0.8版本中提供了多集群支持的特性，补齐K8S在多集群场景下的服务管理能力。

　　当然，Istio作为一个刚满一年的年轻项目，离生产可用还有一定的距离，但这并不削减人们对其使用的兴趣。有调查显示，已有相当一部分K8S的用户开始在生产中部署使用Istio。相信经过2018年市场的打磨和沉淀，Istio的成熟度会有一个质的飞越。

　　Serverless领域发布事件标准CloudEvents 0.1

　　随着云技术的发展和越来越广泛的采用，应用程序变得越来越分散，集成的数量也在不断增长。人们越来越多地发布事件，在各种环境之间传递事件，利用事件驱动的设计模式构建应用。而另一方面，Serverless概念兴起，各大云平台开始提供函数服务(事件驱动计算服务)，支持的事件类型也在不断增加。然而，各个平台对于事件的描述却各不相同。开发人员不得不学习、适配各个平台特定的术语和语义。由于逻辑和基础设施缺少一致的信息，开发者难以实现对事件的智能决策处理，事件的传递也因此颇受阻碍。

　　为了解决Serverless的互操作性问题，CNCF Serverless工作组自去年年底完成白皮书之后，便致力于Serverless事件标准规范 —— CloudEvents 的制定。开源玩家包括华为，谷歌，微软，IBM，红帽等，都积极投入其中，为该项目做出了巨大的贡献。

　　本次大会上发布的CloudEvents 0.1的范围很简单：提供一组一致的元数据，可以将其包含在事件数据中，使事件更容易适用于发布者、中间件、订阅者和应用程序。简而言之，就是一个标准的事件信封。

　　CloudEvents的通用元数据使得事件更易于路由，扇出，追踪，重放，并且基本保持“在线”。它们更便携，更流畅，更易于跨环境传输。项目同时还在制定适用于每种协议的CloudEvents元数据映射到现有协议的规范。目前，网络带宽，成本和延迟仍然是主要挑战。但CloudEvents简单的元数据定义已经可以在诸多场景中为数据带来不错的可移植性。

　　聚焦K8S加速创新，Cloud Native编程框架应运而生

　　众所周知，Kubernetes早在设计之初就做到了架构上的松耦合，在而后的演进中又进行了多处插件化框架和可扩展性的改进和增强。Operator概念的引入，更是标准化了一大部分对K8S有定制扩展需求的场景。

　　然而，Operator本身的开发、测试、运维等，仍然有一定的门槛。开发者往往是寻找一个现有的Operator实现，刨除原有的业务代码，填入自己应用相关的管理逻辑。完成这个过程往往需要对K8S的API有比较深入的了解，并且具备相当的经验和技术知识。而想要完整地实现Operator的测试和运维，所需的额外工作就更多了。

　　Operator开发框架旨在归纳已有实现中优秀的实践经验，形成一套标准，来帮助降低K8S上应用程序的开发、测试和运维的门槛。开发框架包含3部分 —— SDK、生命周期管理以及监控度量。

　　Operator SDK提供了开发者构建、测试和封装Operators的工具。生命管理组件提供监督跨Kubernetes集群运行的所有Operator(及其关联服务)的生命周期的安装，更新和管理。而未来几个月内将会实现的监控度量组件，则会提供CPU、内存等基础指标以及自定义指标的监控采集。

　　Operator开发运维门槛的降低，对那些苦于业务改造上云后运维难、对K8S有定制需求的企业用户来说，是一大福音。

　　本次KubeCon还带来了一个十分新颖的项目——Ballerina。这是一门用于集成的Cloud Native编程语言。

　　Ballerina的开发者认为，未来人们编写的应用程序会越来越依赖于API， 而集成则是打通各端点间弹性通信的重要规范。因此，他们将分布式系统集成的基本概念融合到语言中，设计了这门编译型、事务性、静态强类型编程语言，并提供了类型安全的并发环境。

　　Ballerina支持文本和图形语法，除常规的文本编写代码外，开发者还可以通过在设计器中编辑图表来组织代码。这更进一步降低了云原生应用的开发门槛，开发者可以轻松地实现具有分布式事务、可靠消息传递、流处理和工作流的微服务。

　　大幕拉开，真正的好戏才刚刚开始

　　过去，面向分布式应用开发，我们看到的是Erlang、容错编程和开发框架等，更多的是绑定于不同的编程社区和软件栈。

　　现在，我们可以欣喜地看到，Kubernetes凭借着它许多惊艳的特性和庞大的生态力量，已经进入与诸多分布式系统走向商业化相似的发展历程——日渐变得适合日常的开发者，适合日常的企业，最终成为被业界普遍采用的横向技术。

　　而在以K8S为核心的基座之上，良好的开发监控和运维体验使得创新越来越快。眼下，诸如在微服务治理、机器学习等领域生态中，我们已经可以见到K8S被用作标配的底座和强力的助推器。

　　在接下来的几年里，市面上各类应用定义工具与服务将呈现爆发式增长，大大简化云上部署运维应用的门槛。毫无疑问，将来如果一个软件不能以某种形式直接或者插件化运行在K8S上，将没有人为它们买单。

　　未来，K8S的使用门槛将从白盒转向黑盒，开发者甚至不用掌握太多K8S的知识，只需基于一套标准化原语，便可实现分布式系统风格的编程。人们不必在纠结代码如何编译，镜像如何构建，测试与生产环境的配置有何不同，甚至连“kubernetes just run my code” 这样的命令都不用执行，寻常的一个代码提交动作便可以触发从编译构建测试到生产运维全流程的交付流水线。而出现问题时的回滚也会是如此的简单，因为代码提交的操作都是原子的。

　　回顾当下，或许很多人会觉得K8S已经逐渐稳定，也逐渐变得无聊，但纵观整个Cloud Native生态，许多新鲜有趣的项目正在雨后春笋般地涌现 —— 毕竟，我们只是搭好了云原生的大舞台，真正的好戏，才刚刚开始。点击了解华为云应用服务：https://www.huaweicloud.com/paas/

　　的几年里，市面上各类应用定义工具与服务将呈现爆发式增长，大大简化云上部署运维应用的门槛。毫无疑问，将来如果一个软件不能以某种形式直接或者插件化运行在K8S上，将没有人为它们买单。

　　未来，K8S的使用门槛将从白盒转向黑盒，开发者甚至不用掌握太多K8S的知识，只需基于一套标准化原语，便可实现分布式系统风格的编程。人们不必在纠结代码如何编译，镜像如何构建，测试与生产环境的配置有何不同，甚至连“kubernetes just run my code” 这样的命令都不用执行，寻常的一个代码提交动作便可以触发从编译构建测试到生产运维全流程的交付流水线。而出现问题时的回滚也会是如此的简单，因为代码提交的操作都是原子的。

　　回顾当下，或许很多人会觉得K8S已经逐渐稳定，也逐渐变得无聊，但纵观整个Cloud Native生态，许多新鲜有趣的项目正在雨后春笋般地涌现 —— 毕竟，我们只是搭好了云原生的大舞台，真正的好戏，才刚刚开始。点击了解华为云应用服务：https://www.huaweicloud.com/paas/