Draino helps move applications away from Kubernetes machines that show specified problems. It marks matching nodes as unavailable for new work and drains their existing workloads, so replacement instances can run elsewhere. It is useful as one part of a node-repair process that also detects faults and supplies replacement capacity. Draining does not repair the machine itself, and the conditions and scope need care to avoid evacuating healthy capacity.
Deployment and operating notes
Draino selects nodes by labels and conditions and cordons matching nodes immediately. Its drain buffer spaces drain starts; the first matching node can be drained immediately, so the buffer is not a guaranteed grace period before eviction. The recorded negz/draino repository is a fork of planetlabs/draino. The intended integration with Node Problem Detector and Cluster Autoscaler explains the design, but this review did not establish a supported current release for the target cluster.
Before enabling automatic remediation, identify whether the managed node service already repairs unhealthy nodes. Define which conditions are permanent enough to justify evacuation, and scope the controller to an explicit test pool. Run with --dry-run first to verify the selected nodes without cordoning or draining them. Review disruption budgets, local data, drain timeouts, replacement capacity and permission to cordon or evict. Simulate one condition on a disposable node and verify both application recovery and eventual node replacement; draining alone does not prove the underlying fault is fixed. Keep a way to stop the controller and uncordon a node after diagnosis. Do not let two remediation systems react independently to the same condition without understanding their combined effect.
Historical upstream link check · 2026-10-09
The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. GitHub does not mark negz/draino 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
Original publication: 2018-09-23T06:47:39+00:00. Preserved for context. Commands, versions, prices and results below reflect the original research.
Draino automatically drains Kubernetes nodes based on labels and node conditions. Nodes that match all of the supplied labels and any of the supplied node conditions will be cordoned immediately and drained after a configurable drain-buffer time.
Draino is intended for use alongside the Kubernetes Node Problem Detector and Cluster Autoscaler. The Node Problem Detector can set a node condition when it detects something wrong with a node – for instance by watching node logs or running a script. The Cluster Autoscaler can be configured to delete nodes that are underutilised. Adding Draino to the mix enables autoremediation:
- The Node Problem Detector detects a permanent node problem and sets the corresponding node condition.
- Draino notices the node condition. It immediately cordons the node to prevent new pods being scheduled there, and schedules a drain of the node.
- Once the node has been drained the Cluster Autoscaler will consider it underutilised. It will be eligible for scale down (i.e. termination) by the Autoscaler after a configurable period of time.
There is currently no Helm chart available for Draino which is a shame. However, it should be reasonably easy to create one using the example deployment manifest. It may be a good idea to include the Node Problem Detector daemonset as part of the package since no Helm chart exists for that either.
The post Draino appeared first on kubedex.com.
Sources & further reading
Spotted something that needs another look?
Help improve this page →