Connect a cluster
Choose Connect a cluster, then run two lines where kubectl and helm already point at the cluster. The agent installs from a Helm chart that BasePit serves, or from the same objects as plain YAML.
You make three choices at install, and the agent's own rights in the cluster enforce them:
| Choice | Options |
|---|---|
| Reach | The whole cluster, or only the namespaces you list. |
| View only | On, and BasePit can read but change nothing. |
| Pod terminals | Allowed or not. |
The cluster page has a panel called What BasePit can't do here, which lists what the agent's rights rule out. It changes when the agent is installed with more.
- The agent dials out to BasePit, like every other node. No ingress, load balancer or open port is needed for it.
- It runs as a non-root user, needs no writable file system, and drops every Linux capability. It is one static binary for
linux/amd64andlinux/arm64. - Supported: the three newest Kubernetes minor versions upstream supports, and OpenShift 4.x built on them. An older cluster connects, with a warning on its page.
- The token in the install lines works once and is shown once. A new one can be made from the cluster page.
What you see
The agent sends a live picture of the cluster, held in BasePit's memory, with CPU and memory history.
- Needs you: what needs attention, first.
- Namespaces (Projects on OpenShift), and what runs in each.
- Network: Ingresses, and on OpenShift its Routes, with their hostnames as links.
- Helm releases, described without their values.
- Events of the last hour, warnings first.
- All kinds: every kind the agent can see, custom resources included.
- Each object's conditions, containers and pods, with each pod's logs.
An object whose last change was not made through BasePit (by kubectl, a pipeline or another tool) is marked as changed outside, so you know before you act on it.
A Secret's values never leave the cluster.
The agent strips them before it sends anything. Helm releases are described without their values.
What you can do
Every change is a named action, checked by BasePit and again by the agent, and recorded in Activity, with an optional note saying why.
| Action | What happens |
|---|---|
| Scale | Set replicas from 0 to 500. |
| Restart | Kubernetes replaces every pod, a few at a time, as it does for a new version. Nothing else about it changes. |
| Roll back | Choose one of the revisions Kubernetes keeps; that revision's pods replace the current ones, a few at a time. |
| Delete | A pod, or any object. |
| Set a Secret's value | The value goes to the cluster once. BasePit never shows it, keeps it or logs it; Activity records which key was set. |
| Terminal | Into a pod and container the agent can see, on a cluster installed with pod terminals. Recorded when it opens and closes, never a byte of what is typed. |
Apply YAML and Helm charts
Apply is a full page whose last step is Kubernetes' own dry run: you see what the API server would do before anything changes.
- YAML bundles apply with numbered revisions, and can prune what a newer revision no longer has.
- Helm charts install, upgrade, roll back and uninstall through Helm's own SDK, which runs inside the agent.
- Values marked secret are sealed under your organisation's key, and travel only inside the one action that applies them.
- A bundle or a chart can come from a Git source. Follow the branch applies each new commit by itself, and is off by default.
- Charts can also come from the ready-made catalogue.
OpenShift
OpenShift is detected, never configured: the agent finds OpenShift's APIs and reads its version.
- The console says Project where Kubernetes says namespace.
- Routes appear beside Ingresses, with their hostnames as links.
DeploymentConfig,BuildConfigandImageStreamare readable under All kinds, and aDeploymentConfigcan be scaled and restarted.- The agent's pod runs under OpenShift's
restricted-v2policy: non-root with a user OpenShift assigns, no privilege escalation, all capabilities dropped, and the default seccomp profile.
Install OpenShift or OKD
BasePit can also install a cluster on your own machines. One of your Linux hosts, installed with --allow-openshift-install, makes a boot image. You start each machine from it, and BasePit follows the install and connects the finished cluster.
- What: OpenShift (Red Hat's, which needs your Red Hat pull secret) or OKD (the free community build, with no Red Hat account), and a version.
- Machines: one, three, or three plus two or more workers, each with its network card's MAC address.
- Names and network: the cluster's name, your domain, and the machines' IPv4 network. It must not overlap OpenShift's own
10.128.0.0/14or172.30.0.0/16. With three or more machines, it also needs two free addresses for the API and for apps. - DNS records to make first, listed for you.
- The image maker: the host downloads the installer (about 1.5 GB), needs 10 GB free, and must reach the machines.
- Review. Nothing is made until this step.
Installing wipes each machine's disk.
Alerts and access
- Five alert types: a cluster offline, a node not ready, a pod crash-looping, fewer replicas than wanted, and a Job that failed. The first four wait some minutes before firing; a failed Job fires at once. They page through your usual channels.
- Four levels of access (read, operate, manage, terminal) sit inside the existing Viewer, Operator and Admin roles, and access rules narrow them further.
- Each node of a connected cluster counts as a host. What that costs.
- The simple apps path is untouched: if you never connect a cluster, you never see this area.
Limits
- BasePit can do only what the agent's own rights in the cluster allow. A view-only install changes nothing.
- A Secret's values cannot be read through BasePit.
- No OperatorHub listing.