Installation

Kanister can be easily installed and managed with Helm. You will need to configure your kubectl CLI tool to target the Kubernetes cluster you want to install Kanister on.

Start by adding the Kanister repository to your local setup:

helm repo add kanister https://charts.kanister.io/

Use the helm install command to install Kanister in the kanister namespace:

helm -n kanister upgrade \
--install kanister \
--create-namespace kanister/kanister-operator

Confirm that the Kanister workloads are ready:

kubectl -n kanister get po

You should see the operator pod in the Running state:

NAME READY STATUS RESTARTS AGE
kanister-kanister-operator-85c747bfb8-dmqnj 1/1 Running 0 15s

NOTE

Kanister is guaranteed to work with the 3 most recent versions of Kubernetes. For example, if the latest version of Kubernetes is 1.24, Kanister will work with 1.24, 1.23, and 1.22. Support for older versions is provided on a best-effort basis. If you are using an older version of Kubernetes, please consider upgrading to a newer version.

NOTE

To improve the cluster's security, the default installation of Kanister is restricted to access only the resources within its own namespace. As a result, Kanister may not be able to snapshot or restore applications by default in other namespaces. If Blueprint needs access to resources in other namespaces, please follow the steps provided here to configure the access correctly.

Configuring Kanister

Use the helm show values command to list the configurable options:

helm show values kanister/kanister-operator

For example, you can use the image.tag value to specify the Kanister version to install.

The source of the values.yaml file can be found on GitHub.

Installation in air-gapped environment

In the situation where the K8s cluster is isolated from the internet, below are the images that need to be copied to the local container registry, to make Kanister work successfully.

• Kanister Controller (ghcr.io/kanisterio/controller)
• Kanister Tools (ghcr.io/kanisterio/kanister-tools)

Apart from above images, the images that are being used in the blueprint would also need to be present in the local container registry.

Managing Custom Resource Definitions (CRDs)

The default RBAC settings in the Helm chart permit Kanister to manage and auto-update its own custom resource definitions, to ease the user's operation burden. If your setup requires the removal of these settings, you will have to install Kanister with the --set controller.updateCRDs=false option:

helm -n kanister upgrade \
--install kanister \
--create-namespace kanister/kanister-operator \
--set controller.updateCRDs=false

This option lets Helm manage the CRD resources.

Using custom certificates with the Validating Webhook Controller

Kanister installation also creates a validating admission webhook server that is invoked each time a new Blueprint is created.

By default the Helm chart is configured to automatically generate a self-signed certificates for Admission Webhook Server. If your setup requires custom certificates to be configured, you will have to install kanister with --set bpValidatingWebhook.tls.mode=custom option along with other certificate details.

Create a Secret that stores the TLS key and certificate for webhook admission server:

kubectl create secret tls my-tls-secret \--cert /path/to/tls.crt \--key
/path/to/tls.key -n kanister

Install Kanister, providing the PEM-encoded CA bundle and the tls secret name like below:

helm upgrade --install kanister kanister/kanister-operator --namespace kanister --create-namespace \
--set bpValidatingWebhook.tls.mode=custom \
--set bpValidatingWebhook.tls.caBundle=$(cat /path/to/ca.pem | base64 -w 0) \
--set bpValidatingWebhook.tls.secretName=tls-secret

Building and Deploying from Source

Follow the instructions in the BUILD.md file in the Kanister GitHub repository to build Kanister from source code.