mirror of
https://github.com/cozystack/cozystack.git
synced 2026-11-09 14:02:56 +09:00
Addresses the review on the memory-limits page.
The opening claim that every container in a system namespace gets a
memory limit was too broad, but not for the reason offered. The
LimitRange defaults a limit onto any container that declares none,
whoever created the pod, so chart-level exemptions do not survive it:
a namespace LimitRange with default memory 4Gi turns a container
requesting 700Mi with no limit into one carrying limits.memory 4Gi.
Verified on kind. The real gaps are the ones admission cannot reach or
the operator withholds: Talos static pods bypass LimitRanger entirely,
and a namespace holding a live container that requests more than the
configured limit and declares none of its own loses its LimitRange
altogether. Both are now named in the opening paragraph, and the
withheld-namespace case joins the "does not cover" list with the VPA
maxAllowed of 8Gi in packages/system/monitoring as the case to expect
it in.
Records the two deliberate chart-level exemptions, linstor-controller
and linstor-satellite, as what they are: the same linstor-server JVM,
where a memory.max is what container-aware heap sizing reads, so a
guessed ceiling shrinks the heap rather than capping the process. Both
still receive the namespace default, so they do leave the victim set,
at a namespace-wide figure rather than a fitted one; closing that needs
a peak measured at a high DRBD resource count plus an explicit heap
share.
Three commands were wrong or unsafe as written:
- the pre-change request check queried live Pods only, so it missed
scaled-to-zero workloads and CronJobs. It now reads pod, workload
and CronJob templates alongside live pods, needing both halves
because a template is the only place a scaled-to-zero workload
appears and a live pod the only place a webhook-raised request
does. It also failed silently: with an unreachable cluster it
printed nothing and exited 0, reading as a clean bill of health.
Wrapped in a subshell under set -eu -o pipefail with an explicit
empty-namespace-list check, it now exits non-zero instead.
- the cgroup check hardcoded the burstable QoS segment while the
prose two lines below explained the segment varies. It now derives
the segment from .status.qosClass, and an unreadable class stops
the command rather than sending it to a path that cannot exist.
- the closing pressure diagnosis asserted that persistent triggering
means a pod is at its memory ceiling. The first trigger clause
weighs only System and Podruntime pressure, so it says nothing of
the kind; the diagnosis now sends the reader to the trigger context
first.
Also labels the two CEL fences, which markdownlint reports as MD040,
and drops the em dashes throughout.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>