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