预测容器和云原生的未来

嗯,你知道,首先,我想从一个警告,你知道,这些只是我的观点,我不希望他们一定成为你马上跑出去做的事情,或者你开始计划的事情,你知道的,在未来几年,但是我想给你的感觉我认为世界需要去的地方和容器,而且,也许是为了激发你思考,你知道的,你对未来5-10年集装箱发展方向的看法。因为在过去的8年里，我们在Kubernetes中看到了DevOps容器的真正革命。但它是不完整的，它真的没有实现我认为在DevOps世界中可能实现的所有事情。

我想先看看Kubernetes现在是什么样子。从根本上说，Kubernetes今天的样子和它最初的样子是一样的。当然，我们已经添加了大量的API，我们已经添加了，你知道，许多新的云提供商，许多新的贡献者。但从根本上讲，Kubernetes被设计成一个基于应用程序的API，它存在于机器之上，无论它们是虚拟机还是物理机，它的目的是将你从你对机器的概念中抽象出来，给你一个API，它在定义你的应用程序和应用程序的开发者或操作员考虑的特征方面是有用的。但在现实中，我们在这里开始看到的是机器的概念实际上可能不是人们想要思考的东西。事实上，我们已经看到人们开始将无服务器容器等集成到Kubernetes中。因此，今天，如果你在Azure Kubernetes服务中运行一个集群，例如，但它在许多其他云提供商中也有类似的功能，你有能力运行你的容器，不仅在机器上，在这种特殊情况下，虚拟机，而且在无服务器容器基础设施上，如Azure容器实例。当我说无服务器，容器基础设施时，我的意思是，你所做的就是给我们一个容器，它与CPU和内存一起运行。但是在它下面没有任何核心操作系统。

当然，确实有一个操作系统。但这对你来说是透明的这不是你想的东西。我认为这是考虑Kubernetes未来的第一部分，事实是我相信Kubernetes的未来是完全无服务器的。

我们讲过的那些机器把你从那些特定配置的操作系统中抽离出来，这些操作系统由Kubernetes API集合在一起。这是一个古老的想法。它确实没有解决大多数人在Kubernetes中发现的主要价值，即更高级别的API，如部署服务、入口等。更重要的是，它也不能很好地与云的目标进行交互。

因为云考虑的是如何最大化地利用我投入到数据中心的资源，并将它们暴露给我们的客户和最有用的原语。2022世界杯阿根廷预选赛赛程我们越来越多地看到，你可以向你的客户公开的有用的原语是一个容器，它是一个无服务器的容器?正确的。我认为这里提到的一件事是，无服务器的整个思想有点与编程模型混为一谈，就像函数即服务一样，我认为重要的是要注意，当我们说无服务器时，我们真正的意思是那里没有虚拟机。

对吧?我们不会说，嘿，这都将是函数即服务，或者HTTP web通道，我们并没有真正说，应用程序开发模式，这是传统的通道领域。

我们真正说的是无服务器基础设施，它在某种程度上看起来和感觉上就像你所期望的虚拟机基础设施。但它是一个容器，它是面向应用的原语，Kubernetes从一开始就试图交付。但还有很多悬而未决的问题。当我们思考Kubernetes如何在这个无服务器的未来中生存。

有一大堆非常重要的问题需要思考，我认为为了开始思考它们，重要的是思考为什么无服务器容器在Kubernetes下?对终端用户如此有吸引力?我认为，当你想到虚拟机时，你知道，真正想到的问题是在一个开放的云原生世界中，在一个使用容器进行开发的网络新世界中。

为什么你会对VM感兴趣呢? VM除了为Kubernetes集群提供的CPU和内存之外，并没有为表带来太多东西。

事实上，你已经把4个核和10g的RAM或者100个核和1tb的RAM打包到一个小盒子里然后有效地把这个盒子捐赠给了Kubernetes。这是很随意的。对吧?为什么你知道Kubernetes提供这个抽象API,跨越这些虚拟机已经,,为什么我们甚至困扰建模这些机器,它有很多的遗产社区从何而来,而不是我想思考的未来Kubernetes应该,因为虚拟机的事,有各种各样的担心,它带来了,尤其是在安全性和遵从性,正确的。所以，如果你有一台虚拟机位于你的云中，或者位于你的数据中心的某个地方，那么，有一个完整的合规制度与保持操作系统打补丁有关，确保没有易受攻击的软件。

