A empresa «УРУС» testou o Kubernetes de várias maneiras: implantação autônoma em bare metal, no Google Cloud, e depois transferiu sua plataforma para a nuvem Mail.ru Cloud Solutions (MCS). Igor Shishkin,, administrador de sistemas sênior da «УРУС».
O que faz a «УРУС»
Existem muitas maneiras de melhorar a qualidade do ambiente urbano, e uma delas é torná-lo ecologicamente seguro. Este é precisamente o trabalho da empresa «УРУС — Serviços Digitais Inteligentes». Aqui, são implementadas soluções que ajudam as empresas a monitorar importantes indicadores ambientais e a reduzir o impacto negativo no meio ambiente. Sensores coletam dados sobre a composição do ar, nível de ruído e outros parâmetros, e, em seguida, enviam essas informações para a plataforma unificada «УРУС — Экомон» para análise e formulação de recomendações.
Como funciona a «УРУС» internamente
O cliente típico da «УРУС» é uma empresa localizada em uma área residencial ou próxima a ela. Isso pode ser uma fábrica, porto, depósito ferroviário ou qualquer outro objeto. Se nosso cliente já recebeu um aviso, foi multado por poluição ou deseja emitir menos ruído e reduzir o número de emissões nocivas, ele vem até nós, e oferecemos uma solução pronta para monitoramento ambiental.
No gráfico de monitoramento da concentração de H2S, são visíveis as emissões regulares noturnas de uma empresa próxima.
Os dispositivos que usamos na «УРУС» contêm vários sensores que coletam informações sobre a presença de certos gases, nível de ruído e outros dados para avaliar a situação ambiental. O número exato de sensores é sempre determinado pela tarefa específica.
Dependendo da especificidade das medições, os dispositivos com sensores podem ser instalados nas paredes dos edifícios, postes e em outros locais arbitrários. Cada dispositivo coleta informações, agrega os dados e envia para um gateway de recepção. Lá, armazenamos os dados para armazenamento a longo prazo e os processamos para análise posterior. Um exemplo simples do que obtemos após a análise é o índice de qualidade do ar, também conhecido como AQI.
Paralelamente, muitos outros serviços operam em nossa plataforma, mas em sua maioria eles têm um caráter de suporte. Por exemplo, o serviço de notificação envia alertas aos clientes se algum dos parâmetros monitorados (como o nível de CO2) ultrapassar o valor permitido.
Como armazenamos dados. A história com Kubernetes em bare metal
No projeto de ecomonitoramento «URUS», existem vários repositórios de dados. Em um, armazenamos dados 'brutos' - aquilo que recebemos diretamente dos dispositivos. Este repositório é como uma 'fita magnética', como as antigas fitas cassete, com o histórico de todas as medições. O segundo tipo de repositório é utilizado para dados pré-processados — dados dos dispositivos enriquecidos com metadados sobre as conexões dos sensores e as leituras dos dispositivos, pertencentes a organizações, locais, etc. Essas informações permitem avaliar dinamicamente como um determinado indicador mudou ao longo de um determinado período de tempo. Usamos o repositório de dados 'brutos' também como backup e para recuperar dados pré-processados, se necessário.
Quando, há alguns anos, estávamos procurando como resolver o problema de armazenamento, tínhamos duas opções para escolher a plataforma: Kubernetes e OpenStack. Mas como a última parece bastante monstruosa (basta olhar sua arquitetura para se certificar disso), decidimos ficar com o Kubernetes. Outro argumento a seu favor foi a gerência programática relativamente simples e a possibilidade de distribuir de forma mais flexível até mesmo os nós físicos em recursos.
Paralelamente ao domínio do próprio Kubernetes, estudamos também maneiras de armazenar dados, enquanto mantivemos todos os nossos repositórios no Kubernetes em nosso hardware, adquirimos uma excelente expertise. Tudo o que tínhamos na época vivia justamente no Kubernetes: armazenamento stateful, sistema de monitoramento, CI/CD. O Kubernetes se tornou para nós uma plataforma all-in-one.
Mas nós queríamos trabalhar com Kubernetes como um serviço, em vez de nos ocuparmos com sua manutenção e desenvolvimento. Além disso, não gostávamos do custo associado à sua manutenção em bare metal, e o desenvolvimento era uma constante necessidade! Por exemplo, uma das primeiras tarefas foi integrar os controladores Ingress do Kubernetes na infraestrutura de rede da nossa organização. Essa é uma tarefa complexa, especialmente se considerarmos que, naquela época, nada estava pronto para a gestão programática de recursos como registros DNS ou alocação. endereços IPMais tarde, começamos a experimentar armazenamento externo de dados. Não chegamos a implementar o controlador PVC, mas naquela época já estava claro que era um grande projeto que exigiria profissionais dedicados.
A transição para o Google Cloud Platform - uma solução temporária.
Percebemos que não podíamos continuar assim e migramos nossos dados de bare metal para o Google Cloud Platform. Na verdade, naquela época, para uma empresa russa, não havia muitas opções interessantes: além do Google Cloud Platform, apenas a Amazon oferecia um serviço semelhante, mas ainda assim optamos pela solução do Google. Para nós, parecia mais economicamente vantajoso, mais próximo do Upstream, sem mencionar que o Google em si é uma espécie de PoC do Kubernetes em produção.
O primeiro grande problema surgiu junto com o crescimento da nossa base de clientes. Quando surgiu a necessidade de armazenar dados pessoais, nos deparamos com a escolha: ou trabalhamos com o Google e violamos as leis russas, ou buscamos uma alternativa na Rússia. A escolha, em geral, era previsível. 🙂
Como imaginávamos o serviço de nuvem ideal
No início das nossas buscas, já sabíamos o que queríamos do futuro provedor de nuvem. Que tipo de serviço procurávamos:
- Rápido e flexível. Um que nos permitisse adicionar rapidamente um novo nó ou implantar algo a qualquer momento.
- Barato. Estávamos muito preocupados com a questão financeira, uma vez que estávamos limitados em recursos. Já sabíamos que queríamos trabalhar com Kubernetes, e agora a tarefa era minimizar seu custo, para aumentar ou pelo menos manter a eficiência do uso dessa solução.
- Automatizado. Planejamos trabalhar com o serviço através da API, sem gerentes, telefonemas ou situações em que precisássemos levantar manualmente várias dezenas de nós em modo de emergência. Como a maioria dos nossos processos é automatizada, esperávamos o mesmo do serviço em nuvem.
- Com servidores na Rússia. Claro, planejamos cumprir a legislação russa e a famosa Lei 152-FZ.
Na época, havia poucos provedores de Kubernetes no modelo aaS na Rússia e, ao escolher um provedor, era importante para nós não comprometer nossas prioridades. A equipe do Mail.ru Cloud Solutions, com quem começamos a trabalhar e continuamos a cooperar até hoje, nos forneceu um serviço totalmente automatizado, com suporte a API e um painel de controle conveniente, onde está o Horizon — com ele pudemos rapidamente lançar um número arbitrário de nós.
Como conseguimos migrar para o MCS em duas horas
Em mudanças como essa, muitas empresas enfrentam dificuldades e fracassos, mas no nosso caso isso não aconteceu. Tivemos sorte: como antes da migração já estávamos trabalhando em Kubernetes, apenas ajustamos três arquivos e lançamos nossos serviços na nova plataforma em nuvem, no MCS. Lembro que até aquele momento já havíamos migrado completamente do bare metal e estávamos na Google Cloud Platform. Portanto, a própria migração levou no máximo duas horas, além de mais um pouco de tempo (cerca de uma hora) para copiar dados de nossos dispositivos. Naquela época, já usávamos o Spinnaker (um serviço multi-nuvem de CD para garantir Entrega Contínua). Também o adicionamos rapidamente ao novo cluster e continuamos a trabalhar normalmente.
Graças à automação dos processos de desenvolvimento e CI/CD, no 'URUS' é um único especialista que cuida de tudo (e sou eu). Em algum momento, outro administrador de sistemas trabalhou comigo, mas logo ficou claro que já havíamos automatizado toda a rotina principal e, do lado do nosso produto principal, as tarefas estão aumentando, faz sentido direcionar recursos para isso.
Recebemos do provedor em nuvem o que esperávamos, pois começamos a colaboração sem ilusões. Se houve algum incidente, foi principalmente técnico e facilmente explicável pela relativa novidade do serviço. O mais importante é que a equipe do MCS corrige rapidamente as falhas e responde prontamente às perguntas nas mensagens.
Comparando a experiência com o Google Cloud Platform, eu nem sabia onde estava o botão de feedback, pois não havia necessidade dele. Se algum problema acontecesse, o Google enviava notificações de forma unilateral. Mas no caso da MCS, considero um grande ponto positivo que eles estão muito próximos dos clientes russos — tanto geograficamente quanto mentalmente.
Como vemos o trabalho com nuvens no futuro
Atualmente, nosso trabalho está intimamente vinculado ao Kubernetes, e ele nos atende plenamente em termos de tarefas de infraestrutura. Portanto, não planejamos migrar para outra plataforma, embora estejamos constantemente implementando novas práticas e serviços para simplificar tarefas rotineiras e automatizar novas, buscando aumentar a estabilidade e a confiabilidade dos serviços... Agora estamos lançando o serviço Chaos Monkey (especificamente estamos usando o chaoskube, mas isso não muda o conceito :), que foi originalmente criado na Netflix. O Chaos Monkey faz uma coisa simples: em um momento aleatório, remove um pod aleatório no Kubernetes. Isso é necessário para que nosso serviço funcione normalmente com o número de instâncias n–1, assim nos habituamos a estarmos prontos para quaisquer falhas.
Atualmente, vejo o uso de soluções de terceiros — as mesmas plataformas em nuvem — como a única opção correta para empresas jovens. Normalmente, no início de sua jornada, elas estão limitadas em recursos, tanto de pessoal quanto financeiros, e construir e manter sua própria nuvem ou data center é muito caro e trabalhoso. Os provedores de nuvem permitem minimizar esses custos, possibilitando a obtenção rápida dos recursos necessários para o funcionamento dos serviços aqui e agora, sendo que o pagamento é feito conforme o uso. Quanto à empresa ‘URUS’, ainda permaneceremos fiéis ao Kubernetes na nuvem. Mas quem sabe, talvez precisemos expandir geograficamente ou implementar soluções em alguma infraestrutura específica. Ou, talvez, a quantidade de recursos consumidos justifique um Kubernetes próprio em bare-metal, como nos velhos tempos. 🙂
O que aprendemos com a experiência de trabalhar com serviços em nuvem
Começamos a usar Kubernetes em bare metal, e mesmo lá ele teve suas qualidades. No entanto, seus pontos fortes foram realmente revelados como um componente aaS na nuvem. Se você estabelecer um objetivo e automatizar ao máximo, conseguirá evitar o vendor lock-in e a migração entre provedores de nuvem levará apenas algumas horas, e suas células nervosas permanecerão intactas. Recomendamos a outras empresas: se você deseja lançar seu serviço (em nuvem) com recursos limitados e máxima velocidade de desenvolvimento — comece agora mesmo a alugar recursos em nuvem e construa seu data center depois que a Forbes escrever sobre você.
Fonte: habr.com
