😐 🕖 🧙🏿 “ Docker已经死了”或任何您想了解的关于Devops的信息，但又害怕问 🌜 🙈 🤼

最近，DevOps的Alexander Chistyakov具有7年的经验，并且是圣彼得堡DevOps工程师社区的联合创始人，在我们的社交网络上发表了讲话。

Sasha是该领域的顶级演讲者之一，他在Highload ++，RIT ++，PiterPy和Strike的主要舞台上演出，总共发表了至少100份报告。上周一，他回答了观众的提问，并谈到了自己的经历。

我们分享广播录音和成绩单。

我的名字叫Alexander Chistyakov，我已经担任DevOps工程师很多年了。我一直在为多家公司提供关于实施DevOps实践的建议，使用现代DevOps工具并组织基础架构，以便大家晚上都能入睡，人们继续从他们的商品和服务中获得收益。

基本上我咨询了外国公司。

我们将讨论人们在日常实践中如何使用Kubernetes，为什么需要它，为什么不应该害怕它，应该注意什么以及接下来会发生什么。

我认为系统管理员，DevOps工程师，CIO和其他基础架构经理（和支持者）会发现它很有用。

这种格局是如何发展的？我记得计算机上安装了ROM Basic，并且可以在不安装OS的情况下编写程序。从那以后，桥下流了很多水。最初，没有这样的OS（更确切地说，它们是用汇编语言编写的）。然后出现了C语言，情况大为改善。当然，现在我们都熟悉OS的概念：它是一个平台，允许我们运行自定义应用程序并管理此计算机上的资源。或其他（如果已分发）。即使这样，仍然有可能从笔记本电脑和台式机组装出高性能的计算集群，这就是学生在1997年在圣彼得堡工业大学的宿舍所做的。

后来我发现大概十年前我读过这篇文章，发明了网络邮件的Google正在围绕这种网络邮件构建操作系统，以便用户可以在平板电脑和手机上使用它。这是意外的，通常操作系统是运行二进制文件的东西，当您通过浏览器查看应用程序时，您甚至都不知道二进制文件是否存在。您可以阅读邮件，在线聊天，绘制幻灯片，一起编辑文档。原来，这适合许多人。

没错，Google并不是很稳定，并且制造了许多不需要的产品，并且没有超出原型产品的范围，例如Google Wave。嗯，这是任何大型公司的政策-快速行动，经常崩溃直到公司不复存在。

然而，在大众意识中，操作系统已朝着这样一种观念转变：OS作为不提供曾经由某个标准制定委员会批准并分配给他们的服务，而只是满足用户需求的平台的平台。这些需求是什么？

过去习惯问开发商，他写了些什么。有C ++专家（可能现在有某个地方），现在有很多PHP专家（他们嘲笑自己，这确实发生了）和许多JavaScript开发人员。 Typescript是一种具有PHP知识的人已经转换为GoLang语言的语言，现在正变得越来越流行。曾经有一种Perl语言（可能仍然存在，但是已经失去了很多流行性），这是Ruby语言。通常，应用程序可以用任何东西编写。如果您生活在现实世界中，那么您可能会遇到这样的事实：它们是用任何语言编写的：Javascript，Rust，C；想出一个名字-上面写着一些东西。

所有这些都必须加以利用。事实证明，在这种异构系统中，首先需要专家来开发不同的语言，其次，需要一个平台，该平台允许您在令人愉悦的环境中启动服务并监视其生命周期。这个平台有一个合同，在现代世界中看起来像这样：您有一个容器映像（容器管理系统现在无处不在-Docker，尽管我对此无能为力；我们稍后会讨论问题）。

尽管人类正在沿着某个进化过程前进，但是这个过程已经趋同。在我们的行业中，事实证明有人仍在用Perl（在mod_perl Apache下）编写代码，而有人已在GoLang中编写微服务架构。事实证明，与平台的合同非常重要，平台的内容非常重要，平台帮助一个人非常重要。为了完成并启动服务而进行手动操作变得非常昂贵。我遇到了有20个服务的项目-这不是一个很大的项目；我听说过有上千种不同服务的人。 20是正常金额；并且每组服务都是由自己的团队以自己的语言开发的，它们仅通过交换协议进行连接。

