Your Kubernetes cluster hosts critical, real-time deep learning inference APIs that must maintain high availability. Some of the physical worker nodes in your cluster occasionally experience hardware failures or reboot due to kernel panics, causing service disruptions. Which design pattern should you implement to protect these workloads from single-node failures?
Select an answer to reveal the explanation.
Short Explanation and Infographic
If you put all your eggs in one basket, you know exactly what's going to happen. If that basket drops, you're out of business. In the Kubernetes world, if you run all your API replicas on the same physical server and that server loses power, your API goes dark. Not very efficient! To prevent this, we use Pod Anti-Affinity. Think of it as a rule that tells Kubernetes, "Hey, don't let these replica pods hang out on the same server. Spread them out!" That way, if server A takes a dive, server B and server C are still up and running, handling your traffic without dropping a single beat.
Full explanation below image
Full Explanation
High availability (HA) in a containerized AI environment requires designing for infrastructure failures. When deploying critical services such as real-time inference APIs in Kubernetes, running multiple replicas of a pod is the first step. However, if the scheduler places all those replicas on the same physical node to optimize resource packing, a single hardware failure (such as a power supply failure, memory error, or network drop) on that host will crash all replicas simultaneously, causing an outage.
To prevent this, administrators use Pod Anti-Affinity. By configuring podAntiAffinity in the deployment specification, the Kubernetes scheduler is instructed to avoid scheduling replica pods on nodes that already host a pod matching specific label selectors. This forces the scheduler to distribute the replicas across different physical nodes or availability zones. If one node fails, only a single replica is lost, and the remaining replicas on other nodes continue to serve traffic.
The other choices do not support high availability. Deploying all workloads on a single node creates a massive single point of failure (SPOF). Forcing node affinity to run replicas on the same node has the same structural flaw. Disabling pod preemption prevents the scheduler from reclaiming resources for high-priority pods but does not protect against physical node failures or assist in distributing workloads for redundancy.