La compañía «URUS» probó Kubernetes de varias maneras: despliegue independiente en bare metal, en Google Cloud, y luego trasladó su plataforma a la nube de Mail.ru Cloud Solutions (MCS). Igor Shishkin cuenta cómo eligieron un nuevo proveedor de nube y cómo lograron migrar a él en un tiempo récord de dos horas (), administrador de sistemas senior en «URUS».
A qué se dedica «URUS»
Existen muchas maneras de mejorar la calidad del entorno urbano, y una de ellas es hacerlo ecológicamente seguro. Precisamente en esto está trabajando la compañía «URUS - Servicios Digitales Inteligentes». Aquí 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ón del aire, los niveles de ruido y otros parámetros, y luego los envían a una plataforma unificada «URUS - Ecomon» para su análisis y formulación de recomendaciones.
Cómo funciona «URUS» internamente
El cliente típico de «URUS» es una empresa que se encuentra en una zona residencial o cerca de ella. Puede ser una fábrica, un puerto, un depósito ferroviario o cualquier otro tipo de instalación. Si nuestro cliente ya ha recibido una advertencia, ha sido multado por contaminación ambiental o desea emitir menos ruidos y reducir la cantidad de emisiones nocivas, nos contacta, y nosotros le ofrecemos una solución lista para el monitoreo ambiental.
En el gráfico de monitoreo de concentración de H2S se pueden ver emisiones regulares nocturnas de la empresa ubicada cerca.
Los dispositivos que utilizamos en «URUS» contienen varios sensores que recopilan información sobre la presencia de ciertos gases, el nivel de ruido y otros datos para evaluar la situación ambiental. La cantidad exacta de sensores siempre se determina según la tarea específica.
Dependiendo 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ón, la agrega y la envía a la puerta de enlace de recepción de datos. Allí conservamos los datos para almacenamiento a largo plazo y los procesamos para análisis posterior. Un ejemplo sencillo de lo que obtenemos como resultado después del análisis es el índice de calidad del aire, también conocido como AQI.
Paralelamente, en nuestra plataforma operan muchos otros servicios, pero en su mayoría tienen un carácter de soporte. Por ejemplo, el servicio de notificaciones envía alertas a los clientes si alguno de los parámetros monitoreados (como, por ejemplo, el contenido de CO2) supera el valor permitido.
Cómo almacenamos los datos. La historia con Kubernetes en bare metal
En el proyecto de monitoreo ecológico 'URUS' existen varios almacenes de datos. En uno mantenemos los datos 'en bruto', es decir, lo que recibimos directamente de los dispositivos. Este almacén representa una 'cinta' magnética, como las antigüas casetes, con un historial de todos los indicadores. El segundo tipo de almacén 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ón permite evaluar dinámicamente cómo ha cambiado un indicador particular en un período específico. El almacén de datos 'en bruto' también lo usamos como respaldo y para la recuperación de datos preprocesados, en caso de que surja la necesidad.
Cuando hace unos años buscábamos cómo resolver el problema del almacenamiento, teníamos dos opciones para elegir la plataforma: Kubernetes y OpenStack. Pero dado que este último parece bastante monstruoso (simplemente mire su arquitectura para convencerse), nos decidimos por Kubernetes. Otro argumento a su favor fue la relativamente sencilla gestión programática, la posibilidad de segmentar de manera más flexible incluso los nodos físicos según los recursos.
Paralelamente al aprendizaje de Kubernetes, también exploramos formas de almacenamiento de datos. Mientras mantuvimos todos nuestros datos en Kubernetes en nuestro hardware, obtuvimos una gran experiencia. Todo lo que teníamos en ese momento estaba funcionando en Kubernetes: almacenamiento estatal, sistema de monitoreo, CI/CD. Kubernetes se convirtió en nuestra plataforma todo en uno.
Pero queríamos trabajar con Kubernetes como un servicio, en lugar de preocuparnos por su mantenimiento y desarrollo. Además, no nos gustaban los costos de mantenerlo en bare metal, ¡y 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ón. Esta es una tarea compleja, especialmente si consideramos que en ese momento no había nada preparado para la gestión programática de recursos como registros DNS o asignaciones. direcciones IP. Más tarde comenzamos a experimentar con almacenamiento externo de datos. No llegamos a implementar el controlador PVC, pero ya estaba claro que sería un gran esfuerzo laboral que requeriría especialistas dedicados.
La transición a Google Cloud Platform fue una solución temporal.
Nos dimos cuenta de que no podíamos continuar así y trasladamos nuestros datos de bare metal a Google Cloud Platform. En realidad, en ese momento no había muchas opciones interesantes para una empresa rusa: además de Google Cloud Platform, solo Amazon ofrecía un servicio similar, pero finalmente optamos por la solución de Google. Nos pareció más rentable, más alineada con Upstream, sin mencionar que Google en sí mismo es una especie de PoC de Kubernetes en Producción.
El primer gran problema apareció a medida que crecía nuestra base de clientes. Cuando surgió la necesidad de almacenar datos personales, nos encontramos ante la elección: o trabajamos con Google y violamos las leyes rusas, o buscamos una alternativa en Rusia. La elección, en general, era predecible. 🙂
Cómo imaginábamos el servicio en la nube ideal
Al principio de nuestra búsqueda, ya sabíamos lo que queríamos obtener de nuestro futuro proveedor de nube. Qué servicio estábamos buscando:
- Rápido y flexible. Que pudiéramos añadir una nueva nodo o desplegar algo de manera ágil en cualquier momento.
- Económico. Estábamos muy preocupados por la cuestión financiera, ya que teníamos recursos limitados. Ya sabíamos que queríamos trabajar con Kubernetes, y ahora el desafío era minimizar su costo para aumentar o al menos mantener la eficiencia del uso de esta solución.
- Automatizado. Planeábamos trabajar con el servicio a través de API, sin gerentes ni llamadas telefónicas, o situaciones donde necesitáramos levantar manualmente varias decenas de nodos en una situación de emergencia. Dado que la mayoría de los procesos están automatizados, esperábamos lo mismo del servicio en la nube.
- Con servidores en Rusia. Por supuesto, planeábamos cumplir con la legislación rusa y esa misma 152-FZ.
En ese momento, había pocos proveedores de Kubernetes bajo el modelo aaS en Rusia, y al elegir un proveedor, era importante para nosotros no comprometer nuestras prioridades. El equipo de Mail.ru Cloud Solutions, con quienes comenzamos a trabajar y colaboramos hasta ahora, nos proporcionó un servicio completamente automatizado, con soporte de API y un panel de control conveniente, donde hay Horizon — con él pudimos levantar rápidamente una cantidad arbitraria de nodos.
Cómo logramos migrar a MCS en dos horas
En tales mudanzas, muchas empresas enfrentan dificultades y fracasos, pero en nuestro caso no hubo ninguno. Tuvimos suerte: dado que antes de la migración ya estábamos trabajando en Kubernetes, simplemente ajustamos tres archivos y lanzamos nuestros servicios en la nueva plataforma en la nube, en MCS. Recuerdo que en ese momento ya habíamos abandonado el bare metal y estábamos en Google Cloud Platform. Así que la mudanza en sí no tomó más de dos horas, además de un poco más de tiempo (alrededor de una hora) para copiar los datos de nuestros dispositivos. En ese momento ya estábamos utilizando Spinnaker (un servicio de CD multinube para asegurar la entrega continua). También lo agregamos rápidamente al nuevo clúster y continuamos trabajando de manera habitual.
Gracias a la automatización de los procesos de desarrollo y CI/CD, en ‘URUS’ un solo especialista se encarga de Kubernetes (y soy yo). En algún momento, trabajó conmigo otro administrador del sistema, pero luego resultó que ya habíamos automatizado toda la rutina principal y, desde el lado de nuestro producto principal, las tareas se multiplicaban, por lo que tenía sentido dirigir recursos a eso.
Recibimos de nuestro proveedor de nube lo que esperábamos, ya que comenzamos la colaboración sin ilusiones. Si hubo algunos incidentes, fueron principalmente técnicos y fáciles de explicar por la relativa novedad del servicio. Lo principal es que el equipo de MCS corrige rápidamente los errores y responde de manera ágil a las preguntas en los mensajeros.
Al comparar la experiencia con Google Cloud Platform, en su caso ni siquiera sabía dónde estaba el botón de retroalimentación, ya que simplemente no había necesidad. Y si ocurrían problemas, Google enviaba notificaciones unilaterales. Sin embargo, en el caso de MCS, considero un gran beneficio que están lo más cerca posible de los clientes rusos, tanto territorial como mentalmente.
Cómo vemos el trabajo con la nube en el futuro
Ahora nuestro trabajo está estrechamente ligado a Kubernetes, y nos satisface completamente en términos de tareas de infraestructura. Por lo tanto, no planeamos migrar a otro lado, aunque continuamente implementamos nuevas prácticas y servicios para simplificar tareas rutinarias y automatizar tareas nuevas, mejorando la estabilidad y fiabilidad de los servicios... Actualmente estamos lanzando el servicio Chaos Monkey (en concreto, estamos usando chaoskube, pero el concepto no cambia :), que fue creado originalmente en Netflix. Chaos Monkey hace una cosa simple: elimina aleatoriamente un pod en Kubernetes en cualquier momento. Esto es necesario para que nuestro servicio funcione normalmente con un número de instancias n–1, así nos acostumbramos a estar preparados para cualquier fallo.
En este momento, veo el uso de soluciones de terceros —las mismas plataformas en la nube— como la única opción correcta para las empresas jóvenes. Generalmente, al principio, están limitadas en recursos, tanto humanos como financieros, y construir y mantener su propia nube o centro de datos es demasiado caro y laborioso. Los proveedores de nube permiten minimizar estos costos, proporcionando rápidamente los recursos necesarios para operar los servicios aquí y ahora, y pagando por esos recursos a medida que se utilizan. En cuanto a la empresa «УРУС», por ahora, nos mantendremos fieles a Kubernetes en la nube. Pero quién sabe, tal vez tengamos que expandirnos geográficamente, o implementar soluciones basadas en algún equipo específico. O, tal vez, la cantidad de recursos consumidos justifique tener nuestro propio Kubernetes en bare-metal, como en los buenos viejos tiempos. 🙂
Lo que hemos aprendido de la experiencia con los servicios en la nube
Comenzamos a usar Kubernetes en bare metal, y aún allí tenía sus ventajas. Pero sus fuertes se pudieron destacar precisamente como componente aaS en la nube. Si se establece un objetivo y se automatiza al máximo, se puede evitar el vendor lock-in y la migración entre proveedores de nube tomará un par de horas, mientras que nuestras neuronas seguirán intactas. A otras empresas les podemos aconsejar: si quieren lanzar su propio servicio (en la nube) con recursos limitados y la máxima velocidad de desarrollo, empiecen ahora mismo alquilando recursos en la nube, y construyan su propio centro de datos después de que Forbes escriba sobre ustedes.
Fuente: habr.com