关于申请合同的工作方式。有一个“ 12要素应用程序声明”-12条规则，规定应如何排列应用程序以便于使用。我不喜欢他。特别是，它说您需要通过环境变量来交付配置。例如，在亚马逊上，可以传递给Elastic Beanstalk的环境变量的数量是Linux内核的一页-4 KB。它们很快溢出。当您有80个不同的变量时，很难坚持使用81个变量。而且，它是一个扁平的配置空间-如果有变量，则必须用大写字母命名，并带有下划线，并且它们之间没有层次结构；很难理解发生了什么。我还没有弄清楚如何处理这个问题，也没有人讨论-没有一群爱好者，谁会反对这种方法。如果这突然也不适合某人-写信给我（Telegram中的改善者），我会知道我并不孤单。我绝对不喜欢。难以管理，难以传输分层数据；事实证明，现代工程师的工作是要知道变量在哪里，它们的含义，是否正确设置，更改它们的容易程度。我认为好的旧配置规则更好。是否正确设置它们，更改它们有多容易。在我看来，好的旧配置规则更好。是否正确设置它们，更改它们有多容易。在我看来，好的旧配置规则更好。

返回合同。事实证明，您需要一个Docker映像：您将需要Docker本身（尽管它本身很差-我希望某些Microsoft会购买它们并正常掩埋或开发它）。如果您对Docker不满意，可以尝试Red Hat's Stack。我对此无话可说，尽管在我看来它应该比仅香草Kubernetes更好。来自Red Hat的人们更加关注安全问题，他们甚至知道如何在正常分离权限的情况下进行多回转安装，多用户，多客户端-通常，他们确保权限管理到位。

让我们来谈谈安全性问题。她到处都是坏事，不仅在Kubernetes上。如果我们谈论安全性和容器编排问题，我对由服务器端完成的Web程序集寄予厚望，对于Web程序集应用程序，可以限制资源消耗，可以将系统调用绑定在Rust中的特殊容器中。这将是对安全性问题的一个很好的答案。而且Kubernetes没有安全性。

假设我们有一个应用程序。它是一个Docker映像，它有12个因子-也就是说，它可以从环境变量，安装在容器内的文件中获取配置。可以启动它-它是自给自足的，您可以尝试通过配置自动将其与其他应用程序链接。并且它应该将日志写入标准输出-这可能是最少的麻烦了；当容器将日志写入文件时，很难从那里收集日志。即使已对Nginx进行了修补，以便您可以从容器的标准输出中收集日志，这也是可以接受的（与通过参数传递配置相反）。实际上，我们以前有几个编排者：Rancher，Marathon Mesos，Nomad；但是，正如安娜·卡列尼娜（Anna Karenina）关于技术系统所讲的原则，复杂的技术系统以相同的方式安排。

使用Kubernetes，我们的情况与使用波音737 MAX的航空公司的情况相同-它不会飞行，因为其中有一个错误，但是没有别的，因为设计非常复杂。我不能说我喜欢它-像GoLang语言一样，并通过YAML格式进行控制，当您具有某种语法时，并且除此之外没有其他内容-不检查您编写的内容，没有数据类型。您在Kubernetes中应用配置之前所做的所有检查都是起步阶段。您可以尝试应用错误的配置，它将毫无疑问地应用，并且您不知道要做什么。编写错误的配置文件非常容易。这是一个大问题，人们已经开始使用Kotlin语言（甚至是Typescript）的DSL和Kubernetes来慢慢解决它。有一个Pulumi项目，有一个亚马逊项目EKS-尽管它更侧重于亚马逊； Pulumi是Terraform，仅在Typescript中。我希望我已经尝试过Pulumi，因为我相信这是未来。必须使用具有强静态类型的编程语言来描述配置，以便在应用配置（可能会破坏群集）之前，至少在编译时会告诉您这是不可能的。

