期待中 维塔利·哈巴罗夫 接受采访 德米特里·斯托利亚罗夫 (），Flant 公司技术总监兼联合创始人。 Vitaly 向 Dmitry 询问了 Flant 的业务、Kubernetes、生态系统开发和支持。 我们讨论了为什么需要 Kubernetes 以及是否需要它。 还有微服务、Amazon AWS、DevOps 的“我会很幸运”的方法、Kubernetes 本身的未来、它为何、何时以及如何接管世界、DevOps 的前景以及工程师在未来应该做好哪些准备。简化和神经网络的光明和不久的将来。
收听 DevOps Deflop 上的播客 - 关于 DevOps 的俄语播客，下面是文本版本。
他在这里和下面提出问题 Express42 的工程师。
关于“芙兰特”
- 你好迪玛。 你是技术总监””，也是它的创始人。 请告诉我们公司是做什么的以及你在里面做什么？
德米特里：从外面看，我们似乎是为每个人安装 Kubernetes 并用它做一些事情的人。 但事实并非如此。 我们最初是一家处理 Linux 的公司，但很长一段时间以来，我们的主要活动一直是为生产和高负载交钥匙项目提供服务。 通常我们从头开始构建整个基础设施，然后在很长一段时间内对其负责。 因此，“Flant”主要从事的、获得资金的工作是 承担责任，实施交钥匙生产.
我作为公司的技术总监和创始人之一，日以继夜地思考如何提高生产的可访问性，简化其操作，让管理员的生活更轻松，让开发人员的生活更愉快。
关于库伯内特斯
— 最近我看到了很多来自 Flant 和 关于 Kubernetes。 你是怎么想到的？
德米特里: 我已经说过很多次了，但我不介意重复一遍。 我认为重复这个话题是正确的，因为因果关系存在混淆。
我们确实需要一个工具。 我们遇到了很多问题，挣扎着，用各种拐杖克服了它们，并感到需要一种工具。 我们经历了许多不同的选择，建造了自己的自行车，并积累了经验。 渐渐地，我们几乎在 Docker 一出现的时候就开始使用它了——大约在 2013 年。 在它出现的时候，我们已经有了很多容器方面的经验，我们已经用 Python 编写了一个类似“Docker”的东西——我们自己的一些拐杖。 随着 Docker 的出现，人们可以扔掉拐杖，使用可靠且社区支持的解决方案。
Kubernetes 的情况也类似。 当它开始获得动力时——对我们来说这是 1.2 版本——我们已经在 Shell 和 Chef 上有了一堆拐杖，我们以某种方式尝试用 Docker 来协调它们。 我们认真地寻找 Rancher 和各种其他解决方案，但后来 Kubernetes 出现了，其中一切的实现都与我们完全一样，甚至更好。 没有什么可抱怨的。
是的，这里有某种不完美，那里有某种不完美 - 有很多不完美，1.2 一般都很糟糕，但是...... Kubernetes 就像一座正在建设中的建筑 - 你看看这个项目就明白了这会很酷。 如果建筑物现在有地基和两层楼，那么您明白最好不要搬进去，但该软件不存在此类问题 - 您已经可以使用它了。
我们没有考虑过要不要使用 Kubernetes。 在它出现之前我们就一直在等待它，并尝试自己创建类似物。
关于库伯内特斯
— 您直接参与了 Kubernetes 本身的开发吗？
德米特里: 平庸。 相反，我们参与生态系统的发展。 我们发送一定数量的拉取请求：发送给 Prometheus、发送给各个操作员、发送给 Helm - 发送给生态系统。 不幸的是，我无法跟踪我们所做的一切，我可能是错的，但我们没有一个池进入核心。
— 同时，您是否围绕 Kubernetes 开发了许多工具？
德米特里：策略是这样的：我们去向所有已经存在的东西拉取请求。 如果拉取请求在那里不被接受，我们只需自己分叉它们并生存，直到它们被我们的构建接受。 然后，当它到达上游时，我们回到上游版本。
例如，我们有一个 Prometheus 操作符，我们用它来回切换到程序集的上游可能已经有 5 次了。 我们需要某种功能，我们发送了拉取请求，我们需要明天推出它，但我们不想等待它在上游发布。 因此，我们为自己组装，将具有我们出于某种原因需要的功能的组装推出到我们的所有集群。 然后，例如，他们将其移交给上游的我们，并说：“伙计们，让我们来做一个更一般的情况”，我们或其他人完成它，随着时间的推移，它会再次合并回来。
我们尝试开发现有的一切。 许多还不存在、尚未发明、或者已经发明但还没有时间实现的元素——我们正在做。 并不是因为我们喜欢自行车制造这个行业，而是因为我们需要这个工具。 人们经常问这样的问题：我们为什么要做这件事或那件事？ 答案很简单 - 是的，因为我们必须走得更远，解决一些实际问题，我们用这个图拉解决了它。
路径总是这样的：我们非常仔细地搜索，如果我们找不到任何关于如何用一条面包制作无轨电车的解决方案，那么我们就制作我们自己的面包和我们自己的无轨电车。
弗兰达工具
— 我知道 Flant 现在有插件操作符、shell 操作符和 dapp/werf 工具。 据我了解，这是同一种乐器的不同化身。 我还了解到 Flaunt 中还有更多不同的工具。 这是真实的？
德米特里：我们在 GitHub 上还有更多内容。 据我所知，我们有一个状态图 - 每个人都遇到过的 Grafana 面板。 Medium 上几乎每两篇关于 Kubernetes 监控的文章都会提到它。 不可能简单地解释一下状态图是什么——它需要一篇单独的文章，但它对于监控一段时间内的状态非常有用，因为在 Kubernetes 中我们经常需要显示一段时间内的状态。 我们还有 LogHouse - 这是一个基于 ClickHouse 和黑魔法的东西，用于在 Kubernetes 中收集日志。
很多实用程序！ 而且还会更多，因为今年将会发布一些内部解决方案。 在基于插件操作符的非常大的插件中，有很多用于 Kubernetes 的插件，以及如何正确安装 sert manager - 一个用于管理证书的工具，如何使用一堆附件正确安装 Prometheus - 这些大约有二十种不同的插件导出数据和收集某些东西的二进制文件，普罗米修斯拥有最令人惊叹的图形和警报。 所有这一切只是 Kubernetes 的一堆插件，它们安装在集群中，它从简单变成了酷、复杂、自动化，其中许多问题已经得到解决。 是的，我们做了很多。
生态系统发展
“在我看来，这对这种仪器及其使用方法的发展做出了非常大的贡献。” 您能粗略估计一下还有谁会对生态系统的发展做出同样的贡献吗？
德米特里: 在俄罗斯，在我们市场上运营的公司中，没有一家可以与之相媲美。 当然，这是一个响亮的声明，因为有像 Mail 和 Yandex 这样的主要参与者 - 他们也在利用 Kubernetes 做一些事情，但即使他们也无法与全世界比我们做得更多的公司的贡献相提并论。 如果我没记错的话，很难将拥有 80 名员工的 Flant 和仅每个 Kubernetes 就有 300 名工程师的 Red Hat 进行比较。 很难比较。 我们研发部门有 6 个人，包括我在内，他们削减了我们所有的工具。 6 名红帽工程师与 300 名红帽工程师 - 这在某种程度上很难进行比较。
- 然而，当这 6 个人能够做一些真正有用且令人疏远的事情时，当他们面临实际问题并向社区提供解决方案时 - 一个有趣的案例。 据我了解，在大型科技公司中，他们有自己的 Kubernetes 开发和支持团队，原则上可以开发相同的工具。 对于他们来说，这是一个可以开发并提供给社区的示例，为使用 Kubernetes 的整个社区提供动力。
德米特里：这可能是积分器的一个特点，它的特殊性。 我们有很多项目，我们看到很多不同的情况。 对我们来说，创造附加值的主要方式是分析这些案例，找到共性并让它们尽可能便宜地为我们服务。 我们正在积极致力于此。 我很难谈论俄罗斯和世界，但我们公司有大约 40 名 DevOps 工程师从事 Kubernetes 工作。 我认为俄罗斯没有多少公司拥有同等数量的了解 Kubernetes 的专家（如果有的话）。
关于DevOps工程师这个职位我什么都懂，大家都懂，也习惯称DevOps工程师为DevOps工程师，这个我们就不讨论了。 所有这 40 位出色的 DevOps 工程师每天都会面临并解决问题，我们只是分析这些经验并尝试概括。 我们知道，如果它留在我们体内，那么在一两年内该工具将毫无用处，因为在社区的某个地方，一个现成的图拉将会出现。 在内部积累这些经验是没有意义的——它只是将精力和时间消耗到 dev/null 中。 我们对此一点也不感到遗憾。 我们非常高兴地发布一切，并且明白它需要发布、开发、推广、推广，以便人们使用它并添加他们的经验 - 然后一切都会生长和生存。 两年后，该仪器不会被扔进垃圾桶。 继续倾注力量并不可惜，因为很明显有人在使用你的工具，而且两年后每个人都在使用它。
这是我们 dapp/werf 大战略的一部分。 我不记得我们什么时候开始制作的，好像是三年前了。 最初，它通常位于外壳上。 这是一个超级概念证明，我们解决了一些特殊问题 - 它有效！ 但是shell有问题，不可能进一步扩展，在shell上编程是另一项任务。 我们有用 Ruby 编写的习惯，因此，我们用 Ruby 重新制作了一些东西，开发、开发、开发，然后遇到了这样一个事实：社区、人群不会说“我们想要它或我们不想要它， ” 对 Ruby 嗤之以鼻，这有多有趣？ 我们意识到我们应该用 Go 编写所有这些内容只是为了满足清单上的第一点： DevOps 工具应该是静态二进制文件。 是否成为 Go 并不那么重要，但用 Go 编写的静态二进制文件更好。
我们花费了精力，用 Go 重写了 dapp，并将其命名为 werf。 该 Dapp 不再受支持，不再开发，在某些最新版本中运行，但有一个绝对的升级路径，您可以遵循它。
为什么创建 dapp？
— 您能简单介绍一下为什么要创建这个 dapp，它解决了哪些问题吗？
德米特里: 第一个原因是在装配中。 最初，我们在构建时遇到了严重的问题，因为 Docker 不具备多阶段功能，因此我们自己做了多阶段。 然后我们在清理图像时遇到了更多问题。 每个做 CI/CD 的人迟早都会面临这样的问题：收集到的镜像有一堆，你需要以某种方式清理掉不需要的东西，留下需要的东西。
第二个原因是部署。 是的，有 Helm，但它只能解决部分问题。 有趣的是，它写道“Helm 是 Kubernetes 的包管理器”。 正是“那个”。 还有“包管理器”这个词——包管理器通常的期望是什么？ 我们说：“包管理器 - 安装包！” 我们希望他告诉我们：“包裹已送达。”
有趣的是，我们说：“Helm，安装这个包”，当他回答说他安装了它时，结果发现他刚刚开始安装——他向 Kubernetes 指示：“启动这个东西！”，以及它是否启动，不管有效与否，Helm根本就没有解决这个问题。
事实证明，Helm 只是一个将数据加载到 Kubernetes 中的文本预处理器。
但作为任何部署的一部分，我们想知道应用程序是否已发布用于生产？ 推出到生产环境意味着应用程序已移至那里，新版本已部署，并且至少不会在那里崩溃并正确响应。 Helm 没有以任何方式解决这个问题。 要解决这个问题，你需要花费大量的精力，因为你需要给 Kubernetes 下达命令来部署并监控那里发生的事情 - 无论是部署还是部署。 还有很多与部署、清理、组装相关的任务。
计划
今年我们将开始本地开发。 我们想要实现 Vagrant 之前的目标 - 我们输入“vagrant up”并部署虚拟机。 我们想要到达 Git 中有一个项目的地步，我们在那里写“werf up”，它会调出该项目的本地副本，部署在本地 mini-Kub 中，并连接所有方便开发的目录。 根据开发语言的不同，这样做的方式有所不同，但仍然可以在挂载的文件下方便地进行本地开发。
我们的下一步是 投资为开发商提供便利。 要使用一种工具在本地快速部署项目，开发它，将其推送到 Git，它还将根据管道进行阶段或测试，然后使用相同的工具投入生产。 这种从当地环境到销售的基础设施的统一性、统一性、可重复性对我们来说是非常重要的一点。 但这还没有在 werf 中实现——我们只是计划这样做。
但通往 dapp/werf 的道路始终与一开始的 Kubernetes 相同。 我们遇到了问题，用变通办法解决了它们——我们在 shell 上、任何事情上为自己想出了一些解决方案。 然后他们尝试以某种方式纠正这些解决方法，将它们概括并合并为二进制文件，我们只是分享。
还有另一种方式可以通过类比来看待整个故事。
Kubernetes 是一个带有引擎的车架。 没有门、玻璃、收音机、圣诞树——什么都没有。 只有车架和发动机。 还有 Helm——这是方向盘。 酷——有方向盘，但你还需要转向销、转向齿条、变速箱和车轮，而且你离不开它们。
就 werf 而言，这是 Kubernetes 的另一个组件。 只是现在在 werf 的 alpha 版本中，例如 Helm 是在 werf 内部编译的，因为我们厌倦了自己做。 这样做的原因有很多，我会详细告诉你为什么我们把整个helm和tiller一起编译在werf里面 .
现在 werf 是一个更加集成的组件。 我们得到了一个成品方向盘，一个转向销——我不太擅长汽车，但这是一个大块，已经解决了相当广泛的问题。 我们不需要自己浏览目录，为另一个零件选择一个零件，然后考虑如何将它们组合在一起。 我们得到了一个现成的联合收割机，可以一次性解决大量问题。 但它的内部是由相同的开源组件构建的，它仍然使用 Docker 进行组装，Helm 来实现某些功能，还有其他几个库。 这是一个集成工具，可以快速、方便地开箱即用，很酷的 CI/CD。
Kubernetes 难维护吗？
——你谈到了你开始使用 Kubernetes 的经历，这是你的一个框架，一个引擎，你可以在上面挂很多不同的东西：车身、方向盘、踏板上的螺丝、座椅。 问题出现了 - Kubernetes 对您的支持有多困难？ 您拥有丰富的经验，您花费了多少时间和资源来独立于其他一切来支持 Kubernetes？
德米特里：这是一个非常困难的问题，要回答，我们需要了解什么是支持以及我们希望从 Kubernetes 获得什么。 也许你可以透露一下？
——据我所知和所见，现在很多团队都想尝试 Kubernetes。 每个人都用它来约束自己，把它放在膝盖上。 我有一种感觉，人们并不总是理解这个系统的复杂性。
德米特里： 就像那样。
— 从头开始安装 Kubernetes 以使其做好生产准备有多困难？
德米特里：您认为心脏移植有多难？ 我明白这是一个妥协的问题。 使用手术刀并且不犯错误并不是那么困难。 如果他们告诉您在哪里切割和缝制，那么程序本身并不复杂。 很难一次又一次地保证一切都会顺利。
安装 Kubernetes 并让它运行起来很简单：小妞！ ——安装，安装方法有很多种。 但当问题出现时会发生什么？
问题总是出现——我们还没有考虑到什么？ 我们还没有做什么？ 哪些 Linux 内核参数指定不正确？ 主啊，我们有没有提到过他们？ 我们已经交付了哪些 Kubernetes 组件，哪些还没有交付？ 出现了成千上万的问题，要回答这些问题，你需要在这个行业花费 15 到 20 年的时间。
我最近有一个关于这个主题的例子，也许可以揭示“Kubernetes 难以维护吗？”这个问题的含义。 前段时间我们认真考虑是否应该尝试将 Cilium 实现为 Kubernetes 中的网络。
让我解释一下什么是Cilium。 Kubernetes 有许多不同的网络子系统实现，其中之一非常酷 - Cilium。 它的意义是什么？ 在内核中，不久前可以为内核编写钩子，它以一种或另一种方式侵入网络子系统和各种其他子系统，并允许您绕过内核中的大块。
Linux 内核历史上有一个 ip 路由、一个过度过滤器、网桥和许多已有 15、20、30 年历史的不同旧组件。 总的来说，他们工作正常，一切都很好，但现在他们堆起了集装箱，看起来就像一座由 15 块砖块叠在一起的塔，你单腿站在上面 - 一种奇怪的感觉。 这个系统在历史上有许多细微差别，就像体内的阑尾一样。 例如，在某些情况下会出现性能问题。
有一个很棒的 BPF 和为内核编写钩子的能力 - 这些人为内核编写了自己的钩子。 软件包进入 Linux 内核，他们在输入处将其取出，自行处理，无需桥接，无需 TCP，无需 IP 堆栈 - 简而言之，绕过 Linux 内核中编写的所有内容，然后吐出将其放入容器中。
发生了什么？ 非常酷的性能，很酷的功能 - 太酷了！ 但我们观察一下，发现每台机器上都有一个程序连接到 Kubernetes API，并根据从该 API 接收的数据生成 C 代码并编译二进制文件，然后加载到内核中，以便这些钩子起作用在内核空间中。
如果出现问题怎么办？ 我们不知道。 要理解这一点，您需要阅读所有这些代码，理解所有逻辑，令人惊讶的是它有多么困难。 但是，另一方面，还有这些网桥、网络过滤器、ip 路由——我没有读过它们的源代码，我们公司的 40 名工程师也没有读过它们的源代码。 也许只有少数人理解某些部分。
有什么区别呢？ 事实证明，有 ip rout、Linux 内核，还有一个新工具——它们有什么区别，我们不明白其中一个。 但我们害怕使用新的东西 - 为什么？ 因为如果这个工具已经使用了 30 年，那么在 30 年内，所有的 bug 都已被发现，所有的错误都已被踩过，你不需要知道一切 - 它就像一个黑匣子一样工作，并且始终有效。 每个人都知道哪个诊断螺丝刀应该插在哪个位置，哪个tcpdump 在什么时刻运行。 每个人都非常了解诊断实用程序，并且了解这组组件在 Linux 内核中的工作原理 - 不是它如何工作，而是如何使用它。
而且非常酷的 Cilium 还不到 30 岁，它还没有老化。 Kubernetes 也有同样的问题，复制。 Cilium 安装得很完美，Kubernetes 安装得很完美，但是当生产中出现问题时，你能在危急情况下快速了解出了什么问题吗？
当我们说维护 Kubernetes 很难时，不，它非常容易，是的，它非常困难。 Kubernetes 本身运行良好，但存在十亿个细微差别。
关于“我会幸运”的方法
— 有哪些公司几乎肯定会出现这些细微差别？ 假设Yandex突然将所有服务转移到Kubernetes上，那里会产生巨大的负载。
德米特里：不，这不是关于负载的对话，而是关于最简单的事情。 例如，我们有 Kubernetes，我们在那里部署了应用程序。 你怎么知道它有效？ 根本没有现成的工具可以了解应用程序是否崩溃。 没有现成的系统可以发送警报；您需要配置这些警报和每个计划。 我们正在更新 Kubernetes。
我有 Ubuntu 16.04。 你可以说这是一个旧版本，但我们仍在使用它，因为它是 LTS。 有 systemd，其细微差别在于它不会清理 C 组。 Kubernetes 启动 pod，创建 C 组，然后删除 pod，结果不知何故 - 我不记得细节了，抱歉 - systemd 切片仍然存在。 这导致随着时间的推移，任何汽车都开始大幅减速。 这甚至不是一个关于高负载的问题。 如果启动永久 pod，例如，如果有一个 Cron Job 不断生成 pod，那么安装 Ubuntu 16.04 的机器将在一周后开始变慢。 由于创建了一堆 C 组，因此平均负载会持续较高。 这是任何简单安装 Ubuntu 16 和 Kubernetes 的人都会面临的问题。
假设他以某种方式更新了 systemd 或其他东西，但在 4.16 之前的 Linux 内核中，情况甚至更有趣 - 当你删除 C 组时，它们会在内核中泄漏，并且实际上并没有被删除。 因此，在这台机器上工作一个月后，将无法查看炉灶的内存统计数据。 我们取出一个文件，在程序中滚动它，一个文件滚动了15秒，因为内核需要很长时间来计算其内部的一百万个C组，这些C组似乎被删除了，但没有——它们正在泄漏。
诸如此类的小事，到处还有很多。 这并不是大公司有时在非常重的负载下可能面临的问题——不，这是日常事务。 人们可以这样生活几个月——他们安装了 Kubernetes，部署了应用程序——这似乎有效。 对于许多人来说，这是正常的。 他们甚至不知道该应用程序会因某种原因崩溃，他们不会收到警报，但对他们来说这是常态。 以前，我们生活在没有监控的虚拟机上，现在我们搬到了 Kubernetes，同样没有监控——有什么区别？
问题是，当我们在冰上行走时，除非提前测量，否则我们永远不知道它的厚度。 很多人走路都不用担心，因为他们以前也走路过。
在我看来，操作任何系统的细微差别和复杂性都是为了确保冰的厚度恰好足以解决我们的问题。 这就是我们正在谈论的。
在我看来，在 IT 领域，有太多“我会幸运”的方法。 许多人安装软件并使用软件库是希望自己能幸运。 总的来说，很多人都是幸运的。 这可能就是它起作用的原因。
— 从我的悲观评估来看，它看起来是这样的：当风险很高，并且应用程序必须工作时，那么需要 Flaunt 的支持，也许来自 Red Hat，或者你需要自己的专门针对 Kubernetes 的内部团队，这些团队已经准备好了来完成它。
德米特里: 客观来说是这样的。 独自进入小团队的 Kubernetes 故事涉及许多风险。
我们需要容器吗？
— 您能告诉我们 Kubernetes 在俄罗斯的普及程度吗？
德米特里: 我没有这个数据，也不知道其他人有没有。 我们说：“Kubernetes，Kubernetes”，但还有另一种看待这个问题的方式。 我也不知道容器的普及程度如何，但我从网上的报道中知道一个数字，70%的容器是由 Kubernetes 编排的。 它是世界各地相当大样本的可靠来源。
那么另一个问题——我们需要容器吗？ 我个人的感觉以及Flant公司的整体立场是，Kubernetes是事实上的标准。
除了 Kubernetes 之外什么都没有。
这绝对是基础设施管理领域的游戏规则改变者。 绝对的 - 就是这样，不再有 Ansible、Chef、虚拟机、Terraform。 我不是在谈论旧的集体农庄方法。 Kubernetes 是一个绝对的改变者，现在也只能这样了。
显然，对于某些人来说需要几年的时间，而对于其他人来说需要几十年的时间才能意识到这一点。 我毫不怀疑，除了 Kubernetes 和这个新面貌之外，什么也没有：我们不再破坏操作系统，而是使用 基础设施即代码，只是不是用代码，而是用 yml - 一种声明式描述的基础设施。 我有一种感觉，永远都会这样。
——也就是说，那些还没有转向 Kubernetes 的公司肯定会转向它，或者被遗忘。 我理解你的意思正确吗？
德米特里: 这也不完全正确。 例如，如果我们有运行一个DNS服务器的任务，那么它可以运行在FreeBSD 4.10上，并且可以完美工作20年。 只要工作就够了。 也许20年后有些东西需要更新一次。 如果我们谈论的是我们推出的格式的软件，并且它实际上可以运行很多年而没有任何更新，没有进行任何更改，那么当然就不会有 Kubernetes。 那里不需要他。
与 CI/CD 相关的一切——无论哪里需要持续交付，哪里需要更新版本，进行主动更改，哪里需要构建容错能力——只有 Kubernetes。
关于微服务
- 在这里我有一点不和谐。 要使用 Kubernetes，您需要外部或内部支持 - 这是第一点。 其次，当我们刚刚开始开发时，我们是一家小型初创公司，我们还什么都没有，Kubernetes 或微服务架构的开发通常可能很复杂，而且在经济上并不总是合理的。 我对你的观点很感兴趣——初创公司是否需要立即从头开始为 Kubernetes 编写，或者他们仍然可以编写一个整体，然后只转向 Kubernetes？
德米特里: 很酷的问题。 我有一个关于微服务的演讲 我多次遇到有人试图用显微镜钉钉子。 这种方法本身是正确的；我们自己就是这样设计我们的内部软件的。 但当你这样做的时候，你需要清楚地了解你在做什么。 关于微服务，我最讨厌的词是“微”。 从历史上看，这个词起源于那里，出于某种原因，人们认为微非常小，不到一毫米，就像微米一样。 这是错误的。
例如，有一个由 300 人编写的巨石，每个参与开发的人都知道那里存在问题，应该将其分解为微块 - 大约 10 个块，每个块由 30 人编写在最低版本中。 这很重要、必要而且很酷。 但是，当我们遇到一家初创公司时，每次我都会寻找 Corvalol，其中 3 个非常酷且有才华的人跪下编写了 60 个微服务。
在我看来，这已经被讨论了数千次——我们得到了一种或另一种形式的分布式整体。 这在经济上是不合理的，总的来说，一切都很困难。 我已经看到很多次了，这真的让我很受伤，所以我继续谈论它。
对于最初的问题，以下事实之间存在冲突：一方面，Kubernetes 使用起来很可怕，因为不清楚什么可能会在那里崩溃或不起作用，另一方面，很明显一切都在那里除了 Kubernetes 之外，什么都不会存在。 回答 - 权衡带来的好处，你可以解决的任务量。 这是天平的一侧。 另一方面，存在与停机或响应时间减少、可用性水平下降（性能指标下降）相关的风险。
就是这样——要么我们行动迅速，Kubernetes 使我们能够更快更好地完成许多事情，要么我们使用可靠的、经过时间考验的解决方案，但行动要慢得多。 这是每个企业都必须做出的选择。 你可以把它想象成丛林中的一条小路——当你第一次行走时，你可能会遇到一条蛇、一只老虎或一只疯狂的獾，当你走了10次时，你就已经走过了这条路，远离了树枝和行走更容易。 每一次，路都变得更宽。 然后是柏油路，再后来是美丽的林荫大道。
Kubernetes 并没有停滞不前。 再次提问：Kubernetes，一方面是4-5个二进制文件，另一方面，它是整个生态系统。 这是我们机器上的操作系统。 这是什么？ Ubuntu 还是 Curios？ 这是 Linux 内核，一堆附加组件。 这里发生了所有这些事情，一条毒蛇被扔到了路上，那里竖起了栅栏。 Kubernetes 正在快速、动态地发展，风险量、未知量每个月都在减少，因此，这些规模正在重新平衡。
在回答初创公司应该做什么的问题时，我会说 - 来到 Flaunt，支付 150 万卢布并获得交钥匙 DevOps 轻松服务。 如果您是一家拥有少数开发人员的小型初创公司，那么这很有效。 您将获得解决所有问题的交钥匙解决方案，而不是雇用自己的 DevOps（他们此时需要学习如何解决您的问题并支付薪水）。 是的，有一些缺点。 我们作为外包商，不可能如此投入并快速响应变化。 但我们有很多专业知识和现成的实践。 我们保证在任何情况下我们一定会很快弄清楚并让任何 Kubernetes 起死回生。
我强烈建议外包给初创公司和成熟企业，其规模可以让您专门组建 10 人的团队来运营，否则就没有意义。 将其外包绝对是有意义的。
关于亚马逊和谷歌
— 来自 Amazon 或 Google 的解决方案的主机是否可以被视为外包？
德米特里: 是的，当然，这解决了很多问题。 但同样存在细微差别。 您仍然需要了解如何使用它。 例如，亚马逊AWS的工作中有一千件小事：负载均衡器需要预热或者必须提前写一个请求“伙计们，我们将收到流量，为我们预热负载均衡器！” 您需要了解这些细微差别。
当你求助于专门从事这方面工作的人时，你几乎可以解决所有典型的问题。 我们现在有 40 名工程师，到今年年底可能会达到 60 名 - 我们肯定遇到过所有这些事情。 即使我们在某个项目中再次遇到这个问题，我们也会很快互相询问并知道如何解决。
也许答案是——当然，托管故事会让某些部分变得更容易。 问题是您是否准备好信任这些托管服务商以及他们是否会解决您的问题。 亚马逊和谷歌做得很好。 对于我们所有的情况 - 完全正确。 我们没有更多积极的经历。 我们尝试使用的所有其他云都会产生很多问题 - Ager，以及俄罗斯的所有云，以及不同实现中的各种 OpenStack：Headster、Overage - 无论你想要什么。 它们都会造成你不想解决的问题。
因此，答案是肯定的，但事实上，成熟的托管解决方案并不多。
谁需要 Kubernetes？
— 然而，谁需要 Kubernetes？ 谁应该已经转向 Kubernetes，谁是专门针对 Kubernetes 的典型 Flaunt 客户端？
德米特里：这是一个有趣的问题，因为现在，随着 Kubernetes 的出现，很多人来找我们：“伙计们，我们知道你们在做 Kubernetes，为我们做吧！” 我们回答他们：“先生们，我们不做 Kubernetes，我们做产品以及与之相关的一切。” 因为目前如果不完成所有 CI/CD 和整个故事就不可能制造出产品。 每个人都摆脱了这样的划分：我们先发展再发展，然后再剥削。
我们的客户期望不同的事情，但每个人都在等待他们遇到某些问题的奇迹，现在 - 跳！ — Kubernetes 将解决这些问题。 人们相信奇迹。 在他们的心中，他们明白不会有奇迹，但在他们的灵魂中，他们希望 - 如果这个 Kubernetes 现在能为我们解决一切，那会怎样，他们对此谈论得太多了！ 突然他现在——打喷嚏！ - 还有一个灵丹妙药，打喷嚏！ - 我们拥有 100% 的正常运行时间，所有开发人员都可以将任何进入生产环境的内容发布 50 次，而且不会崩溃。 总的来说，这是一个奇迹！
当这样的人来找我们时，我们会说：“抱歉，奇迹是不存在的。” 为了保持健康，您需要良好的饮食和锻炼。 要拥有可靠的产品，就需要可靠地制造它。 为了有一个方便的 CI/CD，你需要把它做成这样。 这需要做很多工作。
回答谁需要 Kubernetes 的问题——没有人需要 Kubernetes。
有些人错误地认为他们需要 Kubernetes。 人们需要，他们迫切需要停止思考、研究和对所有基础设施问题和运行应用程序的问题感兴趣。 他们希望应用程序能够正常运行和部署。 对于他们来说，Kubernetes 希望他们不再听到“我们躺在那里”或“我们无法推出”或其他什么的故事。
技术总监通常会来找我们。 他们问他两件事：一方面，给我们功能，另一方面，稳定性。 我们建议你自己承担并去做。 灵丹妙药，或者更确切地说是镀银的，是你将不再思考这些问题并浪费时间。 您将有专门的人员来关闭此问题。
我们或任何其他人需要 Kubernetes 的说法是不正确的。
管理员确实需要 Kubernetes，因为它是一个非常有趣的玩具，您可以玩耍和修补。 说实话——每个人都喜欢玩具。 我们都是某个地方的孩子，当我们看到新的东西时，我们就想玩它。 对于一些人来说，这在政府中是不被鼓励的，因为他们已经玩够了，并且已经累到了他们根本不想玩的程度。 但这并不是任何人都完全失去的。 例如，如果我已经厌倦了系统管理和DevOps领域的玩具很长一段时间，那么我仍然喜欢这些玩具，我仍然会买一些新的。 所有人，无论怎样，仍然想要某种玩具。
无需玩弄制作。 无论我明确建议不要做什么，以及我现在看到的一切：“哦，一个新玩具！” ——他们跑去买，买了然后说：“我们现在把它带到学校，给我们所有的朋友看。” 不要那样做。 我很抱歉，我的孩子刚刚长大，我经常在孩子身上看到一些东西，在自己身上注意到它，然后将其推广给其他人。
最终的答案是：你不需要 Kubernetes。 你需要解决你的问题。
您可以实现的目标是：
- 刺棒不掉落；
- 即使他想摔倒，我们也能提前知道，并且可以在里面放一些东西；
- 我们可以按照业务需要的速度进行更改，并且可以方便地进行更改，不会给我们带来任何问题。
有两个真正的需求：可靠性和推出的活力/灵活性。 目前正在做某种IT项目的每个人，无论从事何种业务——缓世软体，谁明白这一点，就需要解决这些需求。 Kubernetes 通过正确的方法、正确的理解和足够的经验可以让您解决这些问题。
关于无服务器
— 如果你把目光放得更远一些，那么试图解决基础设施不存在令人头疼的问题，随着部署的速度和应用程序更改的速度，新的解决方案就会出现，例如无服务器。 您是否觉得这个方向有任何潜力，或者说，对 Kubernetes 和类似解决方案是否存在危险？
德米特里：这里需要再次声明，我不是一个预言家，会展望未来并说——事情会是这样的！ 虽然我只是做了同样的事情。 我看着我的脚，发现那里有很多问题，例如晶体管如何在计算机中工作。 很有趣，对吧？ 我们在 CPU 中遇到了一些错误。
让无服务器变得可靠、廉价、高效和方便，解决所有生态系统问题。 在这里，我同意埃隆·马斯克的观点，即需要第二颗行星来为人类创造容错能力。 虽然我不知道他在说什么，但我知道我还没有准备好亲自飞往火星，而且明天也不会发生。
对于无服务器来说，很明显这是一件意识形态上正确的事情，就像人类的容错能力一样——拥有两个行星比一个更好。 但现在该怎么办呢？ 如果你集中精力的话，派出一支探险队不是问题。 派几次探险队，安置几千人，我想也是现实的。 但要让它完全容错，让一半的人类生活在那里，在我看来现在是不可能的，不被考虑。
一对一的无服务器：这件事很酷，但距离 2019 年的问题还很远。 距离 2030 年越来越近——让我们拭目以待吧。 我毫不怀疑我们会活下去，我们一定会活下去（睡前重复一遍），但现在我们需要解决其他问题。 这就像相信童话里的小马彩虹一样。 是的，有百分之几的案例得到了解决，而且解决得很完美，但主观上来说，Serverless 就是彩虹……对于我来说，这个话题太遥远了，太难以理解了。 我还没准备好说话。 2019 年，你无法用 Serverless 编写单个应用程序。
Kubernetes 将如何发展
— 当我们迈向这个可能美好的遥远未来时，您认为 Kubernetes 及其周围的生态系统将如何发展？
德米特里: 这个问题我想了很多，也有一个明确的答案。 第一个是有状态的——毕竟无状态更容易做到。 Kubernetes 最初在这方面投入了更多，这一切都是从它开始的。 无状态在 Kubernetes 中几乎可以完美运行，没有什么可抱怨的。 仍然存在很多问题，或者更确切地说，存在细微差别。 那里的一切都对我们来说已经很有效，但那就是我们。 至少还需要几年时间才能让每个人都受益。 这不是一个计算出来的指标，而是我头脑中的感觉。
简而言之，有状态的应用程序应该而且将会发展得非常强劲，因为我们所有的应用程序都存储状态；没有无状态的应用程序。 这是一种幻觉；你总是需要某种数据库和其他东西。 Statefull 是为了理顺所有可能的事情，修复所有错误，改善当前面临的所有问题 - 让我们称之为采用。
未知的程度、未解决的问题的程度、遇到某事的概率程度都会显着下降。 这是一个重要的故事。 和操作员 - 与管理逻辑、控制逻辑的编码相关的所有内容，以便获得简单的服务：MySQL 简单服务、RabbitMQ 简单服务、Memcache 简单服务 - 一般来说，我们需要保证所有这些组件都能正常工作盒子。 这正好解决了我们想要一个数据库，但我们不想管理它，或者我们想要 Kubernetes，但我们不想管理它的痛苦。
这种或另一种形式的运营商发展故事将在未来几年中发挥重要作用。
我认为易用性应该大大增加——盒子会变得越来越黑，越来越可靠，旋钮越来越简单。
我曾经在 YouTube 的《周六夜现场》上听过一段 80 年代艾萨克·阿西莫夫的老采访——一个像《Urgant》这样的节目，只是很有趣。 他们向他询问计算机的未来。 他说，未来就是简单，就像收音机一样。 无线电接收器原本是一个复杂的东西。 为了捕捉电波，你必须转动旋钮 15 分钟，转动串杆，并且大致了解一切是如何工作的，了解无线电波传输的物理原理。 结果，收音机就只剩下一个旋钮了。
现在2019年有什么电台？ 在车里，无线电接收器找到所有的电波和电台名称。 一百年来，该过程的物理原理没有改变，但易用性却发生了变化。 现在，不仅是现在，早在 100 年，当阿齐莫夫接受采访时，每个人都使用收音机，但没有人考虑它是如何工作的。 它总是有效的——这是理所当然的。
阿齐莫夫随后表示，计算机也是如此—— 易用性将会提高。 1980 年，您必须接受如何按下计算机上的按钮的培训，但未来情况将不再如此。
我有一种感觉，有了 Kubernetes 和基础设施，易用性也会大大提高。 在我看来，这是显而易见的——它就在表面上。
工程师该怎么办？
— 那么支持 Kubernetes 的工程师和系统管理员会发生什么？
德米特里：1C出现后，会计师怎么样了？ 差不多。 在此之前，他们依靠的是纸质材料——现在是在程序中。 劳动生产率提高了几个数量级，但劳动本身并没有消失。 如果以前需要 10 名工程师才能拧紧一个灯泡，现在只需 XNUMX 名工程师就足够了。
在我看来，软件数量和任务数量现在的增长速度比新的 DevOps 出现的速度还要快，而且效率也在提高。 目前市场存在一定的短缺，而且这种短缺将持续很长时间。 后来，一切都会恢复到某种常态，工作效率会提高，Serverless 会越来越多，一个神经元会附加到 Kubernetes 上，它会根据需要准确地选择所有资源，一般来说会一切事情都应该自己做——那个人只是走开，不要干涉。
但仍然需要有人做出决定。 显然，此人的资质和专业水平更高。 如今，在会计部门，你不需要10名员工记账，这样他们的手就不会累。 这根本没有必要。 许多文档由电子文档管理系统自动扫描和识别。 一位聪明的总会计师就足够了，他已经具备了更高的技能和良好的理解力。
一般来说，这是所有行业都要走的路。 汽车也是如此：以前，一辆车配备一名机械师和三名司机。 如今，驾驶汽车是一个我们每天都参与的简单过程。 没有人认为汽车是复杂的东西。
DevOps 或系统工程不会消失——高水平的工作和效率将会提高。
— 我还听到一个有趣的想法，工作实际上会增加。
德米特里: 当然，百分之一百！ 因为我们编写的软件数量在不断增长。 我们用软件解决的问题数量不断增加。 工作量越来越大。 现在 DevOps 市场严重过热。 这可以从薪资预期中看出。 从好的角度来说，不讲细节，应该有初级想要X，中级想要1,5X，高级想要2X。 现在，如果你看看莫斯科 DevOps 薪资市场，初级员工想要的薪资是 X 到 3 倍，高级员工想要的薪资是 X 到 3 倍。
没有人知道它要花多少钱。 工资水平是由你的信心来衡量的——老实说，这是一个完全疯人院，一个极度过热的市场。
当然，这种情况很快就会改变——应该会出现一定程度的饱和。 软件开发的情况并非如此——尽管每个人都需要开发人员，每个人都需要优秀的开发人员，但市场知道谁值多少钱——这个行业已经稳定下来。 如今 DevOps 的情况并非如此。
——从我听到的情况来看，我的结论是，现在的系统管理员不必太担心，但是时候提升自己的技能了，并为明天的工作量会更多，但资质会更高这一事实做好准备。
德米特里: 百分之一百。 总的来说，我们生活在2019年，生活的规则是这样的： 终身学习——我们一生都在学习。 在我看来，现在每个人都已经知道并感受到了这一点，但仅仅知道还不够——你必须这样做。 每一天我们都必须改变。 如果我们不这样做，那么我们迟早会被边缘化。
做好 180 度急转弯的准备。 我不排除某些事情发生根本性变化、新事物被发明的情况——它会发生。 跳！ - 我们现在的行为有所不同。 重要的是要为此做好准备并且不要担心。 也许明天我所做的一切都会变得不必要——没什么，我已经研究了一辈子，并准备好学习其他东西。 这不是一个问题。 没有必要害怕工作保障，但你需要做好不断学习新东西的准备。
愿望和一分钟广告
- 你有什么愿望吗？
德米特里: 是的，我有几个愿望。
第一和商业 - 订阅 。 亲爱的读者，请访问 YouTube 并订阅我们的频道。 大约一个月后，我们将开始积极拓展视频服务，我们将有很多关于 Kubernetes 的教育内容，开放且多样：从实用的东西，一直到实验室，再到深入的基础理论以及如何在现场使用 Kubernetes。原则和模式的水平。
第二个商业愿望——去 并放上星星，因为我们以它们为食。 如果你不给我们星星，我们就没有东西吃。 这就像电脑游戏中的法力。 我们做了一些事情，我们做了，我们尝试，有人说这些自行车很糟糕，有人说一切都是完全错误的，但我们继续并绝对诚实地行事。 我们发现问题、解决问题并分享我们的经验。 因此，给我们一颗星星，它不会离开你，而是会来到我们身边，因为我们以它们为食。
第三，重要的、不再是商业性的愿望—— 别再相信童话故事。 你们是专业人士。 DevOps是一个非常认真负责的职业。 别再在工作场所玩了。 让它为你点击，你就会明白它。 想象一下，您来到医院，医生正在对您进行实验。 我知道这可能会冒犯某人，但很可能这不是关于您，而是关于其他人。 告诉其他人也停下来。 这确实毁了我们所有人的生活——许多人开始将运维、管理员和 DevOps 视为再次破坏某些东西的家伙。 这被“打破”的最常见原因是我们去玩，并没有冷漠地意识到事情就是这样，事情就是这样。
这并不意味着您不应该进行实验。 我们需要尝试，我们自己做。 老实说，我们自己有时也会玩游戏——这当然是非常糟糕的，但人类对我们来说并不陌生。 让我们宣布 2019 年是认真、深思熟虑的实验的一年，而不是制作游戏的一年。 大概是这样。
- 非常感谢！
德米特里：谢谢 Vitaly 抽出时间接受我们的采访。 亲爱的读者，如果您突然想到这里，非常感谢您。 我希望我们至少能给您带来一些想法。
在采访中，德米特里谈到了werf的问题。 现在，这是一把通用瑞士刀，可以解决几乎所有问题。 但情况并非总是如此。 在 在节日里 Dmitry Stolyarov 将向您详细介绍这个工具。 在报告中 将会有一切：Kubernetes 的问题和隐藏的细微差别、解决这些困难的选项以及 werf 当前的详细实现。 27月28日至XNUMX日加入我们，我们将创造完美的工具。
来源： habr.com