Kubernetes 赢得了容器之战，然后呢？

 | 为  |  容  |  器  |  技  |  术  |  而  |  生  |

作者：Danny Bradbury 

翻译：夏天

校对：李一帆

众所周知，2017 年的 Kubernetes 可谓顺风顺水，大放异彩，最终赢得了艰苦卓绝的容器之战。反观昔日的老对手，有的一笑泯恩仇，有的销声匿迹，还有几个尚存一息。大获全胜的光环下，人们似乎已经忘记了在这场盛大的派对中，Kubernetes 还只是一个资历尚浅的”酷小孩“。至于未来走向如何，是硝烟又起还是一家独大？且听下文分解……

CNCF 家的 “酷小孩”

文章的开头，先来说说 Kubernetes 的开年大事。尽管在中间件（Middleware）和 Java 领域驰骋多年，Red Hat 的制胜法宝仍是 Linux 发行版。前些日子，Red Hat 以 2.5 亿美元收购 CoreOS 公司，自身的云计算业务得以进一步推进。这家 CoreOS 是一个拥有130 名优秀员工的容器创业公司，以面向企业的 Kubernetes 平台 Tectonic、Quay container registry、Container Linux 和一个名为 etcd 的 Kubernetes 分布式数据存储而闻名业内。这次收购在 2018 年开年之际，为 Kubernetes 的战绩又增添了浓墨重彩的一笔。

这个出身 Google，现隶属于 CNCF 的容器编排系统在过去一年可谓大出风头。根据 CloudBees 的高级架构师 James Strachan 的说法，Kubernetes 是这场派对上“最酷的小孩”。James Strachan 本人非常喜欢 Kubernetes，因为它解决了企业希望以不被单一公有云厂商绑定的方式进行部署过程中面临的最大问题。James Strachan 说：“开发人员可以使用任何应用程序，将其打包到 Docker 容器中，使用声明性 YAML 为开发人员描述所有须知内容，包括环境变量、端口和文件系统，然后应用程序就可以在任何公有云上运行了。”

很多人认为，Kubernetes 取得今天这样辉煌的成绩，它背后的 CNCF 功不可没。CNCF 对开源项目表现出非常专业和包容的态度，为这个工具提供了强有力的支持。Cloud Foundry 基金会首席技术官 Chip Childers 就持这样的观点。Cloud Foundry 是一个开源的 “平台即服务”产品，它为开发者提供充分的自由度去选择云平台、开发框架和应用服务。它的 Container Runtime 将容器暴露给使用 BOSH（BOSH 是 Cloud Foundry 开发的基于 Kubernetes 的企业友好型容器运行时间管理器）的开发人员。

“CNCF 的工作非常出色，他们专注于围绕该工具去构建社区。” Childers 说。

朋友圈的助推 

分析公司 Quocirca 的联合创始人 Clive Longbottom 认为，Kubernetes 真正的胜利是赢得了公有云服务提供商们的认可，他曾写过一本关于云计算进化史的书。

Kubernetes 在公有云领域好友众多。2017 年，亚马逊宣布在其 Elastic Container Service 中支持 Kubernetes，与此同时，微软也宣布 Azure Container Service 支持 Kubernetes。Oracle 通过 Oracle 云基础设施为 Kubernetes 提供支持。2017 年 5 月, IBM 也把 Kubernetes 引入 Cloud Container Service 中……这些公司现在都成为了 CNCF 的成员，为 Kubernetes 的发展出钱、出力。

Longbottom 表示，这也将为这些企业开始在其旗下各个产品中使用 Kubernetes 创造了拉动效应。“其实有很多公司发现自己正在使用 Kubernetes，是因为 Kubernetes 被内置在 AWS 和 Azure 等平台中了。如果你想要查看一个混合云，那么最好把 Kubernetes 也置于私有云环境中，这样你就可以更轻松地加入混合云的公有云组件中了。” Longbottom 说。

仍在青春期

虽然 Kubernetes 是容器编排圈的“当红小生”，但请注意，这个“小”字正表示 Kubernetes 尚处在躁动的青春期，确实太过年轻，还需要历练和打磨。“在许多项目中，我已经开始为客户部署基于 Kubernetes 的群集了，但是从部署到投入生产需要进行大量的工作，围绕“确保 Kubernetes 在生产环境中稳定、可用” 这一核心，我们需要在生产各个环节做大量工作进行调试。Cloudreach （一家专注于云实施的专业服务公司）的云计算架构师 Jeremy Bartosiewicz 说。

谷歌的 Kubernetes 产品经理 Aparna Sinha 在一个视频采访中也表达了类似看法。“CNCF 目前的当务之急应该是让 Kubernetes 日趋稳定和成熟起来。”

下一站：Service Mesh 

Service Mesh 概念横空出世

对于一个相对年轻的开源项目来说，它未来走向是有迹可循的。其中一个有趣的趋势，就是向 Service Mesh 发展。这也是 2017 年 12 月 KubeCon 中的演讲话题之一。这个想法源头是从应用程序中提取网络和其他系统服务，并将它们置于容器之间。