因此，目前只有一个协调器。我知道还有一些MATA用户，我握手。我希望没有人使用Docker Swarm-我的经验是负面的。我相信可能是这样，但是我不知道为什么。我没有预见到Docker Swarm会有任何进一步的发展，而且我认为发布它的人现在不会对此做任何事情。资本主义;如果您不赚钱，那么就没有什么可以花在开发上的东西-他们的公司在过去两年中一直处于初创企业的“死亡谷”：没人愿意给他们钱。您可以对谁买标出价。微软对此不感兴趣。如果Docker幸存下来，也许有些Microfocus会做到这一点。

由于只剩下一个Kubernetes，我们来讨论一下。有一张美丽的图画，他的五角星有五角星。据记载，Kubernetes非常简单，只有五个二进制文件。但是，我远不能从编译系统的二进制数量和组成系统核心的服务数量的角度衡量系统的复杂性。多少个二进制文件都没有关系-重要的是Kubernetes可以做什么以及它在内部如何工作。

他能做什么？试想一下，您需要向5岁的孩子解释您在工作中所做的事情。现在，爸爸试图在Ansible上编写剧本和角色，这使他可以在主机和一组未在电视上注册的容器上基于Nginx进行蓝绿色部署，他说：“您知道，儿子，我尝试了所有是时候制作自己的Kubernetes了。它不能很好地工作，测试得很差，我不太了解它，我不知道所有的边界条件，它可以在同一台机器上工作，但这是我的！”我无可辩驳地看到了很多次-我只看了2到3次，有2次我参与了编写。迟早有一个参加此活动的人意识到不应有第4次。就像我的车友他曾经修复过VAZ-2101-安装了电动窗，用羊群修复了内部，并用金属漆了。创建自己的协调器就是这样。您可以尝试一次以确保可以，但是我还不准备将它推荐给所有人-不仅是发烧友。因此，生命周期管理，容器状态管理是Kubernetes的任务。

他可以确保容器在有资源的节点上运行，可以重新启动失效的容器，可以确保如果容器没有启动，那么如果有新的部署，流量将不会流向该容器。我们还首先说过Kubernetes是OS。在操作系统所在的位置，应该有一个程序包管理器。当Kubernetes开始时，对象描述势在必行。有状态集和代码描述是直接起作用的描述，您需要在顶部添加一些内容以使[???]处于状态。 18:52-记录故障]。实际上，与Ansible和其他类似的配置管理系统的根本区别在于，在Kubernetes中，您描述的是结果而不是结果。你自然地描述您拥有哪些对象以及它们具有什么属性。对象是服务，部署，守护程序，状态集。有趣的是，除了可以标准创建的对象之外，还有一些可以在Kubernetes中描述和创建的自定义对象。这非常有用；它还将大大减少系统管理员和devops工程师的队伍。

Kubernetes何时会死？

好问题。取决于“死亡”一词的含义。这是Docker-一年前，我们在圣彼得堡的一次会议上聚集在一起，举行了一次圆桌会议，我们共同决定（嗯，由于我们是一个行业，我认为那里有合格的多数，并且我们有能力为所有人发言）已经死了为什么？因为在会议上没有关于Docker的讨论，尽管它还没有很多年。没有人告诉他任何事情。我们讨论了Kubernetes，以及后续步骤-例如Kube Flow，有关使用运算符，以及如何放置Kubernetes基地。除了Docker之外的任何东西。这就是死亡-当你如此不幸以至于你似乎还活着时，却没人来找你。

Docker已经死了。当Kubernetes死后-让我们等5年，他不会死，每个人都会死-它会在Tesla内，您的手机内，无处不在，没人会对此感兴趣。我认为这就是死亡。也许甚至不是在5年后，而是在3年后。另一个问题是它将取代它：每个人都会谈论的一些响亮的新技术，也许根本不是来自DevOps领域。现在他们甚至只是为了保持对话而谈论Kubernetes，这没关系-它很时髦。

Docker怎么了？