在很多情况下，你更新的软件甚至不是你应用程序所关心的软件，你更新SSH是为了让别人能够登录到这台机器。这不是你的应用程序关心的东西你的应用程序关心的是容器里面的东西。显然，你需要保持这些东西非常非常安全和兼容。但是，您为确保机器上操作系统的安全性和合规性所做的所有工作，在云原生应用程序世界中实际上都是浪费精力。

除了安全性和遵从性。VM带来的另一个东西是可靠性，对吧?比如操作系统可能会崩溃，系统D可能会崩溃，内核可能会恐慌，操作系统内部可能会发生各种各样的事情。守护进程可能会失去控制，您知道，它会启动并使用所有的CPU或耗尽内存运行操作系统。Kubernetes试图保护你不受这类东西的影响。当然，如果发生这种情况，它可以通过在机器之间移动您的pod来恢复。但事实上，你把机器放在那里会带来可靠性问题，这真的不是你关心的事情，它们实际上只会让你的生活更糟。因此，除了机器带来的安全和合规问题之外，机器还会给集群带来可靠性问题。

很明显，云使它更容易，很明显，社区使它更容易，但最简单的事情是完全移除机器。

最后，机器实际上增加了成本。这样考虑的原因有两个。

一是不管Kubernetes把容器打包到你的机器上做得多好，总会有剩余的空间，要么空间会因为内部碎片而剩余，你把每台机器都切碎了，有一些剩余的空间你不能用于任何特定的容器，好吧，你仍然要为此付出代价，即使你没有使用它。很明显，这会增加成本。但是除此之外，你通常会。启动一个虚拟机需要一些时间。你会想要保留一些备用容量，即使你打开了自动缩放以便能够响应缩放事件。所以，这里有额外的容量，要么是你可以使用的内部碎片空间，要么是你为了扩大规模而保留的缓冲容量，这增加了成本，却没有增加任何价值。因此，由于所有这些原因，虚拟机，底层社区，在一天结束的时候，并不能为最终用户提供多少价值。但是如果我们相信，希望到目前为止，在Kubernetes下使用机器并不是特别有用的东西。

一个非常有趣和重要的问题是我们如何到达新的未来?这是因为事实的真相是在代码层面，在Kubernetes的最低层次，Kubernetes本身的API，它实际上非常依赖于机器。对吧?它是在底层构建的，你知道，它认为自己是一个机器管理器。所以当你考虑一些简单的事情，比如我如何得到特定豆荚的对数?

代码实际上是在说，噢，那个豆荚在哪里运行?好吧，我去那台机器，找到那台机器上的日志，把那个吊舱的日志还给我。

从最终用户的角度来看，您只是要求获取特定容器的日志。从Kubernetes的角度来看，它利用了容器在哪里运行的知识以及特定机器的特殊性来为你提供这些日志。因此，Kubernetes向无服务器未来的演变将需要时间和大量的关注。我认为更重要的是，你知道，有一定数量的社区或社区是一个大的广泛的社区，今天正在运行生产工作负载。

其中一些是在裸机上运行的，你知道，这种漂亮的无服务器容器是不可行的，或者Kubernetes就是提供无服务器容器的东西。因此，当我们向前推进时，这将是一个真正的社区演变，看看我们如何从我们所处的位置到达我们需要去的地方。所以肯定有一些大问题，一些我们需要思考的大石头，你知道，为了从我们在Kubernetes下面有虚拟机和Azure容器实例的世界，到一个世界，你知道，我们需要考虑在Kubernetes下面有无服务器的世界。我们要考虑的第一件事就是如何进行积分，考虑失败。

