2018年已过半，Kubernetes和云原生的巨浪要把云计算带向何处

摘要：自年月举办以来，规模持续增大。本届大会议题数量接近，比去年规模较大的北美峰会多出了近一倍。同时还在华为伙伴公有云等云平台上创建集群并接入了他们的平台，以便于快速响应技术峰会等大型活动期间暴涨的计算量。

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

容器领域最具影响力的技术峰会之一 KubeCon + CloudNativeCon Europe 2018 于今年 5 月 2 日 -5 月 4 日在丹麦哥本哈根召开。来自华为、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 生态，许多新鲜有趣的项目正在雨后春笋般地涌现 —— 毕竟，我们只是搭好了云原生的大舞台，真正的好戏，才刚刚开始。

声明：文章收集于网络，如有侵权，请联系小编及时处理，谢谢！

欢迎加入本站公开兴趣群

软件开发技术群

兴趣范围包括：Java，C/C++，Python，PHP，Ruby，shell等各种语言开发经验交流，各种框架使用，外包项目机会，学习、培训、跳槽等交流

QQ群：26931708

Hadoop源代码研究群

兴趣范围包括：Hadoop源代码解读，改进，优化，分布式系统场景定制，与Hadoop有关的各种开源项目，总之就是玩转Hadoop

QQ群：288410967