Kubernetes将接管世界。 什么时候以及如何？

为了迎接DevOpsConf， Vitaliy Khabarov采访了Flant的技术总监兼联合创始人Dmitry Stolyarov （ distol ）。 Vitaly向Dmitry询问了Flant在做什么，有关Kubernetes，生态系统开发和支持的信息。 我们讨论了为什么需要Kubernetes以及是否完全需要Kubernetes。 还有关于微服务，Amazon AWS，DevOps中的“我很幸运”方法，Kubernetes本身的未来，为何，何时以及如何接管世界，DevOps的前景以及工程师应该在不久的将来使用简化和神经网络做些什么准备。

在DevOps Deflop上作为播客收听原始采访 ，这是俄语关于DevOps的播客，下面是文本版本。



此后，Express42的工程师向Vitaliy Khabarov提出了问题。

关于弗朗特

-迪玛，你好 您是Flant的技术总监，也是其创始人。 请告诉我，公司在做什么，您在做什么？

德米特里（Dmitry） ：从外面看，好像我们是要去把Kubernetes放在每个人身上并与他做点什么的家伙。 但是事实并非如此。 我们最初是一家从事Linux的公司，但是很长一段时间以来，我们的主要业务是为生产和交钥匙高负荷项目提供服务。 通常，我们从头开始构建整个基础架构，然后我们要负责很长时间。 因此，弗兰特执行的主要工作是为生产负责，并负责生产的交接工作。


作为公司的技术总监和创始人之一，我日以继夜地研究提高生产可用性，简化生产过程，使管理员的生活更轻松，使开发人员的生活更加愉悦的方法。

关于Kubernetes

-上次来自《 Flanta》的时候，我看到了很多有关Kubernetes的报告和文章 。 你怎么来找他的

德米特里 ：我已经谈论过很多次了，但是我很抱歉重复一遍。 我相信重复这个话题是正确的，因为原因和结果之间存在混淆。

我们确实需要一个工具。 我们面临许多问题，苦苦挣扎，用不同的拐杖克服了它们，并感到需要一种乐器。 筛选了许多不同的选项，制造了自己的自行车，获得了经验。 渐渐地，我们意识到我们几乎在2013年左右就开始使用Docker。 在它出现的时候，我们已经在容器方面有很多经验，我们已经写了一个类似Docker的类似物-我们在Python中的一些拐杖。 随着Docker的出现，拐杖可以被可靠且受社区支持的解决方案淘汰并使用。

使用Kubernetes的故事与此类似。 到他开始获得发展动力时（对我们而言，这是1.2版本），我们在Shell和Chef上都已经有了很多拐杖，我们以某种方式试图编排Docker。 我们认真考虑了Rancher和其他各种解决方案，但随后出现了Kubernetes，其中的一切都按照我们甚至更好的方式实施。 没有什么可抱怨的。

是的，存在某种缺陷，存在某种缺陷-存在许多缺陷，而1.2总体来说很可怕，但是.... Kubernetes就像正在建造的建筑物-您查看该项目并了解它会很酷。 如果建筑物现在有地基和两层楼，那么您可以理解最好不要填充，但是软件不存在此类问题-您已经可以使用它了。

我们暂时没有考虑过是否使用Kubernetes。 在他出现之前，我们已经在等他了很久，并试图自己制作类似物。

在Kubernetes附近

-您是否直接参与Kubernetes本身的开发？

德米特里 ：平庸。 我们更有可能参与生态系统的发展。 我们向Prometheus，各种运营商，对生态系统的Helm发送一定数量的请求。 不幸的是，我无法跟随我们所做的一切，而且我可能会误会，但是我们的核心并没有一个池。

-您是否围绕Kubernetes开发了很多工具？

德米特里（Dmitry） ：策略是这样的：我们去将其拉入已经存在的一切中。 如果那里没有接受拉取请求，我们只需为自己分叉它们，然后继续生活直到它们被我们的建筑所接受。 然后，当它到达上游时，我们返回到上游版本。

