{"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\/es\/blog\/administrirovanie\/kak-blagodarya-kubernetes-i-avtomatizatsii-migrirovat-v-oblako-za-dva-chasa","title":{"rendered":"C\u00f3mo migrar a la nube en dos horas gracias a Kubernetes y la automatizaci\u00f3n","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"C\u00f3mo
\n
\nLa compa\u00f1\u00eda \u00abURUS\u00bb prob\u00f3 Kubernetes de varias maneras: despliegue independiente en bare metal, en Google Cloud, y luego traslad\u00f3 su plataforma a la nube de Mail.ru Cloud Solutions (MCS). Igor Shishkin cuenta c\u00f3mo eligieron un nuevo proveedor de nube y c\u00f3mo lograron migrar a \u00e9l en un tiempo r\u00e9cord de dos horas (t3ran<\/a><\/noindex>), administrador de sistemas senior en \u00abURUS\u00bb.
\n<\/a><\/noindex><\/p>\n

A qu\u00e9 se dedica \u00abURUS\u00bb <\/h2>\n

\nExisten muchas maneras de mejorar la calidad del entorno urbano, y una de ellas es hacerlo ecol\u00f3gicamente seguro. Precisamente en esto est\u00e1 trabajando la compa\u00f1\u00eda \u00abURUS - Servicios Digitales Inteligentes\u00bb. Aqu\u00ed implementan soluciones que ayudan a las empresas a controlar indicadores ambientales clave y a reducir el impacto negativo en el entorno. Los sensores recopilan datos sobre la composici\u00f3n del aire, los niveles de ruido y otros par\u00e1metros, y luego los env\u00edan a una plataforma unificada \u00abURUS - Ecomon\u00bb para su an\u00e1lisis y formulaci\u00f3n de recomendaciones. <\/p>\n

C\u00f3mo funciona \u00abURUS\u00bb internamente<\/h2>\n

\nEl cliente t\u00edpico de \u00abURUS\u00bb es una empresa que se encuentra en una zona residencial o cerca de ella. Puede ser una f\u00e1brica, un puerto, un dep\u00f3sito ferroviario o cualquier otro tipo de instalaci\u00f3n. Si nuestro cliente ya ha recibido una advertencia, ha sido multado por contaminaci\u00f3n ambiental o desea emitir menos ruidos y reducir la cantidad de emisiones nocivas, nos contacta, y nosotros le ofrecemos una soluci\u00f3n lista para el monitoreo ambiental.<\/p>\n

\"C\u00f3mo
\nEn el gr\u00e1fico de monitoreo de concentraci\u00f3n de H2S se pueden ver emisiones regulares nocturnas de la empresa ubicada cerca.<\/i><\/p>\n

Los dispositivos que utilizamos en \u00abURUS\u00bb contienen varios sensores que recopilan informaci\u00f3n sobre la presencia de ciertos gases, el nivel de ruido y otros datos para evaluar la situaci\u00f3n ambiental. La cantidad exacta de sensores siempre se determina seg\u00fan la tarea espec\u00edfica.<\/p>\n

\"C\u00f3mo
\nDependiendo de la especificidad de las mediciones, los dispositivos con sensores pueden ubicarse en las paredes de los edificios, postes y en otros lugares arbitrarios. Cada uno de estos dispositivos recopila informaci\u00f3n, la agrega y la env\u00eda a la puerta de enlace de recepci\u00f3n de datos. All\u00ed conservamos los datos para almacenamiento a largo plazo y los procesamos para an\u00e1lisis posterior. Un ejemplo sencillo de lo que obtenemos como resultado despu\u00e9s del an\u00e1lisis es el \u00edndice de calidad del aire, tambi\u00e9n conocido como AQI.<\/p>\n

Paralelamente, en nuestra plataforma operan muchos otros servicios, pero en su mayor\u00eda tienen un car\u00e1cter de soporte. Por ejemplo, el servicio de notificaciones env\u00eda alertas a los clientes si alguno de los par\u00e1metros monitoreados (como, por ejemplo, el contenido de CO2) supera el valor permitido.<\/p>\n

C\u00f3mo almacenamos los datos. La historia con Kubernetes en bare metal<\/h2>\n

\nEn el proyecto de monitoreo ecol\u00f3gico 'URUS' existen varios almacenes de datos. En uno mantenemos los datos 'en bruto', es decir, lo que recibimos directamente de los dispositivos. Este almac\u00e9n representa una 'cinta' magn\u00e9tica, como las antig\u00fcas casetes, con un historial de todos los indicadores. El segundo tipo de almac\u00e9n se utiliza para los datos preprocesados: datos de los dispositivos enriquecidos con metadatos sobre las relaciones de los sensores y las lecturas de los mismos dispositivos, la pertenencia a organizaciones, ubicaciones, etc. Esta informaci\u00f3n permite evaluar din\u00e1micamente c\u00f3mo ha cambiado un indicador particular en un per\u00edodo espec\u00edfico. El almac\u00e9n de datos 'en bruto' tambi\u00e9n lo usamos como respaldo y para la recuperaci\u00f3n de datos preprocesados, en caso de que surja la necesidad.<\/p>\n

Cuando hace unos a\u00f1os busc\u00e1bamos c\u00f3mo resolver el problema del almacenamiento, ten\u00edamos dos opciones para elegir la plataforma: Kubernetes y OpenStack. Pero dado que este \u00faltimo parece bastante monstruoso (simplemente mire su arquitectura para convencerse), nos decidimos por Kubernetes. Otro argumento a su favor fue la relativamente sencilla gesti\u00f3n program\u00e1tica, la posibilidad de segmentar de manera m\u00e1s flexible incluso los nodos f\u00edsicos seg\u00fan los recursos. <\/p>\n

Paralelamente al aprendizaje de Kubernetes, tambi\u00e9n exploramos formas de almacenamiento de datos. Mientras mantuvimos todos nuestros datos en Kubernetes en nuestro hardware, obtuvimos una gran experiencia. Todo lo que ten\u00edamos en ese momento estaba funcionando en Kubernetes: almacenamiento estatal, sistema de monitoreo, CI\/CD. Kubernetes se convirti\u00f3 en nuestra plataforma todo en uno. <\/p>\n

Pero quer\u00edamos trabajar con Kubernetes como un servicio, en lugar de preocuparnos por su mantenimiento y desarrollo. Adem\u00e1s, no nos gustaban los costos de mantenerlo en bare metal, \u00a1y el desarrollo era una necesidad constante! Por ejemplo, una de las primeras tareas fue integrar los controladores Ingress de Kubernetes en la infraestructura de red de nuestra organizaci\u00f3n. Esta es una tarea compleja, especialmente si consideramos que en ese momento no hab\u00eda nada preparado para la gesti\u00f3n program\u00e1tica de recursos como registros DNS o asignaciones. direcciones IP<\/a>. M\u00e1s tarde comenzamos a experimentar con almacenamiento externo de datos. No llegamos a implementar el controlador PVC, pero ya estaba claro que ser\u00eda un gran esfuerzo laboral que requerir\u00eda especialistas dedicados.<\/p>\n

La transici\u00f3n a Google Cloud Platform fue una soluci\u00f3n temporal.<\/h2>\n

\nNos dimos cuenta de que no pod\u00edamos continuar as\u00ed y trasladamos nuestros datos de bare metal a Google Cloud Platform. En realidad, en ese momento no hab\u00eda muchas opciones interesantes para una empresa rusa: adem\u00e1s de Google Cloud Platform, solo Amazon ofrec\u00eda un servicio similar, pero finalmente optamos por la soluci\u00f3n de Google. Nos pareci\u00f3 m\u00e1s rentable, m\u00e1s alineada con Upstream, sin mencionar que Google en s\u00ed mismo es una especie de PoC de Kubernetes en Producci\u00f3n.<\/p>\n

El primer gran problema apareci\u00f3 a medida que crec\u00eda nuestra base de clientes. Cuando surgi\u00f3 la necesidad de almacenar datos personales, nos encontramos ante la elecci\u00f3n: o trabajamos con Google y violamos las leyes rusas, o buscamos una alternativa en Rusia. La elecci\u00f3n, en general, era predecible. \ud83d\ude42<\/p>\n

C\u00f3mo imagin\u00e1bamos el servicio en la nube ideal<\/h2>\n

\nAl principio de nuestra b\u00fasqueda, ya sab\u00edamos lo que quer\u00edamos obtener de nuestro futuro proveedor de nube. Qu\u00e9 servicio est\u00e1bamos buscando:<\/p>\n