No final de maio realizou uma reunião online sobre o tema . Falamos sobre containers, Kubernetes e orquestração em princípio, critérios de escolha de infraestrutura e muito mais. Os participantes compartilharam casos de sua própria prática.
Membros:
- Evgeniy Potapov, CEO da ITSumma. Mais da metade de seus clientes já estão migrando ou desejam migrar para o Kubernetes.
- Dmitry Stolyarov, CTO "Flant". Tem mais de 10 anos de experiência trabalhando com sistemas de contêineres.
- Denis Remchukov (também conhecido como Eric Oldmann), COO argotech.io, ex-RAO UES. Ele prometeu falar sobre casos do empreendimento “sangrento”.
- Andrey Fedorovsky, CTO “News360.com”Após adquirir a empresa por outro player, ele é responsável por diversos projetos e infraestrutura de ML e IA.
- Ivan Kruglov, engenheiro de sistemas, ex-Booking.com.A mesma pessoa que fez muito com o Kubernetes com as próprias mãos.
Tópicos:
- Insights dos participantes sobre containers e orquestração (Docker, Kubernetes, etc.); o que foi tentado na prática ou analisado.
- Caso: A empresa está construindo um plano de desenvolvimento de infraestrutura há anos. Como é tomada a decisão de construir (ou migrar a infraestrutura atual) para containers e Kuber ou não?
- Problemas no mundo nativo da nuvem, o que falta, vamos imaginar o que vai acontecer amanhã.
Seguiu-se uma discussão interessante, as opiniões dos participantes foram tão diferentes e geraram tantos comentários que quero compartilhá-los com vocês. Comer , e abaixo está um resumo da discussão.
O Kubernetes já é um marketing padrão ou excelente?
“Chegamos a isso (Kubernetes. - Ed.) quando ninguém sabia ainda. Viemos até ele mesmo quando ele não estava lá. Nós queríamos isso antes" - Dmitri Stolyarov
Foto de Reddit.com
De 5 a 10 anos atrás, havia um grande número de ferramentas e não existia um padrão único. A cada seis meses surgia um novo produto, ou até mais de um. Primeiro Vagrant, depois Salt, Chef, Puppet,... “e você reconstrói sua infraestrutura a cada seis meses. Você tem cinco administradores que estão constantemente ocupados reescrevendo configurações”, lembra Andrey Fedorovsky. Ele acredita que o Docker e o Kubernetes “excluíram” o resto. Docker se tornou um padrão nos últimos cinco anos, Kubernetes nos últimos dois anos. E é bom para a indústria.
Dmitry Stolyarov e sua equipe amam Kuber. Eles queriam essa ferramenta antes que ela aparecesse e chegaram a ela quando ninguém sabia sobre ela. Atualmente, por questão de comodidade, eles não contratam cliente se entenderem que não implementarão Kubernetes com ele. Ao mesmo tempo, segundo Dmitry, a empresa tem “muitas histórias de sucesso gigantescas sobre a reconstrução do terrível legado”.
Kubernetes não é apenas orquestração de contêineres, é um sistema de gerenciamento de configuração com uma API desenvolvida, um componente de rede, balanceamento L3 e controladores Ingress, o que torna relativamente fácil gerenciar recursos, escalar e abstrair das camadas inferiores da infraestrutura.
Infelizmente, na nossa vida temos que pagar por tudo. E esse imposto é grande, principalmente se falamos da transição para o Kubernetes de uma empresa com infraestrutura desenvolvida, como acredita Ivan Kruglov. Ele poderia trabalhar livremente tanto em uma empresa com infraestrutura tradicional quanto na Kuber. O principal é entender as características da empresa e do mercado. Mas, por exemplo, para Evgeny Potapov, que generalizaria o Kubernetes para qualquer ferramenta de orquestração de contêineres, tal questão não se coloca.
Evgeniy fez uma analogia com a situação da década de 1990, quando a programação orientada a objetos apareceu como uma forma de programar aplicações complexas. Naquela época, o debate continuou e novas ferramentas surgiram para apoiar a OOP. Então os microsserviços surgiram como uma forma de se afastar do conceito monolítico. Isso, por sua vez, levou ao surgimento de contêineres e de ferramentas de gerenciamento de contêineres. “Acho que em breve chegaremos a um momento em que não haverá dúvidas se vale a pena escrever um pequeno aplicativo de microsserviço; ele será escrito como um microsserviço por padrão”, acredita ele. Da mesma forma, Docker e Kubernetes eventualmente se tornarão a solução padrão sem necessidade de escolha.
O problema dos bancos de dados em apátridas
Foto por
Hoje em dia, existem muitas receitas para executar bancos de dados no Kubernetes. Até como separar a parte que funciona com o disco de E/S, condicionalmente, da parte de aplicação do banco de dados. É possível que no futuro os bancos de dados mudem tanto que serão entregues em uma caixa, onde uma parte será orquestrada através de Docker e Kubernetes, e em outra parte da infraestrutura, através de software separado, será fornecida a parte de armazenamento ? As bases mudarão como produto?
Essa descrição é semelhante ao gerenciamento de filas, mas os requisitos de confiabilidade e sincronização de informações em bancos de dados tradicionais são muito maiores, acredita Andrey. A taxa de acertos de cache em bancos de dados normais permanece em 99%. Se um trabalhador ficar inativo, um novo será iniciado e o cache “aquecerá” do zero. Até que o cache seja aquecido, o trabalhador funciona lentamente, o que significa que não pode ser carregado com carga do usuário. Embora não haja carga de usuário, o cache não aquece. É um círculo vicioso.
Dmitry discorda fundamentalmente - quóruns e fragmentos resolvem o problema. Mas Andrey insiste que a solução não é adequada para todos. Em algumas situações, o quorum é adequado, mas coloca carga adicional na rede. Um banco de dados NoSQL não é adequado em todos os casos.
Os participantes do encontro foram divididos em dois campos.
Denis e Andrey argumentam que tudo o que é gravado em disco – bancos de dados e assim por diante – é impossível de fazer no atual ecossistema Kuber. É impossível manter a integridade e consistência dos dados de produção no Kubernetes. Esta é uma característica fundamental. Solução: infraestrutura híbrida.
Mesmo bancos de dados modernos nativos da nuvem, como MongoDB e Cassandra, ou filas de mensagens como Kafka ou RabbitMQ, exigem armazenamentos de dados persistentes fora do Kubernetes.
Evgeniy objeta: “As bases em Kubera são uma lesão quase russa, ou quase empresarial, que está associada ao fato de que não há adoção de nuvem na Rússia”. As pequenas ou médias empresas no Ocidente são Cloud. Os bancos de dados Amazon RDS são mais fáceis de usar do que mexer no Kubernetes sozinho. Na Rússia, eles usam o Kuber “on-premise” e transferem bases para ele quando tentam se livrar do zoológico.
Dmitry também discordou da afirmação de que nenhum banco de dados pode ser mantido no Kubernetes: “Base é diferente de base. E se você empurrar um banco de dados relacional gigante, em nenhuma circunstância. Se você empurrar algo pequeno e nativo da nuvem, que esteja mentalmente preparado para uma vida semi-efêmera, tudo ficará bem.” Dmitry também mencionou que as ferramentas de gerenciamento de banco de dados não estão prontas para Docker ou Kuber, então surgem grandes dificuldades.
Ivan, por sua vez, tem certeza de que mesmo abstraindo os conceitos de stateful e stateless, o ecossistema de soluções empresariais em Kubernetes ainda não está pronto. Com o Kuber, é difícil manter os requisitos legislativos e regulamentares. Por exemplo, é impossível fazer uma solução de fornecimento de identidade onde sejam exigidas garantias rigorosas de identificação dos servidores, até ao hardware que está inserido nos servidores. Esta área está em desenvolvimento, mas ainda não há solução.
Os participantes não conseguiram chegar a acordo, pelo que não serão tiradas conclusões nesta parte. Vamos dar alguns exemplos práticos.
Caso 1. Cibersegurança de um “mega-regulador” com bases fora de Kubera
No caso de um sistema de cibersegurança desenvolvido, a utilização de containers e orquestração permite combater ataques e intrusões. Por exemplo, em um mega-regulador, Denis e sua equipe implementaram uma combinação de um orquestrador com um serviço SIEM treinado que analisa logs em tempo real e determina o processo de ataque, hacking ou falha. Em caso de ataque, tentativa de colocar algo, ou em caso de invasão de vírus ransomware, ele, por meio do orquestrador, coleta contêineres com aplicativos mais rápido do que eles são infectados, ou mais rápido do que o invasor os ataca.
Caso 2. Migração parcial dos bancos de dados da Booking.com para o Kubernetes
No Booking.com, o banco de dados principal é o MySQL com replicação assíncrona - existe um mestre e toda uma hierarquia de escravos. Quando Ivan deixou a empresa, foi lançado um projeto para transferir escravos que poderiam ser “fuzilados” com certos danos.
Além da base principal, há uma instalação Cassandra com orquestração de autoria própria, que foi escrita antes mesmo de Kuber entrar no mainstream. Não há problemas nesse sentido, mas é persistente em SSDs locais. O armazenamento remoto, mesmo dentro do mesmo data center, não é utilizado devido ao problema de alta latência.
A terceira classe de bancos de dados é o serviço de busca Booking.com, onde cada nó de serviço é um banco de dados. As tentativas de transferir o serviço de pesquisa para o Kuber falharam porque cada nó tem de 60 a 80 GB de armazenamento local, o que é difícil de “levantar” e “aquecer”.
Como resultado, o mecanismo de busca não foi transferido para o Kubernetes e Ivan não acredita que haverá novas tentativas em um futuro próximo. O banco de dados MySQL foi transferido pela metade: apenas os Slaves, que não têm medo de levar “baleado”. Cassandra se adaptou perfeitamente.
Seleção de infraestrutura como uma tarefa sem solução geral
Foto por
Digamos que temos uma nova empresa, ou uma empresa onde parte da infraestrutura é construída da maneira antiga. Ela constrói um plano de desenvolvimento de infraestrutura há anos. Como é tomada a decisão de construir infraestrutura em contêineres e Kuber ou não?
As empresas que lutam pelos nanossegundos estão excluídas da discussão. O conservadorismo saudável compensa em termos de fiabilidade, mas ainda há empresas que deveriam considerar novas abordagens.
Ivan: “Eu definitivamente começaria uma empresa na nuvem agora, simplesmente porque é mais rápido”, embora não necessariamente mais barato. Com o desenvolvimento do capitalismo de risco, as startups não têm grandes problemas com dinheiro e a principal tarefa é conquistar o mercado.
Ivan é da opinião de que o desenvolvimento da infraestrutura atual é um critério de seleção. Se houve um investimento sério no passado e deu certo, então não adianta refazê-lo. Se a infra-estrutura não estiver desenvolvida e houver problemas com ferramentas, segurança e monitorização, então faz sentido olhar para uma infra-estrutura distribuída.
O imposto terá que ser pago de qualquer maneira, e Ivan pagaria aquele que lhe permitisse pagar menos no futuro. "Porque simplesmente pelo facto de estar num comboio que outros estão a transportar, viajarei muito mais longe do que se estivesse sentado noutro comboio, no qual eu próprio teria de abastecer.“, diz Ivan. Quando a empresa é nova e os requisitos de latência são de dezenas de milissegundos, Ivan buscaria os “operadores” nos quais os bancos de dados clássicos são “embrulhados” hoje. Eles levantam uma cadeia de replicação, que se alterna em caso de failover, etc...
Para uma pequena empresa com alguns servidores, o Kubera não faz sentido”, diz Andrey. Mas se planeja crescer para centenas de servidores ou mais, então precisa de automação e de um sistema de gerenciamento de recursos. 90% dos casos valem o custo. Além disso, independentemente do nível de carga e recursos. Faz sentido que todos, desde startups até grandes empresas com um público de milhões de pessoas, olhem gradualmente para produtos de orquestração de contêineres. “Sim, este é realmente o futuro”, Andrey tem certeza.
Denis delineou dois critérios principais - escalabilidade e estabilidade de operação. Ele selecionará as ferramentas mais adequadas para a tarefa. “Pode ser um noname montado em seus joelhos e contém o Nutanix Community Edition. Esta poderia ser uma segunda linha na forma de um aplicativo no Kuber com um banco de dados no backend, que é replicado e possui parâmetros RTO e RPO especificados" (objetivos de tempo/ponto de recuperação - aprox.).
Evgeniy identificou um possível problema de pessoal. No momento, não existem muitos especialistas altamente qualificados no mercado que entendam a “coragem”. Na verdade, se a tecnologia escolhida for antiga, será difícil contratar alguém que não seja pessoas de meia-idade que estão entediadas e cansadas da vida. Embora outros participantes acreditem que se trata de uma questão de formação de pessoal.
Se colocarmos a questão da escolha: lançar uma pequena empresa na Nuvem Pública com bancos de dados em Amazon RDS ou “on premissa” com bancos de dados em Kubernetes, então, apesar de algumas deficiências, o Amazon RDS passou a ser a escolha dos participantes.
Como a maioria dos ouvintes do encontro não são da empresa “sangrenta”, então soluções distribuídas são o que devemos buscar. Os sistemas de armazenamento de dados devem ser distribuídos, confiáveis e criar latência medida em unidades de milissegundos, dezenas no máximo“, resumiu Andrey.
Avaliando o uso do Kubernetes
O ouvinte Anton Zhbankov fez uma pergunta armadilha aos apologistas do Kubernetes: como vocês selecionaram e conduziram um estudo de viabilidade? Por que Kubernetes, por que não máquinas virtuais, por exemplo?
Foto por
Dmitry e Ivan responderam. Em ambos os casos, por tentativa e erro, foi tomada uma sequência de decisões, com a qual ambos os participantes chegaram ao Kubernetes. Agora as empresas estão começando a desenvolver software de forma independente que faz sentido transferir para o Kuber. Não estamos falando de sistemas clássicos de terceiros, como o 1C. O Kubernetes ajuda quando os desenvolvedores precisam fazer lançamentos rapidamente, com Melhoria Contínua ininterrupta.
A equipe de Andrey tentou criar um cluster escalonável baseado em máquinas virtuais. Os nós caíram como dominós, o que às vezes levou ao colapso do cluster. “Teoricamente você pode terminar e apoiar com as mãos, mas é tedioso. E se houver uma solução no mercado que lhe permita trabalhar fora da caixa, ficaremos felizes em aceitá-la. E, como resultado, mudamos”, diz Andrey.
Existem padrões para tais análises e cálculos, mas ninguém pode dizer quão precisos eles são em hardware real em operação. Para os cálculos também é importante entender cada ferramenta e ecossistema, mas isso não é possível.
O que nos espera
Foto por
À medida que a tecnologia evolui, aparecem cada vez mais peças díspares e, então, ocorre uma transição de fase, aparece um fornecedor que matou dinheiro suficiente para que tudo se reunisse em uma única ferramenta.
Você acha que chegará um momento em que haverá uma ferramenta como o Ubuntu para o mundo Linux? Talvez uma única ferramenta de conteinerização e orquestração inclua o Kuber. Isso tornará mais fácil a construção de nuvens locais.
A resposta foi dada por Ivan: “O Google agora está construindo o Anthos – esta é a sua oferta de pacote que implanta a nuvem e inclui Kuber, Service Mesh, monitoramento – todo o hardware necessário para microsserviços locais”. Estamos quase no futuro."
Denis também mencionou Nutanix e VMWare com o produto vRealize Suite, que pode realizar uma tarefa semelhante sem conteinerização.
Dmitry partilhou a sua opinião de que reduzir a “dor” e reduzir os impostos são duas áreas onde podemos esperar melhorias.
Para resumir a discussão, destacamos os seguintes problemas da infraestrutura moderna:
- Três participantes identificaram imediatamente um problema com estado.
- Vários problemas de suporte de segurança, incluindo a possibilidade de o Docker acabar com múltiplas versões de Python, servidores de aplicativos e componentes.
Gastos excessivos, que é melhor discutir em reunião separada.
Um desafio de aprendizagem, pois a orquestração é um ecossistema complexo.
Um problema comum na indústria é o uso indevido de ferramentas.O resto das conclusões cabe a você. Ainda existe a sensação de que não é fácil para a combinação Docker+Kubernetes se tornar uma parte “central” do sistema. Por exemplo, os sistemas operacionais são instalados primeiro no hardware, o que não pode ser dito sobre contêineres e orquestração. Talvez no futuro, os sistemas operacionais e os contêineres se fundam com o software de gerenciamento em nuvem.
Foto porGostaria de aproveitar para cumprimentar minha mãe e lembrar que temos um grupo no Facebook , canal com publicações interessantes de vários blogs de tecnologia. E meu canal , onde falo sobre gerenciamento de desenvolvimento em empresas de produtos.
Fonte: habr.com