5月2日 - 5月4日，容器领域最具影响力的技术峰会之一 KubeCon + CloudNativeCon Europe 2018 在丹麦哥本哈根召开。来自华为、AWS、Azure、Google、IBM、Red Hat、VMWare等IT巨头的专家们分享了各自在Kubernetes、微服务、容器、容器存储、DevOps、Logging、Serverless、GPU加速等领域的技术发现。除了技术研讨，本次大会也非常重视客户案例，包括欧洲粒子研究中心（CERN），Spotify、维基百科、Booking.com、YouTube、NVIDIA、阿迪达斯、金融时报、eBay、挪威税务管理中心等企业客户分享了他们在生产环境中使用容器及其周边技术的实践经验。
Kubernetes 商用成熟，多云成为必然趋势
Kubernetes作为CNCF的核心项目，也是第一个顺利进入商用的项目，围绕它的生产实践在本次大会上成为分享焦点。
在第一天的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一致性认证项目的推动，包括Google、Azure、AWS，以及国内的华为云、阿里云、腾讯云在内的55个提供商都提供了认证的K8S发行版。多云的支持，已成为必然趋势。而随着CloudNative的发展，相信在不久的将来，以K8S为核心的云原生平台将真正实现cloud agnostic。用户可以真正轻松地实现，跨云，跨集群的workload迁移。
核心与基础问题已经解决，如何消除CloudNative背景下的安全焦虑？
过去两年是CNCF的创业期，社区以Kubernetes和容器为平台核心，围绕可观测性，可运维性，微服务发现等领域进行能力补齐，构建了灵活易扩展的基础平台。
随着容器、微服务等技术被越来越多地采用实施，运行于生产环境。越来越多的人关注到新兴技术背景下的安全问题。如何消除这些顾虑，也正是CNCF在接下来的时间内发力的重点。
Runtime方面，Google带来了他们自己的全容器方案 —— gVisor。gVisor提供新型沙箱容器运行时环境，能够在保证轻量化优势的同时，提供与虚拟机类似的隔离效果。这与去年在Austin的KubeCon上宣布成立的KataContainer项目定位十分类似。
KataContainer源自于Intel的ClearContainer和hyper的runV，是一种基于轻量级虚拟化的容器技术。它通过在容器外加装一层经过大量裁剪和优化的虚拟化内核，实现容器间的内核隔离。
与KataContainer略微不同，gVisor通过在用户空间内拦截应用程序系统调用并充当访客内核（guest kernel），来提供强大的隔离边界。另一处不同是gVisor不需要固定资源，它能够随时适应不断变化的资源条件，这一点更像是普通Linux进程。gVisor很像是一种超虚拟化操作系统，其与完整虚拟机相比拥有更灵活的资源利用方式与更低的固定成本，但这种灵活性的代价是其系统调用成本更高且应用程序兼容性略差。
gVisor项目为容器安全性提供了新思路，丰富了安全容器技术的生态，虽然距离商用还有一段路要走，但就将安全容器推向主流市场而言，它未来带来的帮助无疑会是巨大的。
Kubeflow发布0.1版本，大幅降低K8S上部署ML平台门槛
近年来，机器学习的发展可谓突飞猛进。如何发挥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或其他社区下。
Serverless领域发布事件标准CloudEvents 0.1
随着云技术的发展和越来越广泛的采用，应用程序变得越来越分散，集成的数量也在不断增长。人们越来越多地发布事件，利用事件驱动的设计模式，并且在各种环境之间传递事件。而另一方面，Serverless概念兴起，各大云平台开始提供函数服务（事件驱动计算服务），支持的事件数量也在不断增加。然而各个平台对于事件的描述却各不相同。开发人员必须先学习平台特定的术语和语义。事件的传输也颇受阻碍，因为逻辑和基础设施没有一致的信息来支持智能决策如何处理并转发事件。
为了解决Serverless的互操作性问题，CNCF Serverless工作组自去年年底完成白皮书之后，便致力于Serverless事件标准规范 —— CloudEvent 的制定。开源玩家包括华为、谷歌、微软、IBM、红帽等，都积极投入其中，为该项目做出了贡献。
本次大会上发布的CloudEvents 0.1的范围很简单：提供一组一致的元数据，可以将其包含在事件数据中，使事件更容易适用于发布者、中间件、订阅者和应用程序。简而言之，就是一个标准的事件信封。
CloudEvents的通用元数据使得事件更易于路由，扇出，追踪，重放，并且通常保持“在线”。它们更便携，更流畅，更易于跨环境传输。项目同时还在制定适用于每种协议的CloudEvents元数据映射到现有协议的规范。目前，网络带宽，成本和延迟仍然是主要挑战。但CloudEvents简单的元数据定义已经可以在诸多场景中为数据带来不错的可移植性。
聚焦K8S加速创新，CloudNative编程框架应运而生
众所周知，kubernetes早在设计之初就做到了架构上的松耦合，在而后的演进中又进行了多处插件化框架和可扩展性的改进和增强。Operator概念的引入，更是标准化了一大部分对K8S有定制扩展需求的场景。
然而，Operator本身的开发、测试、运维等，仍然有一定的门槛。开发者往往是寻找一个现有的Operator实现，刨除原有的业务代码，填入自己应用相关的管理逻辑。完成这个过程往往需要对K8S的API有比较深入的了解，并且具备相当的经验和技术知识。而想要完整地实现Operator的测试和运维，所需的额外工作就更多了。
Operator开发框架旨在归纳已有实现中优秀的实践经验，形成一套标准，来帮助降低K8S上应用程序的开发、测试和运维的门槛。开发框架包含3部分 —— SDK、生命周期管理以及监控度量。
Operator SDK提供了开发者构建、测试和封装Operators的工具。生命管理组件提供监督跨Kubernetes集群运行的所有Operator（及其关联服务）的生命周期的安装，更新和管理。而未来几个月内将会实现的监控度量组件，则会提供CPU、内存等基础指标以及自定义指标的监控采集。
Operator开发运维门槛的降低，对那些些苦于业务改造上云后运维难、对K8S有定制需求的企业用户来说，是一大福音。
大幕拉开，真正的好戏才刚刚开始
在过去，面向分布式应用开发，我们看到的是诸如Erlang、容错编程和框架等，更多的是绑定于不同的编程社区和软件栈。
可以欣喜地看到，Kubernetes凭借着它许多惊艳的特性，和庞大的生态力量，已经进入诸多分布式系统走向商业化相似的发展历程，日渐变得适合日常的开发者，适合日常的企业，最终成为被业界普遍采用的横向技术。
而在以K8S为核心的基座之上，良好的开发监控和运维体验，使得创新越来越快。眼下，诸如在微服务治理、机器学习等领域生态中，我们已经可以见到K8S被用作标配的底座和强力的助推器。
在接下来的几年里，市面上各类应用定义工具与服务将呈现爆发式增长，大大简化云上部署运维应用的门槛。毫无疑问，将来如果一个软件不能以某种形式直接或者插件化运行在K8S上，将没有人为它们买单。
而在未来，K8S的使用门槛将从白盒转向黑盒，开发者甚至不用掌握太多K8S的知识，只需基于一套标准化原语，便可实现分布式系统风格的编程。人们不必在纠结代码如何编译，镜像如何构建，测试与生产环境的配置有何不同，或者甚至连“kubernetes just run my code” 这样的命令都不用执行，寻常的一个代码提交动作便可以触发从编译构建测试到生产运维全流程的交付流水线。而出现问题时的回滚也会是如此的简单，因为代码提交的操作都是原子的。
今天，许多人或许会说K8S已经逐渐稳定，也逐渐变得无聊，但纵观整个CloudNative生态，许多新鲜有趣的项目正在雨后春笋般地涌现 —— 毕竟，我们只是搭好了云原生的大舞台，真正的好戏，才刚刚开始。