正确的。所以当Kubernetes考虑将容器分散到多台机器上时，它将每台机器视为一个故障单元，由于我之前谈到的那些可靠性问题，机器是一个故障单元而Kubernetes，为了尝试为你提供可靠性，将把事情分散开来。它有这样一个概念，在它的Scheduler里面散布容器。但是当我们迁移到无服务器的容器世界时，这就成为云计算所担心的事情，你知道，在无服务器容器的世界中，机器不会故障，因为没有机器。对吧?通过对无服务器容器的抽象，对您隐藏了该机器。突然间，Kubernetes，之前一直在考虑如何在一堆节点上传播容器，你知道，不再需要考虑传播，我们需要教社区如何，你知道，有效地记住忘记如何忘记传播是它需要担心的事情。但是，当然，在无服务器基础结构中实际上存在故障域。

在一天结束的时候，有物理机器，底层的无服务器容器，他们可能会失败。所以在某个地方扩散是很重要的。对于Kubernetes来说，能够推断应用程序的可靠性也很重要。因此，提供故障域或升级域的云之间的确切相互作用，其中计划的维护将发生到Kubernetes。因此，Kubernetes可以向无服务器容器基础设施请求某些调度特性。以及这种相互作用是如何起作用的。

这仍然是一个悬而未决的问题。当我们考虑将Kubernetes转向无服务器时，我们需要考虑一个重要的领域。我认为另一件有趣的事情是，Kubernetes中的一个节点代表一个容量单位。因此，您可以考虑通过添加或删除节点来增加或删除容量来自动扩展集群。但在无服务器容器世界中，就像容器实例一样，容量是无限的，您只需为使用的内容付费。突然之间，自动扩展集群的概念就变得无关紧要了。

集群的大小正好是它需要的大小。但是，Kubernetes再次考虑了很多关于容量的问题。它考虑了每台机器提供一定数量的核和一定数量的内存。

它并没有过多地考虑潜在的无限容量。因此，当我们考虑将无服务器容器集成到社区中时，我们必须考虑如何使终止器忘记容量之类的东西。

事实是，你知道，以前的说法，未来在这里，只是它不是均匀分布的，在这种情况下也是正确的。事实上，这种未来正在虚拟立方体项目中进行探索，虚拟立方体项目是一种采用无服务器容器技术的努力，无论是Azure容器实例，Amazon, fargate，还是许多其他交付无服务器容器的方式，并将其与Kubernetes API集成。所以，如果你对这个交集是如何产生的感兴趣，如果你对未来探索这些问题感兴趣，我鼓励你去GitHub上看看这个虚拟立方体，甚至可以在Azure上运行它，看看它是什么样子。你也可以帮助我们进入Kubernetes和无服务器容器的世界。

现在，我讲了很多关于集群的形状和提供集群的基础设施。但我并没有过多地谈论我认为Kubernetes未来更有趣的部分。因此，如果我们回到Kubernetes的图片，API位于无服务器容器之上，我认为实际上未来更有趣的部分是发生在Kubernetes之上的事情。

Kubernetes为定义和部署应用程序提供了一个很棒的低级API。但事实是，它并没有使构建这些应用程序变得更容易。我认为未来我们需要做的很多事情是采取措施，让人们更容易地构建那些运行在Kubernetes之上的应用程序。这将涉及到增加更多的功能，增加更多的API。

希望不会增加更多的复杂性，我知道在这里向社区添加更多的API有时有点可怕，你会想，天哪，又一个我要学习的API又一个我要担心的CRD，但我希望当我们开始开发这些额外的层时，我们实际上隐藏了一些复杂性，我们不仅仅是增加资源，我们实际上是在增加抽象和封装。2022世界杯阿根廷预选赛赛程最终，这将使你们成为应用程序开发人员。甚至可能作为应用程序的操作员更容易。

我想要推动这个关于我们如何让开发人员的生活更轻松的讨论，我想从从Kubernetes pod内部的用户应用程序访问云存储的想法开始。当你仔细想想，其实并没有那么复杂。

这是我们在用户应用程序中一直在做的事情，我们弄清楚如何与云存储对话，我们与云存储对话，然后继续我们的生活。

