A empresa URUS experimentou o Kubernetes de diferentes formas: implantação independente em bare metal, no Google Cloud, e depois transferiu sua plataforma para a nuvem Mail.ru Cloud Solutions (MCS). Igor Shishkin conta como escolheram um novo provedor de nuvem e como conseguiram migrar para ele em um recorde de duas horas (), administrador de sistema sênior da URUS.
O que o URUS faz?
Existem muitas formas de melhorar a qualidade do ambiente urbano e uma delas é torná-lo amigo do ambiente. É exatamente nisso que a empresa URUS – Smart Digital Services está trabalhando. Aqui implementam soluções que ajudam as empresas a monitorizar indicadores ambientais importantes e a reduzir o seu impacto negativo no ambiente. Os sensores coletam dados sobre a composição do ar, nível de ruído e outros parâmetros e depois os enviam para a plataforma unificada URUS-Ekomon para análise e formulação de recomendações.
Como o URUS funciona por dentro
Um cliente típico da URUS é uma empresa localizada em ou próximo a uma área residencial. Pode ser uma fábrica, um porto, um depósito ferroviário ou qualquer outra instalação. Se o nosso cliente já recebeu uma advertência, foi multado por poluição ambiental, ou quer fazer menos barulho, diminuir a quantidade de emissões nocivas, ele vem até nós, e já oferecemos a ele uma solução pronta para monitoramento ambiental.
O gráfico de monitoramento da concentração de H2S mostra emissões noturnas regulares de uma planta próxima
Os dispositivos que utilizamos na URUS contêm diversos sensores que recolhem informação sobre o conteúdo de determinados gases, níveis 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 das especificidades das medições, dispositivos com sensores podem ser localizados nas paredes de edifícios, postes e outros locais arbitrários. Cada um desses dispositivos coleta informações, agrega-as e envia-as para o gateway de recebimento de dados. Lá salvamos os dados para armazenamento de longo prazo e os pré-processamos para análise posterior. O exemplo mais simples do que obtemos como resultado da análise é o índice de qualidade do ar, também conhecido como AQI.
Paralelamente, muitos outros serviços operam na nossa plataforma, mas são principalmente de natureza prestativa. Por exemplo, o serviço de notificação envia notificações aos clientes se algum dos parâmetros monitorados (por exemplo, conteúdo de CO2) exceder o valor permitido.
Como armazenamos dados. A história do Kubernetes em bare metal
O projeto de monitoramento ambiental URUS possui diversos data warehouses. Em um deles mantemos dados “brutos” – aquilo que recebemos diretamente dos próprios dispositivos. Esse armazenamento é uma fita “magnética”, como nas fitas cassete antigas, com histórico de todos os indicadores. O segundo tipo de armazenamento é usado para dados pré-processados - dados de dispositivos, enriquecidos com metadados sobre conexões entre sensores e leituras dos próprios dispositivos, afiliação a organizações, locais, etc. mudou durante um determinado período de tempo. Utilizamos o armazenamento de dados “brutos”, entre outras coisas, como backup e para restauração de dados pré-processados, se tal necessidade surgir.
Há vários anos, quando procurávamos resolver nosso problema de armazenamento, tínhamos duas opções de plataforma: Kubernetes e OpenStack. Mas como este último parece bastante monstruoso (basta olhar sua arquitetura para se convencer disso), optamos pelo Kubernetes. Outro argumento a seu favor foi o controle de software relativamente simples, a capacidade de cortar com mais flexibilidade até mesmo nós de hardware de acordo com os recursos.
Paralelamente ao domínio do próprio Kubernetes, também estudamos formas de armazenar dados, enquanto mantivemos todo o nosso armazenamento no Kubernetes em hardware próprio, recebemos excelente expertise. Tudo o que tínhamos naquela época vivia no Kubernetes: armazenamento statefull, sistema de monitoramento, CI/CD. Kubernetes se tornou uma plataforma completa para nós.
Mas queríamos trabalhar com o Kubernetes como um serviço, e não nos envolvermos em seu suporte e desenvolvimento. Além disso, não gostávamos do quanto nos custava mantê-lo em bare metal e precisávamos de desenvolvimento constante! Por exemplo, uma das primeiras tarefas foi integrar os controladores Kubernetes Ingress à infraestrutura de rede da nossa organização. Esta é uma tarefa complicada, especialmente considerando que naquela época nada estava pronto para o gerenciamento programático de recursos, como registros DNS ou alocação de endereços IP. Mais tarde, começamos a experimentar o armazenamento externo de dados. Nunca chegamos a implementar o controlador de PVC, mas mesmo assim ficou claro que se tratava de uma grande área de trabalho que exigia especialistas dedicados.
Mudar para o Google Cloud Platform é uma solução temporária
Percebemos que isso não poderia continuar e migramos nossos dados do bare metal para o Google Cloud Platform. Na verdade, naquela época não havia muitas opções interessantes para uma empresa russa: além do Google Cloud Platform, apenas a Amazon oferecia um serviço semelhante, mas ainda assim optamos pela solução do Google. Aí nos pareceu mais rentável economicamente, mais próximo do Upstream, sem falar no fato do próprio Google ser uma espécie de PoC Kubernetes em Produção.
O primeiro grande problema apareceu no horizonte à medida que nossa base de clientes crescia. Quando tivemos necessidade de armazenar dados pessoais, tivemos de escolher: ou trabalhamos com o Google e violamos as leis russas, ou procuramos uma alternativa na Federação Russa. A escolha, no geral, era previsível. 🙂
Como vimos o serviço de nuvem ideal
No início da pesquisa, já sabíamos o que queríamos do futuro provedor de nuvem. Que serviço procurávamos:
- Rápido e flexível. De forma que possamos adicionar rapidamente um novo nó ou implantar algo a qualquer momento.
- Barato. Estávamos muito preocupados com a questão financeira, pois tínhamos recursos limitados. 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 de utilização desta solução.
- automatizado. Planejamos trabalhar com o serviço através da API, sem gerentes e telefonemas ou situações em que precisemos acionar 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 Federação Russa. É claro que planejamos cumprir a legislação russa e o mesmo 152-FZ.
Naquela época, havia poucos provedores de Kubernetes aaS na Rússia e, ao escolher um provedor, era importante não comprometermos nossas prioridades. A equipe Mail.ru Cloud Solutions, com quem começamos a trabalhar e ainda colaboramos, nos forneceu um serviço totalmente automatizado, com suporte API e um conveniente painel de controle que inclui Horizon - com ele poderíamos aumentar rapidamente um número arbitrário de nós.
Como conseguimos migrar para MCS em duas horas
Nesses movimentos, muitas empresas enfrentam dificuldades e contratempos, mas no nosso caso não houve nenhum. Tivemos sorte: como já estávamos trabalhando no Kubernetes antes do início da migração, simplesmente corrigimos três arquivos e lançamos nossos serviços na nova plataforma de nuvem, MCS. Deixe-me lembrá-lo de que naquela época finalmente havíamos deixado o bare metal e vivido no Google Cloud Platform. Portanto, a mudança em si não demorou mais do que duas horas, além de um pouco mais de tempo (cerca de uma hora) gasto na cópia de dados de nossos dispositivos. Naquela época já usávamos o Spinnaker (um serviço de CD multinuvem para fornecer 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, o Kubernetes na URUS é administrado por um especialista (e sou eu). Em algum momento, outro administrador de sistema trabalhou comigo, mas depois descobrimos que já havíamos automatizado toda a rotina principal e havia cada vez mais tarefas por parte do nosso produto principal e fazia sentido direcionar recursos para isso.
Recebemos o que esperávamos do provedor de nuvem, pois iniciamos a cooperação sem ilusões. Se houve algum incidente, foi na sua maioria técnico e facilmente explicado pela relativa frescura do serviço. O principal é que a equipe do MCS elimine rapidamente as deficiências e responda rapidamente às dúvidas nos mensageiros.
Se eu comparar minha experiência com o Google Cloud Platform, no caso deles eu nem sabia onde estava o botão de feedback, pois simplesmente não havia necessidade dele. E se ocorresse algum problema, o próprio Google enviava notificações unilateralmente. Mas no caso do MCS, penso que a grande vantagem é que eles estão o mais próximo possível dos clientes russos - tanto geográfica como mentalmente.
Como vemos o trabalho com nuvens no futuro
Agora nosso trabalho está intimamente ligado ao Kubernetes e é totalmente adequado para nós do ponto de vista das tarefas de infraestrutura. Portanto, não pretendemos migrar dele para lugar nenhum, embora estejamos constantemente introduzindo novas práticas e serviços para simplificar tarefas rotineiras e automatizar novas, aumentar a estabilidade e confiabilidade dos serviços... Estamos lançando agora o serviço Chaos Monkey (especificamente , usamos o caoskube, mas isso não muda o conceito: ), que foi originalmente criado pela Netflix. O Chaos Monkey faz uma coisa simples: exclui um pod aleatório do Kubernetes em um momento aleatório. Isso é necessário para que nosso serviço possa conviver normalmente com o número de instâncias n–1, por isso nos treinamos para estarmos preparados para eventuais problemas.
Agora vejo o uso de soluções de terceiros – as mesmas plataformas em nuvem – como a única coisa certa para empresas jovens. Geralmente, no início de sua jornada, eles têm recursos limitados, tanto humanos 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; você pode obter deles rapidamente os recursos necessários para a operação dos serviços aqui e agora, e pagar por esses recursos após o fato. Quanto à empresa URUS, por enquanto permaneceremos fiéis ao Kubernetes na nuvem. Mas quem sabe teremos que expandir geograficamente, ou implementar soluções baseadas em alguns equipamentos específicos. Ou talvez a quantidade de recursos consumidos justifique o próprio Kubernetes em bare-metal, como nos velhos tempos. 🙂
O que aprendemos trabalhando com serviços em nuvem
Começamos a usar o Kubernetes em bare metal, e mesmo assim era bom à sua maneira. Mas seus pontos fortes foram revelados justamente como componente aaS na nuvem. Se você definir uma meta e automatizar tudo tanto quanto possível, será capaz de evitar o aprisionamento do fornecedor e a mudança entre provedores de nuvem levará algumas horas e as células nervosas permanecerão conosco. Podemos aconselhar outras empresas: se você deseja lançar seu próprio serviço (nuvem), tendo recursos limitados e velocidade máxima de desenvolvimento, comece agora mesmo alugando recursos em nuvem, e construa seu data center depois que a Forbes escrever sobre você.
Fonte: habr.com