{"id":38075,"date":"2019-10-31T22:21:32","date_gmt":"2019-10-31T19:21:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-blagodarya-kubernetes-i-avtomatizatsii-migrirovat-v-oblako-za-dva-chasa\/"},"modified":"2019-10-31T22:21:32","modified_gmt":"2019-10-31T19:21:32","slug":"kak-blagodarya-kubernetes-i-avtomatizatsii-migrirovat-v-oblako-za-dva-chasa","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/kak-blagodarya-kubernetes-i-avtomatizatsii-migrirovat-v-oblako-za-dva-chasa","title":{"rendered":"How to migrate to the cloud in two hours thanks to Kubernetes and automation","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"How
\n
\nThe company 'URUS' has experimented with Kubernetes in various forms: standalone deployment on bare metal, in Google Cloud, and then migrated its platform to Mail.ru Cloud Solutions (MCS). Igor Shishkin,t3ran<\/a><\/noindex>, a senior system administrator at 'URUS', explains how they chose a new cloud provider and managed to migrate to it in a record two hours.
\n<\/a><\/noindex><\/p>\n

What does 'URUS' do <\/h2>\n

\nThere are many ways to improve the urban environment, and one of them is to make it environmentally safe. This is exactly what the company 'URUS \u2013 Smart Digital Services' is working on. Here, solutions are implemented that help businesses monitor important environmental metrics and reduce negative impacts on the environment. Sensors collect data on air composition, noise levels, and other parameters, sending it to the unified platform 'URUS \u2013 Ecomon' for analysis and recommendations. <\/p>\n

How 'URUS' operates internally<\/h2>\n

\nA typical 'URUS' client is a company located in or near a residential area. This can be a factory, port, railway depot, or any other facility. If our client has already received a warning, been fined for environmental pollution, or wants to produce less noise and reduce harmful emissions, they come to us, and we offer them a ready-made solution for environmental monitoring.<\/p>\n

\"How
\nThe monitoring graph for H2S concentration shows regular nighttime emissions from a nearby facility.<\/i><\/p>\n

The devices we use at 'URUS' contain several sensors that collect information on the content of certain gases, noise levels, and other data for assessing the environmental situation. The exact number of sensors is always determined by the specific task.<\/p>\n

\"How
\nDepending on the measurement specifics, sensor devices can be placed on building walls, poles, and other arbitrary locations. Each device collects information, aggregates it, and sends it to a data reception gateway. There, we store the data for long-term storage and process it for subsequent analysis. A simple example of what we get after analysis is the air quality index, also known as AQI.<\/p>\n

Many other services operate simultaneously on our platform, primarily serving support functions. For example, the notification service sends alerts to clients if any monitored parameter (say, CO2 levels) exceeds acceptable limits.<\/p>\n

How We Store Data. The Story of Kubernetes on Bare Metal<\/h2>\n

\nThe eco-monitoring project \"URUS\" has several data repositories. One holds the \"raw\" data \u2014 that which we collect directly from the devices. This repository resembles a \"magnetic\" tape like the old cassettes, documenting all metrics over time. The second type of repository is used for pre-processed data \u2014 device data enriched with metadata regarding sensor relationships and the readings from the devices, their affiliations to organizations, locations, etc. This information allows us to dynamically evaluate how a specific metric has changed over a given period. We also utilize the \"raw\" data repository as a backup for restoring pre-processed data, should the need arise.<\/p>\n

Several years ago, when we were looking for solutions to our storage problem, we had two options for choosing a platform: Kubernetes and OpenStack. However, since the latter appears rather monstrous (just look at its architecture to see for yourself), we chose Kubernetes. Another argument in its favor was the relatively simple programmable management, allowing for more flexible allocation of even physical nodes based on resources. <\/p>\n

Alongside mastering Kubernetes itself, we explored data storage solutions. While we kept all our repositories in Kubernetes on our hardware, we gained excellent expertise. Everything we had lived on Kubernetes: stateful storage, monitoring systems, CI\/CD. Kubernetes became our all-in-one platform. <\/p>\n

But we wanted to work with Kubernetes as a service, rather than dealing with its support and development. Plus, we were not pleased with the costs of maintaining it on bare metal, especially since we constantly required development! For instance, one of the first tasks was to integrate Kubernetes Ingress controllers into our organization\u2019s network infrastructure. This is a cumbersome task, especially considering that at the time, nothing was ready for programmatic resource management like DNS records or allocations. (the key to connect to is specified, and iroh finds the associated host and establishes an encrypted connection using the QUIC protocol). Direct P2P connections are established whenever possible, but if not, it falls back to using relays, which are also employed for host discovery by keys. You can run your own relay or connect to public relays supported by the community.<\/a>Later, we started experimenting with external data storage. We didn't manage to implement the PVC controller, but it was already clear that this was a significant undertaking that required dedicating specialists.<\/p>\n

Transitioning to Google Cloud Platform was a temporary solution.<\/h2>\n

\nWe realized that we couldn't continue like this, and we migrated our data from bare metal to Google Cloud Platform. At that time, there weren't many interesting options for Russian companies: besides Google Cloud Platform, Amazon was the only similar service available, but we ultimately chose Google's solution. It seemed to us to be more cost-effective and closer to Upstream, not to mention that Google itself is somewhat of a PoC for Kubernetes in Production.<\/p>\n

The first serious problem arose concurrently with the growth of our client base. When we needed to store personal data, we faced a dilemma: either we work with Google and violate Russian laws, or we search for an alternative within Russia. The choice was, in general, predictable. \ud83d\ude42<\/p>\n

What we envisioned as the ideal cloud service<\/h2>\n

\nBy the time we started searching, we already knew what we wanted from our future cloud provider. What service were we looking for:<\/p>\n