但我认为，在这种简化中，我们实际上隐藏了很多东西，这些东西实际上使构建分布式应用程序变得更加困难。当我谈到为什么它会变得更困难时，我想到了三个方面。首先，无论何时集成新的存储，都会有一些问题。第一个问题是，我应该使用哪个客户端库?好，假设我们使用TypeScript，我们将使用NPM，我们将与Redis对话。

这并不像火箭科学，对吧?这是人们多年来一直在做的事情。然而，如果你去NPM，你搜索Redis，那里有不止一个客户端库。就在那里，你知道，可能有一个有更多的，你知道，下载或其他，你知道，但你可能不会真的决定使用那个，

我，我们实际上有一些开发了应用程序的客户，不管出于什么原因，他们决定使用不同的应用程序，也许是因为搜索条件不太匹配，也许是因为，你知道，他们复制粘贴到他们很久以前做的一些项目，甚至没有真正考虑他们正在使用的库。

当你依赖一个库时，你会问自己一个问题，比如，哪个库最好用。问题的真相是，如果我们让1000个人做1000个决定，他们都会做出不同的决定。虽然这很好，你知道，让1000朵花盛开，但它往往不是我们开发最好的应用程序的好方法。

因为我认为，当人们依赖第三方库时，他们不一定会考虑到的另一件事是，他们实际上也引入了风险。今天变得非常时尚谈论软件供应链的风险,但这是一个非常,非常真实的风险,我认为我们需要从一个世界,我们认为,嘿,这太棒了,看看这些不同的库,我可以拉到我的应用程序,使开发更容易,哦,我的上帝,每一个库,我拉到我的应用程序是一个潜在的国家发起攻击者试图进入我的应用程序。这似乎有点悲观。

但事实是，软件供应链和开源就像狂野的西部，如果你拿出一个NPM包，你就信任了开发那个NPM包的所有人，不仅仅是那个开发包，还有那个包所依赖的每一个传递包。正确的。所以我认为我们需要走向这样一个世界，在这个世界里，我们采取的每一种依赖，我们都认为它是一种潜在的风险。在这种情况下，我们应该考虑依赖关系。所以和Redis谈话的行为。使用NPM的库，突然变成了一个引入风险的选择。最后，是一个特定库的速度，以及拥有一个高性能库的性能。

正确的。所以我们生活中的主要工作不是连接到Redis，我们的主要工作是构建某种应用程序，碰巧需要使用Redis。正确的。如果你要学习如何使用客户端，也许你要从Redis切换到Cassandra，到Mongo再到Postgres再到PostgreSQL SQL，每次切换，你都要学习一个新的客户端库。

每次你改变语言，你必须学习一个新的客户端库，你知道，它们看起来会有一点点不同。我为Kubernetes开发了许多不同的客户端库。它们在不同的语言中看起来都有点不同。有些是电火花。

其中一些让它看起来像语言，但很多只是小的选择。我是说get还是read?我说的是删除吗?还是说毁灭?

所有这些小的选择最终意味着，当我切换提供商时，当我搜索存储后端时，当我切换语言时，我在特定领域学到的知识不一定适用，所有这些都增加了认知负荷，这使我变慢了。对吧?所以当我们考虑对存储的依赖时，我们实际上是在做一些事情，让我们自己做出正确的回答，对一堆问题给出正确的答案。

它使我们面临软件依赖的风险，并且它实际上减缓了我们的开发过程。现在希望你在想，哦，天哪，我不能不依赖于存储库，对吧。我是说，我需要储物间，我不想自己动手。所以我认为幸运的人可能感觉有点糟糕。但我认为幸运的是，这个问题以前已经解决了。我想说明的事实是这个问题之前已经解决了没有人实现排序。然而，我们中的许多人在日常生活中或某些项目中使用sort，对吧?我们没有人实现的原因至少从我们学过本科算法开始，我们没有人实现排序的原因，是因为有一个标准库。所以在每一种现代编程语言中，都不只是运行你的东西的运行时。

