Adjusting Pod Eviction Timings in Kubernetes

A node fails. Your pod is rescheduled in seconds, but it never starts. Discover the hidden storage problem in Kubernetes failover.

#1about 3 minutes

A DBA's journey to running SQL Server on Kubernetes

The speaker shares his background as a SQL Server DBA and the efficiency gains that led him to explore running stateful workloads in Kubernetes.

#2about 2 minutes

Why the default five-minute failover is unacceptable

When a node fails, Kubernetes waits five minutes by default before rescheduling pods, which is too long for stateful applications like SQL Server.

#3about 5 minutes

Demonstrating the default pod eviction delay in action

A live demo shows an nginx pod taking five minutes to be rescheduled to a healthy node after its original node is shut down in AKS.

#4about 2 minutes

How to configure faster pod eviction with tolerations

Pod eviction time can be reduced from five minutes to seconds by setting tolerations for not-ready and unreachable nodes in the deployment YAML.

#5about 3 minutes

Demo of a ten-second failover using tolerations

By adding tolerations to the nginx deployment, a new pod is spun up on a healthy node just ten seconds after the original node fails.

#6about 7 minutes

Why fast pod eviction fails for stateful apps

A demo with SQL Server shows that even with tolerations, the new pod gets stuck in a "ContainerCreating" state due to a multi-attach error on the persistent volume.

#7about 7 minutes

Achieving high availability with Portworx storage

A third-party tool called Portworx provides a storage class that correctly detaches and reattaches storage, enabling a SQL Server pod to fail over successfully in seconds.

#8about 1 minute

Key considerations for stateful app high availability

Achieving high availability for stateful apps in Kubernetes requires adjusting pod tolerations and using a storage solution that can handle volume reattachment across nodes.