例如，我们有一个Prometheus运算符，可能已经用它来回切换了装配的上游5次。 我们需要一些功能，我们发送了一个拉取请求，我们需要明天将其推出，并且我们不想等到它在上游发布。 因此，我们为自己收集，使用我们的功能（由于某种原因需要）将组件滚动到所有集群。 然后，例如，他们在上游用以下单词包装我们：“伙计，让我们为更一般的情况做这件事”，我们或其他人将完成此操作，并最终再次合并。

现有的一切，我们都在努力发展 。 许多尚未发明的元素尚未发明或已经发明，但尚未实现-我们正在这样做。 并不是因为我们喜欢流程本身或作为一个行业的自行车制造，而是因为我们需要此工具。 他们经常问这个问题，为什么我们要这样做？ 答案很简单-因为我们必须走得更远，解决一些实际问题，然后我们才能使用此工具解决它。

方式总是这样：我们非常仔细地研究，如果找不到任何解决方案，那么如何用一条面包制成无轨电车，那么我们将自己制造一条面包和自己的无轨电车。

弹力工具

“我知道Flant现在具有插件运算符，shell运算符，dapp / werf工具。 据我了解，这是不同化身的相同工具。 我也明白Flant内部还有许多其他工具。 是这样吗

Dmitry ：GitHub上还有很多东西。 从我现在记得的情况来看，我们有一个状态图-Grafana的面板已经遍及所有人。 几乎每隔第二篇文章都提到了有关在介质上监视Kubernetes的内容。 简要描述什么是状态图是不可能的-您需要单独撰写一篇文章，但这对于随时间监视状态非常有用，因为在Kubernetes中，我们经常需要随时间显示状态。 我们还有LogHouse-这是一个ClickHouse，基于黑魔法，用于在Kubernetes中收集日志。

许多实用程序！ 而且还会有更多，因为今年将发布许多内部解决方案。 在非常大的基于插件的运算符中，Kubernetes有很多插件，但是如何安装sert管理器（证书管理工具），如何使用一堆闪避安装Prometheus，这是二十种不同的二进制文件，它们可以导出数据并收集一些东西。 Prometheus是很棒的图形和警报。 所有这些只是Kubernetes的一堆附加组件，它们被放入一个集群中，并且它从简单变成了凉爽，复杂，自动，其中许多问题已经得到解决。 是的，我们做了很多。

生态系统发展

-在我看来，这是对该工具及其使用方法的发展做出的巨大贡献。 您能粗略地找出还有谁对生态系统的发展做出同样的贡献吗？

德米特里 ： 在俄罗斯，在我们市场上经营的公司都没有一家 。 当然，这是一个引人注目的声明，因为有像Mail with Yandex这样的大型公司-他们也在Kubernetes上做一些事情，但是即使他们没有与世界上公司的贡献相提并论，这些公司所做的比我们要多得多。 如果我没有记错的话，很难将Flant与拥有80名员工和Red Hat的员工进行比较，其中Red Hat只有300名Kubernetes工程师。 很难比较。 RnD部门有6个人（包括我在内）正在使用我们的所有工具。 6名人员与300名Red Hat工程师进行了比较-很难比较。

-尽管如此，即使这6个人都可以做一些真正有用和疏远的事情，当他们面对实际任务并向社区做出决策时-一个有趣的例子。 我了解到，在拥有自己的开发和Kubernetes支持团队的大型技术公司中，原则上可以开发相同的工具。 对于他们来说，这是一个可以发展并提供给社区的示例，以推动使用Kubernetes的整个社区。

德米特里 ：这可能是集成器芯片，它的功能。 我们有许多项目，我们看到许多不同的情况。 对我们来说，创造附加值的主要方法是分析这些案例，找到常见的案例，并使它们对我们来说尽可能便宜。 我们正在积极地这样做。 我很难谈论俄罗斯和世界，但是Kubernetes大约有40位DevOps工程师。 我认为，在俄罗斯，没有多少公司拥有相当数量的了解Kubernetes的专家（如果有）。

