Skip to main content
In this tutorial, you’ll learn how to use AWS Fault Injection Simulator (FIS) to simulate a pod deletion on an Amazon EKS cluster. Simulating pod terminations helps validate your application’s resilience and ensures that Kubernetes automatically recreates pods without impacting end users.

​
Experiment Overview

We’ll design a chaos experiment with two key components:
ComponentDescription
Observed ArchitectureThe current state of the pet adoption web application built with microservices on EKS.
HypothesisKubernetes will detect and recreate deleted pods across multiple Availability Zones (AZs).
Our microservices-based pet adoption application includes a product-details service deployed in multiple AZs. Because these pods have a cold start time of approximately five seconds, we anticipate no noticeable disruption for customers.
  • An existing Amazon EKS cluster with the FIS action role attached.
  • AWS CLI configured with permissions for FIS and EKS.
  • kubectl access to the EKS cluster.
Ensure your EKS node IAM role has the fis:StartExperiment permission to run AWS FIS experiments successfully.
The image illustrates a "Pod Delete Scenario on EKS" with a diagram of a Virtual Private Cloud (VPC) setup, highlighting a hypothesis about Kubernetes restarting application pods with minimal impact on customer experience.

​
Hypothesis

If one or more product-details pods are terminated:
  1. Kubernetes Detects Failure: The control plane marks the pods as unavailable.
  2. Self-Healing: The ReplicaSet controller launches new pods.
  3. User Impact: Due to the low cold start time (~5s), end users experience no downtime.

​
Next Steps

  1. Create an AWS FIS experiment template targeting the EKS pod delete action.
  2. Execute the experiment and monitor pod restart behavior.
  3. Validate application responsiveness via health checks and user interface tests.

​
References

Watch Video