Skip to main content
In this walkthrough, we’ll verify how Amazon EKS and Kubernetes self-heal after a Pod deletion, and confirm there’s no impact on end-users by monitoring the application UI, Real User Monitoring (RUM), and control plane metrics in CloudWatch.

​
1. Verify Pod Auto-Replacement

After deleting a Pod, Kubernetes should automatically spin up a new one. Run:
Expected output:
Kubernetes replaces the deleted petsite-deployment Pod within seconds, demonstrating built-in self-healing.

​
2. Validate Application Availability & RUM Metrics

Next, confirm the application UI loads without errors and that RUM data in CloudWatch shows no spike in errors or user frustration signals.
The image shows an AWS CloudWatch dashboard for monitoring application performance, displaying metrics like page loads, load time, and errors. It includes navigation tabs and filtering options for detailed analysis.
A manual refresh confirms that user frustration signals remain at baseline:
The image shows an AWS CloudWatch dashboard displaying metrics for "Largest Contentful Paint" and "First Input Delay," with graphs indicating performance over time. The metrics are categorized into positive, tolerable, and frustrating levels.

​
3. Monitor EKS Control Plane Metrics

Finally, review your EKS cluster’s control plane metrics to ensure resource utilization stayed consistent throughout the experiment.
The image shows an AWS CloudWatch dashboard for monitoring EKS services, displaying metrics like pod CPU and memory utilization, and the number of running services.
Stable control plane metrics confirm that pod deletion did not adversely affect cluster health.

​
Conclusion

This demo highlights Kubernetes’ resilience on Amazon EKS:
  • Self-healing: Deleted Pods are recreated almost instantly.
  • Zero user impact: No UI errors or RUM spikes.
  • Stable cluster health: Control plane metrics remain steady.

Watch Video