Kubernetes 第 1 部分 解释了过去十年早期技术行业的动态、AWS 对 DevOps 运动的影响、为开发人员开辟了一条新道路的 Docker 的重要性。
Kubernetes 的崛起是由多种力量共同促成的，事后看来，这些力量是遥不可及的。
Amazon Web Services Inc. 的主导地位为云原生应用程序开发创造了动力，并且需要更简单的体验，而不是轻松地将计算作为一项服务。这股浪潮冲击了一家名为 Docker的初创公司的创新，而谷歌的一个不情愿的开源捐助者需要一种方法来改变 Amazon在云中的游戏规则。
Red Hat需要一条超越 Linux 的道路，并且即将选择 Kubernetes 的替代品来支持 OpenShift。最后，找出一个治理结构来放牧生态系统中的所有猫，这样你就可以战胜其他竞争并创建一个事实上的标准。让这一切发生，你就会获得 Kubernetes 的显着优势。
这就是最近在 Honeypot新的两部分纪录片系列中揭晓的故事， 名为“Kubernetes”。 在这个突破性分析中，我们挖掘了这部纪录片的背景故事，其中解释了导致 Kubernetes 创建的不可能事件。我们将分享早期 Kubernetes 提交者和主要参与者的评论，他们来到了 SiliconANGLE 的视频工作室 CUBE，以拼凑出这一切是如何发生的。最后，我们将展示来自 Enterprise Technology Research 关于容器的新调查数据。
Kubernetes 的故事
Kubernetes 第 1 部分 解释了过去十年早期技术行业的动态、AWS 对 DevOps 运动的影响、为开发人员开辟了一条新道路的 Docker 的重要性，以及谷歌最终如何做出决定开源 Kubernetes。 该系列的第 2 部分 介绍了红帽的贡献以及生态系统如何演变以创建软件开发的新标准。
该纪录片由谷歌、红帽和 CNCF 赞助。它包括许多早期提交者或影响 Kubernetes 发展的关键人物的评论。这些创新者中有许多人在主流容器的形成时期参加了各种活动，包括 Tim Hockin、Kelsey Hightower、Craig McLuckie、Joe Beda、Brian Grant、Solomon Hykes、Jerry Chen 等。John Furrier 和 Stu Miniman 参加了许多节目，cube 报道并解开了当时正在发生的事情。在这篇文章中，我们将分享他们采访的客人的评论。
开发人员定义的基础架构
多年来，我们使用了几个短语来描述基础设施的可编程性。Jerry Chen 是 Greylock Ventures 的合伙人。多年前，他创造了开发人员定义的基础架构或 DDI 一词。陈是 VMware Inc. 的云产品组负责人，并于 2013 年离开公司成为全职投资者。
他的第一笔投资是 Docker。Chen 在 CUBE 上解释了在软件中定义基础设施时会发生什么——如何将基础设施分解为每个都有应用程序编程接口的组件，从而允许开发人员通过代码控制基础设施并使应用程序可移植，以及 DDI 如何彻底破坏整个应用程序开发过程。
听 2015 年的 Jerry Chen 解释 DDI 以及它如何改变 IT 的发展。
DDI 的概念或 Wikibon 的 David Floyer 在 2012 年称之为 软件主导的基础设施，是从云和自动化的明显机会中产生的。这引发了 DevOps 运动，最初被视为面向初创开发人员的东西，但随着时间的推移，正如 Kelsey Hightower 解释的那样，它最终在运维人群中流行起来。
在 KubeCon 2017 上听 Kelsey Hightower 解释开发和运维之间的动态。
关于抽象的抽象
Jerry 解释的是一个新的抽象层，它的构建基本上是为了使基础设施对开发人员不可见。这里有一些 ETR 数据可以量化这种趋势并直观地向您展示我们今天所处的位置。
上图在纵轴和市场份额上显示了净得分或支出动量，这代表了调查中的普遍性。正如 Jerry Chen 和创建 Docker 的创新者所看到的那样，云变得越来越突出，你可以看到它的支出速度仍然高于 40% 的红线——这是一种神奇的动力标志。当然，它在 X 轴上很突出。云是推动这场运动的动力。
在 40% 线以下，您会看到低级基础架构，包括虚拟化。虚拟化是服务器、存储和网络之上的抽象层。早在 2011 年，在与 Chad Sakac 的 VMware 简报中，我们第一次听到了公司必须让基础设施“隐形”的既定目标。容器是另一种超越虚拟化的抽象。
具有讽刺意味的是，上面的支出图表显示了这一点。两个红色箭头指向容器——容器编排和容器平台——它们是底层虚拟机和硬件之上的抽象层和服务。
你可以看到容器在市场上的消费势头，以及云、人工智能、机器学习和机器人流程自动化。
星星如何排列以创建 Kubernetes
你拥有 Jerry Chen 和 Kelsey Hightower 所描述的正在形成的力量。用 Google、Red Hat 和 CNCF 内部人士的话来说，“Kubernetes”纪录片很好地解释了它们是如何走到一起的。下图确定了关键元素，我们将描述它们形成 Kubernetes 的不太可能的交互。
在左上角，您可以看到 AWS。我们插入了一张 我们在 2012 年第一次 re:Invent 之后发布的帖子中的图片。很明显，亚马逊是云大猩猩，并且在 IT 领域拥有所有动力。我们将其视为不可阻挡的浪潮，纪录片中的主角也是如此。
Docker 的创始人 Solomon Hykes（右上图）看到了为云开发人员简化应用程序打包的必要性。容器在 Docker 之前已经存在了 30 多年，最初是作为 Unix 操作系统的一部分开发的，用于将某些进程与其他应用程序组件隔离开来。但是绝大多数程序员不知道也不关心容器。它们是一种低级构造，隐藏在主流之外。
Docker 改变了这一切。当时的 Docker 是一家 30 人的公司，刚刚从 dotcloud 更名。令人震惊的是，这家小公司改变了计算的历史。
听 Solomon Hykes 在 2014 年回答这个问题：“什么是容器？”
谷歌需要改变云游戏的规模
想象一下，您在 2013 年就职于 Google。您已经建立了世界上最大、最令人印象深刻的计算机网络，在全球拥有数百万台服务器。您拥有出色的技术，随之而来的是在线商务公司亚马逊。它进入云中捕获了各地开发人员和组织的思想和钱包。亚马逊拥有 IT 领域的所有动力，您的业务建立在挪用消费者数据来销售广告的基础上。你当时的座右铭是“不作恶”。
如果您是 Google 的工程师，您想改变世界。你想开发一些有意义的东西。你不想只关注亚马逊——那不会让你走得太远。那么到底是什么戏？因此，在上图中，谷歌云徽标中的问号。你会看到 Docker 的出现，它创造了一个机会。Docker 很棒，因为它简化了容器并使它们成为主流。但谷歌认为你需要更多。见鬼，Docker 看到你需要更多，Mesosphere 和其他人也是如此。
为什么你需要 Docker 以外的东西？
那么，为什么你需要比 Docker 创造的更多的东西呢？2014 年担任 Google 产品经理的 Craig McLuckie 向 CUBE 主持人 John Furrier 解释了需要另一个管理层。他分享说 Docker 所做的是创建了在任何地方运行二进制文件的能力。但是需要有一种方法可以使用可以在任何地方运行的框架来管理它。
听 Craig McLuckie 讨论 Docker 和 Kubernetes 的结合以及为什么需要另一个层。
所以 McLuckie 解释了为什么这个行业需要像 Kubernetes 这样的东西，但让我们回到更远的过去。这是谷歌拥有这个惊人的云基础设施，但没有商业云业务可以与 AWS 竞争——至少当时没有被认真对待。它具有计算即服务，可以轻松启动虚拟机，但在 Google 的脑海中并没有那么令人兴奋，AWS 已经确定了这个用例。所以谷歌需要一种方法来增加它的相关性。
谷歌从未采用虚拟化来解决其内部挑战
谷歌有一个叫做 Google Borg的东西，它是一个容器管理系统和调度程序。谷歌着眼于云中的问题，而不仅仅是“我如何启动虚拟机？” 而是“我如何运行和管理我的代码？”
当时在谷歌工作的乔·贝达（Joe Beda）向 Furrier 和 Miniman 解释了公司的思维方式以及它是如何看到机会的。
听 Joe Beda 解释 Google 工程师是如何考虑这个问题的，以及他们是如何考虑超越虚拟机即服务的。
所以谷歌看着市场并说：“我们能做些什么来让谷歌在云中具有相关性？” 来自 Google 的 Eric Brewer 解释了 CUBE Google 当时的思考过程。谷歌与 VMware 同年成立。因此，它从未将虚拟化用于自己的基础架构。相反，它使用容器和低级流程来构建其云网络。所以它以不同的心态来解决问题。
听听 Google 基础设施副总裁 Eric Brewer 解释公司早期使用容器的情况。
现在，布鲁尔给了我们这个故事的简短版本。他在纪录片中透露的是，最初他的姿势是对开源 Kubernetes 的即时负面反应。谷歌管理层对此表示怀疑并问道：“我们为什么要开源我们的秘诀来帮助我们的竞争对手？” 但随着时间的推移，通过一系列会议和讨论，谷歌的工程师能够说服管理层相信开源 Kubernetes 不仅对行业有利，对谷歌也有利。
谷歌管理层不愿开源 Kubernetes
Tim Hockin 和 Brian Grant 在最初的 Kubernetes 团队中，并敦促管理层说服他们支持开源 Kubernetes。Hockin 在 the CUBE 上向 Furrier 解释了当时谷歌内部的故事。
听 Tim Hockin 解释他们如何向 Google 高级管理层提出开源 Kubernetes 的想法。
当他们研究这个问题时，开源策略变得更加引人注目，因为它为 Google 提供了一种抵消 AWS 优势的方法：例如，使用容器，您可以在 AWS 上开发，然后在任何地方运行应用程序——比如在 Google 的云上。因此，它不仅为开发人员提供了一条离开 AWS 的道路，如果 Google 可以在 Google Cloud Platform 上开发强大的服务，它可以随着时间的推移从游戏中赚钱。
Linux 需要一条通往云的道路
现在回到图表，它显示了来自 CoreOS 的微笑的 Alex Polvi。他的公司在 2018 年被 RedHat 收购。他看到了将 Linux 带到云端的必要性。毕竟，Linux 正在为互联网提供动力。它是企业应用程序的操作系统，对 Polvi 来说，扩展它的路径是有意义的。
Linux 成为数据中心的操作系统。它通过成为具有一致 API 的开放标准来做到这一点。尽管还有其他操作系统，Linux 是数据中心应用程序的主要生产级操作系统。
在 2015 年的 OpenStack 活动中，Polvi 描述了他认为类似的标准将如何出现在将数据中心视为计算机的抽象层中，而不是针对单个机器。他当时表示他相信该层将围绕 Kubernetes 进行标准化。
听 Alex Polvi 描述 Linux 和 Kubernetes 标准化之间的相似之处。
红帽的未来取决于通往云的新路径
红帽自 1993 年以来就已经存在。因此，它需要一个将公司带入云的未来。OpenShift 就是这样的未来，它必须利用容器管理框架。根据纪录片，红帽通过各自的董事会成员与谷歌建立联系，这引发了工程师之间关于容器的讨论。谷歌不置可否，但确实透露它正在考虑做某事，并可能开源这个新项目。
但谷歌的内部辩论和折腾时间太长了，所以红帽已经等不及了。它必须继续使用开源替代方案，因此它决定按照 Apple Inc.、Airbnb Inc. 和 Heroku（现在由 Salesforce.com Inc. 拥有）正在做的事情并在替代方案上进行构建。它已经准备好投入 Mesos，它比 Kubernetes 更复杂、更成熟。但在最后一刻，谷歌回来说，“让我们开始吧。”
Clayton Coleman 是 Red Hat 架构师，他立即开始参与其中，并且是 Google 以外最早参与该项目的提交者之一。
Kubernetes 的决策时间：追求规模还是简单？
当时，您在市场和内部存在“我们追求简单还是追求系统规模？”之间的竞争力量。谷歌显然拥有构建大型、复杂、可扩展系统的专业知识。Docker Swarm 和 Mesos 等平台正在处理更复杂的用例，但 Kubernetes 团队首先押注于简单性。
来自 Google 的 Chen Goldberg 谈到了为什么公司首先关注简单性并在解决更大的问题之前做到这一点。也许今天看起来很明显，但在外部市场力量和内部工程师倡导不同方向的情况下，这是一个重要的决定。戈德堡解释说，谷歌没有立即与更成熟的 Mesos 或 Docker Swarm 竞争，而是下注保持简单并广泛采用——这显然是正确的选择。
听 Google 的 Chen Goldberg 解释首先关注简单的基本原理。
放牧猫
复杂难题的最后一块是治理。根据纪录片的评论，谷歌曾承诺开源 Kubernetes，但当它开始向谷歌以外的贡献者开放时，代码仍由谷歌控制。开发人员必须签署谷歌文件，这些文件基本上表明谷歌仍然可以为所欲为。
当一家大公司试图挤进开源社区但仍保持控制时，我们之前已经看到过这种情况。谷歌不得不将接力棒交给一个独立的实体，这就是 CNCF 的开始。Kubernetes 是它的第一个项目。
听 Chris Aniszczyk 描述 CNCF 作为中立组织的使命以及它如何支持采用云原生技术。
达到这一点是一条非常了不起的道路。CNCF 现在拥有超过 725 名成员，并已成为托管 Kubernetes以外的100 多个项目的主要组织。
Kubernetes在市场上的主导地位
上面的这个 ETR 数据显示了容器编排产品——与之前显示的相同的 XY 图——你可以看到 Kubernetes 的位置。尽管 Kubernetes 不是一家公司，但受访者知道他们在做 Kubernetes。他们可能不知道他们使用的是哪个平台，但他们知道是 Kubernetes。
ETR 分类有两个容器类别，容器平台和容器编排产品。在 ETR 样本中进行调查是一个具有挑战性的话题，因为 Kubernetes 越来越多地嵌入到云平台中，而 IT 专业人员甚至可能不知道他们具体使用的是哪个平台。
在上图中，我们将 Red Hat OpenShift 和 Kubernetes 联系起来，因为我们真的认为 OpenShift 作为一个越来越受欢迎的平台即服务层在市场上是一个占主导地位的收入参与者。是的，你可以下载 Kubernetes 并用它做你想做的事，但如果你正在构建企业应用程序，你将需要支持，这就是 OpenShift 的用武之地。
跟踪集装箱收入
关于容器软件收入的市场数据并不多，但我们确实 从 Omdia 找到了以下数据。 它显示了容器软件玩家的收入份额。目前尚不清楚这是如何定义的，但 Red Hat 与 Mirantis（Docker Swarm）、VMware 和 SUSE（Rancher）在前四名的收入份额接近 50%。
我们从 Informa找到了一些其他数据，但它已经过时了。它还让红帽成为收入最大的参与者，我们认为这是准确的——尤其是因为我们知道 IBM 的实力支持 OpenShift，这是 IBM 应用程序现代化服务战略的关键。IBM 可以将 OpenShift 捆绑到其应用程序现代化服务中，从而为 Red Hat 提供了一个专属市场。我们一直说，这是收购 Red Hat 的关键投资回报推动因素，并使 IBM 在混合云之战中占据优势。
引擎盖下的 Kubernetes
CNCF 最近发布了年度调查。该出版物的数据表如下所示：
如上所示，过去的 CNCF 年度调查有 1,800 名受访者。数据表明：
79% 的受访者使用经过认证的 Kubernetes 托管平台； 用于 Kubernetes 的 Amazon Elastic Container Service 最为突出，占 39%； Azure Kubernetes 服务紧随其后，占 23%；和 Azure AKS 引擎占 17%，谷歌 Kubernetes 引擎落后。
这让你想起了谷歌管理层最初的担忧：为什么要开源这样一个关键技术？前提是它将在云中创造公平的竞争环境。并且肯定有。
但人们不得不问：这是否推动了谷歌所追求的货币化？你不得不说可能不是。但是如果没有开源 Kubernetes，谷歌会在哪里呢？它在云中的相关性如何？尽管谷歌在 AWS 和微软之后遥遥领先，但如果没有 Kubernetes，谷歌可能不会参与讨论。
Kubernetes 的未来是什么？
让我们对 Kubernetes 的状态和社区的发展方向发表一些评论。
当今 Kubernetes 的状态
对第一个没有新的见解，但 Kubernetes，尽管开端不太可能，但已经成为主流。在过去一年左右的时间里，我们看到在这方面对有状态工作负载和大型生态系统的支持更加成熟和支持，并且具有更好的安全性和持续的简化。但是 Kubernetes 仍然相当复杂。例如，它正在变得更好，但不是 VMware 级别的成熟度。当然不是。
对于从第一天就开始使用容器的云原生公司来说，采用率一直很高。但随着 Kubernetes 的成熟，我们看到越来越多的信息技术组织采用它，这证实了 Kelsey Hightower 之前的评论。
有趣的是，Docker 开始成为云的操作系统，而 Kubernetes 确实成为了这块拼图的一部分。Docker Desktop 是 Docker 蓬勃发展的地方。它将 Swarm 卖给了 Mirantis，并对其许可模式进行了一些调整，以便能够继续发展其商业模式。
正如我们在 2020 年预测文章中所说，我们预计 Kubernetes 会变得不那么明显，并且更多地嵌入到其他平台中，而这正是正在发生的事情。但它仍然有一些复杂的挑战需要克服。还记得 VMware 采用的早期和中期吗？了解应用程序性能需要身穿实验服的人员来解决问题并扩展系统。
在某些方面，您会看到 Kubernetes 的动态重复。要保护、扩大规模、让系统在出现问题时快速执行和恢复，需要大量的专业知识。由于 Kubernetes 生态系统的快速发展，这一切都变得更加困难。但它肯定朝着正确的方向前进。
它为生态系统提供了机会。
更多抽象、多集群、自动化、新工作负载
那么 Kubernetes 的未来是什么？
我们期待进一步的简化和更多的抽象。随着 Kubernetes 改进对多集群的支持，它将开始将这些集群视为一个统一的组，并使集群能够一起管理。这将创建许多生态系统，专注于全球扩展和降低延迟，跟上安全和恢复的步伐。这将需要新的服务来跨集群共享资源。因此，在近期到中期寻找它。
期待更多的自动化。这将在很大程度上由主机云提供商以及生态系统中的其他提供商推动。随着 Kubernetes 支持更多有状态的应用程序并开始扩展其集群管理，云提供商将尽可能多地向系统注入自动化。生态系统初创公司将带来创新，以更好地管理应用程序资源。
最后，随着这些功能的成熟，我们希望看到对人工智能、机器学习和推理等数据密集型工作负载的更好支持。调度这些工作负载变得更加困难，因为它们非常耗费资源。绩效管理变得更加复杂，因此必须不断发展。坦率地说，Kubernetes 团队早期搁置的许多事情，例如在 Docker Swarm 或 Mesos 中看到的，将开始进入 Kubernetes 场景。
Kubernetes 之后是什么？
我们要求您考虑的最后一件事是 Kubernetes 之外的下一步是什么？你知道这不是，对吧？随着无服务器和物联网以及边缘和新的数据繁重的工作负载，有些东西会破坏 Kubernetes。在那次 CNCF 调查中，近 40% 的受访者正在使用无服务器，而且这种情况还会继续增长。
这将如何改变开发模式？亚马逊首席执行官安迪·贾西 (Andy Jassy) 在担任 AWS 首席执行官时曾说过一句名言，如果他们必须从亚马逊零售业重新开始，他们将从无服务器开始。因此，让我们密切关注地平线，看看接下来会发生什么。
最后一个想法，一种预测：云原生社区喜欢见面。我们今天看到的许多创新都是在小型聚会或其他重大活动中产生的。这群人将是第一批返回面对面会议以保持想法流动的人。
声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。
