五月底 召开了该主题的在线会议 。 我们原则上讨论了容器、Kubernetes 和编排、选择基础设施的标准等等。 与会者分享了自己的实践案例。
成员：
- Evgeniy Potapov，ITSumma 首席执行官。 超过一半的客户已经转向或希望转向 Kubernetes。
- Dmitry Stolyarov，“Flant”首席技术官。 拥有 10 多年容器系统工作经验。
- Denis Remchukov（又名 Eric Oldmann），argotech.io 首席运营官，前 RAO UES 成员。 他承诺将谈论“血腥”企业中的案例。
- 安德烈·费多罗夫斯基 (Andrey Fedorovsky)，“News360.com”首席技术官在被另一位玩家收购该公司后，他负责许多 ML 和 AI 项目和基础设施。
- Ivan Kruglov，系统工程师，前 Booking.com。同一个人亲手用 Kubernetes 做了很多事情。
主题：
- 参与者对容器和编排（Docker、Kubernetes等）的见解； 在实践中尝试过或分析过什么。
- 案例：该公司多年来一直在制定基础设施发展计划。 如何决定是否构建（或迁移当前）基础设施到容器和 Kuber？
- 云原生世界的问题，缺少什么，让我们想象一下明天会发生什么。
接下来是一场有趣的讨论，与会者的意见各不相同，引起了很多评论，我想和大家分享一下。 吃 ，下面是讨论的摘要。
Kubernetes 已经成为标准还是伟大的营销？
“我们在还没有人知道的时候就开始研究它（Kubernetes。-编者）。 即使他不在，我们也来找他。 我们之前就想要它”- 德米特里·斯托利亚罗夫
照片来自 Reddit.com
5-10 年前，工具数量巨大，而且没有统一的标准。 每六个月就会出现一种新产品，甚至不止一种。 首先是 Vagrant，然后是 Salt、Chef、Puppet……“然后每六个月重建一次基础设施。 您有五名管理员，他们经常忙于重写配置，”Andrey Fedorovsky 回忆道。 他认为 Docker 和 Kubernetes 已经“排挤”了其余的。 Docker 在过去五年成为了标准，Kubernetes 在过去两年成为了标准。 这对这个行业来说是件好事。.
德米特里·斯托利亚罗夫 (Dmitry Stolyarov) 和他的团队非常喜欢库伯。 在这样的工具出现之前，他们就想要它，并且在无人知晓的情况下才找到它。 目前，出于方便的原因，如果他们知道不会与客户一起实施 Kubernetes，他们就不会接受该客户。 与此同时，德米特里表示，该公司有“许多关于重塑可怕遗产的巨大成功故事”。
Kubernetes 不仅仅是容器编排，它还是一个配置管理系统，具有开发的 API、网络组件、L3 平衡和入口控制器，这使得管理资源、扩展和从基础设施的较低层进行抽象变得相对容易。
不幸的是，在我们的生活中，我们必须为一切付出代价。 正如 Ivan Kruglov 认为的那样，这笔税收很大，尤其是当我们谈论一家拥有发达基础设施的公司向 Kubernetes 过渡时。 他可以自由地在拥有传统基础设施的公司和 Kuber 工作。 主要是了解公司和市场的特点。 但是，对于 Evgeny Potapov 来说，他将 Kubernetes 推广到任何容器编排工具，这样的问题就不会出现。
Evgeniy 与 1990 世纪 XNUMX 年代的情况进行了类比，当时面向对象编程作为一种复杂应用程序编程方式出现。 当时，争论仍在继续，并且出现了支持 OOP 的新工具。 然后，微服务作为摆脱单一概念的一种方式出现。 这反过来又导致了容器和容器管理工具的出现。 他相信：“我认为我们很快就会迎来这样一个时刻：是否值得编写小型微服务应用程序将毫无疑问，默认情况下它将被编写为微服务。” 同样，Docker 和 Kubernetes 最终将成为标准解决方案，无需选择。
无状态数据库的问题
照片由
如今，在 Kubernetes 中运行数据库的方法有很多。 甚至如何有条件地将与 I/O 磁盘一起工作的部分与数据库的应用程序部分分开。 未来数据库有没有可能会发生很大的变化，以至于它们将被装在一个盒子里交付，其中一部分将通过Docker和Kubernetes来编排，而在基础设施的另一部分中，将通过单独的软件提供存储部分？ 作为产品，底座会发生变化吗？
这种描述与队列管理类似，但对传统数据库中信息的可靠性和同步性的要求要高得多，Andrey 认为。 普通数据库的缓存命中率保持在99%。 如果一个工作线程宕机，就会启动一个新的工作线程，并且缓存会从头开始“预热”。 在缓存预热之前，工作线程工作缓慢，这意味着它无法加载用户负载。 当没有用户负载时，缓存不会预热。 这是一个恶性循环。
德米特里从根本上不同意——法定人数和分片解决了问题。 但安德烈坚持认为，该解决方案并不适合所有人。 在某些情况下，仲裁是合适的，但它会给网络带来额外的负载。 NoSQL 数据库并不适合所有情况。
聚会参与者分为两个阵营。
Denis 和 Andrey 认为，写入磁盘的所有操作（数据库等）在当前的 Kuber 生态系统中都是不可能完成的。 在 Kubernetes 中无法保持生产数据的完整性和一致性。 这是一个基本特征。 解决方案：混合基础设施。
即使是像 MongoDB 和 Cassandra 这样的现代云原生数据库，或者像 Kafka 或 RabbitMQ 这样的消息队列，也需要 Kubernetes 之外的持久数据存储。
Evgeniy 反对道：“库贝拉的基地是一个近乎俄罗斯或近乎企业的伤害，这与俄罗斯没有采用云技术有关。” 西方的中小型公司都是云。 Amazon RDS 数据库比自己修改 Kubernetes 更容易使用。 在俄罗斯，他们在“本地”使用 Kuber，并在试图摆脱动物园时将基地转移到它。
Dmitry 也不同意 Kubernetes 中不能保留任何数据库的说法：“Base 与 Base 不同。 如果你推送一个巨大的关系数据库，那么在任何情况下都不会。 如果你推动一些小的、云原生的东西，为半短暂的生活做好心理准备，一切都会好起来的。” Dmitry 还提到，数据库管理工具还没有为 Docker 或 Kuber 做好准备，因此出现了很大的困难。
反过来，Ivan 确信，即使我们从有状态和无状态的概念中抽象出来，Kubernetes 中的企业解决方案生态系统还没有准备好。 对于 Kuber，很难维持立法和监管要求。 例如，不可能制定需要严格的服务器身份保证（甚至包括插入服务器的硬件）的身份提供解决方案。 这个领域正在发展，但还没有解决方案。
与会者无法达成一致，因此本部分不得出任何结论。 让我们举几个实际的例子。
案例 1. 基地位于库贝拉以外的“大型监管机构”的网络安全
对于成熟的网络安全系统，容器和编排的使用使得抵御攻击和入侵成为可能。 例如，在一个大型监管机构中，Denis 和他的团队将协调器与训练有素的 SIEM 服务相结合，实时分析日志并确定攻击、黑客攻击或故障的过程。 如果发生攻击、试图放置某些东西，或者发生勒索软件病毒入侵，它会通过协调器以比被感染或攻击者攻击它们的速度更快的速度拾取包含应用程序的容器。
案例2. Booking.com数据库部分迁移至Kubernetes
在Booking.com中，主数据库是具有异步复制功能的MySQL——有一个主数据库和一个完整的从数据库层次结构。 当伊万离开公司时，启动了一个转移奴隶的项目，这些奴隶可能会被“枪杀”并造成一定的伤害。
除了主基地之外，还有一个带有自写编排的Cassandra安装，这是在Kuber进入主流之前就编写的。 这方面没有问题，但在本地SSD上却是持久的。 由于高延迟问题，即使在同一数据中心内，也不会使用远程存储。
第三类数据库是Booking.com搜索服务，其中每个服务节点都是一个数据库。 尝试将搜索服务转移到Kuber失败了，因为每个节点都有60-80GB的本地存储，很难“提升”和“预热”。
结果，搜索引擎并没有转移到 Kubernetes，Ivan 认为近期不会有新的尝试。 MySQL数据库被转移了一半：只有Slave，它们不怕被“枪杀”。 卡桑德拉已经完美地适应了。
基础设施选择是一项没有通用解决方案的任务
照片由
假设我们有一家新公司，或者一家部分基础设施是按照旧方式构建的公司。 它制定了多年的基础设施发展计划。 如何决定是否在容器和 Kuber 上构建基础设施？
争取纳秒的公司被排除在讨论之外。 健康的保守主义在可靠性方面得到了回报，但仍然有一些公司应该考虑新的方法。
Ivan：“我现在肯定会在云上创办一家公司，只是因为它更快，”尽管不一定更便宜。 随着风险投资主义的发展，初创企业在资金上已经没有什么大问题了，主要任务是征服市场。
伊万认为 当前基础设施的发展是一个选择标准。 如果过去进行过重大投资并且有效，那么就没有必要重做。 如果基础设施尚未开发，并且工具、安全和监控存在问题，那么考虑分布式基础设施是有意义的。
税是无论如何都得交的，而伊万会交那些让他以后少交的税。 ”因为仅仅因为我乘坐的是别人正在运行的火车，我就会比乘坐另一辆我必须自己加油的火车走得更远。“伊万说。 当公司是新成立的，延迟要求是几十毫秒时，Ivan就会把目光投向今天“包装”经典数据库的“运营商”。 他们提出了一个复制链，该复制链会在发生故障转移等情况下自行切换......
对于拥有几台服务器的小公司来说，Kubera 毫无意义，”Andrey 说。 但如果它计划增长到数百台服务器或更多，那么它就需要自动化和资源管理系统。 90%的情况都是值得的。 而且，无论负载和资源水平如何。 对于每个人来说，从初创公司到拥有数百万受众的大公司，逐渐关注容器编排产品都是有意义的。 “是的，这确实是未来，”安德烈确信。
丹尼斯概述了两个主要标准 - 可扩展性和运行稳定性。 他将选择最适合该任务的工具。 “它可能是一个组装在你膝盖上的无名产品，上面有 Nutanix 社区版。 这可以是 Kuber 上应用程序形式的第二行，后端有一个数据库，该数据库被复制并指定了 RTO 和 RPO 参数”（恢复时间/点目标 - 约).
叶夫根尼发现了人员方面可能存在的问题。 目前，市场上懂“胆”的高素质专家并不多。 确实，如果所选择的技术是陈旧的，那么除了对生活感到无聊和厌倦的中年人之外，很难雇用任何人。 尽管其他与会者认为这是人员培训的问题。
如果我们提出选择的问题：在公共云中启动一家使用 Amazon RDS 数据库的小公司，或者在“本地”使用 Kubernetes 数据库的小公司，那么尽管存在一些缺点，Amazon RDS 成为了参与者的选择。
既然大多数聚会听众都不是来自“血腥”企业，那么 分布式解决方案是我们应该努力的方向。 数据存储系统必须是分布式的、可靠的，并且产生以毫秒为单位（最多数十毫秒）的延迟“，安德烈总结道。
评估 Kubernetes 使用情况
听众 Anton Zhbankov 向 Kubernetes 的辩护者提出了一个陷阱问题：你们是如何选择并进行可行性研究的？ 例如，为什么选择 Kubernetes，为什么不选择虚拟机？
照片由
德米特里和伊万回答了。 在这两种情况下，通过反复试验，做出了一系列决定，最终参与者都来到了 Kubernetes。 现在，企业开始独立开发适合转移到 Kuber 的软件。 我们不是在谈论经典的第三方系统，例如1C。 当开发人员需要快速发布版本并进行不间断的持续改进时，Kubernetes 会提供帮助。
Andrey 的团队尝试创建一个基于虚拟机的可扩展集群。 节点像多米诺骨牌一样倒下，有时会导致集群崩溃。 “理论上，你可以完成它并用手支撑它，但这很乏味。 如果市场上有一种解决方案可以让您开箱即用，那么我们很乐意采用。 结果我们就换了，”安德烈说。
这种分析和计算是有标准的，但没有人能说它们在实际运行的硬件上有多准确。 对于计算来说，了解每个工具和生态系统也很重要，但这是不可能的。
等待我们的是什么
照片由
随着技术的发展，越来越多的不同部件出现，然后发生相变，出现了一个供应商，他已经赚到了足够的钱，可以将所有东西整合到一个工具中。
您认为 Linux 世界会出现像 Ubuntu 这样的工具吗？ 也许单个容器化和编排工具将包括 Kuber。 这将使构建本地云变得容易。
Ivan 给出了答案：“Google 现在正在构建 Anthos - 这是他们部署云的打包产品，包括 Kuber、Service Mesh、监控 - 本地微服务所需的所有硬件。” 我们几乎就在未来。”
Denis 还提到 Nutanix 和 VMWare 以及 vRealize Suite 产品，无需容器化即可应对类似任务。
德米特里分享了他的观点，减少“痛苦”和减税是我们可以期待改进的两个领域。
总结讨论，我们强调现代基础设施的以下问题：
- 三名参与者立即发现了 Stateful 的一个问题。
- 各种安全支持问题，包括 Docker 最终可能会出现多个版本的 Python、应用程序服务器和组件。
超支，最好在单独的会议上讨论。
编排是一个复杂的生态系统，这是一个学习挑战。
该行业的一个常见问题是工具的滥用。其余的结论由你决定。 仍然有一种感觉，Docker+Kubernetes 组合要成为系统的“中心”部分并不容易。 比如操作系统是先安装在硬件上的，容器和编排就更不用说了。 也许在未来，操作系统和容器将与云管理软件合并。
照片由我想借此机会向我的母亲问好并提醒您我们有一个 Facebook 群组 ， 渠道 以及来自各种技术博客的有趣出版物。 还有我的频道 ，我在这里谈论管理产品公司的开发。
来源： habr.com