Steadybit logoResilience Hub
Try SteadybitGitHub icon
Steadybit logoResilience Hub

Host

Extension

Extension

A Steadybit extension to discover hosts and attack them.
Install now

Host

A Steadybit extension to discover hosts and attack them.
Extension

Extension

Install now

Host

Extension

Extension

A Steadybit extension to discover hosts and attack them.
Install now

Host

A Steadybit extension to discover hosts and attack them.
Extension

Extension

Install now
Go back to list
Statistics
-Stars
Tags
Host
Kubernetes
Network
AWS
Azure
GCP
Homepage
hub.steadybit.com/extension/com.steadybit.extension_host
License
MIT
MaintainerSteadybit
Install now

Provided Target Discovery

See all
Hosts

Provided Actions

See all
Block DNS

Blocks access to DNS servers

Attack

Attack

Hosts

Useful Templates

See all
Network outage for Kubernetes nodes in an availability zone

Achieve high availability of your Kubernetes cluster via redundancy across different Availability Zones. Check what happens to your Kubernetes cluster when one of the zones is down.

Motivation

Cloud providers host your deployments and services across multiple locations worldwide. From a reliability standpoint, regions and availability zones are most interesting. While the former refers to separate geographic areas spread worldwide, the latter refers to an isolated location within a region. For most use cases, applying deployments across availability zones is sufficient. Given that failures may happen at this level quite frequently, you should verify that your applications are still working in case of an outage.

Structure

We leverage the block traffic attack to simulate a full network loss in an availability zone. While the zone outage happens, we observe changes in the Kubernetes cluster with Steadybit's built-in visibility. Once the zone outage is over, we expect that all deployments will recover again within a specified time.

Solution Sketch

  • AWS Regions and Zones
  • Azure Regions and Zones
  • GCP Regions and Zones
  • Kubernetes liveness, readiness, and startup probes
Azure
GCP
Redundancy
AWS
Availability Zone

Hosts

Kubernetes cluster

Kubernetes deployments

Network loss for Kubernetes node's outgoing traffic in an availability zone

Achieve high availability of your Kubernetes cluster via redundancy across different Availability Zones. Check what happens to your Kubernetes cluster when one of the zones suffers from a network loss.

Motivation

Cloud provider host your deployments and services across multiple locations worldwide. From a reliability standpoint, regions and availability zones are most interesting. While the former refers to separate geographic areas spread worldwide, the latter refers to an isolated location within a region. For most use cases, applying deployments across availability zone is sufficient. Given that failures may happen at this level quite frequently, you should verify that your applications are still working in case of an outage.

Structure

We leverage the drop outgoing traffic to simulate network loss in an availability. If you want to test for a full outage of the zone, configure it to 100% loss. While the network loss happens, we observe changes of a Kubernetes cluster with Steadybit's built-in visibility. Once the network loss is over, we expect that all deployments will recover again within a specified time.

Solution Sketch

  • AWS Regions and Zones
  • Azure Regions and Zones
  • GCP Regions and Zones
  • Kubernetes liveness, readiness, and startup probes
AWS
Azure
GCP
Redundancy
Kubernetes
Availability Zone

Hosts

Kubernetes cluster

Kubernetes deployments

Kubernetes node shutdown results in new node startup

A resilient Kubernetes cluster can cope with a crashing node and simply starts a new one.

Motivation

A changing number of nodes in your Kubernetes cluster is expected, as you may update your nodes from time to time or simply scale the cluster depending on traffic peaks. This is especially true when using spot instances in a Cloud environment. This requires the deployments to be node-independent and properly configured to be rescheduled on a newly started node or a node that still has free resources.

Structure

Before restarting a node, we verify that the cluster is healthy and that the deployments are ready. Afterward, we trigger the shutdown of the node of a specific Kubernetes deployment and expect the deployment to be rescheduled on any other node and a new node to start up within a reasonable amount of time.

Solution Sketch

  • Kubernetes liveness, readiness, and startup probes

Warning

Please be aware that we will shut down a node. Please ensure this is fine and your node is either virtual or can somehow be started up afterward.

Elasticity
Kubernetes

Hosts

Kubernetes cluster

Kubernetes deployments

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