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
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.CreateOrUpdateHostDatanames 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
mainas of 2026-09-08