Clusters virtuais do Kubernetes: um novo modelo para multilocação

Experimente o vcluster, uma implementação de código aberto que aborda certos aspectos de modelos típicos de isolamento baseados em namespace e cluster.

Se você conversar com pessoas que executam o Kubernetes em produção, uma das reclamações que você ouvirá com frequência é como a multilocação é difícil. As organizações usam dois modelos principais para compartilhar clusters Kubernetes com vários locatários, mas ambos apresentam problemas. Os modelos são:

Multilocação baseada em namespace
Multilocação baseada em cluster

O primeiro modelo comum de multitenancy é baseado no isolamento de namespace, onde locatários individuais (uma equipe desenvolvendo um microsserviço, por exemplo) são limitados a usar um ou mais namespaces no cluster. Embora esse modelo possa funcionar para algumas equipes, ele apresenta falhas. Primeiro, restringir os membros da equipe ao acesso a recursos apenas em namespaces significa que eles não podem administrar objetos globais no cluster, como definições de recursos personalizados (CRDs). Este é um grande problema para equipes que trabalham com CRDs como parte de seus aplicativos ou em uma dependência (por exemplo, construindo sobre Kubeflow ou Argo Pipelines).

Em segundo lugar, um problema de manutenção muito maior a longo prazo é a necessidade de adicionar constantemente exceções às regras de isolamento do namespace. Por exemplo, ao usar políticas de rede para bloquear namespaces individuais, os administradores provavelmente descobrirão que algumas equipes eventualmente precisarão executar vários microsserviços que se comunicam entre si. Os administradores de cluster precisam, de alguma forma, adicionar exceções para esses casos, rastreá-las e gerenciar todos esses casos especiais. É claro que a complexidade aumenta à medida que o tempo passa e mais equipes começam a integrar o Kubernetes.

O outro modelo padrão de multilocação, que usa o isolamento no nível do cluster, é ainda mais problemático. Nesse cenário, cada equipe obtém seu próprio cluster, ou possivelmente até vários clusters (dev, test, UAT, staging, etc.). O problema imediato com o uso do isolamento de cluster é acabar com muitos clusters para gerenciar, o que pode ser uma grande dor de cabeça. E todos esses clusters precisam de recursos caros de computação em nuvem, mesmo que ninguém os use ativamente, como à noite ou no fim de semana. Como Holly Cummins aponta em sua palestra na KubeCon 2021, essa explosão de clusters tem um impacto perigoso no meio ambiente.

Até recentemente, os administradores de cluster tinham que escolher entre esses dois modelos insatisfatórios, escolhendo aquele que melhor se adaptasse ao seu caso de uso e ao seu orçamento. No entanto, existe um conceito relativamente novo no Kubernetes chamado clusters virtuais, que se adapta melhor a muitos casos de uso.

O que são clusters virtuais?

Um cluster virtual é um cluster Kubernetes compartilhado que aparece para o locatário como um cluster dedicado. Em 2020, nossa equipe do Loft Labs lançou o vcluster, uma implementação de código aberto de clusters virtuais do Kubernetes.

Com o vcluster, os engenheiros podem provisionar clusters virtuais sobre clusters Kubernetes compartilhados. Esses clusters virtuais são executados dentro dos namespaces regulares do cluster subjacente. Assim, um administrador pode criar clusters virtuais e distribuí-los aos locatários ou, se uma organização já usa multilocação baseada em namespace, mas os usuários estão restritos a um único namespace, os próprios usuários locatários podem ativar esses clusters virtuais dentro de seu namespace.

Isso combina o melhor das duas abordagens de multilocação descritas acima: os locatários ficam restritos a um único namespace, sem a necessidade de exceções, pois têm controle total dentro do cluster virtual, mas acesso muito restrito fora do cluster virtual.

Assim como um administrador de cluster, o usuário tem controle total dentro de um cluster virtual. Isto permite-lhes fazer qualquer coisa dentro do cluster virtual sem afetar outros inquilinos no cluster de anfitrião partilhado subjacente. Nos bastidores, o vcluster faz isso executando um servidor API Kubernetes e alguns outros componentes em um pod dentro do namespace no cluster host. O usuário envia solicitações para esse servidor API de cluster virtual dentro de seu namespace, em vez de para o servidor API do cluster subjacente. O estado do cluster virtual também é totalmente separado do cluster subjacente. Recursos como implantações ou entradas criados dentro do cluster virtual existem apenas no armazenamento de dados do cluster virtual e não são persistidos no etcd do cluster subjacente.

Essa arquitetura oferece benefícios significativos em relação aos modelos de isolamento de namespace e de cluster:

Como o usuário é um administrador em seu cluster virtual, ele pode gerenciar objetos de todo o cluster, como CRDs, o que supera a grande limitação do isolamento do namespace.
Como os usuários se comunicam com seus próprios servidores API, o tráfego é mais isolado do que em um cluster compartilhado normal. Isso também fornece federação, que pode ajudar no dimensionamento de solicitações de API em clusters de alto tráfego.
Os clusters virtuais são muito rápidos para provisionar e desmontar novamente, de modo que os usuários podem se beneficiar do uso de ambientes verdadeiramente efêmeros e potencialmente ativar muitos deles, se necessário.

