Skip to main content
Glasskube is a lightweight package manager for Kubernetes that leverages Helm charts and plain Kubernetes manifests to provide a unified, developer-friendly package experience. Although the project began in February 2024 with a small core team, it has rapidly gained traction on GitHub thanks to a clear focus on CLI, UI, and GitOps-style workflows. In this article you will learn:
  • The primary ways to interact with Glasskube (CLI, UI, declarative).
  • The core architecture and controllers that power package reconciliation.
  • How to install and bootstrap Glasskube into a cluster.
  • Practical next steps and useful references.

​
Primary interaction methods

Glasskube provides three main interfaces for managing packages. Use the table below to quickly compare them.

​
Architecture overview

Glasskube follows a client-server model:
  • Server-side: controllers running in-cluster (Package Controller, PackageInfo Controller) that reconcile package CRs and manage package lifecycles.
  • Client-side: CLI, UI, and configured repositories (public or private) that submit Package/ClusterPackage resources and query status.
Example package CustomResource:
The controllers reconcile these CRs and ensure the desired package state is present in the cluster.
The image is a diagram of the Glasskube architecture, illustrating the interaction between client-side and server-side components, such as the Client, Kubernetes API, and PackageController, within a package management system.

​
Key server-side controllers

  • Package Controller: manages package lifecycle operations (install, update, rollback) by reconciling Package and ClusterPackage CRs.
  • PackageInfo Controller: fetches package manifests and metadata from repositories and exposes that information to the cluster via PackageInfo CRs.
On the client side, Glasskube reads from a central public Glasskube repository by default; you can also add private or additional public repositories. The UI and CLI interact with both the repository and the in-cluster controllers.

​
Package installation flow (single repository)

A typical single-repository install flow:
  1. A user selects a package in the CLI or UI.
  2. The client validates the selection against the configured repository.
  3. The client creates a Package or ClusterPackage CustomResource in the cluster.
  4. The Kubernetes API notifies controllers and triggers reconciliation.
  5. If needed, a PackageInfo CR is created and reconciled by the PackageInfo Controller.
  6. PackageInfo fetches manifest and version details from the repository and updates the CR status.
  7. The Package Controller reads the manifest and deploys the package resources through the Kubernetes API.
  8. The client (CLI/UI) receives updates as reconciliation progresses.
Reconciliation runs periodically and continuously enforce desired state, enabling automatic remediation and drift detection (reinstall, revert, or repair when package health degrades).
The image is a workflow diagram illustrating the process of package validation, creation, and deployment using a Kubernetes API, involving client-side and server-side interactions. It includes steps like validating a package, reconciling 'Package' and 'PackageInfo', and deploying the package.

​
Multiple repositories and repository UI

Glasskube supports multiple repositories. This enables:
  • Central public catalogs,
  • Private team catalogs,
  • Aggregation of multiple public sources.
Below is an example screenshot of the Glasskube repository UI (Rakkess backend) showing available packages, search, and filtering.
The image shows a webpage from the Glasskube package repository, listing supported software packages with filtering options. It features a search bar, category filters, and a section displaying various package options.

​
Getting started: install the CLI and bootstrap

Install the Glasskube CLI using a platform-appropriate method. Example commands:
Before running glasskube bootstrap, ensure your kubeconfig is pointed to the correct cluster context. Glasskube will install server-side components (the package operator) into the selected context.
Explore the CLI commands:
Bootstrap deploys the server-side package operator and controllers into your cluster:

​
Example: checking version before and after bootstrap

Before bootstrapping you may see the package operator is not installed:
After running glasskube bootstrap (and allowing installation to complete), re-run:
Once bootstrapped, Glasskube is ready to manage packages in the cluster.

​
Pros and cons (summary)

Use this quick comparison to evaluate Glasskube for your team:
The image is a comparison chart with a list of pros and cons. The pros include multiple clients and backend flexibility, while the cons mention a lack of native configuration language and a smaller user base.

​
Next steps

  • Install the CLI and run glasskube bootstrap in a test cluster.
  • Try installing a package via the CLI: glasskube install <package> and observe the Package / PackageInfo CRs.
  • Experiment with private repositories and a GitOps workflow (store ClusterPackage CRs in Git).
  • Explore automatic updates and package scopes for multi-tenant scenarios.

Watch Video

Practice Lab