Package Scopes - KodeKloud

Before we dive into package configuration and installation, it helps to understand the two package scopes Glasskube supports: cluster-scoped and namespaced packages. Choosing the right scope determines how a package is deployed, who can reuse it, and whether it can create cluster-level resources. Cluster-scoped packages

Cluster-scoped packages manage cluster-wide resources such as ClusterRole, ClusterRoleBinding, and CustomResourceDefinition (CRD).
Because they operate at the cluster level, these packages are typically installed once per cluster and shared across namespaces.
Common use cases: cluster networking, global observability, cluster-wide security tools, and CRD providers.

The image depicts a diagram of a Single-Node Cluster divided into "Cluster Scoped" and "Namespace Scoped" sections, featuring observability, continuous deployment, and analytics.

Namespaced packages

Namespaced packages are confined to a single Kubernetes namespace and don’t manage cluster-level resources.
They can be installed multiple times in different namespaces, providing isolated instances for teams, environments, or applications.
Common use cases: per-team deployments, environment-specific instances (dev/stage/prod), and application-scoped tooling.

How to choose a scope

Use cluster-scoped packages for functionality that must be shared across the cluster or that manages cluster-level resources (e.g., networking, cluster-wide monitoring, CRDs).
Use namespaced packages when you need multiple isolated instances of the same package (e.g., separate team environments) or when the package only affects resources within a single namespace.

Scope	Typical resources managed	When to use
Cluster-scoped	`ClusterRole`, `ClusterRoleBinding`, `CustomResourceDefinition`	Shared services, global controllers, CRD providers
Namespaced	`Role`, `RoleBinding`, `Deployment`, `Service` (within a namespace)	Per-team or per-environment isolation, application-scoped tooling

Cluster-scoped packages are ideal for functionality that must be installed only once per cluster (e.g., an operator that provides CRDs). Namespaced packages are best when you need repeatable, isolated deployments across namespaces.

Glasskube UI and where scopes appear

In the Glasskube web UI:
- Cluster-scoped packages appear under the Cluster Packages tab.
- Namespaced packages appear under the Packages tab.

Authoring package manifests When creating Glasskube package definition files, set the kind to ClusterPackage for cluster-scoped packages or Package for namespaced packages. For example:

apiVersion: packages.glasskube.dev/v1alpha1
kind: ClusterPackage
metadata:
  creationTimestamp: null
  name: argo-cd
spec:
  packageInfo:
    name: argo-cd
    repositoryName: glasskube
    version: v2.11.7+1

Be cautious when authoring cluster-scoped packages: because they affect cluster-wide state, changes can impact all namespaces. Test cluster-scoped manifests in a safe environment before deploying to production clusters.

Links and references

Glasskube package docs: https://glasskube.dev/docs (refer to your Glasskube installation docs)
Kubernetes RBAC and resources: https://kubernetes.io/docs/reference/access-authn-authz/rbac/
CustomResourceDefinitions: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/

Now that you know how package scopes work and how to pick between them, you’re ready to move on to installing and configuring packages with Glasskube.

Watch Video