> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Glasskube

> Overview of Glasskube, a lightweight Kubernetes package manager using Helm and manifests, covering CLI, UI, GitOps workflows, architecture, controllers, installation, and usage

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.

|            Interface | Purpose                                                                                     | Example / Quick Command                                                |
| -------------------: | ------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
|                  CLI | Configure, install, update, and manage packages from the terminal.                          | `glasskube install <package>`                                          |
|       UI (Graphical) | Visual package discovery, installation, and status monitoring for users who prefer a GUI.   | Access via the Glasskube dashboard connected to your cluster           |
| Declarative (GitOps) | Define `Package` CustomResources in Git and let reconciliation apply changes automatically. | Commit `ClusterPackage` CRs to your repo and let controllers reconcile |

## 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:

```yaml theme={null}
apiVersion: packages.glasskube.dev/v1alpha1
kind: ClusterPackage
metadata:
  name: kubernetes-dashboard
spec:
  packageInfo:
    name: kubernetes-dashboard
    version: v2.7.0+2
```

The controllers reconcile these CRs and ensure the desired package state is present in the cluster.

<Frame>
  <img src="https://mintcdn.com/kodekloud-c4ac6d9a/GUk2-1Y8Wvqthmtm/images/Kubernetes-Administration-Package-Management-with-Glasskube/Tooling/Glasskube/glasskube-architecture-diagram-client-server.jpg?fit=max&auto=format&n=GUk2-1Y8Wvqthmtm&q=85&s=62fc1300f76778af7d4a66d7e529eed2" alt="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." width="1920" height="1080" data-path="images/Kubernetes-Administration-Package-Management-with-Glasskube/Tooling/Glasskube/glasskube-architecture-diagram-client-server.jpg" />
</Frame>

### 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).

<Frame>
  <img src="https://mintcdn.com/kodekloud-c4ac6d9a/GUk2-1Y8Wvqthmtm/images/Kubernetes-Administration-Package-Management-with-Glasskube/Tooling/Glasskube/package-validation-creation-deployment-diagram.jpg?fit=max&auto=format&n=GUk2-1Y8Wvqthmtm&q=85&s=43430bced8406a7ae87b76710365a3d3" alt="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." width="1920" height="1080" data-path="images/Kubernetes-Administration-Package-Management-with-Glasskube/Tooling/Glasskube/package-validation-creation-deployment-diagram.jpg" />
</Frame>

## 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.

<Frame>
  <img src="https://mintcdn.com/kodekloud-c4ac6d9a/GUk2-1Y8Wvqthmtm/images/Kubernetes-Administration-Package-Management-with-Glasskube/Tooling/Glasskube/glasskube-package-repository-software-listing.jpg?fit=max&auto=format&n=GUk2-1Y8Wvqthmtm&q=85&s=917b992cb50323e09215a7a1b25f542d" alt="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." width="1920" height="1080" data-path="images/Kubernetes-Administration-Package-Management-with-Glasskube/Tooling/Glasskube/glasskube-package-repository-software-listing.jpg" />
</Frame>

## Getting started: install the CLI and bootstrap

Install the Glasskube CLI using a platform-appropriate method. Example commands:

```bash theme={null}
# Homebrew (macOS)
brew install glasskube/tap/glasskube

# Debian/Ubuntu .deb
curl -LO https://releases.d1.glasskube.dev/glasskube_v0.14.0_amd64.deb
sudo dpkg -i glasskube_v0.14.0_amd64.deb

# Fedora/RHEL .rpm
sudo dnf install https://releases.d1.glasskube.dev/glasskube_v0.14.0.rpm

# Nix
nix-shell -p glasskube
```

<Callout icon="lightbulb" color="#1CB2FE">
  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.
</Callout>

Explore the CLI commands:

```bash theme={null}
glasskube help
📦 The next generation Package Manager for Kubernetes 📦
Usage:
  glasskube [command]

Available Commands:
  auto-update    Update autopilot for packages where automatic updates are enabled
  bootstrap      Bootstrap Glasskube in a Kubernetes cluster
  completion     Generate the autocompletion script
  help           Help about any command
  install        Install a package
  version        Show Glasskube and package-operator versions
  # ...additional commands omitted for brevity
```

Bootstrap deploys the server-side package operator and controllers into your cluster:

```bash theme={null}
glasskube bootstrap
```

### Example: checking version before and after bootstrap

Before bootstrapping you may see the package operator is not installed:

```bash theme={null}
glasskube version
Error checking PackageOperator version:
deployments.apps "glasskube-controller-manager" not found

GLASSKUBE
glasskube: v0.17.0
package-operator: not installed
```

After running `glasskube bootstrap` (and allowing installation to complete), re-run:

```bash theme={null}
glasskube version
GLASSKUBE
glasskube: v0.17.0
package-operator: v0.17.0
```

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:

| Pros                                                                       | Cons                                                                                                |
| -------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| Multiple client interfaces: CLI, UI, and declarative manifests             | Relies on Helm charts and Kubernetes manifests today; a native config language is still in progress |
| Backend flexibility: public Glasskube repo plus private repositories       | Opinionated configuration may not suit every workflow                                               |
| Simplified package configuration vs. raw Helm charts                       | Newer project: smaller ecosystem and community compared to Helm                                     |
| Good GitOps integration for version control and rollbacks                  | —                                                                                                   |
| Support for automatic updates and package scopes                           | —                                                                                                   |
| Built-in access methods to package frontends reduce ad-hoc port-forwarding | —                                                                                                   |

<Frame>
  <img src="https://mintcdn.com/kodekloud-c4ac6d9a/GUk2-1Y8Wvqthmtm/images/Kubernetes-Administration-Package-Management-with-Glasskube/Tooling/Glasskube/pros-cons-comparison-chart-flexibility.jpg?fit=max&auto=format&n=GUk2-1Y8Wvqthmtm&q=85&s=62dcea7aa0c39f9b21a7c3f0b00263e0" alt="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." width="1920" height="1080" data-path="images/Kubernetes-Administration-Package-Management-with-Glasskube/Tooling/Glasskube/pros-cons-comparison-chart-flexibility.jpg" />
</Frame>

## 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.

## Links and references

* [Kubernetes Documentation](https://kubernetes.io/docs/)
* [Helm Documentation](https://helm.sh/docs/)
* Glasskube releases and downloads: [https://releases.d1.glasskube.dev/](https://releases.d1.glasskube.dev/)
* General GitOps resources: [https://www.gitops.tech/](https://www.gitops.tech/)

<CardGroup>
  <Card title="Watch Video" icon="video" cta="Learn more" href="https://learn.kodekloud.com/user/courses/k8s-administration-package-management-with-glasskube/module/140a6ea0-1539-4d23-9aa6-0d07654a4526/lesson/d3a7578d-b239-48af-bded-d4fe039d4502" />

  <Card title="Practice Lab" icon="flask-conical" cta="Learn more" href="https://learn.kodekloud.com/user/courses/k8s-administration-package-management-with-glasskube/module/140a6ea0-1539-4d23-9aa6-0d07654a4526/lesson/4b52c5b3-817b-48d1-8e30-3103a4da690e" />
</CardGroup>