Steadybit logoResilience Hub
Try SteadybitGitHub icon
Steadybit logoResilience Hub

Drain Node

Attack

Attack

Drains a node
Install now

Drain Node

Drains a node
Attack

Attack

Install now

Drain Node

Attack

Attack

Drains a node
Install now

Drain Node

Drains a node
Attack

Attack

Install now
Go back to list
Experiment EditorExperiment Editor

Introduction

Use the attack to drain one or multiple nodes. The nodes are drained via kubectl drain.

Some details:

  • Steadybit agents and extensions are excluded from the drain
  • kubectl parameter force is used to continue even if there are pods that do not declare a controller
  • kubectl parameter ignore-daemonsets is used to ignore daemonsets
  • kubectl parameter delete-emptydir-data is used to delete local data of pods using emptyDir

Use Cases

  • Check your application failover when a node is drained
  • Check if new nodes are created by your autoscaler (in combination with node count check)

Parameters

ParameterDescriptionDefault
DurationHow long should the node keep drained / cordoned?180s

Rollback

A drained node will be automatically uncorden after the given duration or in case of an error to rollback the effect.

Statistics
-Stars
Tags
Kubernetes
Homepage
hub.steadybit.com/extension/com.steadybit.extension_kubernetes
License
MIT
MaintainerSteadybit
Install now

Useful Templates

See all
Draining a node should reschedule pods quickly

When draining a node, Kubernetes should reschedule running pods on other nodes without hiccups to ease, e.g., node maintenance.

Motivation

Draining a node may be necessary for, e.g., maintenance of a node. If that happens, Kubernetes should be able to reschedule the pods running on that node within the expected time and without user-noticeable failures.

Structure

For the entire duration of the experiment, a user-facing endpoint should work within expected success rates. At the beginning of the experiment, all pods should be ready to accept traffic. As soon as the node is drained, Kubernetes will evict the pods, but we still expect the pod's redundancy to be able to serve the user-facing endpoint. Eventually, after 120 seconds, all pods should be rescheduled and ready again to recover after the maintenance.

Elasticity
Kubernetes

Kubernetes cluster

Kubernetes deployments

Kubernetes nodes

More Kubernetes Node Actions

See all
Start Using Steadybit Today

Get started with Steadybit, and you’ll get access to all of our features to discover the full power of Steadybit. Available for SaaS and on-prem!

Are you unsure where to begin?

No worries, our reliability experts are here to help: book a demo with them!

Steadybit logoResilience Hub
Try Steadybit
© 2024 Steadybit GmbH. All rights reserved.
Twitter iconLinkedIn iconGitHub icon