所有。这是一个用于管理所有内容的二进制文件，这是必须在系统中启动的服务，这也是通过套接字控制的一部分。我认为，这是一款产品，其中包含许多未经任何人审查的代码。总体来说，这是没有企业资金的产品。红帽公司有非常聪明的人，我非常尊重他们，如果您是一名普通工程师，则应该查看他们的工作，因为这可能会确定未来5年的情况。好吧，红帽完全放弃了Docker。他们正在走向没有他。到目前为止，他们无法做到这一点，但是他们很亲密，迟早他们将完成Docker。除了我列出的所有内容以外，他还有一个巨大的攻击区域。那里没有安全。并未提出很多CVE，但是如果您仔细观察一下，很明显，与其他任何不把安全放在首位的项目一样，它是在剩余的基础上处理的。这是法律。安全是一个漫长，昂贵，沉闷的过程，它限制了开发人员，使生活非常艰难。正确完成安全性是一项艰巨的工作，您必须为此付出代价。如果您与任何安全专家交谈，无论具备什么资格，您都会听到很多有关Docker的恐怖故事以及有关事情有多糟的故事。它们部分与Docker本身有关，部分与操作它的人有关，但是Docker本身可以帮助人们并在其内部进行一些安全检查；例如，除非明确要求这样做，否则不要从根目录启动容器中的进程。限制了开发人员，使生活非常艰难。正确完成安全性是一项艰巨的工作，您必须为此付出代价。如果您与任何安全专家交谈，无论具备什么资格，您都会听到很多有关Docker的恐怖故事以及有关事情有多糟的故事。它们部分与Docker本身有关，部分与操作它的人有关，但是Docker本身可以帮助人们并在其内部进行一些安全检查；例如，除非明确要求这样做，否则不要从根目录启动容器中的进程。限制了开发人员，使生活非常艰难。正确完成安全性是一项艰巨的工作，您必须为此付出代价。如果您与任何安全专家交谈，无论具备什么资格，您都会听到很多有关Docker的恐怖故事以及有关事情有多糟的故事。他们部分与Docker本身联系在一起，部分与操作它的人联系在一起，但是Docker本身可以帮助人们并在其内部进行一些安全检查；例如，除非明确要求这样做，否则不要从根目录启动容器中的进程。部分地-与利用它的人合作，但是Docker本身可以帮助人们并在其内部进行一些安全检查；例如，除非明确要求这样做，否则不要从根目录启动容器中的进程。部分地-与利用它的人合作，但是Docker本身可以帮助人们并在其内部进行一些安全检查；例如，除非明确要求这样做，否则不要从根目录启动容器中的进程。

如何存储状态？我可以在Kubernetes上托管数据库吗？

如果您在决定将数据库放入Kubernetes之前询问DBA或负责该数据库基础结构的人员，则该人员会拒绝。我认为在许多圆桌会议上，人们会说Kubernetes中不应该有任何数据库：这是困难，不可靠的，并且不清楚如何管理它。

我相信Kubernetes中的DB可以代表。它的可靠性如何？好吧，看：我们正在处理分布式系统。将数据库放在群集中时，必须了解对容错的要求。如果您有这样的要求，您最有可能将Kubernetes放入数据库集群。现代世界中有多少人知道如何做一个普通的数据库集群？许多数据库是否提供集群功能？从这里开始将数据库分为传统的-关系型和非关系型。它们的区别不是后者不支持一种形式或另一种形式的SQL。不同之处在于非关系数据库更适合在集群中工作，因为它们最初是为编写数据库而编写的。因此，如果您想在Kubernetes中托管某个MongoDB或Cassandra，我不能劝阻您，但是您应该对下一步将有一个很好的了解。您应该非常了解数据的位置，发生故障和恢复时会发生什么情况，备份将如何进行，恢复点位于何处以及恢复需要多长时间。这些问题与Kubernetes无关；它们与您基本如何操作基于常规数据库的群集解决方案有关。使用NoSQL解决方案更容易，它们立即可用于云。恢复点在哪里，恢复需要多长时间。这些问题与Kubernetes无关；它们与您基本如何操作基于常规数据库的群集解决方案有关。使用NoSQL解决方案更容易，它们立即可用于云。恢复点在哪里，恢复需要多长时间。这些问题与Kubernetes无关；它们与您基本如何操作基于常规数据库的集群解决方案有关。使用NoSQL解决方案更容易，它们立即可用于云。