我了解有关DevOps工程师职称的所有知识，每个人都了解所有知识，并且习惯于打电话给DevOps工程师DevOps工程师，我们将不再讨论这一点。 所有这40名出色的DevOps工程师每天都面临问题并解决问题，我们只是分析这种经验并尝试进行总结。 我们知道，如果仍然存在，那么该工具将在一两年之内变得无用，因为在社区中某个地方会出现现成的工具。 在内部积累这种经验是没有意义的-在dev / null中浪费时间和精力。 因此，我们一点也不后悔。 我们非常高兴地发布了所有内容，并了解我们需要发布，开发，推广，推广它，以便人们可以使用和添加自己的经验，然后一切都得以成长和发展。 然后，两年后，该工具就没有丢到垃圾箱了。 继续倾注精力并不可惜，因为很明显有人在使用您的工具，两年后所有人都在使用它。

这是我们dapp / werf大战略的一部分 。 我不记得大约3年前我们何时开始这样做。 最初，它通常位于外壳上。 这是一个超级概念证明，我们解决了一些私人任务-结果证明了！ 但是外壳存在问题，无法进一步构建，在外壳上进行编程是另外一回事。 我们习惯于分别用Ruby编写代码，在Ruby中，我们重做，开发，开发，开发和开发某些东西是基于这样一个事实，即社区（一群不说“我们想要或不想要”的人）抬起了Ruby的鼻子，这不好笑。 我们意识到，我们应该在Go上编写所有这些内容，以便与清单中的第一段相对应： DevOps-tool应该是静态二进制文件 。 在Go上还是不那么重要，但是用Go编写的静态二进制更好。

花了点功夫，在Go上重写了dapp并将其命名为werf。 Dapp不再受支持，不会开发，它可以在某些最新版本中运行，但是从顶部到顶部都有绝对的升级路径，您可以按照它进行操作。

为什么要创建dapp？

-您能否简要介绍一下创建dapp的原因，它可以解决什么问题？

德米特里（Dmitry） ：组装的第一个原因。 最初，当Docker不知道如何进行多阶段时，我们遇到了很大的构建问题，而我们自己进行了多阶段。 然后我们对清洁图像有很多疑问。 制作CI / CD的每个人都迟早要面对这样一个问题，即有一堆收集的图像，您需要以某种方式清理不需要的东西并留下需要的东西。

第二个原因是在部署中。 是的，有头盔，但只能解决部分问题。 具有讽刺意味的是，上面写着“ Helm-Kubernetes的软件包管理器”。 即那个“那个”。 也有“ Package Manager”一词-Package Manager通常期望什么？ 我们说：“包裹管理员-交付包裹！” 并希望他告诉我们：“包裹已送达。”

有趣的是，我们说：“头盔，放好包装”，当他回答说已经安装了它时，事实证明他才刚刚开始安装-Kubernetes指出：“运行该东西！”，但是不管它启动与否，它是否有效头盔根本解决不了这个问题。

事实证明，Helm只是将数据加载到Kubernetes中的文本预处理器。

但是我们想知道在任何部署的框架中-应用程序是否已经正式发布？ 推向产品意味着该应用程序已部署到那里，已部署了新版本，并且至少不会崩溃并能够正确回答。 头盔无法解决此问题。 要解决此问题，您需要花费大量精力，因为您需要给Kubernetes命令以推出并监视在那里发生的事情-它是否转过身，是否已经展开。 并且还有许多与部署，清洁和组装有关的任务。

计划

今年，我们将去当地发展。 我们想了解一下Vagrant中的情况-输入“ vagrant up”并部署虚拟机。 我们希望达到这样的状态，Git中有一个项目，我们在那里写了“ werf up”，它引发了该项目的本地副本，并部署在本地mini-Kub中，所有便于开发的目录都已连接到该副本。 取决于开发语言，这可以通过不同的方式完成，但是尽管如此，这样仍可以方便地在已挂载文件下进行本地开发。

