A empresa URUS probou Kubernetes de diferentes formas: despregamento independente en bare metal, en Google Cloud, e despois trasladou a súa plataforma á nube Mail.ru Cloud Solutions (MCS). Igor Shishkin conta como escolleron un novo provedor de nube e como conseguiron migrar a el nun récord de dúas horas (), administrador de sistemas senior en URUS.
Que fai URUS?
Hai moitas formas de mellorar a calidade do medio urbano, e unha delas é facelo respectuoso co medio ambiente. Isto é exactamente no que está a traballar a empresa URUS - Smart Digital Services. Aquí implementan solucións que axudan ás empresas a supervisar importantes indicadores ambientais e reducir o seu impacto negativo no medio ambiente. Os sensores recollen datos sobre a composición do aire, o nivel de ruído e outros parámetros, e despois envíanos á plataforma unificada URUS-Ekomon para analizalos e facer recomendacións.
Como funciona URUS desde dentro
Un cliente típico de URUS é unha empresa situada dentro ou preto dunha zona residencial. Pode ser unha fábrica, porto, depósito ferroviario ou calquera outra instalación. Se o noso cliente xa recibiu un aviso, foi multado por contaminación ambiental ou quere facer menos ruído, reducir a cantidade de emisións nocivas, achégase a nós e xa lle ofrecemos unha solución preparada para a vixilancia ambiental.
O gráfico de seguimento da concentración de H2S mostra as emisións nocturnas regulares dunha planta próxima
Os dispositivos que utilizamos en URUS conteñen varios sensores que recollen información sobre o contido de determinados gases, niveis de ruído e outros datos para avaliar a situación ambiental. O número exacto de sensores sempre está determinado pola tarefa específica.
Dependendo das características específicas das medicións, os dispositivos con sensores pódense situar nas paredes de edificios, postes e outros lugares arbitrarios. Cada un destes dispositivos recolle información, agrégaa e envíaa á pasarela de recepción de datos. Alí gardamos os datos para almacenalos a longo prazo e preprocesámolos para a súa posterior análise. O exemplo máis sinxelo do que obtemos como resultado da análise é o índice de calidade do aire, tamén coñecido como AQI.
Paralelamente, na nosa plataforma operan moitos outros servizos, pero son principalmente de tipo servizo. Por exemplo, o servizo de notificacións envía notificacións aos clientes se algún dos parámetros supervisados (por exemplo, o contido de CO2) supera o valor permitido.
Como almacenamos os datos. A historia de Kubernetes no bare metal
O proxecto de vixilancia ambiental URUS conta con varios almacéns de datos. Nunha gardamos datos "en bruto": o que recibimos directamente dos propios dispositivos. Este almacenamento é unha cinta "magnética", como nas antigas cintas de casete, cun historial de todos os indicadores. O segundo tipo de almacenamento utilízase para datos preprocesados: datos de dispositivos, enriquecidos con metadatos sobre conexións entre sensores e lecturas dos propios dispositivos, afiliación a organizacións, localizacións, etc. Esta información permítelle avaliar de forma dinámica como ten un indicador en particular. cambiou durante un determinado período de tempo. Usamos o almacenamento de datos "en bruto", entre outras cousas, como copia de seguridade e para restaurar os datos preprocesados, se é necesario.
Cando buscabamos resolver o noso problema de almacenamento hai varios anos, tiñamos dúas opcións de plataforma: Kubernetes e OpenStack. Pero dado que este último parece bastante monstruoso (só basta con mirar a súa arquitectura para convencerse diso), decidimos por Kubernetes. Outro argumento ao seu favor foi o control do software relativamente sinxelo, a capacidade de cortar de forma máis flexible incluso os nodos de hardware segundo os recursos.
Paralelamente ao dominio de Kubernetes, tamén estudamos formas de almacenar datos, mentres que conservamos todo o noso almacenamento en Kubernetes no noso propio hardware, recibimos unha excelente experiencia. Todo o que tiñamos entón vivido en Kubernetes: almacenamento con estado, sistema de monitorización, CI/CD. Kubernetes converteuse nunha plataforma todo en un para nós.
Pero queriamos traballar con Kubernetes como servizo e non participar no seu apoio e desenvolvemento. Ademais, non nos gustou o que nos custou mantelo en metal nu, e necesitabamos desenvolvemento constantemente! Por exemplo, unha das primeiras tarefas foi integrar os controladores Kubernetes Ingress na infraestrutura de rede da nosa organización. Esta é unha tarefa engorrosa, sobre todo tendo en conta que naquel momento nada estaba preparado para a xestión de recursos programáticos como rexistros DNS ou a asignación de enderezos IP. Máis tarde comezamos a experimentar co almacenamento de datos externo. Nunca chegamos a implementar o controlador de PVC, pero aínda así quedou claro que se trataba dunha gran área de traballo que requiría especialistas dedicados.
Cambiar a Google Cloud Platform é unha solución temporal
Démonos conta de que isto non podía continuar e movemos os nosos datos desde o bare metal a Google Cloud Platform. De feito, naquel momento non había moitas opcións interesantes para unha empresa rusa: ademais de Google Cloud Platform, só Amazon ofrecía un servizo similar, pero aínda así decidimos a solución de Google. Entón pareceunos máis rendible economicamente, máis próximo a Upstream, sen esquecer que o propio Google é unha especie de PoC Kubernetes en Produción.
O primeiro gran problema apareceu no horizonte a medida que creceu a nosa base de clientes. Cando tivemos necesidade de almacenar datos persoais, enfrontámonos a unha elección: ou traballamos con Google e infrinxemos as leis rusas, ou buscamos unha alternativa na Federación Rusa. A elección, en xeral, era previsible. 🙂
Como vimos o servizo na nube ideal
Ao comezo da busca, xa sabiamos o que queríamos conseguir do futuro provedor de nube. Que servizo buscabamos:
- Rápido e flexible. De tal xeito que podemos engadir rapidamente un novo nodo ou implementar algo en calquera momento.
- Barato. Preocupábanos moito o tema económico, xa que eramos limitados nos recursos. Xa sabiamos que queriamos traballar con Kubernetes, e agora a tarefa era minimizar o seu custo para aumentar ou polo menos manter a eficiencia do uso desta solución.
- Automatizado. Planeamos traballar co servizo a través da API, sen xestores e chamadas telefónicas ou situacións nas que necesitemos levantar manualmente varias ducias de nodos en modo de emerxencia. Dado que a maioría dos nosos procesos están automatizados, esperabamos o mesmo do servizo na nube.
- Con servidores na Federación Rusa. Por suposto, planeamos cumprir coa lexislación rusa e ese mesmo 152-FZ.
Nese momento, había poucos provedores de aaS de Kubernetes en Rusia e, á hora de elixir un provedor, era importante que non comprometéramos as nosas prioridades. O equipo de Mail.ru Cloud Solutions, co que comezamos a traballar e seguimos colaborando, proporcionounos un servizo totalmente automatizado, con soporte para API e un cómodo panel de control que inclúe Horizon; con el poderíamos elevar rapidamente un número arbitrario de nós.
Como conseguimos migrar a MCS en dúas horas
Neste tipo de movementos, moitas empresas afrontan dificultades e contratempos, pero no noso caso non os houbo. Tivemos sorte: como xa estabamos traballando en Kubernetes antes de comezar a migración, simplemente corriximos tres ficheiros e lanzamos os nosos servizos na nova plataforma na nube, MCS. Permíteme lembrarche que por aquel entón xa deixamos o bare metal e vivíamos na plataforma Google Cloud. Polo tanto, o movemento en si non levou máis de dúas horas, ademais de dedicarse un pouco máis de tempo (aproximadamente unha hora) a copiar datos dos nosos dispositivos. Daquela xa estabamos usando Spinnaker (un servizo de CD multi-nube para proporcionar entrega continua). Tamén o engadimos rapidamente ao novo clúster e seguimos traballando como sempre.
Grazas á automatización dos procesos de desenvolvemento e CI/CD, Kubernetes en URUS está xestionado por un especialista (e son eu). Nalgún momento, outro administrador do sistema traballou comigo, pero entón resultou que xa tiñamos automatizado toda a rutina principal e había cada vez máis tarefas por parte do noso produto principal e tiña sentido dirixir os recursos a iso.
Recibimos o que esperabamos do provedor da nube, xa que comezamos a cooperar sen ilusións. Se houbo incidencias, foron maioritariamente técnicas e as que se explican facilmente pola relativa frescura do servizo. O principal é que o equipo MCS elimina rapidamente as deficiencias e responde rapidamente ás preguntas dos mensaxeiros.
Se comparo a miña experiencia con Google Cloud Platform, no seu caso nin sequera sabía onde estaba o botón de comentarios, xa que simplemente non era necesario. E se se producía algún problema, a propia Google enviaba notificacións unilateralmente. Pero no caso de MCS, creo que a gran vantaxe é que están o máis preto posible dos clientes rusos, tanto xeográficamente como mentalmente.
Como vemos traballar coas nubes no futuro
Agora o noso traballo está intimamente ligado a Kubernetes, e convénnos completamente desde o punto de vista das tarefas de infraestrutura. Polo tanto, non pensamos migrar del a ningún lado, aínda que constantemente estamos introducindo novas prácticas e servizos para simplificar tarefas rutineiras e automatizar outras novas, aumentar a estabilidade e fiabilidade dos servizos... Agora lanzamos o servizo Chaos Monkey (concretamente). , usamos chaoskube, pero isto non cambia o concepto: ), que foi creado orixinalmente por Netflix. Chaos Monkey fai unha cousa sinxela: elimina unha cápsula de Kubernetes aleatoria nun momento aleatorio. Isto é necesario para que o noso servizo conviva con normalidade co número de instancias n–1, polo que adestramos para estar preparados para calquera problema.
Agora vexo o uso de solucións de terceiros -as mesmas plataformas na nube- como o único correcto para as empresas novas. Normalmente, ao comezo da súa viaxe, teñen recursos limitados, tanto humanos como financeiros, e construír e manter a súa propia nube ou centro de datos é demasiado caro e require moito traballo. Os provedores de nube permítenche minimizar estes custos; podes obter rapidamente deles os recursos necesarios para o funcionamento dos servizos aquí e agora, e pagar estes recursos despois do feito. En canto á empresa URUS, por agora permaneceremos fieis a Kubernetes na nube. Pero quen sabe, quizais teñamos que expandirnos xeograficamente, ou implementar solucións baseadas nalgún equipamento específico. Ou quizais a cantidade de recursos consumidos xustificará o propio Kubernetes no bare-metal, como nos bos tempos. 🙂
O que aprendemos ao traballar cos servizos na nube
Comezamos a usar Kubernetes en bare metal, e mesmo alí foi bo ao seu xeito. Pero os seus puntos fortes reveláronse precisamente como un compoñente aaS na nube. Se estableces un obxectivo e automatizas todo o máximo posible, poderás evitar o bloqueo de provedores e moverte entre provedores de nube levará un par de horas e as células nerviosas permanecerán connosco. Podemos aconsellar a outras empresas: se queres lanzar o teu propio servizo (na nube), con recursos limitados e máxima velocidade de desenvolvemento, comeza agora mesmo por alugar recursos na nube e constrúe o teu centro de datos despois de que Forbes escriba sobre ti.
Fonte: www.habr.com