O URUS experimentou o Kubernetes de diferentes formas: uma implantação bare metal autônoma no Google Cloud e depois mudou sua plataforma para Mail.ru Cloud Solutions (MCS). Como escolher um novo provedor de nuvem e como migrar para ele em um recorde de duas horas, é informado por Igor Shishkin (
t3ran ), administrador sênior de sistemas da URUS.
O que Urus faz
Existem muitas maneiras de melhorar a qualidade do ambiente urbano e uma delas é torná-lo ecológico. É exatamente nisso que a empresa URUS - Smart Digital Services está trabalhando. Implementa soluções que ajudam as empresas a monitorar indicadores ambientais importantes e reduzir impactos ambientais negativos. Os sensores coletam dados sobre composição do ar, nível de ruído e outros parâmetros e os enviam para uma única plataforma "Urus-Ekomon" para análise e preparação de recomendações.
Como é o trabalho de "Urus" por dentro
Um cliente típico da URUS é uma empresa localizada dentro ou perto de uma área residencial. Pode ser uma fábrica, porto, depósito ferroviário ou qualquer outra instalação. Se o nosso cliente já recebeu um aviso, foi multado por poluição ambiental ou deseja fazer menos barulho, reduzir a quantidade de emissões perigosas, ele chega até nós e já oferecemos uma solução pronta para o monitoramento ambiental.
Um gráfico do monitoramento da concentração de H2S mostra as emissões noturnas regulares de uma instalação próximaOs dispositivos que usamos no URUS contêm vários sensores que coletam informações sobre o conteúdo de certos gases, níveis de ruído e outros dados para avaliar a situação ambiental. O número exato de sensores é sempre determinado por uma tarefa específica.
Dependendo da medição específica, os dispositivos com sensores podem ser localizados nas paredes de edifícios, postes e outros locais arbitrários. Cada um desses dispositivos coleta informações, as agrega e as envia ao gateway de recebimento de dados. Lá, salvamos os dados para armazenamento a longo prazo e pré-processamos para análises subsequentes. O exemplo mais simples do que obtemos após a análise é um índice de qualidade do ar, também conhecido como AQI.
Ao mesmo tempo, muitos outros serviços funcionam em nossa plataforma, mas basicamente eles são de natureza de serviço. Por exemplo, um serviço de notificação envia notificações aos clientes se algum dos parâmetros monitorados (por exemplo, o conteúdo de CO
2 ) exceder o valor permitido.
Como armazenamos dados. A história de Kubernetes no bare metal
O projeto de monitoramento ecológico da URUS possui vários data warehouses. Em um, mantemos os dados "brutos" - o que recebemos diretamente dos próprios dispositivos. Esse armazenamento é uma fita "magnética", como em cassetes antigas, com um 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 de sensores e leituras dos próprios dispositivos, afiliação a organizações, locais etc. Essas informações permitem avaliar dinamicamente como um determinado indicador mudou durante um certo período de tempo . Usamos o armazenamento de dados brutos, inclusive como backup e para restaurar dados pré-processados, se houver necessidade.
Quando estávamos procurando maneiras de resolver o problema de armazenamento há vários anos, tínhamos duas opções para escolher uma plataforma: Kubernetes e OpenStack. Mas como o último parece bastante monstruoso (basta olhar para sua arquitetura para ver isso), decidimos pelo Kubernetes. Outro argumento a seu favor foi o controle relativamente simples do software, a capacidade de cortar com mais flexibilidade até os nós de ferro em recursos.
Paralelamente ao desenvolvimento do Kubernetes, também estudamos maneiras de armazenar dados, enquanto mantivemos todos os nossos armazenamentos no Kubernetes em nosso hardware, recebemos uma excelente experiência. Tudo o que tínhamos vivido no Kubernetes: armazenamento completo do estado, sistema de monitoramento, CI / CD. Kubernetes se tornou nossa plataforma tudo-em-um.
Mas queríamos trabalhar com o Kubernetes como um serviço, e não nos envolver em seu suporte e desenvolvimento. Além disso, não gostamos do custo de seu conteúdo em bare metal, e o desenvolvimento sempre foi necessário para nós! Por exemplo, uma das primeiras tarefas foi integrar os controladores Kubernetes Ingress à infraestrutura de rede da nossa organização. Essa é uma tarefa complicada, especialmente se você imaginar que naquele momento nada estava pronto para o gerenciamento de recursos programáticos, como registros DNS ou alocação de IP. Mais tarde, começamos a experimentar um data warehouse externo. Não chegamos à implementação do controlador de PVC, mas mesmo assim ficou claro que esse era um grande campo de trabalho, para o qual era necessário destacar especialistas individuais.
Migrando para a solução temporária do Google Cloud Platform
Percebemos que isso não poderia continuar mais e transferimos nossos dados de bare metal para o Google Cloud Platform. De fato, para a 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 por uma solução do Google. Então, pareceu-nos economicamente mais rentável, mais próximo do Upstream, sem mencionar o fato de que o próprio Google é uma espécie de PoC Kubernetes em produção.
O primeiro problema sério apareceu no horizonte em paralelo com o crescimento da nossa base de clientes. Quando se tornou necessário armazenar dados pessoais, enfrentamos uma opção: trabalhamos com o Google e violamos as leis russas ou estamos procurando uma alternativa na Federação Russa. A escolha, em geral, era previsível. :)
Como vimos o serviço de nuvem perfeito
No início da pesquisa, já sabíamos o que queríamos obter do futuro provedor de nuvem. Que serviço procurávamos:
- Rápido e flexível . Para 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 o Kubernetes, e agora a tarefa era minimizar seu custo para aumentar ou pelo menos manter a eficácia do uso dessa solução.
- Automatizado . Planejamos trabalhar com o serviço por meio da API, sem gerentes e telefonemas ou situações em que você precisa gerar manualmente várias dezenas de nós no modo de emergência. Como a maioria dos nossos processos é automatizada, esperávamos o mesmo de um serviço em nuvem.
- Com servidores na Federação Russa . Obviamente, planejávamos cumprir a lei russa e o mesmo 152-FZ.
Naquela época, os fornecedores de aaS da Kubernetes eram poucos na Rússia. Ao escolher um fornecedor, era importante não comprometer nossas prioridades. A equipe do Mail.ru Cloud Solutions, com a qual começamos a trabalhar e ainda estamos trabalhando, nos forneceu um serviço totalmente automatizado com suporte à API e um painel de controle conveniente no qual existe o Horizon - com isso, poderíamos rapidamente aumentar um número arbitrário de nós.
Como conseguimos migrar para o MCS em duas horas
Nessas realocações, muitas empresas enfrentam dificuldades e falhas, mas, no nosso caso, não o foram. Tivemos sorte: como já estávamos trabalhando no Kubernetes antes do início da migração, apenas consertamos três arquivos e lançamos nossos serviços em uma nova plataforma em nuvem, no MCS. Deixe-me lembrá-lo de que naquela época finalmente tínhamos deixado o bare metal e morávamos no Google Cloud Platform. Como a mudança em si não levou mais de duas horas, mais um pouco mais (cerca de uma hora) para copiar dados de nossos dispositivos. Em seguida, já usamos o Spinnaker (um serviço de CD com várias nuvens para fornecer entrega contínua). Também o adicionamos rapidamente ao novo cluster e continuamos a funcionar normalmente.
Graças à automação dos processos de desenvolvimento, o CI / CD Kubernetes no URUS é ocupado por um especialista (e sou eu). Em algum momento, outro administrador de sistema trabalhou comigo, mas depois descobrimos que já tínhamos automatizado toda a rotina principal e, pelo lado do nosso produto principal, havia mais e mais tarefas e fazia sentido direcionar recursos para isso.
Recebemos do provedor de nuvem o que esperávamos, desde que começamos a cooperação sem ilusões. Se houve algum incidente, na maior parte técnico, o que pode ser facilmente explicado pela relativa frescura do serviço. O principal é que a equipe do MCS elimina rapidamente as falhas e responde rapidamente às perguntas dos mensageiros instantâneos.
Se compararmos a experiência com o Google Cloud Platform, no caso deles, eu nem sabia onde fica o botão de feedback, pois simplesmente não era necessário. E se algum problema acontecesse, o próprio Google enviava notificações unilateralmente. Mas, no caso do MCS, uma grande vantagem, acredito que eles sejam o mais próximo possível dos clientes russos - tanto geográfica quanto mentalmente.
Como vemos trabalhando com nuvens no futuro
Agora, nosso trabalho está intimamente ligado ao Kubernetes e nos convém completamente em termos de tarefas de infraestrutura. Portanto, não planejamos migrar para algum lugar, embora constantemente introduzamos novas práticas e serviços para simplificar tarefas rotineiras e automatizar novas, 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 Caos Monkey faz uma coisa simples: em um momento arbitrário, ele exclui um sub arbitrário no Kubernetes. Isso é necessário para o nosso serviço viver normalmente com o número de instâncias n-1, para que nos acostumemos a estar preparados para qualquer mau funcionamento.
Agora vejo o uso de soluções de terceiros - as mesmas plataformas em nuvem - como a única certa para empresas jovens. Geralmente, no início da jornada, eles são limitados em recursos, humanos e financeiros, e construir e manter sua própria nuvem ou data center é muito caro e demorado. Os provedores de nuvem podem minimizar esses custos, obter rapidamente os recursos necessários para que os serviços funcionem aqui e agora e pagar por esses recursos. Quanto à empresa Urus, por enquanto permaneceremos fiéis a Kubernetes na nuvem. Mas quem sabe, talvez tenhamos que expandir geograficamente ou implementar soluções baseadas em alguns equipamentos específicos. Ou talvez a quantidade de recursos consumidos justifique seus próprios Kubernetes no metal puro, como nos bons velhos tempos. :)
O que aprendemos com nossa experiência com serviços em nuvem
Começamos a usar o Kubernetes no bare metal, e mesmo lá era bom à sua maneira. Mas seus pontos fortes foram revelados precisamente como um componente aaS na nuvem. Se você definir uma meta e automatizar tudo o máximo possível, poderá evitar o aprisionamento do fornecedor e a movimentação entre os provedores de nuvem levará algumas horas, e as células nervosas permanecerão conosco. Podemos aconselhar outras empresas: se você deseja iniciar seu serviço (em nuvem), com recursos limitados e velocidade máxima para desenvolvimento, comece agora mesmo com o aluguel de recursos em nuvem e construa seu data center depois que a Forbes escrever sobre você.