对我们来说，下一步就是大量投资于开发人员的便利性 。 为了使用一个工具在本地快速部署项目以完成并推送到Git，它还将根据管道进行阶段或测试，然后使用相同的工具进入产品。 从本地环境到销售，基础设施的统一，统一和可复制性对我们而言是非常重要的时刻。 但这还不是在werf中-只是计划这样做。

但是开始使用dapp / werf的方法始终与使用Kubernetes相同。 我们遇到了问题，并通过变通办法解决了这些问题-我们在shell或其他任何方面为自己想出了一些解决方案。 然后，这些变通办法试图以某种方式理顺，归纳和合并为二进制文件，我们简单地将它们共享。

对于整个故事还有另一种观点，即类推。

Kubernetes是带有引擎的汽车框架。 没有门，窗户，收音机，圣诞树-什么都没有。 只有车架和引擎。 还有头盔-这就是方向盘。 酷-有一个方向盘，但仍然需要一个方向盘，方向盘，变速箱和方向盘，但没有它们。

就werf而言，这是Kubernetes的另一个组成部分。 例如，直到现在，在我们的werf的Alpha版本中，Helm才完全编译为werf，因为我们已经厌倦了自己这样做。 这样做有很多原因，详细说明为什么我们在werf中将舵手与分till一起编译为一个整体，我将在RIT ++的报告中告诉大家。

现在，werf是一个更加集成的组件。 我们有一个现成的方向盘，方向盘-我不是很擅长汽车，但这是一个很大的块，已经解决了很多任务。 我们不需要自己去爬目录，也不必自己去研究另一部分，而是考虑如何将它们彼此固定在一起。 我们得到了现成的联合收割机，可以立即解决一大堆任务。 但是内部由所有相同的开源组件组成，还使用Docker进行组装，使用Helm进行部分功能，还有其他几个库。 这是一个集成工具，可以快速方便地从包装中取出CI / CD。

Kubernetes难以维护吗？

-您谈论的是您开始使用Kubernetes的经验，这是一个框架，一个适合您的引擎，您可以在上面悬挂很多不同的东西：车身，方向盘，固定踏板，座椅。 问题是-Kubernetes对您的支持有多困难？ 您拥有丰富的经验，与其他所有东西分开支持Kubernetes需要花费多少时间和资源？

德米特里（Dmitry） ：这是一个非常困难的问题，要回答，您需要了解什么是Kubernetes的支持以及我们想要的支持。 也许你会透露？

-据我所知，现在很多团队都想尝试Kubernetes。 每个人都抓住他，跪下。 我感到人们并不总是了解该系统的复杂性。

德米特里 ：就是这样。

-不带任何东西交付Kubernetes使其准备就绪有多困难？

德米特里 ：您认为移植心脏有多困难？ 我了解，这个问题正在折中。 携带手术刀而不犯错误并不难。 如果告诉您在哪里切割和在哪里缝，那么程序本身很简单。 很难不时地保证一切都会顺利进行。

放入Kubernetes，使其工作简单：小鸡！ -交付时，有很多安装方法。 但是，当出现问题时会发生什么？

总是出现问题-我们还没有考虑什么？ 我们还没做什么？ 您没有正确指定Linux内核的哪些参数？ 主啊，我们甚至指出了他们吗？ 我们提供了哪些Kubernetes组件，哪些没有？ 出现成千上万的问题，要回答这些问题，您需要在该行业中做15-20年的烹饪。

我有一个有关该主题的新示例，它可能揭示“维护Kubernetes是否困难？”问题的含义。 前一段时间，我们认真考虑过是否应该在Kubernetes中将Cilium作为网络实现。

让我解释一下Cilium是什么。 Kubernetes有许多不同的网络子系统实现，其中之一非常酷-它是Cilium。 它是什么意思？ 前一段时间在内核中，可以为内核编写钩子，从而以某种方式入侵网络子系统和其他子系统，并允许您绕过内核中的大块。

