No final de maio realizamos um meetup online sobre . Discutimos sobre contêineres, Kubernetes e orquestração em geral, sobre critérios de escolha da infraestrutura e muito mais. Os participantes compartilharam casos da própria experiência.
Participantes:
- Evgeny Potapov, CEO da «ITSumma». Mais da metade de seus clientes já estão migrando ou desejam migrar para Kubernetes.
- Dmitry Stolyarov, CTO da «Flant». Possui mais de 10 anos de experiência com sistemas de contêiner.
- Denis Remchukov (aka Eric Oldmann), COO da argotech.io, ex-RAO EES. Prometeu contar sobre casos no ‘sanguinário’ setor empresarial.
- Andrey Fedorovsky, CTO da «News360.com». Após a compra da empresa por outro jogador, ele é responsável por uma série de projetos de ML e AI e pela infraestrutura.
- Ivan Kruglov, engenheiro de sistemas, ex-Booking.com.Aquele que fez muito por conta própria com Kubernetes.
Temas:
- Insights dos participantes sobre contêineres e orquestração (Docker, Kubernetes e outros); o que testaram na prática ou analisaram.
- Caso: Na empresa, está sendo elaborado um plano de desenvolvimento da infraestrutura para os próximos anos. Como é tomada a decisão de construir (ou migrar) a infraestrutura para contêineres e Kubernetes ou não?
- Problemas no mundo cloud-native, o que falta, vamos sonhar sobre o que será amanhã.
Uma discussão interessante surgiu, as opiniões dos participantes eram tão diferentes e provocaram tantos comentários que queremos compartilhá-las com vocês. Há , e abaixo – um resumo da discussão.
Kubernetes é já um padrão ou um excelente marketing?
«Chegamos até ele (Kubernetes — Nota do editor) quando ainda ninguém sabia sobre ele. Chegamos até ele quando ele ainda não existia. Nós o queríamos antes disso» — Dmitry Stolyarov
Foto do Reddit.com
Há 5-10 anos, havia uma enorme quantidade de ferramentas, e não havia um único padrão. A cada seis meses, um novo produto aparecia, ou até mais de um. Primeiro Vagrant, depois Salt, Chef, Puppet,… ‘e você reestrutura sua infraestrutura a cada seis meses. Você tem cinco administradores que estão constantemente ocupados reescrevendo configurações’ — lembra Andrey Fedorovsky. Ele acredita que Docker e Kubernetes ‘sufocaram’ os demais. Docker se tornou o padrão nos últimos cinco anos, Kubernetes — nos últimos dois anos. E isso é bom para a indústria..
Dmitry Stolyarov e sua equipe amam o Kuber. Eles queriam essa ferramenta antes mesmo de ela aparecer, e a descobriram quando ninguém ainda sabia sobre ela. No momento, por questões de conveniência, eles não aceitam clientes se acharem que não implementarão o Kubernetes. No entanto, segundo Dmitry, a empresa tem "várias histórias de sucesso gigantescas na reestruturação de legados assustadores".
Kubernetes não é apenas uma orquestração de contêineres, é um sistema de gerenciamento de configuração com uma API avançada, um componente de rede, balanceamento L3 e controladores de Ingress, que permite gerenciar recursos de maneira relativamente fácil, escalar e se abstrair das camadas inferiores da infraestrutura.
Infelizmente, em nossas vidas, tudo tem um preço. E esse custo é alto, especialmente ao falar sobre a transição para o Kubernetes em uma empresa com infraestrutura desenvolvida, como acredita Ivan Kruglov. Ele poderia facilmente trabalhar tanto em uma empresa com infraestrutura tradicional quanto com o Kuber. O principal é entender as características da empresa e do mercado. Mas, por exemplo, para Evgeny Potapov, que generalizaria o Kubernetes como qualquer ferramenta de orquestração de contêineres, essa questão não é relevante.
Evgeny fez uma analogia com a situação nos anos 1990, quando surgiu a programação orientada a objetos como uma forma de programar aplicativos complexos. Naquela época, os debates não cessavam e novas ferramentas surgiam para apoiar OOP. Então, apareceram microsserviços como uma maneira de se afastar do conceito monolítico. Isso, por sua vez, levou ao surgimento de contêineres e ferramentas para gerenciá-los. "Acho que em breve chegaremos ao ponto em que não haverá mais uma questão sobre se devemos escrever um pequeno aplicativo de forma microsserviço; isso será feito por padrão como microsserviço", acredita ele. Da mesma forma, Docker e Kubernetes se tornarão soluções padrão com o tempo, sem necessidade de escolha.
O problema das bases é stateless.
Foto por
Nos dias de hoje existem muitas receitas para executar bancos de dados no Kubernetes. Até mesmo como separar a parte que trabalha com disco I/O da, por assim dizer, parte de aplicação do banco. É possível que no futuro os bancos de dados se transformem tanto que sejam fornecidos em um pacote, onde uma parte será orquestrada via Docker e Kubernetes, e a outra parte da infraestrutura, através de software separado, fornecerá a parte de armazenamento? Os bancos de dados se transformarão como produto?
Essa descrição se assemelha à gestão de filas, mas as exigências em termos de confiabilidade e sincronia das informações em bancos de dados tradicionais são muito maiores, afirma Andrey. A taxa de acerto do cache em bancos normais permanece em torno de 99%. Se um worker falhar, um novo será iniciado, e o cache será "aquecido" desde o início. Enquanto o cache não estiver aquecido, o worker opera lentamente, o que significa que não se pode permitir carga de usuários. Enquanto não houver carga de usuários, o cache não aquecerá. Esse é um ciclo vicioso.
Dmitry discorda completamente, - os quóruns e sharding resolvem o problema. Mas Andrey insiste que a solução não serve para todos. Em algumas situações, o quórum é adequado, mas ele impõe uma carga adicional à rede. O banco NoSQL não se aplica a todos os casos.
Os participantes do meetup se dividiram em dois grupos.
Denis e Andrey afirmam que tudo o que escreve no disco - bancos e outros - não é possível fazer na atual ecossistema do Kubernetes. É impossível manter a integridade e consistência dos dados produtivos no Kubernetes. Essa é uma característica fundamental. Solução: infraestrutura híbrida.
Mesmo os bancos de dados cloud native modernos, como MongoDB e Cassandra, ou filas de mensagens como Kafka ou RabbitMQ, exigem armazenamentos de dados permanentes fora do Kubernetes.
Evgeny contesta: "Bancos no Kubernetes são uma questão traumática para a Rússia, ou quase empresarial, que está relacionada ao fato de que na Rússia não há adoção de nuvem". Pequenas ou médias empresas no Ocidente operam em Nuvem. Usar bancos Amazon RDS é mais simples do que se preocupar com Kubernetes. Na Rússia, usam Kubernetes "on-premise" e transferem bancos para ele quando tentam se livrar do zoológico.
Dmitry também discordou da afirmação de que nenhum banco pode ser mantido no Kubernetes: "Banco é banco. E se você colocar um enorme banco relacional - de jeito nenhum. Se colocar algo pequeno e cloud native, que está moralmente preparado para uma vida semi-efêmera, tudo ficará bem." Dmitry também mencionou que as ferramentas de gerenciamento de bancos não estão preparadas nem para Docker, nem para Kubernetes, portanto surgem grandes complicações.
Ivan, por sua vez, está confiante de que, mesmo se abstrairmos os conceitos de stateful e stateless, o ecossistema de soluções enterprise no Kubernetes ainda não está pronto. É complicado atender às exigências de órgãos legislativos e regulamentares com o Kuber. Por exemplo, não é possível criar uma solução de fornecimento de identidade que exija garantias rigorosas de identificação do servidor, até mesmo em relação ao hardware inserido nos servidores. Esta área está se desenvolvendo, mas, por enquanto, não há uma solução.
Os participantes não conseguiram chegar a um acordo, portanto, não haverá conclusões nesta parte. Vamos trazer alguns exemplos práticos.
Caso 1. Cibersegurança do 'megaregulador' com bancos de dados fora do Kuber
Em um sistema de cibersegurança avançado, o uso de contêineres e orquestração permite repelir ataques e intrusões. Por exemplo, em um megaregulador, Denis e sua equipe implementaram uma combinação de orquestrador com um serviço SIEM treinado, que analisa logs em tempo real e determina o processo de ataque, violação ou falha. Em caso de ataque, tentativas de colocar algo, ou durante uma infecção por ransomware, ele, através do orquestrador, levanta contêineres com aplicações mais rapidamente do que elas são infectadas, ou mais rapidamente do que são atacadas por um invasor.
Caso 2. Mudança parcial dos bancos de dados do Booking.com para Kubernetes
No Booking.com, o banco de dados principal é MySQL com replicação assíncrona — há um master e uma hierarquia inteira de slaves. Quando Ivan deixou a empresa, havia um projeto em andamento para transferir os slaves, que podiam ser 'desligados' com um certo dano.
Além do banco principal, existe uma instalação do Cassandra com uma orquestração feita sob medida, que foi desenvolvida antes do Kubernetes se tornar mainstream. Não há problemas nesse aspecto, mas ela usa armazenamento persistente em SSD locais. Armazenamentos remotos, mesmo dentro de um único data center, não são utilizados devido ao problema da alta latência.
A terceira classe de bancos de dados é o serviço de busca do Booking.com, onde cada nó do serviço é um banco de dados. As tentativas de transferir o serviço de busca para o Kuber não tiveram sucesso, porque cada nó possui entre 60 e 80 GB de armazenamento local, que é difícil de 'subir' e 'aquecê-lo'.
No final, o motor de busca não foi transferido para o Kubernetes, e Ivan não acredita que haverá novas tentativas em breve. O banco MySQL foi transferido parcialmente: apenas os Slaves, que não é um problema 'desligar'. O Cassandra 'se adaptou' muito bem.
Escolha de infraestrutura como uma tarefa sem solução universal
Foto por
Suponha que temos uma nova empresa, ou uma empresa onde parte da infraestrutura foi construída de forma antiga. Ela desenvolve um plano de desenvolvimento de infraestrutura para os próximos anos. Como é tomada a decisão de construir a infraestrutura em contêineres e Kubernetes ou não?
Empresas que competem por nanossegundos estão excluídas da discussão. Um conservadorismo saudável se paga em termos de confiabilidade, mas ainda assim, há empresas que deveriam considerar novas abordagens.
Ivan: "Eu definitivamente começaria uma empresa em cloud agora, simplesmente porque é mais rápido", embora não necessariamente mais barato. Com o desenvolvimento do capital de risco, as startups não têm grandes problemas com dinheiro, e a principal tarefa é conquistar o mercado.
Ivan acredita que o desenvolvimento atual da infraestrutura é um critério de escolha. Se no passado houve investimentos significativos, e isso está funcionando, não faz sentido refazer. Contudo, se a infraestrutura não está desenvolvida e há problemas com ferramentas, segurança e monitoramento, faz sentido considerar a infraestrutura distribuída.
O imposto terá que ser pago de qualquer forma, e Ivan pagaria aquele que lhe permitisse pagar menos no futuro. "Porque simplesmente por estar em um trem que é movido por outros, eu irei muito mais longe do que se eu entrasse em outro trem, onde teria que abastecer o combustível eu mesmo." — diz Ivan. Quando a empresa é nova, e os requisitos de latência são de dezenas de milissegundos, Ivan estaria olhando para "operadores", onde hoje "empacotam" bancos de dados clássicos. Eles levantam uma cadeia de replicação que se alterna automaticamente em caso de falha, etc.
Para uma pequena empresa com alguns servidores no Kubernetes não há sentido — afirma Andrei. Mas se ela planeja crescer para centenas de servidores ou mais, a automação e o sistema de gerenciamento de recursos são necessários. 90% dos casos justificam os custos. E isso, independentemente do nível de carga e de recursos. Faz sentido para todos, desde startups até grandes empresas com audiências de milhões, olhar gradualmente para produtos de orquestração de contêineres. "Sim, isso realmente é o futuro", acredita Andrei.
Denis definiu dois critérios principais — escalabilidade e estabilidade de operação. Ele escolherá as ferramentas que melhor se adequam a essa tarefa. "Isso pode ser um dispositivo genérico montado de forma improvisada, rodando o Nutanix Community Edition. Isso pode ser uma segunda linha na forma de um aplicativo em Kuber com um banco de dados no backend, que é replicado e possui parâmetros definidos de RTO e RPO" (objetivos de tempo de recuperação/ponto de recuperação — exemplo).
Evgeny destacou um possível problema com a força de trabalho. Atualmente, o mercado não possui muitos especialistas altamente qualificados que entendam "as entranhas". De fato, se a tecnologia escolhida é antiga, é difícil contratar alguém além de pessoas mais velhas que estão entediadas e cansadas da vida. Embora outros participantes achem que isso é uma questão de formação.
Se a questão for a escolha: iniciar uma pequena empresa na nuvem pública com bancos de dados na Amazon RDS ou "on-premise" com bancos de dados no Kubernetes, apesar de algumas desvantagens, a escolha dos participantes foi pela Amazon RDS.
Como a maioria dos ouvintes do meetup não são do "sanguinário" setor empresarial, soluções distribuídas são o que devemos almejar. Sistemas de armazenamento de dados devem ser distribuídos, confiáveis e criar latências medíveis em milissegundos, no máximo em dezenas., — resumiu Andrei.
Avaliação do uso do Kubernetes
O ouvinte Anton Zhbankov fez uma pergunta armadilha aos apologistas do Kubernetes: como escolheram e conduziram a análise técnico-econômica? Por que Kubernetes, e não máquinas virtuais, por exemplo?
Foto por
A resposta veio de Dmitry e Ivan. Em ambos os casos, através de tentativas e erros, foi feita uma sequência de decisões, resultando na escolha de Kubernetes. Agora as empresas começam a desenvolver software que vale a pena migrar para o Kuber. Não se trata de sistemas clássicos de terceiros, como o 1C. O Kubernetes ajuda quando os desenvolvedores precisam lançar atualizações rapidamente, em um Continuous Improvement constante.
A equipe de Andrei tentou criar um cluster escalável baseado em máquinas virtuais. Os nós caíam como dominós, o que às vezes resultava na queda do cluster. "Teoricamente, é possível finalizar e manter manualmente, mas é cansativo. E se há uma solução no mercado que permite trabalhar de forma pronta, vamos para ela. E nós acabamos fazendo isso", — conta Andrei.
Existem padrões para esse tipo de análise e cálculo, mas ninguém pode dizer o quão precisos são em hardware real em operação. Para os cálculos, também é importante entender cada ferramenta e ecossistema, mas isso é impossível.
O que nos aguarda
Foto por
Quando as tecnologias evoluem, surgem cada vez mais peças desconectadas, e então ocorre uma transição de fase; aparece um fornecedor que gastou o suficiente em 'dinheiro' para que tudo se conecte em uma única ferramenta.
Você não acha que chegará um momento em que aparecerá uma ferramenta que se tornará o que o Ubuntu é para o mundo Linux? Talvez uma única ferramenta de conteinerização e orquestração inclua o Kubernetes. Com isso, será mais fácil construir nuvens on-premise.
Ivan respondeu: 'O Google está construindo o Anthos — é sua oferta de pacote, que implanta nuvens e inclui Kuber, Service Mesh, monitoramento — toda a articulação necessária para microsserviços em on-premise. Estamos quase no futuro.'
Denis também mencionou a Nutanix e a VMWare com o produto vRealize Suite, que pode lidar com essa tarefa sem a conteinerização.
Dmitry compartilhou a opinião de que a diminuição da 'dor' e a redução de impostos são duas áreas em que devemos esperar melhorias.
Resumindo a discussão, destacamos os seguintes problemas da infraestrutura moderna
- Três participantes apontaram problemas com stateful.
- Vários problemas de suporte à segurança, incluindo a probabilidade de que várias versões do Python, servidores de aplicação e componentes acabem no Docker.
O desperdício, sobre o qual seria melhor realizar um meet-up separado.
O problema do treinamento, já que a orquestração representa um ecossistema complexo.
Um problema geral da indústria é o uso de ferramentas para fins inadequados.As outras conclusões ficam com você. Por enquanto, permanece a sensação de que a combinação Docker+Kubernetes enfrenta dificuldades para se tornar a parte 'central' do sistema. Por exemplo, sistemas operacionais são instalados primeiro no hardware, o que não se pode dizer sobre containers e orquestração. Talvez, no futuro, os sistemas operacionais e containers se integrem com softwares de gerenciamento de nuvem.
Foto porAproveitando a oportunidade, quero enviar um abraço para 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 a gestão de desenvolvimento em empresas de produtos.
Fonte: habr.com
