opscart/opscart-k8s-watcher v1.11.0

OpsCart v1.11.0 — Node Health & Workload Placement

on GitHub

OpsCart v1.11.0 — Node Health & Workload Placement

This release extends OpsCart beyond workload-level diagnostics by introducing
persistent Kubernetes node-health incidents and workload-placement correlation.

OpsCart can now detect unhealthy node conditions, preserve them in Operational
Memory, correlate workloads currently placed on those nodes, and surface the
evidence across Infrastructure, War Room, Investigation, and emergency CLI
triage.

What's New

Node Health Detection

OpsCart now detects Kubernetes-reported node conditions including:

• Ready=False/Unknown — CRITICAL
• DiskPressure — HIGH
• MemoryPressure — HIGH
• PIDPressure — HIGH
• NetworkUnavailable — HIGH

Severity is derived from the node condition itself. The number of colocated
workloads does not increase severity.

Workload Placement Correlation

For unhealthy nodes, OpsCart captures the workloads and pods currently placed
on the node.

Correlation is based on Kubernetes node placement and is explicitly presented
as:

Correlated by node placement — not a claim of causation.

This provides useful infrastructure context without claiming that a node
condition caused a workload failure.

Persistent Node Incidents

Node conditions now participate in the existing OpsCart incident lifecycle:

• DETECTED
• RESOLVED
• REOPENED
• Three-scan resolution debounce
• Historical evidence retention

Node and workload incidents share the same scan-wide persistence and lifecycle
flow.

Infrastructure — Node Health

The Infrastructure page now shows unhealthy nodes alongside their node-pool
context and compact workload-placement summaries.

Detailed placement information remains available without overwhelming the
primary infrastructure view.

War Room Integration

Active node incidents now participate in War Room prioritization alongside
workload incidents.

Node-condition severity follows the Kubernetes condition policy rather than
the persisted placeholder severity or number of colocated workloads.

Node Investigation

Node incidents now have a dedicated Investigation experience with:

• Node identity and node pool
• Condition status
• Kubernetes reason and message
• Last transition time
• Current workload-placement snapshot
• Workload and pod counts by namespace
• Incident timeline
• Read-only investigation commands

Resolved incidents retain their historical evidence without presenting stale
placement information as current state.

Node investigations intentionally do not expose Container Logs.

Emergency CLI Node Health

opscart-scan emergency now includes a compact Node Health section when
unhealthy node conditions are detected.

Example:

🔷 NODE HEALTH:
HIGH  DiskPressure on opscart-m02
      Reason: KubeletHasDiskPressure
      Placement: 27 workloads · 32 pods colocated
      Correlated by node placement — not a claim of causation.
      kubectl describe node opscart-m02

Healthy nodes add no additional CLI noise.

Safety & Evidence Semantics

Node-to-workload relationships in this release represent placement correlation,
not inferred causation.

OpsCart continues to provide read-only investigation guidance. Node Health does
not introduce cordon, drain, delete, restart, or other remediation actions.

Container Images

Official image:

ghcr.io/opscart/opscart-dashboard:v1.11.0

Supported platforms:

• linux/amd64
• linux/arm64

Security

The v1.11.0 Go binary was scanned with Trivy:

Vulnerabilities: 0

Validation

The release was validated with:

go build ./...
go vet ./...
go test ./... -race
git diff --check

The published multi-architecture container image was also deployed and
validated through the OpsCart Helm chart.

Full Changelog: v1.10.3...v1.11.0