Linux内核历来具有ip rout，超级过滤器，网桥以及许多具有15、20、30年历史的旧组件。 通常，它们可以工作，一切都很酷，但是现在他们已经制成了一个容器容器，它看起来像15块砖砌成的塔，彼此叠放在一起，而您却站在那条腿上-一种奇怪的感觉。 这个系统在历史上发展了许多细微差别，就像身体的附录一样。 例如，在某些情况下，性能存在问题。

有一个很棒的BPF和为内核编写钩子的能力-伙计们为内核编写了钩子。 该软件包进入Linux内核，他们在输入端将其取出，无需桥接，没有TCP，没有IP堆栈即可进行处理-简而言之，绕过Linux内核中编写的所有内容，然后立即将其吐出到容器中。

怎么了 很棒的性能，很棒的功能-太棒了！ 但是我们看了看，发现每台机器上都有一个程序连接到Kubernetes API，并根据从该API接收到的数据，生成C代码并编译将其加载到内核中的二进制文件，以便这些钩子可以在内核空间中工作。

如果出问题了怎么办？ 我们不知道。 要了解这一点，您需要阅读所有这些代码，了解所有逻辑，这真是令人震惊，难上加难。 但是，另一方面，有这些网桥，网络过滤器，ip路由-我没有阅读他们的资料，还有40位在我们公司工作的工程师。 也许有些作品可以理解单位。

有什么区别？ 事实证明，这里有ip rout和Linux内核，还有一个新工具-有什么区别，我们不能理解一个或另一个。 但是我们害怕使用新的-为什么？ 因为如果使用该工具已有30年的历史，那么30多年来就发现了所有的错误，所有的佣金都来了，您不需要一无所知-它像黑盒子一样工作，并且始终可以工作。 每个人都知道哪个诊断螺丝刀会粘在哪个位置，哪个tcpdump会从什么位置开始。 每个人都非常了解诊断实用程序，并且了解这组组件如何在Linux内核中工作-不是工作原理，而是如何使用它。

而且超酷的Cilium还没有30岁，还没有成熟。 对于Kubernetes，存在相同的问题，请复制。 Cilium设置完美，Kubernetes设置完美，但是当产品出现问题时，您是否能够快速了解​​关键情况下出了什么问题？

当我们说维护Kubernetes很困难时，不，这非常简单，是的，这非常困难。 Kubernetes , .

« »

— , ? , Kubernetes, - .

: , , . , Kubernetes, . , ? , , , . , — , . Kubernetes.

Ubuntu 16.04. , , , LTS. systemd, , C-. Kubernetes , C-, , - — , , — systemd. , . highload. , , Cron Job, , Ubuntu 16.04 . load average - , C-. , , Ubuntu 16 Kubernetes.

, - systemd - , Linux 4.16 — C- . . , , 15 , C-, , — .

. , - — , . — Kubernetes, — . . , - - , , , . , Kubernetes — ?

, , , . , .

, , , , . .

IT, , « ». , , . , . .

— : , , «», , Red Hat, , Kubernetes, .

: . Kubernetes — .

?

— , Kubernetes ?

: , , -. : «Kubernetes, Kubernetes», . , , , 70% Kubernetes. .

— ? «» , Kubernetes — -.

, Kubernetes .

game-changer . — , Ansible, Chef, , Terraform. . Kubernetes — changer , .

, - , - , . , , Kubernetes : , infrastructure as code , , yml — . , .

— , Kubernetes, . ?

: . , dns-, FreeBSD 4.10 20 . . , 20 - . , - , , , , Kubernetes. .

, CI/CD — , Continuous Delivery, , , , — Kubernetes.

— . Kubernetes, — . — - , , , Kubernetes , . — Kubernetes - , Kubernetes?

: . «: ». , . , . , , . «». , , - , — , , . 事实并非如此。

, , 300 , , , , , - — 10, 30 . , . , 3 60 , .

, — . , . , , .

, , , , Kubernetes , , , , , , Kubernetes, . — , , , . . — , , — .

— , Kubernetes , , , . . — , , , 10 — , . . , .