[ Aprenda o que é necessário para desenvolver aplicativos nativos da nuvem usando ferramentas modernas. Faça download do e-book microsserviços nativos do Kubernetes com Quarkus e MicroProfile. ]

Como usar clusters virtuais

Existem muitos casos de uso para clusters virtuais, mas aqui estão alguns que vimos a maioria dos usuários de vcluster adotar.

Ambientes de desenvolvimento

O provisionamento e o gerenciamento de ambientes de desenvolvimento são atualmente o caso de uso mais popular do vcluster. Os desenvolvedores que escrevem serviços executados em clusters Kubernetes precisam de um lugar para executar seus aplicativos enquanto estão em desenvolvimento. Embora seja possível usar ferramentas como o Docker Compose para orquestrar contêineres para ambientes de desenvolvimento, os desenvolvedores que codificam em clusters Kubernetes terão uma experiência muito mais próxima de como seus serviços são executados em produção.

Outra opção para desenvolvimento local é usar uma ferramenta como Minikube ou Docker Desktop para provisionar clusters Kubernetes, mas isso tem algumas desvantagens. Os desenvolvedores devem possuir e manter essa pilha de cluster local, o que é um fardo e uma grande perda de tempo. Além disso, esses clusters locais podem precisar de muito poder de computação, o que é difícil em máquinas de desenvolvimento local. Todos nós sabemos o quão quentes os laptops podem ficar durante o desenvolvimento, e pode não ser uma boa ideia adicionar Kubernetes à mistura.

A execução de clusters virtuais como ambientes de desenvolvimento em um cluster de desenvolvimento compartilhado aborda essas preocupações. Além disso, como mencionado acima, os vclusters são rápidos de provisionar e excluir. Os administradores podem remover um vcluster simplesmente excluindo o namespace do host subjacente com um único comando kubetctl ou executando o comando vcluster delete fornecido com a ferramenta de interface de linha de comando. A velocidade da infraestrutura e das ferramentas nos fluxos de trabalho de desenvolvimento é crítica porque melhorar os tempos de ciclo dos desenvolvedores pode aumentar sua produtividade e felicidade.

Pipelines de CI/CD

A integração/desenvolvimento contínuos (CI/CD) é outro forte caso de uso para clusters virtuais. Normalmente, os pipelines provisionam sistemas em teste (SUTs) para executar conjuntos de testes. Freqüentemente, as equipes desejam que esses sistemas sejam novos, sem nenhum lixo acumulado que possa interferir nos testes. As equipes que executam pipelines longos com muitos testes podem provisionar e destruir SUTs diversas vezes em uma execução de teste. Se você passou muito tempo provisionando clusters, provavelmente percebeu que ativar um cluster Kubernetes costuma ser uma operação demorada. Mesmo nas nuvens públicas mais sofisticadas, isso pode levar mais de 20 minutos.

Clusters virtuais são rápidos e fáceis de provisionar com o vcluster. Ao executar o comando vcluster create para provisionar um novo cluster virtual, tudo o que está envolvido nos bastidores é executar um gráfico Helm e instalar alguns pods. É uma operação que geralmente leva apenas alguns segundos. Qualquer pessoa que execute longos conjuntos de testes sabe que qualquer tempo perdido no processo pode fazer uma enorme diferença na rapidez com que a equipe de controle de qualidade e os engenheiros recebem feedback.

Além disso, as organizações poderiam usar a velocidade do vcluster para melhorar quaisquer outros processos onde muitos clusters são provisionados, como a criação de ambientes para workshops ou treinamento de clientes.

Testando diferentes versões do Kubernetes

Conforme mencionado anteriormente, o vcluster executa um servidor API Kubernetes no namespace do host subjacente. Ele usa o servidor API K3s (Lightweight Kubernetes) por padrão, mas você também pode usar k0s, Amazon Elastic Kubernetes Service ou o servidor API Kubernetes upstream regular. Ao provisionar um vcluster, você pode especificar a versão do Kubernetes para executá-lo, o que abre muitas possibilidades. Você poderia:

Execute uma versão mais recente do Kubernetes no cluster virtual para ver como um aplicativo se comportará em relação ao servidor API mais recente.
Execute vários clusters virtuais com diferentes versões do Kubernetes para testar um operador em um conjunto de diferentes distros e versões do Kubernetes durante o desenvolvimento ou durante testes completos.

Saber mais

Pode não haver uma solução perfeita para a multilocação do Kubernetes, mas os clusters virtuais resolvem muitos problemas com os modelos de locação atuais. A velocidade e a facilidade de uso do Vcluster fazem dele um ótimo candidato para muitos cenários onde você preferiria usar um cluster compartilhado, mas também deseja dar aos usuários a flexibilidade para administrar seus clusters. Existem muitos casos de uso do vcluster além dos descritos neste artigo.

Para saber mais, acesse vcluster.com ou, se quiser se aprofundar no código, baixe-o no repositório GitHub. A equipe do Loft Labs mantém o vcluster e adoramos ter ideias sobre ele. Adicionamos muitos recursos com base no feedback do usuário. Sinta-se à vontade para abrir questões ou PRs. Se você quiser conversar conosco primeiro sobre suas ideias ou tiver alguma dúvida ao explorar o vcluster, também temos um canal vcluster no Slack.