Kaisin
Importing a cluster
Most clusters Kaisin is installed into already run something: a chart installed last year, a database somebody applied by hand. Kaisin can see those, and take a namespace on where it stands, without redeploying anything in it.
Inventory
Inventory lists what runs on the cluster that Kaisin did not deploy, namespace by namespace, sorted into applications and datastores. PostgreSQL, Redis and object storage are recognised by their image. Where a workload came from a Helm release, the chart and its version are shown beside it.
It is read only, and open to administrators. Kaisin's own namespaces and the cluster's are left out. Reading a release takes the chart's name and version and nothing else: its values are never read out, and neither is any Secret.
With more than one cluster registered, the page asks which.
Importing a namespace
Import on a namespace makes it a project. The dialog says what comes along before anything happens:
- its applications, as applications;
- its datastores, as connections;
- anything else, named and left as it is.
Nothing in the cluster changes, and the chart goes on running it. Kaisin watches from here: the
image and the instance count shown are whatever the cluster says they are, so a helm upgrade
from your own pipeline shows up in Kaisin rather than fighting it.
What an imported application is
It has an overview, logs, the Kubernetes objects behind it, and settings. What it does not have is anything that would make Kaisin a second owner of something a chart already owns:
| Deploy | Refused. The chart deploys it. |
| Restart | Works for a Deployment. Refused for a StatefulSet. |
| Delete | Forgets it. The application, the datastore and the namespace are left running. |
| Isolation | Refused. Enforcing fences in only what Kaisin deployed. |
| Move | Moves to another project with its whole namespace, since that is what was imported. |
On the network map an imported application is drawn with what it calls, read from the variables its chart gives it, including the ones that arrive from a ConfigMap.
Changing it through its chart
Scaling an imported application by hand would last until the next helm upgrade put the chart's
number back. So the change goes where the number lives.
On the application's settings, under Change it through its chart, name the repository that
deploys it. Kaisin finds the workflow that runs helm upgrade for that release and the values
file it passes. Changing the instance count or the image tag then opens a pull request that edits
that one value and nothing around it. Merging it is the deployment.
This is the one thing that needs the GitHub App to hold Contents and Pull requests write. A new App asks for them; an older one is told on the connection screen what to grant. Kaisin pushes only to a branch it created, and merges nothing.