KubeCon 第二天| 6 大 Keynote 强势展现 K8S 新趋势

2018-05-03

5 月 3 日,KubeCon + CloudNativeCon Europe 2018 的第二天,继续昨天的火热人气,不同于第一天 Keynote 的温情脉脉,今天的 6 大 Keynote 可谓干货满满、惊喜不断……


在今天的 6 大 Keynote 中 Google 演讲人带来了 Kubernetes 项目的最新进展、CoreOS 发布加速 Kubernetes 原生应用开发的新思路 “Operator Framework”、Google 新一代安全容器 gVisor 正式发布, 不同于上一届满屏的“boring”,“创新”、“落地”才是这一届 KubeCon 的主题词。正如本次大会的 Slogan “Keep Cloud Native Hygge” ,安全、易用、宜人将成为未来 Cloud Native 的发展方向!接下来,听听现场技术大牛如何抽丝剥茧分析这 6 个 Keynote。


KubeCon Opening Keynote


Keynote 1: Kubernetes Project Update

今天的的第一个 Keynote,演讲人 Google 产品经理 Aparna Sinha 带来了 Kubernetes 项目的最新进展。


目前 Kubernetes 在 GitHub 上已经超过 35,000 颗星,整体活跃度仅次于 Linux。Kubernetes 在技术上快速成熟,目前已有 54% 的企业开始落地 Kubernetes。


在介绍 Kubernetes 前,Aparna 回顾了自己加入 Google 的心路历程。加入 Google 前,Aparna 的主要工作内容是企业系统,但是企业系统往往迭代缓慢。为了追求软件研发的速度,Aparna 开始转向消费类产品研发。但加入 Google 之后,Aparna 惊讶地看到原来企业系统软件也可以如此敏捷高效,于是开始做 Google 云的相关工作,为引出 Kubernetes 的项目更新做足了铺垫。



Aparna 随后带来了 Kubernetes 在三个方面的更新:Security、Applications 和 Experience。


在 Kubernetes Security 层面,Aparna 提到了 Kubernetes 的 5 个重要功能:

  • Network Policy: 1.7 Stable
  • Encrypted Secrets: 1.7 Alpha
  • RBAC: 1.6 beta, 1.8 Stable
  • TLS Cert Rotation: 1.7 Alpha, 1.8 Beta
  • PodSecurityPolicy: 1.4 Alpha, 1.8 Beta



除了 Kubernetes 以外,现在也有很多公司提供基于 Kubernetes 的安全服务,例如 Aqua、StackRox、Twistlock 等等。Google 也在与此类公司合作,并公布了包含容器安全的云安全命令中心,提供更加专业的容器安全服务。


接下来,Aparna 再次介绍了容器沙箱 gVisor,Aparna 认为这是继 Kubernetes 之后的一个伟大的创新。


在应用(Application) 层面,Kubernetes 不再仅仅只聚焦在无状态服务上,而会支持更多不同种类的运行负载,包括:

  • 批处理任务,定时任务:1.8 Beta
  • 负载类控制器 GA,本地存储 1.9 Beta
  • GPUs 支持 1.9
  • CSI 1.10 Beta


Aparna 带来了 spark-operator demo,通过 Kubernetes,运行复杂应用如 spark 的平台只需要不超过 10 分钟。



最后,Aparana 带来了 User Experience 的更新。Kubernetes 的开发体验一直不好,一个理想的开发环境应该是:Source code -> Build -> Deploy -> Kubernetes (CD) 。为了实现这样的体验,Aparana 分享了 Scaffold 项目。通过使用 Scaffold,用户只需要更新代码,Scaffold 会将更新自动上传至 Kubernetes 集群。



Keynote 2:Accelerating Kubernetes Native Applications

云计算时代已经到来,当用户想要应用上云时,到底该选择公有云还是私有容器云呢?出于数据安全或其他原因考虑,很多用户通常无法接受将应用部署到公有云上运行。



同时,有状态应用的治理也需要一定的工作量来提供稳定性保障。因此,为特定业务的有状态应用实现一个专用的 Operator 成为了用户的一种选择。但是,开发一个专用的 Operator 并不简单。开发者通常需要进行以下工作:在 Kubernete 集群中持续追踪对应资源类型、完成一系列测试流程、管理 Op erator 项目和其依赖的第三方软件包和库。



几年前,CoreOS 率先开发了一套家喻户晓的 etcd-operator,成功地展示了如何在 Kubernetes 集群中进行有状态应用及其生命周期的管理。



今天,演讲人 CoreOS CTO Brandon Philips 带来了加速 Kubernetes 原生应用开发的新思路 —— Operator Framework。


作为一个全新的开源组织,为了快速赋能云原生开发者,该组织同时提供了一套快速上手的工具集 —— Operator SDK。开发者使用该 SDK 快速搭建、测试和打包满足用户需求的专用 Operator,进一步提升应用上云的效率和加速云原生应用生态的建设。




Keynote 3:

Switching Horses Midstream: The Challenges of Migrating 150+ Microservices to Kubernetes

演讲人英国《金融时报》Operations and Reliability 技术总监 Sarah Wells 指出,《金融时报》在 2015 年中将容器技术引入到公司内容平台是一个非常明智的创新。因为这几乎减少了在 AWS EC2 上 80% 的开销。但是,这种改变也仅仅是万里长征迈出的第一步,接下来要维护一个内部的容器平台将是一大挑战。


