- Glasskube se presenta como un gestor de paquetes open source para Kubernetes que hace que desplegar, actualizar y configurar sea 20 veces más rápido que con herramientas como Helm o Kustomize
- Los usuarios pueden desplegar paquetes mediante la UI de Glasskube, la CLI o un flujo GitOps, y está inspirado en la simplicidad de Homebrew y npm
- Sus funciones principales incluyen instalación de paquetes desde la UI sin buscar repositorios de Helm, entradas de configuración con seguridad de tipos, inyección de valores entre paquetes, instalación con reconocimiento de dependencias y actualizaciones seguras previamente probadas
- Todos los paquetes de Glasskube se gestionan como recursos personalizados y pueden manejarse con GitOps; también admite múltiples repositorios y despliegue de private package
- Actualmente soporta Kubernetes Dashboard, cert-manager, Ingress-NGINX Controller, Kube Prometheus Stack, Cloud Native PG y otros; la versión beta puede instalarse con Homebrew
El problema de gestión de paquetes de Kubernetes que Glasskube busca resolver
- Glasskube es un gestor de paquetes open source para Kubernetes
- Se presenta como una herramienta que hace que desplegar, actualizar y configurar paquetes en Kubernetes sea 20 veces más rápido que con herramientas como Helm o Kustomize
- Está inspirado en la simplicidad de Homebrew y npm, y los usuarios pueden elegir una de estas formas de uso
- UI de Glasskube
- CLI de Glasskube
- Despliegue directo de paquetes mediante GitOps
- El contexto de su desarrollo es la experiencia de haber trabajado durante más de 5 años en el ecosistema Kubernetes y haber enfrentado dificultades constantes con la gestión, configuración y despliegue de paquetes
- En los flujos de trabajo existentes, se invertía mucho tiempo en crear plantillas y escribir documentación para comandos y conceptos difíciles de entender
- Herramientas como Homebrew, apt y dnf, fáciles de usar y con menos problemas, sirvieron como punto de comparación para el desarrollo de Glasskube
Flujo de instalación y configuración
- La versión beta puede instalarse con Homebrew
brew install glasskube/tap/glasskube
- Otras opciones de instalación están en la installation guide
- Después de instalar la CLI, se ejecuta el siguiente comando para instalar en el clúster los componentes necesarios
glasskube bootstrap
- Una vez terminado el bootstrap del clúster, se puede iniciar la UI del gestor de paquetes
glasskube serve
- Este comando abre
http://localhost:8580 en el navegador predeterminado, donde los usuarios pueden explorar e instalar los paquetes disponibles
Funciones de UI, configuración y gestión de dependencias
- La UI de Glasskube reúne todos los paquetes en un solo lugar, lo que permite instalar paquetes en el clúster sin tener que buscar repositorios de Helm por separado
- La configuración de paquetes puede definirse mediante la UI o un cuestionario interactivo en la CLI, usando valores de entrada con seguridad de tipos
- Permite inyectar fácilmente valores desde otros paquetes, ConfigMap y Secret
- Propone dejar de usar archivos
values.yaml sin tipos y sin documentación
- La gestión de dependencias permite que los paquetes de Glasskube sean usados y referenciados por varios otros paquetes
- Los paquetes dependientes se instalan en el namespace correcto
- El README lo expresa como “así es como un umbrella chart debería haber funcionado desde el principio”
Actualizaciones, GitOps y soporte de repositorios
- Las actualizaciones de paquetes permiten previsualizar una pending update a la versión deseada y ejecutarla con un clic o un comando de CLI
- Todas las actualizaciones se prueban previamente con el conjunto de pruebas de Glasskube
- Las reacciones y comentarios sobre los paquetes pueden dejarse en GitHub discussions o dentro de la UI de Glasskube
- La integración con GitOps se basa en gestionar todos los paquetes de Glasskube como recursos personalizados
- La integración con Renovate también está en curso, y el issue relacionado está en renovatebot/renovate#29322
- Se pueden usar múltiples repositorios y private package
- Puede utilizarse para desplegar paquetes de servicios internos de una empresa
- Se plantea un escenario en el que los desarrolladores pueden configurar fácilmente servicios internos actualizados
Arquitectura de instalación de paquetes
- El flujo
glasskube install [package] tiene una estructura en la que la UI o la CLI usan en conjunto el repositorio de paquetes y la API de Kubernetes a través del Client
- La UI se conecta con el Client mediante el servidor local
http://localhost:8580
- La CLI se conecta con el Client mediante cobra CLI
- Primero, el Client revisa el Package Repo para la validación del paquete
- Después de la validación, crea un recurso personalizado
Package en la API de Kubernetes
- Dentro del clúster,
PackageController y PackageInfoController realizan la reconciliación (reconcile)
PackageController reconcilia el Package y, si es necesario, crea un PackageInfoPackageInfoController actualiza el manifest del paquete desde el repositorio de paquetes- El manifest actualizado se refleja en
PackageInfo
- Luego
PackageController despliega el paquete en Kubernetes
- Kubernetes devuelve el estado del paquete al Client
Paquetes soportados e información del proyecto
- Glasskube ya soporta varios paquetes
- La lista completa de paquetes soportados y previstos puede consultarse en glasskube.dev/packages
- Un proyecto relacionado es Glasskube Apps Operator
glasskube/operator
- Los problemas, bugs y solicitudes de funciones se reciben a través de Discord o issues de GitHub
- Glasskube se distribuye bajo la licencia Apache 2.0
1 comentarios
Opiniones en Hacker News
Puede ser un paso en la dirección correcta, pero el mayor problema actual en la gestión de paquetes de Kubernetes no parece fácil de resolver con un gestor de paquetes.
Lo más difícil en el día a día es que el YAML anidado se acumula en varios niveles y el resultado es impredecible.
Por ejemplo, ArgoCD ApplicationSet crea varias Applications, esas Applications renderizan charts de Helm, y dentro de esos charts hay CRD usados por operadores arbitrarios como Strimzi, Grafana o Vector.
YAML tiene una sintaxis pobre y no hay un estándar para renderizar plantillas, así que cuando se hace un cambio en el nivel superior es casi imposible saber qué YAML se inyectará realmente en la API de Kubernetes.
Al final, eso termina en prueba y error todos los meses, despliegues blue-green costosos y cientos de minutos de depuración.
Creo que la dirección correcta es tener soporte de un lenguaje de programación adecuado.
Idealmente se necesita un sistema de tipos estático que no sea Turing completo y que garantice la terminación; algo como Starlark con tipos parece apropiado.
Quieren que glasskube[bot] comente en los pull requests de GitOps el diff exacto de los recursos que realmente cambiarán en todos los clústeres conectados.
Ese diff lo realiza un controlador que se ejecuta dentro del clúster.
Es parecido al análisis de codecov, pero dedicado a cambios de recursos.
Parece un enfoque interesante para la gestión de paquetes, y se ve bien para algo como un clúster al estilo Homebrew.
Aun así, personalmente prefiero la combinación de helmfile + Renovate + pipeline, aunque sea para mantener la coherencia desde el repositorio.
Por ejemplo, un botón de
update allse siente bastante aterrador en un clúster importante.Para proyectos personales sigue siendo una herramienta genial.
El controlador de paquetes se parece mucho al antiguo Tiller de Helm, que fue un gran problema de seguridad en muchas empresas y por eso se eliminó en Helm 3, cambiándolo por procesamiento del lado del cliente basado en configmaps; me pregunto cómo este proyecto superará ese problema.
También es posible configurarlos desde la CLI con los flags
--dry-runy--output yamly luego ponerlos en Git.Además, están trabajando en pull requests que soporten actualizaciones de paquetes con Renovate: https://github.com/renovatebot/renovate/issues/29322
Helm 3 ahora es una herramienta del lado del cliente, así que no puede imponer RBAC por sí mismo.
OLM introdujo Operator Groups(https://olm.operatorframework.io/docs/advanced-tasks/operato...) para ofrecer permisos a nivel de operador.
Se podría introducir algo similar en los paquetes de Glasskube, y aunque Glasskube en sí todavía necesitaría permisos bastante amplios, se podría limitar el alcance de los paquetes e incorporar permisos granulares.
Tradicionalmente, los paquetes de aplicaciones son binarios inmutables con versión fija que incluyen pasos previos y posteriores a la instalación; se compilan pensando en una plataforma específica y dependencias concretas, y la configuración durante la instalación es extremadamente limitada.
La razón por la que los paquetes funcionan bien es que están diseñados para un entorno muy específico y minimizan lo que puede cambiarse al instalarlos.
Aun así, los paquetes de sistemas operativos siguen requiriendo enormes cantidades de pruebas, desarrollo y parches incluso dentro de esas condiciones estrechas.
Si el paquete que instalas ahora parece fácil, puede ser porque se invirtieron cientos de horas en la plataforma, los componentes y las versiones actuales.
Un “paquete” de Kubernetes en realidad no es un paquete, sino más bien un conjunto de instrucciones sobre los componentes que se deben instalar y configurar, y a menudo incluye varios conjuntos de aplicaciones separadas.
Esta diferencia se manifiesta de dos formas: los “paquetes” de K8s tienen una definición muy laxa y son muy variables, y todo tipo de personas los crean de todo tipo de maneras, haciendo todo tipo de suposiciones sobre el estado del sistema donde se instalarán.
Para que un “paquete” de Kubernetes funcione, deben coincidir varias capas de dependencias y configuración.
Deben coincidir la versión de la API de K8s, la forma en que están instalados y ejecutándose los componentes de K8s, las ACL, la ausencia de componentes existentes que puedan entrar en conflicto, la fijación de versiones de los componentes y contenedores que instala el paquete y su compatibilidad con otras cosas dentro del clúster, además de la configuración del usuario.
Las actualizaciones son igual de caóticas porque no existe el concepto de un árbol de versiones estables ni de rolling release; es parecido a instalar archivos
.deb,.rpmo.dmgarbitrarios en un sistema operativo y esperar que todo salga bien.Hoy no hay nada que haga todo esto.
Para que el empaquetado de Kubernetes sea tan fluido como el empaquetado binario por plataforma, se necesitaría toda una comunidad de mantenedores y un enfoque de rolling release como Homebrew, o ramas estables de lanzamiento por versión.
Al final, un proyecto como ArtifactHub o Homebrew tendría que gestionar todos los paquetes de una sola manera, pero es una tarea enorme y no parece nada rentable.
La idea es guardar todas las actualizaciones de forma centralizada y probarlas con flujos de trabajo de CI/CD, para que los usuarios puedan disfrutar de actualizaciones probadas y sin fricción.
Los usuarios también pueden alojar sus propios repositorios y paquetes, pero por defecto queremos ofrecer directamente un conjunto de paquetes con una postura definida.
Ya estamos pensando en compilar para distintas versiones o entornos de Kubernetes, y será necesario algún día si queremos incorporar más configuración en la etapa de build.
No estoy seguro de que un gestor de paquetes de K8s pueda llegar a ser tan simple como brew o apt.
Esto se debe especialmente a que los valores varían según el entorno de destino y casi todos los usuarios tienen entornos “copo de nieve” distintos.
No me atrae usar prompts tipo REPL o una UI web para configurar esos valores.
El dolor principal sigue sin resolverse: escribir charts de Helm es una tortura, hay que gestionar valores por entorno y ojalá evitaran que tuviéramos que conectar valores entre charts.
Los equipos de plataforma están creando plataformas internas para desarrolladores con el fin de estandarizar más la configuración de Kubernetes entre equipos y clústeres, y permitir que los desarrolladores hagan solo pequeños ajustes.
Según mi experiencia, hay que reducir estas configuraciones tan dispares; de hecho, esa también fue una de las razones por las que creamos Glasskube.
Estoy 100% de acuerdo en que escribir charts de Helm es doloroso, y queremos cambiar eso en el futuro.
Los paquetes de Glasskube siguen siendo configurables, pero ofrecen valores predeterminados con sentido.
En Glasskube se pueden referenciar fácilmente los valores de configuración de otros paquetes, de modo que no tengas que proporcionar el mismo valor varias veces.
Creo muchos operadores de Kubernetes y trato con frecuencia los problemas de Helm y OLM.
La documentación dice que “Glasskube se encarga de las actualizaciones de CRD para que los CR y los operadores no queden desalineados”, pero al buscar “CRD” en la documentación no aparece nada concreto.
Este es uno de los mayores dolores que tenemos ahora con Helm, así que me gustaría saber si pueden compartir sus planes.
[1] <https://stackable.tech/en/>
[2] <https://www.youtube.com/watch?v=Q8OSYOgBdCc>
Esto se gestiona mediante Manifest o helm-controller.
Actualizaremos la documentación.
Creo que Kubernetes está fundamentalmente limitado por un modelo de operadores demasiado simple.
Me gusta la idea general, pero reducir todo el modelo a “estado actual, estado deseado, siguiente acción” es prácticamente imposible.
Al final, todo el flujo de trabajo termina dentro de la lógica de la siguiente acción, y como hay demasiados operadores mirando el mismo estado del sistema, es difícil saber cómo interactuarán los distintos componentes.
El problema de Helm es un subcaso de este problema más grande.
Como analogía, es el mismo problema que enfrenta la programación frontend con el DOM.
Introducir un paradigma de DOM virtual/reducer como React ayudaría mucho a resolver estos problemas.
Hay un estado, un objetivo y perturbaciones hacia ese objetivo, y si quieres una herramienta potente y flexible, creo que ese nivel de abstracción es el correcto.
El problema es que las características físicas y la disposición de las máquinas generan diferencias tan grandes que el costo de virtualizarlas o simularlas de forma significativa es demasiado alto.
Por eso, en su lugar validamos si el estado de la configuración funciona en un subconjunto de la estructura física.
Es el enfoque de tener entornos
dev,stagingyprod, y usar despliegues por color, análisis canary, rollouts parciales, etc.Si necesitas una herramienta así para usar K8s, probablemente te convenga usar otra solución.
Kubernetes no fue creado para usarse sin conocimientos previos, y es difícil.
A menos que construyas un PaaS completo, es difícil escapar de esa complejidad.
Creo que esta herramienta tiene mal encaminado el marketing
Esto no tiene mucho que ver con Helm
Para mí, Helm es principalmente un lenguaje de plantillas, no un gestor de paquetes, y una forma de configurar e instalar en clústeres de K8s mediante kubeapps, Helm CLI y ArgoCD
Este enfoque también rompe un excelente paradigma de IaC
Porque, después de hacer bootstrap de ArgoCD, conviene una estructura que solo haga referencia a repositorios Git
La demo no muestra cómo usar funciones de plantillas como el soporte de
form; muestra todo lo demásSigo teniendo la sensación de que hay algo problemático en Helm, así que, sinceramente, la herramienta en sí me gusta, pero con el enfoque actual creo que va a fracasar
A las empresas grandes no les hace falta esta herramienta, así que será difícil lograr suficiente adopción
Kubeapps y Helm ya funcionan bien, y aunque digan que van a reemplazar Helm, probablemente mantengan el soporte para Helm durante mucho tiempo
El problema de Helm es que se vuelve más complejo a medida que los charts crecen
La estructura en la que prácticamente todo va dentro de una sola carpeta
templateses un desastre, YAML no es adecuado para plantillas yvalues.yamlcrece demasiadoPuedes ver más detalles sobre las opciones de configuración en la documentación de configuración de paquetes: https://glasskube.dev/docs/design/package-config/
El argumento de venta de que es más rápido que Helm no me convence mucho
Nunca sentí que el problema de Helm fuera la velocidad
Se ve interesante
Me ayudaría entenderlo si explicaran brevemente cómo encaja con herramientas existentes como ArgoCD, o cómo se compara con ellas
Vi el video y una de las herramientas que instalaban era Argo, así que claramente parece ocupar otro nicho, pero todavía no sé bien cuál es
Se usa a menudo para que los desarrolladores puedan revisar el estado de las aplicaciones clave de la empresa sin tener acceso al clúster
Glasskube se centra en los paquetes de los que dependen las aplicaciones principales
Gestiona el ciclo de vida de los componentes de infraestructura, prueba actualizaciones y ofrece rutas de upgrade
También puedes poner paquetes de Glasskube en un repositorio GitOps y sincronizarlos con el clúster mediante ArgoCD; el PackageController se encarga del resto