This historical handler watched AWS Spot interruption notices from each Kubernetes node and attempted to stop its workloads gracefully before the machine disappeared. It was intended to give applications a chance to move or finish work rather than experience an abrupt loss. The recorded mumoshu project later moved to kube-aws, separately from AWS's own Node Termination Handler. Notices remain best effort, so reliable recovery cannot depend on every drain completing in time.
Current guidance
The recovered entry points to mumoshu/kube-spot-termination-notice-handler. Its README describes polling EC2 instance metadata and draining a node when a Spot termination notice appears, with examples using older egeland images. The repository explicitly says it moved to kube-aws/kube-spot-termination-notice-handler. That documented continuation is separate from the aws/aws-node-termination-handler project; the move alone does not establish current support for the old implementation.
AWS documents Spot interruption notices as best-effort signals. The usual warning interval is not a guaranteed completion window, and hibernation starts immediately. Workloads must therefore tolerate interruption even when a drain cannot finish: use appropriate retries, checkpointing and durable storage rather than relying on the watcher alone.
For an existing deployment, identify the node groups, metadata access and drain flags before selecting a replacement. The current AWS handler has metadata and queue-processing modes, while EKS managed node groups already handle relevant lifecycle actions and do not generally require the handler. Avoid duplicate controllers responding to the same event. Test the chosen mechanism against the exact infrastructure and application disruption constraints. A current support matrix for this historical mumoshu implementation was not established.
Historical upstream link check · 2026-10-09
The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. GitHub does not mark mumoshu/kube-spot-termination-notice-handler archived or disabled; this does not establish active maintenance, support or compatibility. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Preserved for context. Commands, versions, prices and results below reflect the original research.
This chart installs the kube-spot-termination-notice-handler as a daemonset across the cluster nodes. A Kubernetes DaemonSet to run 1 container per node to periodically polls the EC2 Spot Instance Termination Notices endpoint. Once a termination notice is received, it will try to gracefully stop all the pods running on the Kubernetes node, up to 2 minutes before the EC2 Spot Instance backing the node is terminated.
Purpose
- The handler watches for Spot termination events, and will do the following if detected:
- Drain the affected node
- [Optional] Send a message to a Slack channel informing that a termination notice has been received.
- your kubernetes jobs backed by spot instances can keep running on other instances (typically on-demand instances)
How it works
Each spot-termination-notice-handler pod polls the notice endpoint until it returns a HTTP status 200. That status means a termination is scheduled for the EC2 spot instance running the handler pod.
Introduced in version 0.9.2 of this application (the @mumoshu version), you are able to setup a Slack incoming web hook in order to send slack notifications to a channel, notifying the users that an instance has been terminated.
Incoming WebHooks require that you set the SLACK_URL environmental variable as part of your PodSpec.
Sources & further reading
Spotted something that needs another look?
Help improve this page →