有一个标准库，提供了很多有用的实现，你每天都会用到，你会告诉某人，他们疯了，如果他们决定，嘿，我要写这个应用程序。顺便说一下,在编写应用程序,我将重新实现排序,我将随机极限,HTTP服务,要做的一切从头开始的那些相同的原因,我只是上市之前必须回答所有的问题,正确的,引入安全问题和自己慢下来,你会说不,不,不,有一个标准库,使用标准的HTTP服务器,使用标准的排序算法别烦,专注于业务逻辑。

这就是衣冠楚楚的意思。所以dapper是一个开源项目。它是up@dapper.io，在GitHub上，它试图为分布式应用程序提供标准库。

正确的。因此，就像每个应用程序或每种编程语言都有一个标准库一样，我们正在努力为容器化应用程序提供一个标准库。考虑这个问题的方法是我们使用侧车模型。

你们可能见过带服务网格的侧车模型。我认为服务网格是一个很好的例子，说明了dapper所处的更广泛的模式，也就是说dapper提供了一堆有用的协同例程，或者协同过程可以让你的生活更轻松。我在前面提到过很多编程语言都有标准库。在集装箱的世界里，有一件事是显而易见的，那就是这是一个多语言的世界。你不能亲和眼睛，任何特定的标准库。所以，你知道，有一些库已经被开发出来了，但它们非常固定于一种语言。

Dapper采取了相反的方法。Dapper说，嘿，你知道吗，我们只讨论HTTP或G RPC。这意味着任何语言都可以和衣冠楚楚的人交谈。我们可以使用完全相同的实现，不管你是来自go Python、TypeScript、Java、rust、dotnet，还是任何其他可以使用HTTP的语言。所有这些都是关于如何正确地设计产品，如何采取正确的依赖关系，如何考虑安全性。

Dapper负责所有这些，因为HTTP内置于所有这些语言中，不存在外部依赖关系，因为访问HTTP是访问事物的标准方式。关于如何做到这一点，实际上没有任何悬而未决的问题。让我们看看这在Java中是什么样子的。

它能帮助你整合所有人都做过的最佳实践，抱歉，Java的例子马上就来，我想谈谈这个精巧的协处理器的价值。它封装了如何访问存储的最佳实践，你不再需要，你知道，以正确的方式回答问题。因为dapper是一个社区项目，所以该社区中的所有人都聚集在一起开发了一个您可以利用的最佳实践实现。它还具有安全依赖关系。我之前提到过。

dapper项目采用的是依赖关系，而不是应用程序代码。所采取的依赖是由社区非常仔细地，非常谨慎地做的，也是负责任地做的，以看到易用性和诸如此类的事情。因此，您可以依赖您可以对dapper有一个依赖项，并相信dapper项目将为您处理安全依赖项。最后，你马上会看到如何使用dapper的例子，它实际上降低了复杂性，因为dapper的接口是标准化的，所以无论你是在Redis，或Cassandra，或Cosmos dB，或Azure，或任何其他基于云的，没有SQL存储，接口是相同的。所以有一件事需要学习。接口本身就是一个普通的HTTP。这也是大多数开发人员在大多数编程语言中非常熟悉的东西。回到我之前提到的，让我们看看从Java访问dapper内部存储是什么样子的。你在这里看到的是存储一个JSON blob到一个特定的键值。

在一个非SQL存储中，只有三行代码，其中一行不太适合幻灯片。我已经把我的分成了两部分，但这是三行代码，创建一个新帖子。你可以看到，我在和localhost对话localhost并不是在演示中任意选择的。

实际上使用了Localhost，因为dapper在同一个pod中运行，因为您的应用程序共享相同的网络名称空间，只在Localhost上公开。这样做的好处是，你不用担心安全问题，你可以使用纯HTTP，而不是HTTPS，因为网络流量只在pod内部运行dapper，实际上，HTTPS会加密处理身份验证到存储后端，一旦你创建了你的帖子，你设置了帖子的主体，你执行了帖子，你就存储了数据到您的无SQL存储。再说一次，不管你是在和Redis, Cassandra, Mongo, Cosmos dB，或者其他云NO SEQUEL对话，这段代码都是一样的。所以，dapper不仅有助于简化代码编写，它实际上也使编写可移植代码变得更容易。这对于标准库来说也是很有价值的。

