Skip to content

docs: document ResourceQuota interaction for init container accounting. #2535

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
hami-robot merged 2 commits into from
Aug 11, 2026
Merged

docs: document ResourceQuota interaction for init container accounting. #2535

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
67fc3c2
docs: document ResourceQuota interaction for init container accounting
maishivamhoo123 Aug 10, 2026
0464704
docs: quota usage is released at terminal phase, not only deletion
maishivamhoo123 Aug 10, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 16 additions & 1 deletion docs/develop/initContainer-design.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -263,4 +263,19 @@ The terminal-phase release is not persisted as a separate state — it's
recomputed on every reconcile directly from `pod.Status.Phase`:

if pod.Status.Phase in (Succeeded, Failed):
usage = 0
usage = 0

## Interaction with Kubernetes ResourceQuota

If the namespace has a `ResourceQuota` (like `requests.nvidia.com/gpumem`), the
kube-apiserver checks it first, before the pod reaches HAMi. The apiserver uses the
same formula `max(sum(app), max(init))`, but it charges this value only once, when
the pod is created, and it keeps the charge while the pod is non-terminal (released
once the pod reaches `Succeeded`/`Failed` or is deleted). It does not react when
init containers finish, so the shrink in this design only frees capacity inside
HAMi. The apiserver quota is not released at that point.

Because of this, the same pods can run fine without a quota but fail when a quota is
set. Example: quota is 10000. Pod A (init 8000, app 5000) is charged 8000 for as
long as it stays non-terminal, even after its init container exits. Pod B (effective 5000) gets rejected with `exceeded quota: ... used: 8k` before HAMi even sees it. This is normal Kubernetes behavior and HAMi cannot change it.

Loading