但是，仍然存在一个问题-为什么将数据库放入Kubernetes？您可以采用提供商提供的服务，托管解决方案；您可以从Amazon获取RDS，也可以从Google获取托管数据库。甚至可以安装和使用基于该基础的地理分布集群（对于Amazon，这就是Aurora）。但是，如果您要安装一个地理位置分散的基础集群，请仔细阅读文档；我见过具有单个节点的Aurora群集-它们甚至都没有分成两个区域。此外，根本不需要第二区域。通常，人们头脑中有非常奇怪的事情：他们认为主要的事情是选择一种产品，然后该产品将提供自己的产品并按预期工作。没有。关系数据库即使在常规集群中也根本无法工作，更不用说地理分布了。因此，如果您要基于它们执行复杂的操作，请查阅文档。

基本上，我有在Kubernetes内部操作数据库的经验。没有什么可怕的。有几次与节点掉落有关的崩溃。移动到其他节点正常进行。一切都在掌控之中。我唯一不能令您满意的是，每秒有成千上万的请求。

如果您有中等或较小的解决方案-俄罗斯的平均解决方案大约相当于Lenta这样的大型新闻社-则数据库中应该没有大量的复杂查询。如果基地无法应对，那么可能是您做错了，您需要考虑一下。不要盲目扩大规模。将非集群解决方案移动到集群有其优点，但也有很多缺点-特别是如果您使用基于Patroni或Stallone的postgres集群。边界条件很多。我还没有遇到过，但是Data Egret的同事很乐意告诉您它是如何发生的。 Alexei Lesovsky发表了一篇精彩的报告，内容涉及如果您不考虑而将基地转移到集群中将会发生什么。

每秒约有数千个请求。如果您有一个数据库实例，则仍可以按每秒数千个请求进行调整。迟早您会遇到麻烦。在我看来，如果计划了繁重的工作，最好考虑水平缩放选项。在数据库中找到最大的表，查看其中的内容，然后考虑是否可以将其移至非关系存储中。考虑一下如何不将关系数据库中通常存储的内容存储在关系数据库中—例如，访问系统日志很多，并且通常按照访问键值存储的相同方式来访问它们...那么，为什么不在Cassandra中写日志呢？这是一个建筑师的问题。在Kubernetes中保留一个很小但不是很忙的基本实例非常重要因为操作者的魔力开始对此负责。

基本上，如果您将Kubernetes看作是一个操作系统和一个平台，那么它就是一个自己动手的构造函数。您可以构建微服务架构，包括将状态存储在磁盘上，组织遥测，监视和警报的所有功能。这是由Kubernetes软件包管理器Helm完成的。 Internet上有大量开源，可公开获得的Helm Charts。提高项目基础结构最简单的方法是获取Helm Chart，该Helm Chart将应用程序，服务（如果该服务是Redis数据库，PostgreSQL，Patroni）放置在您的桌面上。开始配置它，并应用此配置。它是完全声明性的；无论可以预见到什么，Helm Charts的作者通常都会提供。最好同时使用Helm发布您的应用程序。第三个Helm不包含群集端服务；第二个包含，他有一个由群集管理员不断提供的服务，这是按名称空间分发发布所必需的，但是第三个Helm弥补了此安全漏洞。

Helm是一种基于GoLang模板语法的模板引擎。它需要一个变量列表，这些变量是非平面结构（感谢上帝，它是分层的-用YAML编写）；使用Helm，将这些变量放置在Helm模板中的正确位置，然后将其全部应用到某个命名空间中，在此处启动代码，服务并创建角色。有一个脚手架生成器，可以在不恢复意识的情况下编写Helm Chart。我唯一不喜欢的是需要了解Helm本身中GoLang模板化和条件分支的语法；它们是根据lisp原理制作的，带有前缀表示法。有人喜欢它是件好事，但每次都会使头转向。好吧，我们会克服它。

