Problem
The Kubernetes Lease backend creates a distinct Lease object for every session. Release writes a tombstone instead of deleting the object so leaseTransitions remains monotonic. Consequently, session and recurring-schedule activity grows the namespace's Lease population without bound.
This creates a long-term API-server/etcd capacity and operability risk.
Evidence
internal/adapter/k8slease/k8slease.go:createLease creates one object per session ID.Release deliberately retains the object and fencing token.- There is no Lease GC, cardinality bound, ownership label, or alerting surface.
Proposed direction
Design GC that preserves fencing monotonicity, potentially by durably retaining the generation outside the Kubernetes object before deletion. Add ownership metadata, cardinality metrics, alerts, and an explicit supported bound.
Acceptance criteria
- Lease object growth is bounded under unbounded historical session creation.
- A deleted/collected Lease can never reset or reuse a stale fencing generation.
- GC is safe under concurrent acquire, renew, release, restart, and takeover.
- Operators can observe current cardinality and GC failures.
Problem
The Kubernetes Lease backend creates a distinct Lease object for every session. Release writes a tombstone instead of deleting the object so
leaseTransitionsremains monotonic. Consequently, session and recurring-schedule activity grows the namespace's Lease population without bound.This creates a long-term API-server/etcd capacity and operability risk.
Evidence
internal/adapter/k8slease/k8slease.go:createLeasecreates one object per session ID.Releasedeliberately retains the object and fencing token.Proposed direction
Design GC that preserves fencing monotonicity, potentially by durably retaining the generation outside the Kubernetes object before deletion. Add ownership metadata, cardinality metrics, alerts, and an explicit supported bound.
Acceptance criteria