k8s spot termination handler

AWS can interrupt Spot instances, leaving Kubernetes workloads on a machine that is about to disappear. This historical handler watched for notices in instance metadata and attempted to drain the affected node so workloads could move elsewhere. It was useful for improving the chance of an orderly transition. Notice delivery and available lead time are not guaranteed, and a managed node service or another provisioner may already own interruption handling.

Current guidance

The archived stable/k8s-spot-termination-handler chart identifies kube-aws/kube-spot-termination-notice-handler. Its README describes a DaemonSet polling EC2 metadata and lists image tags tied to old kubectl versions. Chart deprecation is confirmed, but this review does not assert a project-wide retirement notice or a supported current image.

AWS documents Spot interruption notices as best effort; hibernation does not provide the usual two-minute lead time. Design applications to tolerate node loss rather than treating graceful drain as guaranteed. Check metadata access, pod termination grace periods, disruption budgets and whether enough replacement capacity can become ready.

The separate AWS Node Termination Handler supports metadata-monitor and queue-processor modes with different permissions and event coverage. Its README also says EKS managed node groups do not require that handler. Determine what your node group or provisioning system already handles before installing another drainer. Test a controlled interruption, confirm workloads resume elsewhere and inspect stalled evictions. Do not copy old cluster-admin and image defaults into a modern cluster solely because the chart still renders.