Timeline
Kubernetes keeps only the current version of an object. KubeGlass records changes as they happen, so you can see what changed before something broke. Timeline in the sidebar is one list, newest first, of:
- the changes people and tools made, with what changed and who made them;
- the cluster’s events;
- containers that stopped, with how (an exit code, or killed for using too much memory).
Show everything, only changes, or only warnings, and choose how far back: 1 hour, 6 hours (the default), 24 hours or 1 week. Kubernetes keeps events for about an hour, so further back the list is mostly changes. For admins, a second tab holds the Audit log.
The Overview puts the change that came before a problem on the problem itself (see Overview). The History tab on an object’s page shows the recorded changes to that one object, and its Events tab the object’s events.
Changes
Section titled “Changes”Each change says when, which object, what changed and who changed it. Open it (click it, or press the right arrow) for every field that changed, with the old and new values, and Revert change when KubeGlass can undo it (see Undoing a change). Deleted objects are struck through; the others link to their page.
What is recorded
Section titled “What is recorded”KubeGlass watches Deployments, StatefulSets, DaemonSets, CronJobs, Services, Ingresses, ConfigMaps, Secrets and HorizontalPodAutoscalers. For each one it records when it is created, changed or deleted. For each change it keeps:
- the fields that changed, with the old and new values, shown in words where it can: “Image of app: 1.0 → 1.1”, “Replicas: 2 → 3”, “Restarted”, “LOG_LEVEL: info → debug”;
- the field manager that made the change, such as
kubectl-edit,helm,argocd-controllerorkubeglass. Kubernetes doesn’t record which person made a change, and when an object is deleted it doesn’t record who deleted it; - the KubeGlass user who made it, when it was made through KubeGlass. KubeGlass matches the change to its own audit log (the same cluster and object, a matching action, while the request ran), and for a Helm install or upgrade, to the changes Helm made in the release’s namespace. The By column then shows the user, followed by the field manager. Changes made with other tools show only the field manager;
- for a change Argo CD or Flux applied, the Git commit its application synced at the time, linked to the commit when the repository is on GitHub, GitLab, Bitbucket or a Gitea-style host.
Status updates and bookkeeping (resource versions, revision numbers, last-applied copies) aren’t changes. Pods, ReplicaSets and Jobs aren’t recorded either: controllers make them from the kinds above, and their churn would bury the changes behind it.
For Secrets, KubeGlass records which keys changed but never their values; it keeps a hash to tell that a value changed. ConfigMap values longer than 2,048 characters are kept the same way. Helm’s release records, ServiceAccount tokens and bootstrap tokens, which are Secrets, are left out.
An autoscaler changing a workload’s replica count is marked automatic and hidden until you turn on Include autoscaling.
When it records
Section titled “When it records”KubeGlass starts recording a cluster the first time someone uses it, and records it while KubeGlass runs. A cluster nobody has used for 24 hours stops being recorded until someone uses it again, and at most 8 clusters are recorded at once: a ninth stops the one used least recently. The record is saved in the data directory and kept for 30 days (drift_result_retention). If KubeGlass wasn’t recording, the changes made in the meantime aren’t there. The page says how far back the record goes.
Who sees what
Section titled “Who sees what”KubeGlass watches as itself. A person sees a change only if they may list that kind in its namespace. In a cluster, the chart’s ClusterRole includes watch on Secrets when rbac.readSecrets is on (the default); without it, changes to Secrets aren’t recorded.
The MCP server’s list_changes tool returns the changes, and its timeline tool the whole list, so an assistant can answer “what changed in production in the last hour?”.
Undoing a change
Section titled “Undoing a change”Revert change puts back what one recorded change replaced. It is on the change in the Timeline, in the object’s History tab, and on an Overview entry when it is the change that came before the problem. For a deleted object the button is Restore, which creates the object again as it was; what it made, such as pods, comes back as its controller makes it again. A Service that had a cluster IP gets a new one.
The dialog shows the fields the revert puts back, then asks the API server for a dry run, admission included, and says whether it accepted it. Show the YAML diff compares the object now with the object after the revert. Revert runs as you, so your RBAC applies, and it is recorded in the audit log as revert.
KubeGlass undoes an update with a merge patch from the object after the change back to the object before it, covering labels, annotations and everything except status. It refuses when the fields the change set don’t hold those values any more, because a revert would then undo the later change too; the dialog names the fields and links to the object’s History, so you can revert the later change first or edit the object. The patch carries the object’s resource version, so a change made between the check and the patch makes the API server refuse it. Once a change is reverted it says Reverted.
Some changes can’t be undone, and the change says why:
- A change to a Secret’s values: KubeGlass keeps only hashes of them. A change to a Secret’s labels or annotations can be undone.
- A change too large to keep a copy of: more than 64 KiB, or a ConfigMap value kept only as a hash.
- An older change whose copy KubeGlass dropped to make room: it keeps at most 16 MiB of undo data per cluster, dropping the oldest first.
Creating an object and an autoscaler’s changes to replicas can’t be reverted. In read-only mode, or on a cluster marked read-only, the button isn’t there.
POST /api/v1/namespaces/{namespace}/{resource}/{name}/revert?change=<id> does the same through the API.
Events
Section titled “Events”Events come from the Kubernetes API: each one says its reason, the object, the message and how many times it happened. Warnings have a stripe. For one object’s events, open its Events tab. Every kind’s events are also a list under Resources › Cluster › Events.
Audit log
Section titled “Audit log”The Audit log lists the changes people made through KubeGlass: who, which action (scale, restart, cordon, revert, delete and so on), the object, the cluster and whether it worked. It doesn’t store request bodies, only a hash of them. Search by user or object, or filter by action and result. It refreshes every 15 seconds.
Only admins see this tab. The tab keeps the latest 5,000 events in memory, so it starts empty after a restart. Every event is also written to the server log with the message audit; collect the log if you need a permanent record.