A vCluster desenvolve clusters Kubernetes virtuais dentro de clusters físicos de host Kubernetes, diminuindo significativamente o uso de recursos e melhorando a flexibilidade e gerenciamento.
Fora do conjunto de diretrizes do webscale, a engenharia de plataforma costumava ser vista como uma área avançada até recentemente. Seria complicado para equipes empresariais tradicionais adotá-la? As empresas estão realmente interessadas em gerenciar sua infraestrutura como os principais provedores de nuvem? Segundo a Gartner, até 2026, 80% das empresas deverão estar praticando isso.
A engenharia de plataforma é interpretada de maneiras variadas por diferentes pessoas, e não há uma abordagem única que determine a maneira correta de fazê-la. No entanto, os objetivos principais são amplamente entendidos. Por um lado, busca-se acelerar o processo de desenvolvimento, eliminando obstáculos e implementando autoatendimento. Por outro lado, visa estabelecer padrões em áreas essenciais como segurança e conformidade, a fim de controlar os custos e a complexidade.
A engenharia de plataforma obteve um grande sucesso ao acelerar o processo de desenvolvimento de software. Graças a tecnologias como containers, microservices, Kubernetes, CI/CD e o moderno fluxo de trabalho de desenvolvimento, as equipes distribuídas agora podem contar com uma experiência de desenvolvimento mais ágil, eficiente e automatizada.
Porém, será fácil afirmar que o controle central é parte integrante da engenharia de plataforma? Atualmente, não é tão simples assim. Estamos no meio de uma reação prolongada contra o alto custo e a complexidade do modelo operacional da nuvem. Atualmente, o aspecto de controle central da engenharia de plataforma não é apenas um desafio para a equipe de engenharia de plataforma, mas também para os CFOs, à medida que os custos da nuvem aumentam e as empresas buscam reduzir despesas. A nuvem e o Kubernetes são tecnologias permanentes, porém resolver o problema do controle central quebrado é um dilema financeiro significativo que muitas empresas enfrentam atualmente.
Por isso, um projeto de código aberto chamado vCluster está progredindo significativamente. O vCluster visa aprimorar a abstração do cluster, que é o cerne do modelo operacional Kubernetes, proporcionando diversos benefícios para as empresas que utilizam essa tecnologia. Além de diminuir consideravelmente a utilização excessiva de recursos, o que pode resultar em economias significativas, o vCluster também oferece maior agilidade e controle centralizado para as equipes de engenharia de plataforma.
A via aberta de código para o potencial
Os fundadores do vCluster (e do Loft Labs), Lukas Gentele e Fabian Kramm, se conheceram durante a faculdade na Universidade de Mannheim. Ambos estudantes de ciência da computação, compartilharam uma trajetória tecnológica semelhante, começando com Java e bancos de dados de gráficos como Neo4j, e depois migrando para tecnologias web como PHP e JavaScript. Mais tarde, passaram a se dedicar à linguagem Go, percebendo seu potencial futuro, especialmente com o surgimento do Docker e Kubernetes. Enquanto Gentele iniciou uma consultoria de TI durante seus estudos, Kramm foi seu primeiro cliente.
No ramo de serviços de TI, Gentele e Kramm lançaram o DevSpace, um projeto que é uma alternativa ao Docker Compose, focado em simplificar os processos do Kubernetes. Eles disponibilizaram o projeto no GitHub, sendo esta a primeira vez que se envolveram no desenvolvimento e na manutenção de um projeto de código aberto. Apesar de já terem feito contribuições e correções em projetos de código aberto, nunca haviam liderado um projeto como mantenedores. Ao testemunharem o impacto positivo da prática de código aberto – através da distribuição, utilização, valorização e contribuição por parte das pessoas – eles se tornaram entusiastas desse modelo.
Após se formarem na faculdade, os dois iniciaram o desenvolvimento de um produto PaaS (descrito como “semelhante ao Heroku para Kubernetes” por Gentele). Embora tenham sido inicialmente rejeitados ao aplicar para o Y Combinator, receberam um convite para tentar novamente e acabaram participando do programa de aceleração SkyDeck na U.C. Berkeley. Eventualmente, perceberam que operar um negócio de PaaS era bastante desafiador. Eles não foram os primeiros a enfrentar essa dificuldade, como demonstrado pelas lutas de Cloud Foundry, Heroku e os fundadores do Docker para monetizar o dotCloud.
“Identificamos que tínhamos uma quantidade significativa de usuários utilizando nosso PaaS de forma gratuita, mas com pouca disposição para pagar”, afirmou Gentele. “A partir dessa experiência, compreendemos que gerenciar grandes clusters Kubernetes e disponibilizá-los para os usuários era uma tarefa complexa e dispendiosa. Descobrimos uma abordagem mais eficiente e promissora, que se revelou como uma oportunidade maior do que o próprio PaaS. Essa ideia pode ser valiosa para qualquer pessoa que trabalhe com clusters Kubernetes.”
As frotas são uma concepção equivocada.
Nos estágios iniciais da implementação de contêineres, houve uma aceitação da ideia de considerar os servidores como “gado” (hardware intercambiável que pode ser substituído), em oposição a “animais de estimação” (cada servidor tratado de forma individual com atenção e manutenção próprias), como um conceito fundamental para a transformação de servidores em clusters.
Por um longo tempo, houve uma discussão na área da arquitetura sobre a escolha entre criar vários pequenos clusters ou um único cluster grande. De acordo com Gentele, o Kubernetes foi desenvolvido para operar em grande escala, não sendo ideal para ser executado em pequenos clusters de cinco nós devido à duplicação e ineficiência resultantes.
À medida que os principais provedores de computação em nuvem introduziram suas plataformas Kubernetes, surgiram pequenos grupos de servidores e frotas compostas por vários grupos como as principais unidades de abstração oferecidas às empresas, acompanhadas de soluções de “gestão de frotas” para coordenar todos os componentes em funcionamento e manter os serviços em sincronia na abordagem de “grupos de pequenos grupos”.
O Gentele afirma que uma parcela significativa do custo atual da computação em nuvem se deve principalmente à prática inicial dos provedores de nuvem.
A primeira consequência de adotar a abordagem da frota é que ocorre uma sobrecarga nos componentes de infraestrutura essenciais, os quais são pagos repetidamente. As equipes de plataforma buscam a padronização em serviços fundamentais, como Istio e Open Policy Agent, que são desenvolvidos para operar em grande escala. No entanto, ao executá-los em pequena escala, a eficiência é comprometida. Na abordagem da frota, esses serviços são instalados em cada cluster, resultando em uma duplicação significativa de serviços básicos, uma vez que toda a infraestrutura da plataforma é replicada em diversos clusters menores.
A principal consequência é que os clusters permanecem ativos o tempo todo, sem possibilidade de desligamento fácil. Nas principais ofertas de nuvem, não é possível desligar um cluster inteiro com um simples clique, sendo necessário um processo manual que envolve a implementação de uma política e cerca de 30 minutos para desativar todos os serviços de plataforma conectados ao cluster. Além disso, é complicado determinar quando um cluster está realmente inativo, uma vez que os diversos serviços de plataforma, como segurança, conformidade, backup, monitoramento e registro, continuam em execução em segundo plano.
Título: VCluster: Adição através de subtração
Gentele e Kramm perceberam que a forma como a frota abordava clusters poderia ser significativamente aprimorada, e que a capacidade de multilocação do Kubernetes poderia ser reimaginada para ir além das práticas convencionais de namespace.
No ano de 2023, foi apresentado o vCluster e concebido o termo “clusters virtuais”, uma ideia para formar clusters Kubernetes virtuais mais leves. Assim como as redes privadas virtuais estabelecem uma rede virtual em cima de uma infraestrutura física, os clusters virtuais criam ambientes isolados de Kubernetes em um cluster físico de Kubernetes compartilhado.
Cluster é uma distribuição certificada Kubernetes que permite que os clusters virtuais se comportem como qualquer outro cluster Kubernetes, exceto por uma diferença significativa: cada cluster virtual gerencia seus próprios namespaces, pods e serviços, mas compartilha componentes da plataforma pesada, como Istio ou Open Policy Agent, que são executados pelo cluster físico subjacente. Isso elimina a necessidade de replicar a pilha da plataforma nos clusters virtuais, evitando assim a sobrecarga de serviços de plataforma.
Cada vCluster possui seu próprio servidor API e plano de controle, o que garante um isolamento robusto entre os usuários e permite que as equipes de plataforma desenvolvam políticas personalizadas para segurança e governança. Com essa estrutura, é possível criar namespaces exclusivos, implementar recursos personalizados, proteger os dados do cluster com backups específicos e aplicar políticas de controle de acesso personalizadas para os usuários.
O vCluster oferece às equipes de plataforma uma maior rapidez e flexibilidade em comparação com um cluster físico. Enquanto um cluster físico pode levar muito tempo para reiniciar, o vCluster reinicia em apenas seis segundos, tornando-o uma opção mais eficiente para serviços pesados como Istio.
“Kubernetes é elogiado por suas APIs, ferramentas e padronização, mas a abordagem dos provedores de nuvem na configuração de clusters pequenos está resultando em desafios semelhantes aos enfrentados com servidores físicos em termos de custo e complexidade”, afirmou Gentele. Ele comparou a situação atual com a necessidade dos anos 90 de intervenção manual em data centers para provisionar servidores e conceder credenciais. Atualmente, o uso difundido do Kubernetes está levando a uma sobrecarga de aplicativos em clusters, resultando em duplicação excessiva.
Clusters vClusters tornam o cluster Kubernetes mais leve e temporário, de forma semelhante ao impacto das máquinas virtuais nos servidores físicos e dos contêineres nas cargas de trabalho em geral.
“Implementar pequenos clusters Kubernetes dedicados foi uma ideia extremamente desafiadora desde o início, devido ao alto custo e à complexidade de gerenciamento envolvida,” observou Gentele. “Isso poderia resultar em uma grande quantidade de clusters individuais, exigindo a manutenção de elementos como controlador de ingress, gerenciador de certificados, Prometheus e métricas em cada um deles. Isso demanda um esforço significativo e torna a sincronização uma tarefa árdua.”
Agrupamento com base em números.
O vCluster possui mais de 6.000 estrelas no GitHub e conta com mais de 120 colaboradores. O projeto atraiu a atenção de especialistas em Kubernetes, incluindo o ex-CTO da Rancher e co-fundador Darren Shepherd, que tem promovido a utilização de clusters virtuais. Empresas como Adobe, CoreWeave e Codefresh foram elogiadas por sua implementação do vCluster em eventos como KubeCon.
Gentele e Kramm, da startup Loft Labs, receberam recentemente investimento para expandir as capacidades empresariais relacionadas ao vCluster. A rodada de financiamento Série A de $24 milhões foi liderada pela Khosla Ventures, conhecida por ser a primeira investidora institucional em empresas como GitLab e OpenAI.
A proposta de negócios da startup em torno do vCluster causou entusiasmo especial devido à sua funcionalidade de “modo de repouso”, que desliga automaticamente clusters virtuais inativos. Geralmente, as empresas que operam clusters tendem a mantê-los funcionando o tempo todo. O produto da Loft Labs avalia a atividade dos clusters virtuais, acompanhando as solicitações de API recebidas e utilizando o modo de repouso para ajustar automaticamente os clusters virtuais quando não estão em uso, a fim de economizar recursos de nuvem e reduzir os custos gerais.
O vCluster pode auxiliar na otimização da infraestrutura em nuvem, resultando em uma redução de custos. Além disso, proporciona às empresas uma maior clareza no controle central e na agilidade do desenvolvimento. Ao alocar recursos de forma mais eficiente, o vCluster disponibiliza um servidor API separado e um plano de controle para cada cluster virtual, permitindo às equipes de plataforma ter mais flexibilidade e controle na gestão, segurança, alocação de recursos e dimensionamento dos clusters Kubernetes.
