URUS 公司尝试了不同形式的 Kubernetes：在裸机、Google Cloud 中独立部署，然后将其平台转移到 Mail.ru Cloud Solutions (MCS) 云上。 Igor Shishkin 讲述了他们如何选择新的云提供商以及如何在创纪录的两小时内迁移到该提供商（），URUS 高级系统管理员。
URUS 有什么作用？
改善城市环境质量的方法有很多，其中之一就是环境友好型。 这正是 URUS（智能数字服务公司）正在致力于的事情。 他们在这里实施解决方案，帮助企业监控重要的环境指标并减少对环境的负面影响。 传感器收集空气成分、噪音水平和其他参数的数据，然后将其发送到统一的 URUS-Ekomon 平台进行分析并提出建议。
URUS 的内部运作原理
URUS 的典型客户是位于住宅区或住宅区附近的公司。 这可以是工厂、港口、火车站或任何其他设施。 如果我们的客户已经收到警告，因环境污染被罚款，或者想要减少噪音，减少有害排放量，他来找我们，我们已经为他提供了现成的环境监测解决方案。
硫化氢浓度监测图显示附近工厂夜间定期排放
我们在 URUS 使用的设备包含多个传感器，这些传感器收集有关某些气体含量、噪音水平和其他数据的信息，以评估环境状况。 传感器的确切数量始终由具体任务决定。
根据测量的具体情况，带有传感器的设备可以放置在建筑物的墙壁、电线杆和其他任意位置。 每个这样的设备收集信息、聚合信息并将其发送到数据接收网关。 在那里，我们保存数据以供长期存储，并对其进行预处理以供后续分析。 我们得到的分析结果最简单的例子是空气质量指数，也称为 AQI。
与此同时，许多其他服务也在我们的平台上运行，但它们主要是服务性质的。 例如，如果任何监控参数（例如二氧化碳含量）超过允许值，通知服务就会向客户端发送通知。
我们如何存储数据。 裸机上 Kubernetes 的故事
URUS环境监测项目有多个数据仓库。 在其中，我们保留“原始”数据——我们直接从设备本身接收到的数据。 该存储是一个“磁带”，就像旧的盒式磁带一样，具有所有指标的历史记录。 第二种类型的存储用于预处理数据 - 来自设备的数据，其中包含有关传感器之间的连接和设备本身的读数、与组织、位置等的隶属关系的元数据。这些信息允许您动态评估特定指标的表现在一定时间内发生变化。 除其他外，我们使用“原始”数据存储作为备份和恢复预处理数据（如果出现这种需要）。
几年前，当我们寻求解决存储问题时，我们有两个平台选择：Kubernetes 和 OpenStack。 但由于后者看起来相当可怕（只要看看它的架构就可以确信这一点），我们选择了 Kubernetes。 支持它的另一个论点是相对简单的软件控制，能够根据资源更灵活地削减硬件节点。
在掌握 Kubernetes 本身的同时，我们还研究了存储数据的方法，同时我们将 Kubernetes 中的所有存储都保留在我们自己的硬件上，我们获得了出色的专业知识。 我们当时的一切都生活在 Kubernetes 上：有状态存储、监控系统、CI/CD。 Kubernetes 已成为我们的一体化平台。
但我们希望将 Kubernetes 作为一项服务来使用，而不是参与其支持和开发。 另外，我们不喜欢在裸机上维护它的成本，而且我们需要不断开发！ 例如，首要任务之一是将 Kubernetes Ingress 控制器集成到我们组织的网络基础设施中。 这是一项繁琐的任务，特别是考虑到当时还没有任何程序可以进行资源管理，例如 DNS 记录或 IP 地址分配。 后来我们开始尝试外部数据存储。 我们从未抽出时间来实施 PVC 控制器，但即便如此，我们仍然清楚这是一个需要专门专家的大范围工作。
切换到 Google Cloud Platform 是一个临时解决方案
我们意识到这种情况无法继续下去，并将我们的数据从裸机转移到 Google Cloud Platform。 事实上，当时俄罗斯公司并没有太多有趣的选择：除了谷歌云平台之外，只有亚马逊提供类似的服务，但我们仍然选择了谷歌的解决方案。 那么在我们看来，它在经济上更有利可图，更接近上游，更不用说谷歌本身就是生产中的一种PoC Kubernetes。
随着我们客户群的增长，第一个主要问题出现了。 当我们需要存储个人数据时，我们面临着一个选择：要么与谷歌合作并违反俄罗斯法律，要么在俄罗斯联邦寻找替代方案。 总的来说，这个选择是可以预见的。 🙂
我们如何看待理想的云服务
在搜索开始时，我们已经知道我们想从未来的云提供商那里得到什么。 我们正在寻找什么服务：
- 快速灵活。 这样我们就可以随时快速添加新节点或部署某些东西。
- 便宜。 我们非常担心财务问题，因为我们的资源有限。 我们已经知道我们想要使用 Kubernetes，现在的任务是最大限度地降低其成本，以提高或至少保持使用该解决方案的效率。
- 自动的。 我们计划通过 API 使用该服务，无需经理和电话，也无需在紧急模式下手动启动数十个节点。 由于我们的大多数流程都是自动化的，因此我们对云服务的期望也是如此。
- 服务器位于俄罗斯联邦。 当然，我们计划遵守俄罗斯立法和 152-FZ。
当时，俄罗斯的 Kubernetes aaS 提供商很少，在选择提供商时，对我们来说重要的是不要妥协我们的优先事项。 Mail.ru 云解决方案团队是我们开始合作并仍在合作的团队，他们为我们提供了完全自动化的服务，提供 API 支持和方便的控制面板，其中包括 Horizon - 借助它，我们可以快速提升任意数量的节点。
我们如何在两小时内成功迁移到 MCS
在这样的过程中，很多企业都会遇到困难和挫折，但我们却没有。 我们很幸运：由于在迁移开始之前我们已经在 Kubernetes 上工作，我们只需更正三个文件并在新的云平台 MCS 上启动我们的服务。 让我提醒您，那时我们终于离开了裸机并生活在 Google Cloud Platform 上。 因此，移动本身花费的时间不超过两个小时，再加上从我们的设备复制数据所花费的时间（大约一个小时）。 当时我们已经在使用 Spinnaker（一种提供持续交付的多云 CD 服务）。 我们也很快将其添加到新集群中并继续照常工作。
得益于开发流程和 CI/CD 的自动化，URUS 的 Kubernetes 由一名专家（那就是我）负责处理。 在某个阶段，另一位系统管理员与我一起工作，但后来发现我们已经自动化了所有主要例程，并且我们的主要产品的任务越来越多，因此将资源用于此是有意义的。
我们从云提供商那里得到了我们所期望的，因为我们不抱任何幻想地开始了合作。 如果发生任何事件，它们大多是技术性的，并且可以很容易地用服务的相对新鲜度来解释。 最主要的是MCS团队快速消除缺点并快速回复Messenger中的问题。
如果我将我的体验与 Google Cloud Platform 进行比较，在他们的情况下，我什至不知道反馈按钮在哪里，因为根本不需要它。 如果确实出现任何问题，谷歌也会单方面发出通知。 但就 MCS 而言，我认为最大的优势是他们尽可能接近俄罗斯客户——无论是在地理上还是在精神上。
我们如何看待未来的云合作
现在我们的工作与 Kubernetes 紧密相关，从基础设施任务的角度来看它完全适合我们。 因此，我们不打算从它迁移到任何地方，尽管我们不断引入新的实践和服务来简化日常任务并自动化新任务，提高服务的稳定性和可靠性......我们现在推出 Chaos Monkey 服务（具体来说是，我们使用chaoskube，但这并没有改变概念：），它最初是由Netflix创建的。 Chaos Monkey 做了一件简单的事情：它在随机时间删除一个随机 Kubernetes pod。 这对于我们的服务在实例数量为 n-1 的情况下正常运行是必要的，因此我们训练自己为任何问题做好准备。
现在，我认为使用第三方解决方案（相同的云平台）是年轻公司唯一正确的选择。 通常，在他们的旅程开始时，他们的人力和财力资源都有限，并且构建和维护自己的云或数据中心过于昂贵且劳动密集型。 云提供商可以让您最大限度地降低这些成本；您可以从他们那里快速获取此时此刻运行服务所需的资源，并在事后为这些资源付费。 至于URUS公司，我们目前仍将忠实于云中的Kubernetes。 但谁知道呢，我们可能必须扩大地域，或者实施基于某些特定设备的解决方案。 或者，消耗的资源量可能会证明在裸机上使用 Kubernetes 是合理的，就像过去的美好时光一样。 🙂
我们从使用云服务中学到了什么
我们开始在裸机上使用 Kubernetes，即使在那里它也以自己的方式表现良好。 但它的优势恰恰是作为云中的 aaS 组件展现出来的。 如果你设定一个目标并尽可能地自动化一切，你将能够避免供应商锁定，并且在云提供商之间移动将需要几个小时，而神经细胞将留在我们身边。 我们可以建议其他公司：如果您想推出自己的（云）服务，但资源有限且开发速度最快，请立即开始租用云资源，并在《福布斯》报道您之后构建您的数据中心。
来源： habr.com