An operations team needs to deploy a containerized, multi-node deep learning inference application onto a shared Kubernetes cluster. The cluster contains a mix of GPU-enabled worker nodes and CPU-only general-purpose worker nodes. Which strategy best ensures the resource-intensive AI containers are scheduled onto the correct hardware while maintaining high availability and efficient resource scheduling?
Select an answer to reveal the explanation.
Short Explanation
In a mixed Kubernetes cluster, you need GPU-hungry AI containers to land on GPU nodes, not CPU-only nodes. Node affinity lets you label GPU workers and constrain the deployment to those labels, so Kubernetes schedules the right hardware while preserving scaling and high availability. Skipping orchestration or forcing CPU-only nodes just wrecks performance and resilience.
Full Explanation
In enterprise environments, container orchestration is crucial for achieving high availability, scalability, and resource efficiency. When deploying accelerated workloads (such as deep learning models) in a mixed Kubernetes cluster that contains both CPU-only and GPU-accelerated nodes, operators must direct workloads to the appropriate physical resources. Kubernetes facilitates this through scheduling constraints, specifically node affinity and tolerations. Node affinity allows developers to define rules based on labels attached to worker nodes (e.g., accelerator=nvidia-tesla-a100). The Kubernetes scheduler uses these rules to ensure that pods requiring GPU resources are only scheduled on nodes that possess the required hardware.
The strategy that configures Kubernetes node affinity rules to target worker nodes equipped with GPU accelerators is correct because it uses the native scheduler to place GPU-dependent inference pods on GPU-capable nodes while still benefiting from Kubernetes high availability, self-healing, rolling updates, and efficient bin packing.
The Docker Swarm approach is incorrect because Docker Swarm is generally less feature-rich and less widely adopted in enterprise AI environments compared to Kubernetes, which has native device plugin support (such as the NVIDIA GPU Operator) to manage complex hardware lifecycles.
The bare-metal virtual machines without container orchestration approach is incorrect because deploying workloads directly on bare-metal VMs without container orchestration sacrifices high availability, automated scaling, self-healing, and declarative deployment capabilities.
The CPU-only Kubernetes nodes approach is incorrect because executing compute-intensive deep learning models on CPU-only nodes violates the performance requirement, leading to excessive latencies and processing queues. Furthermore, GPU accelerators are designed for compute workloads, not administrative cluster tasks.