Skip to content

Add system-node-critical priorityClass to health-monitoring-agent DaemonSets - #451

Open
huaziyao wants to merge 1 commit into
aws:mainfrom
huaziyao:hma-priority-class
Open

Add system-node-critical priorityClass to health-monitoring-agent DaemonSets#451
huaziyao wants to merge 1 commit into
aws:mainfrom
huaziyao:hma-priority-class

Conversation

@huaziyao

@huaziyao huaziyao commented Aug 21, 2026

Copy link
Copy Markdown
Collaborator

What's changing and why?

Adds a priorityClassName (defaulting to the Kubernetes built-in system-node-critical) to both health-monitoring-agent DaemonSets:

  • health-monitoring-agent (NVIDIA / GPU)
  • health-monitoring-agent-non-nvidia (Trainium / Inferentia)

The value is configurable via .Values.priorityClassName and falls back to system-node-critical when unset.

Why: Under node DiskPressure, HMA was evicted moments before a GPU failure occurred — so the failure went undetected and unremediated. system-node-critical (priority value 2000001000) makes HMA among the last pods evicted under node pressure, after training and other monitoring pods, preserving health monitoring exactly when it matters most. This mirrors what EKSNodeMonitoringAgent already does. Because system-node-critical is a built-in PriorityClass, no additional PriorityClass object needs to be created.

Before / After UX

  • Before: HMA pods run at priority 0. Under node pressure (e.g. DiskPressure), they can be evicted early — potentially before or during a hardware failure — leaving the node unmonitored.
  • After: HMA pods run at priority 2000001000 (system-node-critical) by default, so the kubelet evicts them last, keeping health monitoring alive during node pressure. Operators can override or disable via .Values.priorityClassName.

How was this change tested?

Validated through render, lint, dry-run, and a live apply/observe/revert on a real cluster:

  1. helm template — rendered both DaemonSets and confirmed priorityClassName: system-node-critical appears in each pod spec; verified --set priorityClassName=<x> propagates correctly, with fallback to system-node-critical when unset.
  2. helm lint — passes clean.
  3. Server-side dry-runkubectl apply --server-side --dry-run accepted with no schema/admission errors.
  4. Live apply → observe → revert on an e2e test cluster (~10 nodes, 4 HMA pods): after apply, all HMA pods rolled out cleanly and reported priority: 2000001000 (up from 0); reverting returned them to priority: 0 with no priorityClassName, again via a clean rollout. No DaemonSet disruption during either transition.

Are unit tests added?

No — this is a Helm chart template/values change with no application code. Coverage is provided by the helm template / helm lint render checks above.

Are integration tests added?

No new automated integration tests. Verified manually via the live apply/observe/revert described above.

Reviewer Guidelines

‼️ Merge Requirements: PRs with failing integration tests cannot be merged without justification.

One of the following must be true:

  • All automated PR checks pass
  • Failed tests include local run results/screenshots proving they work
  • Changes are documentation-only

…monSets

Under node DiskPressure, HMA was evicted moments before a GPU failure went
undetected and unremediated (P438078245). Setting priorityClassName to the
built-in system-node-critical makes HMA the last pod evicted (after training
and other monitoring pods), preserving health monitoring during node pressure.
Mirrors what EKSNodeMonitoringAgent already does.

Applied to both the health-monitoring-agent (NVIDIA) and
health-monitoring-agent-non-nvidia (Trainium/Inferentia) DaemonSets.
Configurable via .Values.priorityClassName, defaulting to system-node-critical.
@huaziyao
huaziyao requested a review from a team as a code owner August 21, 2026 22:43
@kethang-sm

Copy link
Copy Markdown
Contributor

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants