Garbage-collect host-data resources after Kubernetes Nodes are deleted

What happened?

Host-data custom resources created by the node agent remain after their Kubernetes Node is deleted. On clusters with node autoscaling, each scale-up creates another set of cluster-scoped resources and the stale objects accumulate indefinitely.

Why it happens

CRDClient.CreateOrUpdateHostData names each resource after the node but sets no owner reference. The host-sensor manager has no node-deletion watcher or shutdown cleanup, so nothing removes resources when a Node disappears.

This affects the resources in hostdata.kubescape.cloud, including OS release, kernel, kubelet, CNI, open-port, security-hardening, control-plane, cloud-provider, and kernel-variable data.

Requested behavior

Please garbage-collect host-data resources whose named Kubernetes Node no longer exists. Cleanup should fail closed when the Node list cannot be read or is empty, and should not remove data for a present Node.

A controller-side Node deletion watcher is likely more reliable than pod shutdown cleanup because an autoscaled node can disappear without giving its node-agent pod a clean shutdown window. Tests should cover node deletion, transient Node-list failure, and a present node.

Versions checked

• node-agent v0.3.142
• current main as of 2026-09-08

Start with CRDClient.CreateOrUpdateHostData and the host-sensor manager to trace how host-data resources are created and managed. Then inspect the controller-side Node handling and existing tests, adding coverage for deleted Nodes, an empty or failing Node list, and a present Node. Done means stale resources are removed only for missing Nodes and cleanup fails closed on list errors or empty results.