Kubernetes . : Kubernetes, , 4-5 , — . , . 这是什么 Ubuntu Curios? Linux, . , . Kubernetes , , , , .

, , — «», 150 DevOps easy service. — . , DevOps, , . , . , , . , . , Kubernetes.

, 10 , . .

Amazon Google

— Amazon Google?

: , , . . , . , Amazon AWS: Load Balancer , «, , Load Balancer!» .

, , . 40 , , , 60 — . - , , .

, — , hosted- - . , , . Amazon Google . — . . clouds, , — Ager, , , OpenStack : Headster, Overage — , . , .

, — , , , hosted- .

Kubernetes?

— - Kubernetes? Kubernetes, «», Kubernetes?

: , Kubernetes : «, , Kubernetes, !». : «, Kubernetes, , ». , CI/CD , . , , .

, , , — ! — Kubernetes . . , , — Kubernetes , ! — ! — , ! — 100% uptime, 50 , . , !

, : «, ». , . , . CI/CD, . , .

, Kubernetes — Kubernetes .

, Kubernetes. , , , . , . Kubernetes — , , « », « », - .

. : , , — . . , , , , . , .

, - Kubernetes — .

Kubernetes , , , . — . - , — . - , , , , . . , DevOps , - , - . - .

. : «, !» — , : « , ». . , , - , , .

: Kubernetes. .

, :

• ;
  
• , , - ;
  
• , , , .
  

: / . , - IT-, , - — soft for easing the world, , . Kubernetes , .

关于无服务器

-如果您对未来有更进一步的了解，然后尝试解决基础架构缺乏麻烦的问题，并且推出速度和应用程序更改速度会出现新的解决方案，例如无服务器。 您在这个方向上是否有任何潜力，并且可以说对Kubernetes和类似解决方案构成威胁？

德米特里（Dmitry） ：在这里，我们需要再次说明一下，我不是一个有远见的人，他会向前看，然后说-那样！ 虽然我只是做同样的事情。 我看着我的脚，看到那里有很多问题，例如，晶体管在计算机中的工作方式。 好笑吧？ 我们在CPU中遇到一些错误。

使无服务器足够可靠，便宜，高效和便捷，解决了所有生态系统问题。 然后，我同意埃隆·马斯克（Elon Mask）的观点，我们需要第二颗行星来对人类进行容错。 尽管我不知道他在说什么，但我知道我还没有准备好亲自飞往火星，所以明天就不会了。

在无服务器的情况下，很显然这在思想上是正确的，因为对人类的容错能力是-两颗行星比一颗更好。 但是现在该怎么办？ 如果我们专注于这项工作，派遣一支探险队就不是问题。 我认为，派几支探险队并在那里居住数千人也是现实的。 但这完全是为了让人类一半的人生活在这里来容错，在我看来，这似乎是不可能的，没有被考虑。

使用无服务器一对一：事情很酷，但这远非2019年的问题。 接近2030年-让我们一起生活吧。 我毫不怀疑我们会生存，我们一定会生存（睡前重复），但是现在我们需要解决其他问题。 就像相信神话般的小马彩虹。 是的，已经解决了百分之二的案件，并且完美地解决了这些案件，但是主观上无服务器是彩虹……对我来说，这个话题太过遥不可及了。 我还没准备好说话。 在无服务器的2019年中，您将不会编写单个应用程序。

Kubernetes将如何发展

“随着我们朝着这个美好而遥远的未来迈进，您认为将如何发展Kubernetes及其周围的生态系统？”

德米特里 ：我对此进行了很多思考，我有一个明确的答案。 第一个是有状态的-无状态仍然更容易实现。 Kubernetes最初对它进行了更多投资，这一切都始于它。 无状态在Kubernetes中几乎完美地工作，没有什么可抱怨的。 通过statefull，仍然存在很多问题，或者说是细微差别。 一切对我们来说都已经很好了，但是我们做到了。 为了使此方法适用于所有人，至少还需要几年。 这不是计算得出的指标，而是我从头开始的感觉。