现在，你可能会想，这个dapper只是用来存储的，因为到目前为止我画的例子都是这样。

但实际上，dapper旨在成为许多不同的云原生应用程序类型模式的标准库。存储的一个更明显的推论是事件。

存储是一个出站的东西，事件是一个入站的东西。这就是在dapper中监听事件的方式，你只需要创建一个HTTP服务器。

或者，如果您已经有一个HTTP服务器，只需向该HTTP服务器添加一个新的处理程序。该处理程序将在事件发生时被调用。就是这样，没有客户库可以引入，没有客户库可以学习。

你知道，没有最佳实践来弄清楚如何监听Kafka、事件网格和任何其他事件存储之间的区别，你只需要设置一个HTTP处理程序，正确的事情就会发生。所以，这是我们恢复的同一张照片，但是错误已经被逆转了。从云或者其他事件存储中，事件进入dapper co进程，dapper co进程处理理解Kafka的细节，或者rabbit mq，或者其他什么将事件转换为HTTP调用到你的代码中。再说一次，它是多语言的，因为现代世界的任何编程语言都知道如何开发HTTP服务器。因此，我希望这能让您清晰地理解dapper是云原生应用程序的标准库是什么意思。它不仅仅局限于存储和事件。

但事实上，数据提供了存储事件、秘密、身份验证等等。它们都是通过接口和实现的概念完成的。因此，您可以拥有一个由Azure Cloud备份的秘密实现，Azure Key Vault由hashey备份，Core Vault由任何其他云机密提供商备份。因此，您可以处理adaper秘密这个抽象概念，而不必担心特定云或其他秘密提供者的特定实现的具体细节。

我真的邀请你，如果它看起来有趣或令人兴奋，或者你只是想玩玩，我真的邀请你出来加入这个社区。

它真的是一个我们聚在一起建立标准库的地方，因为它真的是，它只能成为一个标准库，如果你知道社区聚集在它周围，如果只有三个人写东西，但我们不能从每个人的专业知识，每个人的意见和所有的用例中受益。所以请到GitHub加入我们。

它已经打了一个多托发布。所以今天就可以生产了。我真的认为这是容器和Kubernetes未来的重要组成部分。就是这样。我希望你们喜欢这次演讲。

我在最后打了个问号，因为这当然不是真正的结束。这也许是开始的结束。我希望关于无服务器和无服务器容器如何与Kubernetes集成的想法，以及我们如何为Kubernetes构建一个标准库。我希望这些东西能引起你的共鸣。你们帮助我们作为一个社区向前迈进，进入容器云和Kubernetes的未来10年。

谢谢你！

谢谢你，Brendan，这是一个很棒的主题演讲开场白，我很高兴能听到关于容器的所有未来以及你在dapper项目中所做的事情。

显然，如果有人感兴趣，我们会在聊天中，我们可以给你一些链接，在那里你可以找到那个项目，并为它贡献更多。接下来我们将开始我们的合作伙伴展示日，在那里，我们将有两个曲目超过25个赞助商，很多东西需要我们学习。再说一次，这将是非常深入的，非常真实的世界和现实生活的场景，我们将带你们走过。

这将是一种深入的开发人员演练，你将看到关于如何从我们的许多合作伙伴那里集成JFrog平台的一切。显然，如果有一个赛道同时进行，而且有两个你真的想去，我们会把所有这些都放到网上，当然是在我们完成swappa之后。所以，我想欢迎你加入我们，在这两个轨道中选择一个或两个，在它们之间跳跃。今天和我们的合作伙伴一起展示，尽可能多地学习，给我们反馈，让我们知道事情进展如何。

最后会有个调查。所以如果你想买一件T恤，请填写我们的调查问卷，让我们知道我们是怎么做的。

谢谢大家，祝大家有愉快的一天。