Operate Kerf¶
Running Kerf day to day means four things: keep the versions of its components in step, keep a copy of the state that matters, watch the signals it exports, and fix a cluster that falls out of its readiness state. These pages cover each one.
Kerf has two kinds of state. The hub keeps everything in PostgreSQL: recommendations, the audit log,
policies made in the UI, users, tokens and the cluster list. Each workload cluster keeps only what the agent
derives from the hub, plus any RightsizingPolicy you apply from Git.
Pages¶
| Page | Read it when |
|---|---|
| Upgrade | A new release is out, or you need to roll one back. |
| Backup and restore | You plan the backups of the hub database, secrets and values, or you restore after a loss. |
| Alerts and dashboards | An alert fires, or you set up Grafana and the chart's alert rules. |
| Cluster readiness | A cluster is stuck below Automation ready, or auto-patch is refused. |
| Troubleshooting | Something does not work and you start from the symptom. |
| Maintenance and updates | You want the versions of every component, or the check for a new release. |
A routine¶
- Open Admin → Maintenance after every upgrade. All components should run the hub's version.
- Keep one alert route for the chart's alerts.
KerfNoHubLeaderis the only one with severitycritical. - Look at each cluster's readiness page when you add a cluster and when an alert names it.
- Take a database snapshot before every hub upgrade.