简而言之，全状态需要并且将非常发展，因为我们所有的应用程序都具有状态，因此没有无状态应用程序。 这是一种错觉，您总是需要某种数据库和其他东西。 Statefull是对可能的一切进行纠正，对所有错误的纠正，对当前面临的所有问题的改进-我们称之为采用。

未知的水平，未解决的问题的水平，遇到问题的可能性的水平将急剧下降。 这是一个重要的故事。 而操作员-与获得易于服务的管理逻辑，控制逻辑的编纂相关的一切：MySQL便捷服务，RabbitMQ便捷服务，Memcache便捷服务-通常，我们需要保证所有这些组件都可以直接使用。 这只是解决了我们想要一个数据库，但又不想管理它，或者想要Kubernetes，但又不想管理它的痛苦。

在未来几年中，随着运营商以一种或另一种形式发展的这个故事将非常重要。

我认为易用性应该大大提高-盒子将变得越来越黑，越来越可靠，并且越来越简单。

我曾经在周六夜现场在YouTube上听过艾萨克·阿西莫夫（Isaac Asimov）的80年代旧访谈，这是一部类似Urgant的节目，很有趣。 有人问他有关计算机的未来。 他说，未来很简单，就像收音机一样。 收音机原本是一件复杂的事情。 为了捕捉电波，花了15分钟扭动陀螺，旋转串流，并大致了解一切工作原理，以了解无线电波传输的物理原理。 结果，收音机里只剩下一个转弯。

现在是2019年，哪个电台？ 在汽车中，收音机找到所有海浪，即电台的名称。 该过程的物理原理在100年内没有发生变化，易用性也发生了变化。 现在，不仅现在，在1980年，当接受Azimov采访时，每个人都使用了收音机，没有人想到它的布置方式。 它始终有效-这是给定的。

阿兹莫夫（Azimov）随后说，它将与计算机相似- 易用性将会增加 。 如果在1980年您需要接受特殊教育以按计算机上的按钮，那么将来就不会如此。

我觉得有了Kubernetes和基础设施，易用性也会大大提高。 我认为，这很明显-它位于表面。

与工程师做什么？

-然后，支持Kubernetes的工程师，系统管理员会怎样？

德米特里 ：1C出台后，会计师怎么了？ 差不多。 在此之前，他们想到了一张纸-现在在程序中。 劳动生产率提高了几个数量级，劳动本身并没有因此而消失。 以前，需要10名工程师拧紧灯泡，但是现在一名工程师就足够了。

在我看来，软件的数量和任务的数量正在以比新的DevOps更高的速度增长，并且效率正在提高。 市场上存在特定的短缺，这种情况将持续很长时间。 后来，一切都会按照一定的规范进行，工作效率将提高，变得更加无服务器，他们将神经元连接到Kubernetes，Kubernetes将按需选择所有资源，并且通常它将按其应有的方式做一切-这个人可以逃脱并且不会打扰。

但是无论如何，都将不得不做出决定。 显然，此人的资格和专业水平较高。 现在，在会计部门，您不需要10名记账的员工，这样他们的手就不会累了。 只是没有必要。 电子文档管理系统会自动扫描并识别许多文档。 一位聪明的总会计师就足够了，已经掌握了大得多的技能并且有很好的理解力。

总的来说，这条道路在所有部门中都有。 汽车也是如此：早期，有一名汽车修理工和三名驾驶员被固定在汽车上。 现在开车是我们每个人每天参与的最简单的过程。 没有人认为汽车是一件复杂的事情。

DevOps或系统工程将无处可走-高水平和运营效率将提高。

-我还听到了一个有趣的想法，实际上这项工作将会增加。

德米特里 ：当然，百分之一百！ 因为我们编写的软件数量在不断增长。 我们使用软件解决的问题数量在不断增长。 工作量正在增长。 现在，DevOps市场非常过热。 从薪水期望中可以明显看出这一点。 以一种很好的方式，在不赘述的情况下，应该有希望获得X的初中生，希望获得1.5倍的中产阶级和希望获得2倍的老年人。 而现在，如果您看一下莫斯科DevOps的薪资市场，那么初级的价格是X到3X，高级的价格是X到3X。