现在，了解接下来将要发生的事情。我已经很像运营商了。这些是Kubernetes集群内部的服务，用于管理另一个更大的应用程序的生命周期。有够难。您可以将运营商视为您的硅家庭站点可靠性工程师；可以肯定的是，将来人们会写越来越多的运算符，因为没有人愿意保持更改第一支持级别的人员，这些人员会遵循Nagios的时间表，注意到中断并采取手动操作。操作员了解哪些系统状态是可能的；这是一个状态机。现在，以GoLang语言或类似语言编写的人类知识集中起来，被编入一个集群中，并为您做了很多工作：添加或删除节点，重新配置，确保下降的节点上升，这样数据就可以从它们所在的位置停靠到所需的代码。通常，它管理下面安装的组件的生命周期。现在，运营商几乎可以处理所有事情。我一直在享受使用Rook运算符的乐趣，我将sev直接放入Kubernetes集群中。我查看了这是如何发生的，我感到非常高兴，并且我认为需要更多的操作员，我们都应该参与他们的测试。您花费时间纠正别人的操作员是对人类的礼物。您不再需要一遍又一遍地执行相同的工作。您可以将这项工作以异化的形式放在存储库中，然后一个智能程序将为您完成-是不是幸福？现在，运营商几乎可以处理所有事情。我一直在享受使用Rook运算符的乐趣，我将sev直接放入Kubernetes集群中。我查看了这是如何发生的，我感到非常高兴，并且我认为需要更多的操作员，我们都应该参与他们的测试。您花费时间纠正别人的操作员是对人类的礼物。您不再需要一遍又一遍地执行相同的工作。您可以将这项工作以异化的形式放在存储库中，然后一个智能程序将为您完成-是不是幸福？运营商现在几乎可以承担一切。我一直在享受使用Rook运算符的乐趣，我将sev直接放入Kubernetes集群中。我看着情况如何，我很高兴，我认为需要更多的操作员，我们都应该参加他们的测试。您花费时间纠正别人的操作员是对人类的礼物。您不再需要一遍又一遍地执行相同的工作。您可以将这项工作以异化的形式放在存储库中，然后一个智能程序将为您完成它-是不是幸福？您花费在纠正别人的操作员身上是对人类的礼物。您不再需要一遍又一遍地执行相同的工作。您可以将这项工作以异化的形式放在存储库中，然后一个智能程序将为您完成它-是不是幸福？您花费在纠正别人的操作员身上是对人类的礼物。您不再需要一遍又一遍地执行相同的工作。您可以将这项工作以异化的形式放在存储库中，然后一个智能程序将为您完成-是不是幸福？

我下载了Red Hat的书-他们免费提供-关于Kubernetes运营商的工作方式以及如何编写自己的书，我建议您也访问他们的网站并下载它，这本书非常有趣。当我阅读全文时，也许我们可以一起分析一些运算符。

谁支持Swarm？除了Docker Inc？

没有人。还有Docker Inc. 已经撕成两半，一半卖了。我不了解他们的情况；他们曾一次将产品称为Mobi，但它是一个开源版本，也就是说，它不是一个开放版本。有东西被出售了但有权利，但是没有被出售。对我来说，这就像“一个病人在死亡之前就流汗了”-人们试图以某种方式提取投资的钱。通常，没有人支持它。

主从

有用。如果主/从停止在关系数据库中工作，那么世界将在此处结束。Kubernetes不会以任何方式干扰数据库的运行。唯一带来的是不同的健康检查，如果需要，可以将其禁用，并且原则上可以进行状态管理。建议不要禁用它-您管理数据库的操作员应查看其状态。

红帽书的名字是什么？

Kubernetes运算符称为。鸭子被吸引在那里。奥莱利的书现在重新设计了封面。与Red Hat合作出版了许多书籍。Red Hat提供了3或4本书，您可以免费下载Kubernetes书籍：例如Kubernetes Patterns，gRPC。尽管gRPC协议与Kubernetes没有直接关系，但许多人仍使用gRPC协议在微服务之间交换数据。此外，它还用于下一代负载平衡器中，例如在Envoy中。

什么是SRA？