这些 Service Mesh 平台都有一个数据平台（Data Plane）和一个控制平台（Control Plane）。一个在容器化微服务和其他容器部分之间通信的代理组成了数据平台。他们负责处理诸如服务发现、健康检查、认证和加密等工作。他们是工蜂，控制平台（Control Plane）是蜂王，告诉他们究竟该做什么。

“Service Mesh 的概念是关于在这些容器之间放置“东西”，并与这些“东西”交谈以获得所有“东西”的总体图像，这将有助于以协调一致的方式，解决监控数以万计的单个容器的问题，但 Service Mesh 的出现却不仅仅是为了解决这个问题。” Bartosiewicz 说。 Service Mesh 有各种各样的用例，其中一些可能用于监控，还有一些用于安全性，另外一些可能提供新的抽象层功能。

越来越重要的 Service Mesh

Bartosiewicz 认为，许多开发人员开始吐槽 DevOps Kool-Aid，也是 Service Mesh 变得越来越重要的原因。Service Mesh 非常适合打破开发人员和系统管理员之间的隔阂，但它的出现也迫使开发人员开始担心他们的代码将会在哪运行，毕竟以前的他们只想静静地写代码，至于代码要运行在哪，并不关心。

通过从应用程序代码中抽象出基础架构的注意事项，开发人员可以为容器编写代码，然后再提供给操作方。Service Mesh 让我们更接近 AWS Lambda 风格的 Serverless 计算概念，开发人员只需对应用程序进行编码，然后让基础架构处理其所需的基本服务，无需担心库导入，依赖性等问题。“我认为 Kubernetes 进化的下一步就是成为一个 Serverless 的平台，”CloudBees 的高级架构师 Strachan 说。“未来将会出现更多的工具把 Kubernetes 引入并隐藏在幕后。”

2017 年 5 月，Google、IBM 和 Lyft 共同开发的新一代 Service Mesh 开源项目——Istio，是一个容器环境的服务平台。它的出现为 Kubernetes 及其竞争对手提供了在 Service Mesh 领域展开新一轮竞争的机会 。Istio 包括服务发现工具和负载平衡工具，可以帮助容器有效使用。

围绕 Service Mesh 推出的产品还有很多。除 Istio 外，还有一款超轻型 Kubernetes 专用的 Service Mesh ，名为 Conduit，于 12 月在 KubeCon 推出。这是对 Linkerd （一种支持多种平台的 CNCF 的 Service Mesh) 的发展。

聚焦商业价值 

现实中的 Service Mesh

Service Mesh 是许多支持 Kubernetes 的第三方组件中的一个优秀的例子。这些服务可以处理从网络连接（CNI）到 Notary（安全）和Jaeger（分布式跟踪）的所有事情。然而，Kubernetes 企业级解决方案需要的不仅仅是一个多元化且充满活力的工具层。市场决定它必须让企业客户更容易消化。

Longbottom 说，Service Mesh 发展最大的挑战之一就是它仍然是一个“超技术产品”。你甚至都不想让业务分析师去费时间琢磨它。这与其他编排产品形成鲜明对比。

今天，开发人员使用 YAML 在 Kubernetes 中定义他们的原始代码和服务。采用基于 YAML 的描述文件，并将其转换为基于任何云的环境下都能运行的服务，可以为工作负载设置适当的虚拟基础架构。

梦想中的 Service Mesh

到了这一步，其实已经很棒了。但在 Longbottom 理想的世界中，就算不是极客的业务分析师也可以描述他们需要的东西，然后 Kubernetes 会立马做到他们想要的。

只要你想要一个动态网站你就可以从 NoSQL 数据库中绘制数据，处理来自某个在线服务的流数据。如果你预计第一周有 10,000 名访客，但实际数字却翻番了怎么办？没有问题！只需要用一些非技术性的语言来进行描述，让容器编排系统来解决难题。Longbottom 梦想中的容器编排系统能够主动出击，直接为你做好所有设置。

这是一个梦想，梦想这个词却代表着遥远，今天还没有任何产品能做到这样。Longbottom 说：“这是发展的下一个阶段，不仅是针对 Kubernetes 本身，对那些运营基于 Kubernetes 产品的公司来说也一样，” 他说。“好的容器编排工具就是可以为您提供适当的工作负载，可以在适当的时间和正确的地点灵活运行，只有这样企业才能可以完全控制所有环节。”

期待新战场 

在 Kubernetes 社区不断发展壮大，持续为现在主流的编排平台引入更多工具时，它的竞争对手又在做什么呢？来看看最著名的对手 Docker ，它目前全面拥抱 Kubernetes，这个举动也捎带为 Swarm 敲响了丧钟。目前它的对手已经寥寥无几，但尽管如此，还有几位尚在。比如，Mesos 还有 Hashicorp 的 Nomad……

其实，即使 Kubernetes 再有吸引力，也没有人喜欢这一家独大的垄断。我们更希望这些替代品不会真的消失，虽然这很困难。但为了存活，希望这些竞争对手多多思考，另辟蹊径早日找到能与 Kubernetes 一较高下的新战场！

原文链接：https://www.theregister.co.uk/2018/02/07/kubernetes_hegemony/

推荐阅读：

END