对容器和云原生的未来的预测

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

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

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

我们讨论过的那些机器将你从这些机器中抽象出来在一个特定的配置中有一个操作系统，有一个集合由Kubernetes API集合在一起。这是一个古老的想法。它确实没有解决大多数人在Kubernetes中发现的主要价值，这些价值是更高级的API，如部署服务、入口等。更重要的是，它也不能很好地与云的发展方向相连接。

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

对吧?我们并没有说，嘿，它将会是功能即服务，或者，你知道，HTTP web通行证，我们并没有真正说任何东西，你知道，一个应用程序开发模式，那是传统的通行证领域。

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

有一大堆非常重要的问题需要思考，我认为为了开始思考这些问题，重要的是要思考为什么Kubernetes下是无服务器容器?这么吸引终端用户的东西?嗯，我认为当你想到虚拟机时，你知道，真正出现在你脑海中的问题是在一个云原生的世界里在一个开放的，你知道，在一个使用容器开发的新世界里。

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

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

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

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

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

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

一个是，无论Kubernetes把容器打包到你的机器上做得有多好，总会有剩余空间，要么是由于内部碎片造成的剩余空间，你把每台机器都分割开了，还有一点剩余空间你不能用于任何特定的容器，好吧，你仍然要为此付费，即使你不使用它。很明显，这会增加你的成本。但除此之外，你通常会保持你知道，启动一个虚拟机需要一点时间。你会想要保留一些备用容量，即使你打开自动缩放以便能够响应缩放事件。所以，这里有额外的容量，或者是你可以使用的内部碎片空间，或者是你为了扩展而保留的缓冲容量，这增加了成本，但没有增加任何价值。因此，由于所有这些原因，虚拟机和底层社区的存在，最终并不能为终端用户提供太多价值。但如果我们相信，你也相信，希望到目前为止，Kubernetes下的机器并不是特别有用。

一个非常有趣和重要的问题是我们如何走向新的未来?原因是，在代码层面，在Kubernetes的底层，Kubernetes本身的API，它实际上非常依赖于机器。对吧?它是在底层建立的，你知道，它把自己看作是一个机器管理器。所以当你考虑一些简单的问题，比如我如何得到一个特定舱的log ?

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

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

其中一些在裸机上运行，这种漂亮的无服务器容器并不真正可行，或者Kubernetes是提供无服务器容器的东西。所以当我们向前发展的时候，这将是一个真正的社区进化，看看我们如何从我们现在的位置到达我们需要去的地方。所以肯定会有一些大问题，一些我们需要思考的大问题，你知道，为了从一个我们有vm的世界，和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开发了许多不同的客户端库。它们在不同的语言中看起来都有点不同。其中一些是EDM。

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

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

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

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

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

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

你们可能见过sidecar模型和服务网格之类的东西。我认为服务网格是dapper属于的更广泛模式的一个很好的例子，也就是说，dapper提供了一堆有用的co例程或co进程可以让你的生活更轻松。我之前提到过很多编程语言都有标准库。在容器世界中，有一点很明显，那就是它是一个多语言的世界。你不能亲和眼睛，任何特定的标准库。所以，你知道，有一些库已经被开发出来了，但是它们非常固定于一种语言。

Dapper采取了相反的方法。Dapper说，嘿，你知道吗，我们只讨论HTTP或grpc。这就意味着任何语言都可以和dapper交流。我们可以使用完全相同的实现，无论你来自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在demo中不是任意选择的。

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

现在，你可能会认为，衣帽器只是用来存储的，因为这是我目前为止画的例子。

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

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

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

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

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

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

它确实是一个我们聚集在一起建立标准库的地方，因为它确实是，它只能成为一个标准库，如果你知道社区围绕它团结起来，如果只有三个人写东西，但我们没有从每个人的专业知识、每个人的意见和他们所有的用例中获益。所以请加入我们的GitHub。

它已经达到了一个Dotto释放。所以今天就可以生产了。我真的认为它是容器和Kubernetes未来的重要组成部分。就是这样。我希望你们喜欢我的演讲。

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

谢谢你！

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

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

这将是一个深入的开发攻略，你将从我们的许多合作伙伴那里看到关于如何与JFrog平台集成的所有内容。很明显，如果有一个轨道同时运行，有两个你想要的，我们会把所有这些放到网上，当然是在我们完成swappa之后。所以，我想欢迎你们加入我们的行列，选择其中的一条或两条，在它们之间来回切换。尽可能多地了解我们的合作伙伴展示日，给我们反馈，让我们知道事情的进展。

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

说到这里，谢谢大家，祝你们今天愉快。