这种人了解分布式系统中发生的更改的时间范围。粗略地说，他知道您这个月躺了多久，您还能得到多少，是否允许发布。管理备份，恢复计划，灾难恢复问题，适用于24/7的工业应用程序的基础结构维护问题的密钥。在应用程序度量标准中，它具有用于应用程序状态和业务状态的度量标准–多少延迟，何处以及多少请求；那些相同的4金信号。此外，SRA根据这些指标可以采取措施使系统恢复战斗准备状态，他对如何做到这一点有一个计划。由于某种原因，传统的DevOps不需要这样做，它只是帮助开发人员将应用程序发布，通常将其发布到某个地方。SRA还阻止来自不同方面的请求流。

我答应谈论安全问题。您知道，这是Kubernetes中的一个相当年轻的话题。我仅了解非常基本的知识：例如，您不应从根目录在服务中运行应用程序，因为一旦发生这种情况，它就可以访问名称空间中的所有内容，超级用户权限，并且您可以尝试破坏主机系统内核，可能会解决（并从根目录执行任何其他操作）。不要给黑客这样的提示；如果可能，给用户尽可能少的权限并妥善处理用户输入。在我看来，如果我们谈论Kubernetes安全，则需要将其从我们现有的封闭电路中删除。或者，如果您确实想解决安全问题，则应签出Cilium项目。他知道如何使用电涌保护器基于BPF的网络流量区分-比iptables更好。这就是未来。在我看来，在加利福尼亚州以外，没有人真正使用过它，但是您已经可以开始使用。也许还会有其他项目，但我对此表示怀疑。一般而言，人类很少有工作要做。

因此，对于安全性，我没有什么特别的要说的。 Kubernetes中有多种选择来增加租期，但是您必须坐在那里坐下来弄清楚人们做了什么，他们关闭了哪些漏洞，是否有意义，是否适用于您的威胁模型。顺便说一句，我建议先查找有关如何构建威胁模型的说明，然后自己构建。有或多或少的正式方法。绘制，查看它，也许会出现洞察力，您将了解当前情况所需的内容和不需要的内容。也许足以将所有Kubernetes驱动到一个闭环中。顺便说一句，这是正确的决定。我碰到过这一点，这是不可穿透的。如果您只需要在手表上出示通行证即可访问系统，并且里面没有Internet，并且交易会通过一些特殊的网关进行，它位于DMZ中，并且由于其写法异常而难以破坏-这是一个受到良好保护的系统。如何通过技术手段做到这一点-那么，您需要监视当前的解决方案市场。它正在发生很大变化，安全性是一个热门话题。有很多玩家想成为，但其中谁在撒谎，谁在撒谎-我不敢说。尽管Red Hat可能不会撒谎，但它并不领先于所有人。您只需要做研究（我也要做），因为目前尚不清楚。您只需要做研究（我也要做），因为目前尚不清楚。您只需要做研究（我也要做），因为目前尚不清楚。

让我们谈谈Kubernetes集群还应该拥有什么。由于我们有机会免费在该处安装应用程序，因此我们不怕将数据库存储在该处。顺便说一句，如果您拥有Managed Kubernetes，那么对于在哪里存储数据库毫无疑问：您可以从托管托管Kubernetes的云中以一种或另一种形式（通常以块设备的形式）引入容错存储。您可以安全地从该存储中将磁盘放置到群集中，并使用快照进行一致的备份。只是不要忘记快照不是备份，还需要将快照复制到某个地方。这是显而易见的，但是显而易见的事情是可以重复的，这样就不会忘记它们。

当您具有微服务体系结构平台以使其可追溯，可观察时，这非常重要，这样您才能了解请求在哪里以及它们在哪里浪费时间，等等。建立这样一个平台是很多工作。您将需要普罗米修斯。因为它是Cloud Native Computing Foundation项目，所以将需要它。它专门用于监视Kubernetes。包含大量的出口商，指标收集器；一些应用程序本机包含其所有仪表板。如果您的应用程序不包含它们，则需要20分钟才能将其附加到寿命长的Prometheus仪表板应用程序。尽管由于某种原因，没有人附上它。根据我的经验，发生这种情况是因为人们将他们的产品保存在云端。有Amazon CloudWatch，Google StackDriver，并且您可以用相同的方式向其中发送指标-尽管这会花费很多钱。也就是说，如果人们仍然为基础架构付费，那么他们将为基础架构附带的监视工具付费。但是，如果您在多个不同的地方进行度量，如果云不在一个地方，如果它是混合的，如果您有本地计算机并且需要集中式基础结构，那么Prometheus可能会非常方便。然后，普罗米修斯是您的选择。如果您有本地计算机，并且需要集中式基础架构。然后，普罗米修斯是您的选择。如果您有本地计算机，并且需要集中式基础架构。然后，普罗米修斯是您的选择。

