CKA Workloads & Scheduling Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution for the GPU label.

  Why it's wrong here

  Node affinity only constrains pod placement based on labels but does not manage hardware resource allocation. While this mechanism ensures a Pod lands on a node labelled 'accelerator=nvidia-tesla', it fails to request the actual GPU capacity from the kubelet, leading to scheduling errors if the device plugin is not invoked via resources. You would use node affinity when you need to restrict pods to specific zones or hardware types without requesting specific consumable quantities.

• ✗

  Set resources.limits for 'nvidia.com/gpu' only.

  Why it's wrong here

  Requesting 'nvidia.com/gpu' in a Pod's `resources.limits` (or `requests`) signals to the scheduler that the Pod requires a GPU. However, this alone does not constrain the Pod to GPU-enabled nodes. Without a `nodeSelector` or `nodeAffinity` targeting specific nodes, the scheduler might attempt to place the Pod on any available node, including those without GPUs. If a non-GPU node is chosen, the Pod will remain in a `Pending` state indefinitely, as the requested `nvidia.com/gpu` resource will never be satisfied on that node.

• ✓

  Set nodeSelector to 'accelerator=nvidia-tesla' and request 'nvidia.com/gpu' in resources.

  Why this is correct

  This is the correct and comprehensive approach because it addresses both the placement of the Pod and the allocation of the specialized hardware resource. The `nodeSelector` ensures the Pod is scheduled exclusively onto nodes labeled `accelerator=nvidia-tesla`, which are the GPU-equipped nodes in this scenario. Simultaneously, requesting `nvidia.com/gpu` in the Pod's `resources` section (either `requests` or `limits`) informs the Kubernetes device plugin for NVIDIA GPUs to allocate a specific GPU device to the container, making it available inside the Pod. Both mechanisms are crucial for successful GPU workload deployment.

• ✗

  Add a toleration for GPU node taints.

  Why it's wrong here

  Adding a `toleration` for GPU node taints would only allow a Pod to be scheduled onto a tainted GPU node if such taints existed. `Tolerations` are used to permit Pods to be scheduled on nodes that have specific taints, preventing other Pods from running there, but they do not actively direct a Pod to a specific type of node. Furthermore, `tolerations` do not manage or request specific hardware resources like GPUs. Without a `nodeSelector` or `nodeAffinity` and an explicit resource request, the Pod would still not be guaranteed to land on a GPU node or acquire a GPU.

Go deeper

Related to this question