没有人知道它要花多少钱。 您的薪水水平由您的信心来衡量-坦白地说，这是一个完整的疯人院，市场过热。

当然，这种情况很快就会改变-应该会饱和。 对于软件开发而言，情况并非如此-尽管每个人都需要开发人员，每个人都需要优秀的开发人员，但市场知道它要花多少钱，该行业已经稳定下来。 DevOps并非如此。

-据我所知，我得出的结论是，当前的系统管理员应该不会太担心，但是现在该下载技能并为明天的工作做准备了，但是它的资格更高。

德米特里 ：当然。 总的来说，我们生活在2019年，生活规则是： 终身学习-我们学习一生 。 在我看来，现在每个人都知道并感觉到它，但要知道一点点是必要的。 每天我们都要改变。 如果我们不这样做，那么迟早我们将被抛弃在该行业的边缘。

准备好急转180度。 我不排除某些情况发生重大变化而他们提出了新的东西的情况。 跳！ -现在我们的行为有所不同。 重要的是为此做准备而不要蒸。 明天可能会发生我做的所有事情都是不必要的-没什么，我毕生学习并准备学习其他东西。 这不是问题。 您不应该担心工作安全，但是您需要准备不断学习新知识。

祝愿和一分钟的广告

-你有什么愿望吗？

德米特里 ：是的，我有几个愿望。

第一个是具有商业性质的-订阅YouTube 。 尊敬的读者，请访问YouTube并订阅我们的频道。 在大约一个月的时间里，我们将开始积极扩展到视频服务，我们将提供一系列有关Kubernetes的教育性内容，这些内容都是开放的和不同的：从实践到实验室，再到深入的基础理论知识以及如何在原理和模式层面应用Kubernetes。

第二个商业愿望-转到GitHub并添加星号，因为我们吃了它们。 如果您不给我们星星，我们将一无所有。 这就像是电脑游戏中的法力值。 我们正在做某事，正在做某事，正在尝试，有人说这是可怕的自行车，有人说一切都错了，我们继续并绝对诚实地行动。 我们看到问题，解决问题并分享我们的经验。 因此，给我们一个星号，它不会因您而减少，但会降临到我们这里，因为我们吃了它们。

第三个重要的，不再是重商的欲望- 停止相信童话 。 你是专业人士。 DevOps是一个非常认真负责的职业。 停止在工作场所玩。 让您单击，您将了解它。 想象一下，您将去医院，那里的医生将为您做实验。 我了解这可能会冒犯某人，但这很可能与您无关，而与其他人无关。 告诉其他人也停下来。 它确实破坏了我们所有人的生活-许多人开始与剥削，管理人员和DevOps有关，与与那些再次破坏某些东西的家伙有关。 这种情况最常被“破坏”，是因为我们去比赛了，而且看上去并没有那种冷酷的意识。

这并不意味着您不需要进行实验。 我们需要实验，我们自己做。 老实说，我们自己有时也会玩游戏-当然，这很糟糕，但是人类对我们来说并不陌生。 让我们宣布2019年为认真周到的实验之年，而不是正式推出的游戏。 大概是这样。

-非常感谢！

德米特里（Dmitry） ：Vitaly，谢谢您的宝贵时间和采访。 亲爱的读者，如果您突然到达这一点，非常感谢。 我希望至少我们能带给您一些想法。

在一次采访中，德米特里谈到了韦弗。 现在，它已成为瑞士通用刀具，几乎可以解决所有任务。 但这并非总是如此。 在RIT ++节上的DevOpsConf上，Dmitry Stolyarov将详细讨论此工具。 报告“ werf是我们在Kubernetes中用于CI / CD的工具”将包含一切：Kubernetes的问题和隐藏的细微差别，解决这些困难的方法以及werf当前的实施细节。 加入5月27日至28日，我们将创建理想的工具。