我们都知道,《金融时报》不是一个做容器编排的公司。他们一开始就在各种开源工具中进行选择,直到 2016 年底,工具才成熟。他们当时选择成熟工具的标准就是:

  • 他们花了大量的时间研究如何保持集群的健康
  • 研究了 Slack 上对各种工具的差评


最后,《金融时报》 选择了 Kubernetes。


要使用最前沿先进的技术,必须能够适应变化:对做出的错误决定不要害怕,更要不断去试错。选择了平台之后,他们面临着迁移 150 个服务到 Kubernetes 平台的巨大任务。他们遇到了并行运行会出现的并发问题,同时这期间还有许多其他的事情需要去做。在并行运行部分代码栈的过程中,他们曾有 2000 多次的代码发布。


然后,他们也做了许多决定,比如:

  • 创建独立的分支 vs 代码中使用 if/else 逻辑
  • 分开的部署机制 vs 单一的部署机制


把所有测试都做一遍是不可能的,所以他们选择采用冒险的策略做测试,他们觉得应该只做自己认为有必要做的测试。


任何事情做 150 次都需要花费时间。他们把所有的 systemd service 迁移到 helm chart,把服务集成到 jenkins pipeline,让公司所有人都参与进来是一件好事情。


这个项目最后用数据显示出采纳 Kubernetes 和 Micrervices 是一个非常正确的技术选择,大大减少了 hosting 和 support 的开销。



Keynote 4: Shaping the Cloud Native Future

在 Keynote 4,演讲人 Cloud Foundry Foundation 执行董事 Abby Keams 展望了未来云原生世界的美好愿景,他认为未来所有的应用都会在云上(Cloud Everything)。同时,他认为云上应用最重要的三个特点是高效性(velocity)、创新性(innovation)和交互性(interoperability)。



Abby Keams 预测 2020 年企业的云原生应用相比现在将有 100% 增长。



而一个云原生应用从开发到部署上线,通常由多个团队共同完成,如 CIO 负责资金投入、研发(Dev)负责应用开发、运维(Ops)负责部署和维护。



虽然跨团队合作很难,但是仍然有很多大公司果断做出了上云的决策,并取得了不错的成效。Abby Keams 分别列举了大众汽车(Volkswagen)、美国空军(U.S.AIR FORCE)和家得宝(The Home Depot)的上云案例,分享了这几家企业和组织通过上云取得的开发效率和投入产出比的提升。



最后,Abby Keams 总结到:“随着企业云原生应用规模的壮大,未来应用开发和运维将会更多地节省您的资金和时间。同时,正因为企业自己完成了应用的开发和部署,这将使得企业自身对数据和应用拥有更多的控制力。”



Keynote 5:

Skip the Anxiety Attack - Build Secure Apps with Kubernetes

演讲者,IBM Container and Microservice 部门 VP 及 CTO Jason McGee 认为,未来他将关注应用的 Scalability、Stability 和 Security。


2018 年软件开发将变得更快、更分布式和更动态,开发者生产力的关键将体现在:

  • 原生的 CI/CD
  • 灵活的架构
  • 安全内置
  • 可移植性


因为 Kubernetes 将作为服务为开发者提供如下功能:

  • 智能调度
  • 自我修复
  • 弹性伸缩
  • 服务发现和辅助均衡
  • 自动升级和回退
  • 密钥和配置管理


扩展性和稳定性可以通过平台获得,但是安全性则比较难以马上获得。因为安全性包含了很多方面,有技术和非技术方面。最后,Jason McGee 介绍了 IBM Cloud 如何从 Kubernetes、Istio、Image Registry 三个方面为应用提供安全性支持。


Keynote 6: Software's Community

来自 Spotify 的工程师 Dave Zolotusky 分享了软件社区的经验。有意思的是,Dave 本来想讲 Spotify 微服务迁移的故事,但是发现和前面 Keynote 3 有 80% 的重合度,于是就换了一个话题,看来大家都要面临云原生迁移的问题(也许只是 Dave 的一个玩笑,谁知道呢)。


Dave 提到,开源不仅仅是代码贡献,而是需要深入参与到社区。面对复杂的云原生环境,如何上手开始云原生项目是每个公司都会面临的问题,如何知道谁在用 Kubernetes?Kubernetes 的最佳实践是什么?有没有人在用 Prometheus 和 Istio 都是问题。Dave 认为,社区的魅力就在于它是公开的,我们可以随时在社区里面去寻找相同场景的用户,得到最佳实践,互相交流。


社区的支持是它另外一个巨大的魅力。Dave 以自己的亲身经历说明了社区的支持。Spotify 团队有一个需求,让 ingress 能导流到不同的 Namespace。经过不断尝试,该功能无论如何都不能实现,最后 Spotify 通过向社区群寻求帮助得到了答案,问题在于他们错误的 RBAC 配置。帮助 Spotify 的社区成员甚至都不知道 Dave 团队是谁,但是互帮互助的社区氛围使得寻求帮助非常方便。Dave 高度称赞了这样的氛围,并表示我们需要坚持下去。



在最后,Dave 大声疾呼出了心中的呐喊。人与人的联系,是建立软件社区的关键,我们都面临着同样的问题,也在解决同样的问题,我们都思考过集群扩容、我们想落地云原生,我们尝试过联邦集群,我们需要建立更紧密的联系。让我们行动起来,让社区变得更加强大。


结合谷歌十年容器实践,基于国内大型企业落地经验打造 的容器集群智能云平台。

立即体验
立即咨询