Bootstrap
As Glasskube is still in technical preview a manual bootstrap is needed.
Automatic detection and bootstrapping will be implemented in a future version.
In order to install packages in a Kubernetes cluster using Glasskube, it is necessary to install the required server components.
Conveniently, for most users this can be achieved by running glasskube bootstrap
in a terminal.
The bootstrap command installs the Package Operator and it's associated Custom Resource Definitions (CRDs). By default, the Package Operator is installed in an All-In-One (AIO) configuration. This configuration comes bundled with a subset of Flux. Glasskube is still compatible with any other GitOps solution, but Flux is a necessary requirement of the Package Operator.
If you already use Flux in your cluster or want to manage it yourself, first install Flux,
and then Glasskube using a slim configuration by running glasskube bootstrap --type=slim
.
To ensure compatibility, please verify that the following flux components are installed in their respective version:
source-controller
deployment: v1.3.0helm-controller
deployment: v1.0.1HelmChart
CRD: v1HelmRelease
CRD: v2
For more information and command-line options check out glasskube help bootstrap
.
Bootstrapping in GitOps environments
In our GitOps template we explain how Glasskube can be set up together with ArgoCD,
using the glasskube bootstrap git
command.
If you prefer a different GitOps tool or need a more customized solution, you can use glasskube bootstrap --dry-run -o yaml
in order to generate the Glasskube manifests that you can put into your GitOps repository.
Common Issues
Deployments do not become ready
By default, the Deployment
s included in the bootstrapped configuration do not contain any taint tolerations.
Please make sure that your cluster has at least one schedulable node that is not tainted.
This issue was reported by users trying to bootstrap Glasskube on Amazon EKS clusters consisting exclusively of Fargate nodes.
Fargate nodes come with the taint eks.amazonaws.com/compute-type=fargate:NoSchedule
by default, which results in the Pods
associated with the Glasskube Deployments
to be unschedulable.