你还需要什么？显然，在Prometheus所在的地方，也需要Alert Manager。而且，您还需要某种分布式的请求跟踪。如何在Kubernetes中做到这一点-好吧，拿jaeger或zipkin之类的产品，或者现在最上面的东西；还有Cassandra来存储您的痕迹，还有Grafana来渲染它们。据我了解，此功能最近在Grafana中出现，但这不是没有实现它的理由。也就是说，您可以手动组装一个环境，在该环境中应用程序将[故障49:14]（拥有？）到此运行时为止，计数器和其他适用于构建分布式跟踪的可视化指标：应用程序在哪里花费了多长时间？

讲述它比展示它不方便，但是现在没有东西可以显示给我。我的实验室现在还没有这些。有一天我可能会准备好。

我想我已经说了我想讲的一切。我将再次重复主要规定。

首先：Kubernetes使您无需编写在Ansible Engine X上用另一个容器进行故障安全替换的机制。

其二：Kubernetes不会在任何地方消失。它可以“消亡”，但是不再可能停止使用它，它已经占领了大部分市场。关于“ Kubernetes何时会死亡：”这个问题，我想问“ WordPress何时会死亡？”。他仍然必须活着，让我们设定顺序：首先是WP，然后是Kubernetes。

所以Kubernetes与我们同在。有趣的不是他本人，而是缠绕在顶部的那些服务很有趣-这些是运算符和“自定义资源定义”。能够获取和编写自己的资源（称为“ PostgreSQL集群”）的能力，可以用一个YAML脚步对其进行描述，然后将其扔到集群中。

还会发生什么？还可以管理所有这些静态类型的编程语言，例如GoLang和TypeScript。我真的相信Kotlin-已经在上面写了很多很棒的DSL。还会写更多。

还将提供付费的Helm Chart，可在内部启动的付费应用程序（某些已许可的应用程序），可通过订阅获得。将集成各种服务-实际上，它已经存在，例如，DataDog已经与Kubernetes集成。而且出于明显的原因，将出现在监视警报市场上的新人也将与Kubernetes集成。任何云产品都不会以某种方式通过Kubernetes。这是每个人都将针对的平台。

但是，这一切并不意味着Kubernetes是好的，没有什么比这更好的了。我将其与以前的产品进行了比较-与Amazon解决方案：ECS，Elastic Beanstalk。碰到它们的人都知道，按照我的老比喻，一件事，那件事不仅是737 MAX，而是由电工胶带和橡皮泥制成的737 MAX。因此，主要参与者-亚马逊，微软Azure，谷歌-都已经在Kubernetes中了，也许Yandex和Mail.ru也在，但我不关注它们。这是一个共同的未来。如此糟糕，但“足够好”的共同未来，到目前为止，每个人都同意。接下来，所有这些都会引起什么变化，您必须问Red Hat-他们比我聪明。

Java对Kubernetes的感觉如何？

精细。

您在PC上使用什么操作系统？

两者都在macOS上。

DevOps专家现在正在积极招聘吗？

是的，他们总是被积极地带到偏远的地方，而现在他们以同样的方式被积极地带走。我认为情况不会根本改变。总的来说，我不会考虑未完成的工作：并不是每个好的公司都在圣彼得堡设有办事处。当然，这距离还有一段距离，时事向人们表明了这是可能的。对此感到更自在的人数只会增加。有人告诉我们“很多人尝试过，然后回到办公室”-好吧，回到办公室要花钱。没有钱-没有选择，许多公司现在都在储蓄。

“ Docker已经死了”或任何您想了解的关于Devops的信息，但又害怕问