- O Glasskube é um gerenciador de pacotes open source para Kubernetes, apresentado como uma ferramenta que torna implantação, atualização e configuração 20 vezes mais rápidas do que ferramentas como Helm ou Kustomize
- Os usuários podem implantar pacotes pela UI do Glasskube, pela CLI ou via GitOps, com inspiração na simplicidade do Homebrew e do npm
- Entre os principais recursos estão instalação de pacotes pela UI sem precisar procurar repositórios Helm, entrada de configuração com segurança de tipos, injeção de valores entre pacotes, instalação com reconhecimento de dependências e atualizações seguras previamente testadas
- Todos os pacotes do Glasskube são gerenciados como recursos personalizados e podem ser tratados com GitOps, com suporte também a múltiplos repositórios e implantação de pacotes privados
- Atualmente oferece suporte a Kubernetes Dashboard, cert-manager, Ingress-NGINX Controller, Kube Prometheus Stack, Cloud Native PG e outros, e a versão beta pode ser instalada via Homebrew
O problema de gerenciamento de pacotes no Kubernetes que o Glasskube quer resolver
- O Glasskube é um gerenciador de pacotes open source para Kubernetes
- Ele é apresentado como uma ferramenta que torna o trabalho de implantar, atualizar e configurar pacotes no Kubernetes 20 vezes mais rápido do que ferramentas como Helm ou Kustomize
- Foi inspirado na simplicidade do Homebrew e do npm, e o usuário pode escolher uma das seguintes formas de uso
- UI do Glasskube
- CLI do Glasskube
- Implantação direta de pacotes via GitOps
- O contexto de desenvolvimento veio da experiência de mais de 5 anos trabalhando no ecossistema Kubernetes e enfrentando dificuldades recorrentes com gerenciamento de pacotes, configuração e implantação
- No trabalho anterior, muito tempo era gasto criando templates e escrevendo documentação para comandos e conceitos difíceis de entender
- Ferramentas como Homebrew, apt e dnf, por serem fáceis de usar e darem menos problemas, serviram como comparação na criação do Glasskube
Fluxo de instalação e configuração
- A versão beta pode ser instalada via Homebrew
brew install glasskube/tap/glasskube
- Outras opções de instalação estão no guia de instalação
- Depois de instalar a CLI, é preciso executar o seguinte comando para instalar os componentes necessários no cluster
glasskube bootstrap
- Quando o bootstrap do cluster terminar, é possível iniciar a UI do gerenciador de pacotes
glasskube serve
- Esse comando abre
http://localhost:8580 no navegador padrão, e o usuário pode navegar pelos pacotes disponíveis e instalá-los
Recursos de UI, configuração e gerenciamento de dependências
- A UI do Glasskube reúne todos os pacotes em um só lugar, permitindo instalar pacotes no cluster sem precisar buscar repositórios Helm separadamente
- A configuração de pacotes pode ser feita com entradas tipadas e seguras pela UI ou por um questionário interativo da CLI
- É possível injetar facilmente valores de outros pacotes, ConfigMap e Secret
- A proposta é evitar o uso de arquivos
values.yaml sem tipagem e sem documentação
- O gerenciamento de dependências permite que pacotes Glasskube sejam usados e referenciados por vários outros pacotes
- Os pacotes dependentes são instalados no namespace correto
- O README descreve isso como algo no estilo de “é assim que os umbrella charts deveriam ter funcionado desde o início”
Atualizações, GitOps e suporte a repositórios
- As atualizações de pacotes permitem visualizar previamente as atualizações pendentes para a versão desejada e executá-las com um clique ou com um comando da CLI
- Todas as atualizações são pré-testadas pela suíte de testes do Glasskube
- Reações e comentários sobre pacotes podem ser deixados no GitHub discussions ou dentro da própria UI do Glasskube
- A integração com GitOps é baseada no gerenciamento de todos os pacotes Glasskube como recursos personalizados
- A integração com Renovate também está em andamento, e a issue relacionada está em renovatebot/renovate#29322
- É possível usar vários repositórios e pacotes privados
- Isso pode ser usado para implantar pacotes de serviços internos da empresa
- O projeto sugere um cenário em que desenvolvedores conseguem configurar facilmente serviços internos sempre atualizados
Arquitetura de instalação de pacotes
- O fluxo
glasskube install [package] tem uma estrutura em que a UI ou a CLI usam o Client junto com o repositório de pacotes e a API do Kubernetes
- A UI se conecta ao Client por meio do servidor local
http://localhost:8580
- A CLI se conecta ao Client via cobra CLI
- O Client primeiro consulta o Package Repo para validação do pacote
- Após a validação, ele cria o recurso personalizado
Package na API do Kubernetes
- Dentro do cluster,
PackageController e PackageInfoController fazem a reconciliação
- O
PackageController reconcilia Package e, se necessário, cria PackageInfo
- O
PackageInfoController atualiza o manifesto do pacote a partir do repositório de pacotes
- O manifesto atualizado é refletido em
PackageInfo
- Depois disso, o
PackageController implanta o pacote no Kubernetes
- O Kubernetes retorna o status do pacote ao Client
Pacotes suportados e informações do projeto
- O Glasskube já oferece suporte a vários pacotes
- A lista completa de pacotes suportados e planejados pode ser vista em glasskube.dev/packages
- Um projeto relacionado é o Glasskube Apps Operator
glasskube/operator
- Problemas, bugs e pedidos de funcionalidade podem ser enviados via Discord ou issues no GitHub
- O Glasskube é distribuído sob a licença Apache 2.0
1 comentários
Comentários do Hacker News
Pode ser um passo na direção certa, mas hoje o maior problema do gerenciamento de pacotes no Kubernetes parece difícil de resolver com um gerenciador de pacotes
No dia a dia, o mais difícil é que YAMLs aninhados vão se acumulando em várias camadas e o resultado fica imprevisível
Por exemplo, um ApplicationSet do ArgoCD cria várias Applications, essas Applications renderizam charts do Helm, e dentro desses charts há CRDs usados por operadores diversos como Strimzi, Grafana e Vector
O YAML tem uma sintaxe pobre e não existe um padrão para renderização de templates, então quando se faz uma mudança no nível mais alto é quase impossível saber qual YAML de fato será injetado na API do Kubernetes
No fim, isso leva a tentativa e erro todo mês, implantações blue-green caras e centenas de minutos de debugging
Acho que o caminho certo é ter suporte a uma linguagem de programação de verdade
Idealmente, seria necessário um sistema de tipos estático que não fosse Turing-completo e garantisse término, algo parecido com um Starlark com tipos
A ideia é fazer o glasskube[bot] comentar nas pull requests de GitOps o diff exato dos recursos que realmente mudariam em todos os clusters conectados
Esse diff é gerado por um controller executado dentro do cluster
Dá para pensar nisso como uma análise ao estilo do codecov, mas voltada apenas para mudanças de recursos
Parece uma abordagem interessante para gerenciamento de pacotes, e parece boa para algo como um cluster no estilo Homebrew
Ainda assim, pessoalmente prefiro a combinação helmfile + Renovate + pipeline, nem que seja só para manter consistência no repositório
Por exemplo, um botão
update allparece bem assustador em um cluster com alguma importânciaEm algo como um projeto pessoal, continua sendo uma ferramenta bacana
O controller de pacotes lembra bastante o antigo Tiller do Helm, que virou um grande problema de segurança em várias empresas e acabou removido no Helm 3 em favor de um processamento no cliente baseado em configmap; fico curioso para saber como este projeto pretende contornar isso
Também é possível configurar pela CLI com as flags
--dry-rune--output yamle depois colocar no GitAlém disso, estão trabalhando em pull requests para que o Renovate ofereça suporte a atualizações de pacotes: https://github.com/renovatebot/renovate/issues/29322
O Helm 3 agora é uma ferramenta client-side, então ele mesmo não consegue impor RBAC
O OLM introduziu Operator Groups(https://olm.operatorframework.io/docs/advanced-tasks/operato...) para fornecer permissões no nível de operador
Algo parecido pode ser introduzido nos pacotes do Glasskube, e embora o próprio Glasskube ainda precise de permissões bem amplas, dá para limitar o escopo dos pacotes e colocar permissões mais granulares
Tradicionalmente, pacotes de aplicação são binários imutáveis com versão fixada que incluem etapas antes e depois da instalação, são construídos pensando em uma plataforma específica e dependências específicas, e têm configuração extremamente limitada no momento da instalação
O motivo de os pacotes funcionarem bem é que eles são projetados para ambientes muito específicos e minimizam o que pode ser alterado na instalação
Mesmo assim, pacotes de sistema operacional ainda exigem enormes quantidades de testes, desenvolvimento e correções contínuas dentro dessas condições restritas
Se o pacote que você instala hoje parece simples, é porque talvez centenas de horas tenham sido investidas na plataforma, nos componentes e nas versões atuais
Os “pacotes” do Kubernetes na verdade não são pacotes, mas algo mais próximo de um conjunto de instruções sobre os componentes a instalar e configurar, muitas vezes incluindo vários conjuntos de aplicações separadas
Essa diferença aparece de duas formas: os “pacotes” de K8s têm uma definição muito frouxa e alta variabilidade, e são criados por todo tipo de gente, de todo tipo de jeito, fazendo todo tipo de suposição sobre o estado do sistema onde serão instalados
Para que um “pacote” de Kubernetes funcione, várias camadas de dependências e configurações precisam estar alinhadas
A versão da API do K8s, a forma como os componentes do K8s são instalados e executados, ACLs, a ausência de componentes preexistentes que possam causar conflito, o travamento de versões dos componentes e contêineres instalados pelo pacote e sua compatibilidade com outras coisas no cluster, além da configuração do usuário, tudo precisa bater
Atualizações também são confusas de forma parecida, já que não há conceito de árvore de releases estáveis nem de rolling release, e isso se parece com instalar arquivos
.deb,.rpmou.dmgaleatórios no sistema operacional e torcer para dar certoHoje não existe nada que faça tudo isso
Para tornar o empacotamento de Kubernetes tão fluido quanto o empacotamento de binários por plataforma, seria necessária toda uma comunidade de mantenedores e um modelo de rolling release como o do Homebrew, ou branches estáveis de release por versão
No fim, um projeto como ArtifactHub ou Homebrew teria que gerenciar todos os pacotes de uma única forma, mas isso é um trabalho enorme e não parece nada rentável
A ideia é centralizar todas as atualizações e testá-las com workflows de CI/CD, para que os usuários possam desfrutar de upgrades suaves e testados
Usuários também podem hospedar repositórios e pacotes próprios, mas por padrão queremos fornecer diretamente um conjunto opinativo de pacotes
Também já estamos pensando em builds voltadas para diferentes versões ou ambientes de Kubernetes, e isso provavelmente vai se tornar necessário no futuro para incorporar mais configurações já na etapa de build
Não sei se um gerenciador de pacotes para K8s pode ficar tão simples quanto brew ou apt
Principalmente porque os valores mudam conforme o ambiente de destino, e quase todo usuário tem um ambiente “flake de neve” próprio
Não me atrai usar um prompt em estilo REPL ou uma UI web para configurar esses valores
A dor principal continua sem solução: escrever charts Helm é sofrido, é preciso gerenciar valores por ambiente, e seria ótimo não precisar conectar valores entre charts
Equipes de plataforma estão criando plataformas internas para desenvolvedores para padronizar melhor as configurações de Kubernetes entre times e clusters, e permitir que desenvolvedores façam apenas pequenos ajustes
Pela minha experiência, essas configurações tão diferentes precisam ser reduzidas, e esse também é um dos motivos pelos quais o Glasskube foi criado
Concordo 100% que escrever charts Helm é sofrido, e queremos mudar isso no futuro
Pacotes do Glasskube continuam sendo configuráveis, mas fornecem valores padrão úteis
Também é possível referenciar facilmente no Glasskube valores de configuração de outros pacotes, então você não precisa fornecer o mesmo valor várias vezes
Eu crio muitos operadores de Kubernetes e lido com frequência com problemas de Helm e OLM
A documentação diz que “upgrades de CRD são tratados pelo Glasskube para evitar que CRs e operadores fiquem desalinhados”, mas ao buscar “CRD” na documentação não aparece nada muito concreto
Essa é uma das maiores dores que tenho com Helm hoje, então queria saber se vocês podem compartilhar o plano
[1] <https://stackable.tech/en/>
[2] <https://www.youtube.com/watch?v=Q8OSYOgBdCc>
Isso é tratado via Manifest ou helm-controller
A documentação será atualizada
Acho que o Kubernetes é fundamentalmente limitado por um modelo de operador simplista demais
Gosto da ideia geral, mas reduzir todo o modelo a “estado atual, estado desejado, próxima ação” é na prática impossível
No fim, todo o workflow acaba indo para a lógica da próxima ação, e como há operadores demais observando o mesmo estado do sistema, fica difícil entender como os vários componentes vão interagir
O problema do Helm é um caso particular desse problema maior
Fazendo uma analogia, é o mesmo tipo de problema que a programação frontend enfrenta com o DOM
Adotar um paradigma de DOM virtual/reducer como o do React ajudaria bastante a resolver isso
Existe um estado, um objetivo e perturbações no caminho até esse objetivo, e se você quer uma ferramenta poderosa e flexível, esse nível de abstração me parece adequado
O problema é que as características físicas e a disposição das máquinas fazem uma diferença tão grande que o custo de virtualizar ou simular isso de forma significativa acaba sendo alto demais
Então, em vez disso, valida-se se o estado de configuração funciona sobre um subconjunto da estrutura física
É por isso que existem ambientes
dev,stagingeprod, além de práticas como blue-green deployment, análise canary e rollout parcialSe você precisa de ferramentas assim para usar K8s, provavelmente é melhor usar outra solução
Kubernetes não foi feito para ser usado sem conhecimento prévio, e é difícil
A menos que você construa um PaaS completo, é difícil escapar dessa complexidade
Acho que este projeto está com a direção de marketing errada
Isso tem pouco a ver com o Helm
Para mim, o Helm é principalmente uma linguagem de templates, e a forma de configurar e instalar no cluster K8s é via kubeapps, Helm CLI e ArgoCD
Essa abordagem também quebra um ótimo paradigma de IaC
Porque, depois de fazer o bootstrap do ArgoCD, o ideal é ter uma estrutura que referencie apenas o repositório Git
A demo não mostra como usar recursos de template, como suporte a
form, e só mostra o restoAinda continuo com a sensação de que há algo de errado com o Helm, então sinceramente gosto desta ferramenta em si, mas acho que vai fracassar com a abordagem atual
As grandes empresas não precisam desta ferramenta, então será difícil conseguir adoção suficiente
Tanto o Kubeapps quanto o Helm funcionam bem e, mesmo que digam que vão substituir o Helm, provavelmente ainda manterão suporte ao Helm por muito tempo
O problema do Helm é que ele fica mais complexo à medida que os charts crescem
A estrutura em que praticamente tudo fica dentro de uma única pasta
templatesé uma bagunça, YAML não é adequado para templates, e ovalues.yamlfica grande demaisMais detalhes sobre as opções de configuração podem ser vistos na documentação de configuração de pacotes: https://glasskube.dev/docs/design/package-config/
O argumento de venda de ser mais rápido que o Helm não me atrai muito
Nunca senti que o problema do Helm fosse velocidade
Parece interessante
Ajudaria a entender melhor se houvesse uma explicação curta de como isso se encaixa ou se compara com ferramentas existentes como o ArgoCD
Assisti ao vídeo e um dos utilitários de instalação era o Argo, então claramente parece ocupar outro nicho, mas ainda não entendi qual é
Ele é frequentemente usado para que desenvolvedores possam verificar o estado das aplicações centrais da empresa sem acesso ao cluster
O Glasskube foca nos pacotes dos quais essas aplicações centrais dependem
Ele gerencia o ciclo de vida dos componentes de infraestrutura, testa atualizações e fornece caminhos de upgrade
Você também pode colocar pacotes do Glasskube no repositório GitOps e sincronizá-los com o cluster via ArgoCD, e o restante fica por conta do PackageController