La empresa URUS probó Kubernetes de diferentes formas: implementación independiente en bare metal, en Google Cloud, y luego transfirió su plataforma a la nube 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 senior de sistemas en URUS.
¿Qué hace URUS?
Hay muchas maneras de mejorar la calidad del entorno urbano y una de ellas es hacerlo respetuoso con el medio ambiente. Esto es exactamente en lo que está trabajando la empresa URUS - Smart Digital Services. Aquí implementan soluciones que ayudan a las empresas a monitorear indicadores ambientales importantes y reducir su impacto negativo en el medio ambiente. Los sensores recopilan datos sobre la composición del aire, el nivel de ruido y otros parámetros y luego los envían a la plataforma unificada URUS-Ekomon para su análisis y formulación de recomendaciones.
Cómo funciona URUS desde dentro
Un cliente típico de URUS es una empresa ubicada en o cerca de una zona residencial. Podría ser una fábrica, un puerto, un depósito ferroviario o cualquier otra instalación. Si nuestro cliente ya recibió una advertencia, fue multado por contaminación ambiental o quiere hacer menos ruido, reducir la cantidad de emisiones nocivas, acude a nosotros y ya le ofrecemos una solución preparada para el monitoreo ambiental.
El gráfico de seguimiento de la concentración de H2S muestra las emisiones nocturnas habituales de una planta cercana
Los dispositivos que utilizamos en URUS contienen varios sensores que recopilan información sobre el contenido de determinados gases, niveles de ruido y otros datos para evaluar la situación ambiental. El número exacto de sensores siempre está determinado por la tarea específica.
Dependiendo de las características específicas de las mediciones, los dispositivos con sensores se pueden ubicar en las paredes de edificios, postes y 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í guardamos los datos para su almacenamiento a largo plazo y los preprocesamos para su posterior análisis. El ejemplo más simple de lo que obtenemos como resultado del análisis es el índice de calidad del aire, también conocido como AQI.
Paralelamente, en nuestra plataforma operan muchos otros servicios, pero principalmente son de carácter de servicio. Por ejemplo, el servicio de notificación envía notificaciones a los clientes si alguno de los parámetros monitoreados (por ejemplo, contenido de CO2) excede el valor permitido.
Cómo almacenamos los datos. La historia de Kubernetes sobre metal desnudo
El proyecto de monitoreo ambiental URUS cuenta con varios almacenes de datos. En uno guardamos datos "sin procesar": los que recibimos directamente de los propios dispositivos. Este almacenamiento es una cinta “magnética”, como en las antiguas cintas de casete, con un historial de todos los indicadores. El segundo tipo de almacenamiento se utiliza para datos preprocesados: datos de dispositivos, enriquecidos con metadatos sobre conexiones entre sensores y lecturas de los propios dispositivos, afiliaciones con organizaciones, ubicaciones, etc. Esta información le permite evaluar dinámicamente cómo se ha desarrollado un indicador en particular. cambiado durante un cierto período de tiempo. Utilizamos el almacenamiento de datos "sin procesar", entre otras cosas, como copia de seguridad y para restaurar datos preprocesados, si surge la necesidad.
Cuando buscábamos resolver nuestro problema de almacenamiento hace varios años, teníamos dos opciones de plataforma: Kubernetes y OpenStack. Pero como este último parece bastante monstruoso (basta con mirar su arquitectura para convencerse de ello), nos decidimos por Kubernetes. Otro argumento a su favor fue el control de software relativamente simple, la capacidad de cortar de manera más flexible incluso nodos de hardware según los recursos.
Paralelamente a dominar Kubernetes, también estudiamos formas de almacenar datos, mientras manteníamos todo nuestro almacenamiento en Kubernetes en nuestro propio hardware, obtuvimos una excelente experiencia. Todo lo que habíamos vivido entonces en Kubernetes: almacenamiento con estado completo, sistema de monitoreo, CI/CD. Kubernetes se ha convertido para nosotros en una plataforma todo en uno.
Pero queríamos trabajar con Kubernetes como un servicio y no involucrarnos en su soporte y desarrollo. Además, no nos gustaba lo que nos costaba mantenerlo en estado puro y necesitábamos un desarrollo constante. Por ejemplo, una de las primeras tareas fue integrar los controladores Kubernetes Ingress en la infraestructura de red de nuestra organización. Esta es una tarea engorrosa, especialmente considerando que en ese momento no había nada listo para la gestión programática de recursos como registros DNS o la asignación de direcciones IP. Posteriormente comenzamos a experimentar con el almacenamiento de datos externo. Nunca logramos implementar el controlador de PVC, pero incluso entonces quedó claro que se trataba de un área de trabajo grande que requería especialistas dedicados.
Cambiar a Google Cloud Platform es una solución temporal
Nos dimos cuenta de que esto no podía continuar y trasladamos nuestros datos desde bare metal a Google Cloud Platform. De hecho, en aquel momento no había muchas opciones interesantes para una empresa rusa: además de Google Cloud Platform, sólo Amazon ofrecía un servicio similar, pero aún así nos decidimos por la solución de Google. Entonces nos pareció más rentable económicamente, más cercano a Upstream, sin mencionar que el propio Google es una especie de PoC Kubernetes en producción.
El primer problema importante apareció en el horizonte a medida que crecía nuestra base de clientes. Cuando tuvimos la necesidad de almacenar datos personales, nos enfrentamos a una elección: o trabajamos con Google y violamos las leyes rusas, o buscamos una alternativa en la Federación Rusa. La elección, en general, era predecible. 🙂
Cómo vimos el servicio en la nube ideal
Al principio de la búsqueda ya sabíamos lo que queríamos obtener del futuro proveedor de la nube. Qué servicio buscábamos:
- Rápido y flexible. De modo que podamos agregar rápidamente un nuevo nodo o implementar algo en cualquier momento.
- Barato. Estábamos muy preocupados por el tema financiero, ya que teníamos recursos limitados. Ya sabíamos que queríamos trabajar con Kubernetes y ahora la tarea era minimizar su costo para aumentar o al menos mantener la eficiencia del uso de esta solución.
- automatizado. Planeamos trabajar con el servicio a través de API, sin administradores ni llamadas telefónicas ni situaciones en las que necesitemos activar manualmente varias docenas de nodos en modo de emergencia. Dado que la mayoría de nuestros procesos están automatizados, esperábamos lo mismo del servicio en la nube.
- Con servidores en la Federación Rusa. Por supuesto, planeamos cumplir con la legislación rusa y el mismo 152-FZ.
En ese momento, había pocos proveedores de Kubernetes aaS en Rusia y, al elegir un proveedor, era importante para nosotros no comprometer nuestras prioridades. El equipo de Mail.ru Cloud Solutions, con quien comenzamos a trabajar y todavía colaboramos, nos brindó un servicio totalmente automatizado, con soporte API y un panel de control conveniente que incluye Horizon; con él pudimos levantar rápidamente una cantidad arbitraria de nodos.
Cómo logramos migrar a MCS en dos horas
En tales movimientos, muchas empresas enfrentan dificultades y reveses, pero en nuestro caso no hubo ninguno. Tuvimos suerte: como ya estábamos trabajando en Kubernetes antes de que comenzara la migración, simplemente corregimos tres archivos y lanzamos nuestros servicios en la nueva plataforma en la nube, MCS. Permítanme recordarles que en ese momento finalmente habíamos dejado el metal desnudo y vivíamos en Google Cloud Platform. Por lo tanto, la mudanza en sí no tomó más de dos horas, además se dedicó un poco más de tiempo (aproximadamente una hora) a copiar datos de nuestros dispositivos. En aquel entonces ya estábamos usando Spinnaker (un servicio de CD multinube para proporcionar entrega continua). También lo agregamos rápidamente al nuevo clúster y continuamos trabajando como de costumbre.
Gracias a la automatización de los procesos de desarrollo y CI/CD, Kubernetes en URUS está a cargo de un especialista (y ese soy yo). En algún momento, otro administrador del sistema trabajó conmigo, pero luego resultó que ya habíamos automatizado toda la rutina principal y cada vez había más tareas por parte de nuestro producto principal y tenía sentido dirigir recursos a esto.
Recibimos lo que esperábamos del proveedor de la nube, ya que comenzamos a cooperar sin ilusiones. Si hubo alguna incidencia, fue en su mayoría técnica y fácilmente explicable por la relativa frescura del servicio. Lo principal es que el equipo de MCS soluciona rápidamente las deficiencias y responde rápidamente a las preguntas en los mensajeros.
Si comparo mi experiencia con Google Cloud Platform, en su caso ni siquiera sabía dónde estaba el botón de comentarios, ya que simplemente no era necesario. Y si ocurría algún problema, el propio Google enviaba notificaciones unilateralmente. Pero en el caso de MCS, creo que la gran ventaja es que están lo más cerca posible de los clientes rusos, tanto geográfica como mentalmente.
Cómo vemos el trabajo con las nubes en el futuro
Ahora nuestro trabajo está estrechamente ligado a Kubernetes y nos conviene perfectamente desde el punto de vista de las tareas de infraestructura. Por lo tanto, no planeamos migrar de él a ninguna parte, aunque constantemente introducimos nuevas prácticas y servicios para simplificar las tareas rutinarias y automatizar otras nuevas, aumentar la estabilidad y confiabilidad de los servicios... Ahora estamos lanzando el servicio Chaos Monkey (específicamente , usamos caoskube, pero esto no cambia el concepto: ), que fue creado originalmente por Netflix. Chaos Monkey hace una cosa simple: elimina un pod de Kubernetes aleatorio en un momento aleatorio. Esto es necesario para que nuestro servicio viva normalmente con el número de instancias n–1, por lo que nos entrenamos para estar preparados para cualquier problema.
Ahora considero que el uso de soluciones de terceros (las mismas plataformas en la nube) es lo único correcto para las empresas jóvenes. Por lo general, al comienzo de su viaje, tienen recursos limitados, tanto humanos como financieros, y construir y mantener su propia nube o centro de datos es demasiado costoso y requiere mucha mano de obra. Los proveedores de la nube le permiten minimizar estos costos; puede obtener rápidamente de ellos los recursos necesarios para el funcionamiento de los servicios aquí y ahora, y pagar por estos recursos después del hecho. En cuanto a la empresa URUS, de momento seguiremos fieles a Kubernetes en la nube. Pero quién sabe, quizá tengamos que expandirnos geográficamente, o implementar soluciones basadas en algún equipamiento concreto. O tal vez la cantidad de recursos consumidos justifique tener Kubernetes sin sistema operativo, como en los viejos tiempos. 🙂
Lo que aprendimos al trabajar con servicios en la nube
Comenzamos a usar Kubernetes en bare metal, e incluso allí fue bueno a su manera. Pero sus puntos fuertes se revelaron precisamente como componente aaS en la nube. Si establece un objetivo y automatiza todo tanto como sea posible, podrá evitar el bloqueo de proveedores y el cambio entre proveedores de nube llevará un par de horas y las células nerviosas permanecerán con nosotros. Podemos asesorar a otras empresas: si desea lanzar su propio servicio (en la nube), teniendo recursos limitados y la máxima velocidad de desarrollo, comience ahora mismo alquilando recursos en la nube y construya su centro de datos después de que Forbes escriba sobre usted.
Fuente: habr.com