Task 1.3: Scheduling

• AIt hands Pods to the nodes in turn, one after another, so each node gets the same count

  Incorrect

  The scheduler does not rotate blindly; it checks requests, constraints and policies and ranks the nodes that fit.

• BIt filters out unsuitable nodes, scores the rest, and binds the Pod to the best node

  Correct

  Scheduling is two steps, filtering and scoring; the Pod goes to the feasible node with the highest score, with ties broken at random.

• CIt reads live CPU usage from the metrics pipeline and picks the least busy node

  Incorrect

  Placement is based on the requests of scheduled Pods and on constraints, not on live usage figures.

• DIt waits until a kubelet with spare capacity claims the Pod for its own node

  Incorrect

  Kubelets run Pods that are already bound to their node; the scheduler does the binding.

kube-scheduler watches for unscheduled Pods, filters the nodes to the feasible set, scores them, and binds the Pod to the best one.

• AScheduling counts the requests of the Pods on each node, not their actual CPU use

  Correct

  The capacity check uses requests, not usage. Even when actual usage is low, a node whose requests are nearly used up is rejected.

• BCPU limits on the running Pods are throttling the scheduler's own process

  Incorrect

  Limits cap a running container's CPU at runtime; they do not throttle scheduling.

• Cmetrics-server is down, so the scheduler sees no usage data for the nodes

  Incorrect

  The scheduler does not read metrics-server for placement, so its health does not explain the event.

• DThe namespace ResourceQuota is used up, so the Pod waits in Pending until it frees

  Incorrect

  An exceeded quota rejects the create request with a Forbidden error; the Pod is never stored, so it cannot be Pending.

Requests are reservations. The scheduler fits a Pod only where the sum of requests stays within the node's allocatable resources, whatever the live usage graph shows.

• ARequired node affinity for the GPU nodes on the ML Pods

  Incorrect

  Affinity draws the ML Pods toward the GPU nodes, but it does nothing to keep other Pods away from them.

• BCordon each GPU node so the scheduler keeps other Pods away from it

  Incorrect

  A cordoned node is marked unschedulable, so the scheduler places no new ML Pods there either.

• CA ResourceQuota on GPU requests in the default namespace

  Incorrect

  A quota limits totals in one namespace; it does not decide which nodes Pods run on.

• DTaint the GPU nodes and add a matching toleration to the ML Pods

  Correct

  A taint repels every Pod that does not tolerate it, and the toleration lets the ML Pods through.

Taints work from the node's side: they keep away Pods that lack a matching toleration. That is the tool for dedicating nodes to a set of workloads.

• ARequired Pod affinity to its own app label, with topologyKey kubernetes.io/hostname

  Incorrect

  Affinity would not keep the replicas apart, so two of them could still share a node.

• BRequired Pod anti-affinity against its own app label, with topologyKey kubernetes.io/hostname

  Correct

  Required anti-affinity forbids placing a Pod on a node that already runs a Pod matching the selector, so the replicas end up on separate nodes.

• CRequired node affinity for a node label carried by the cache node pool, such as pool=cache

  Incorrect

  Node affinity picks eligible nodes but ignores which Pods already run there, so two replicas can share a node.

• DA PodDisruptionBudget for the cache with minAvailable set to 2 replicas

  Incorrect

  A disruption budget limits voluntary evictions. It has no say in where the replicas are placed.

Inter-pod anti-affinity places Pods relative to other Pods; with the hostname topology key each node can hold at most one replica.

• AA PriorityClass with a high value assigned to the payment Pods

  Correct

  When a Pod with higher priority cannot fit, the scheduler can preempt lower-priority Pods to make room for it.

• BRequests equal to limits so the payment Pods get the Guaranteed QoS class

  Incorrect

  QoS class matters to the kubelet when a node runs short of resources. It does not let a Pending Pod displace others.

• CA PodDisruptionBudget on the payment Deployment

  Incorrect

  A budget protects existing payment Pods from voluntary evictions; it does not help new ones get scheduled.

• DA ResourceQuota on the batch namespace

  Incorrect

  A quota caps new batch requests, but it does not remove batch Pods that are already running.

Priority and preemption let important Pods take resources from less important ones when the cluster is short.

• AA PriorityClass with a high value

  Incorrect

  Priority affects scheduling order and preemption. It does not decide the QoS class.

• BCPU and memory requests with no limits

  Incorrect

  Requests without limits make the Pod Burstable.

• CA CPU request equal to its CPU limit

  Correct

  Guaranteed requires a CPU request and limit on every container, with the two values equal.

• DA toleration for the node.kubernetes.io/memory-pressure taint

  Incorrect

  A toleration only affects which nodes accept the Pod; it has no bearing on QoS.

• EA memory request equal to its memory limit

  Correct

  Guaranteed also requires a memory request and limit on every container, with the two values equal.

Kubernetes derives the QoS class from requests and limits. Equal requests and limits for both CPU and memory on every container give Guaranteed, the class least likely to be evicted under node pressure.

• A512Mi, the limit copied as request

  Correct

  When only a limit is set and no default request applies, Kubernetes uses the limit as the request.

• BZero, so the Pod fits on any node

  Incorrect

  The request is not left at zero when a limit is given.

• CHalf of the limit, which is 256Mi

  Incorrect

  No halving rule exists.

• DThe total memory of the node

  Incorrect

  Requests are never derived from node size.

Setting only a limit also sets the request to the same value, which affects scheduling and the QoS class.

• ABy adding a toleration for the custom scheduler

  Incorrect

  Tolerations relate to taints, not to choosing a scheduler.

• BBy labeling the Pods scheduler=custom

  Incorrect

  Labels do not select a scheduler.

• CBy giving the Pods a higher priority

  Incorrect

  Priority orders the queue of whichever scheduler handles the Pod.

• DBy setting spec.schedulerName in the Pod

  Correct

  Each Pod names the scheduler responsible for it in spec.schedulerName; without it, the default scheduler is used.

Several schedulers can run side by side; spec.schedulerName picks one per Pod.

• ANode affinity with NotIn on lifecycle=spot

  Correct

  NotIn and DoesNotExist express node anti-affinity, keeping this workload off matching nodes.

• BA toleration for lifecycle=spot

  Incorrect

  Tolerations relate to taints, and these nodes carry none.

• CA lower priority for the Deployment's Pods

  Incorrect

  Priority orders scheduling and preemption; it does not keep Pods off particular nodes.

• DA DaemonSet in place of the Deployment

  Incorrect

  A DaemonSet places Pods per node; it does not exclude labeled nodes on its own.

Node affinity operators such as NotIn let one workload avoid nodes without changing the nodes themselves.

• Akey dedicated with operator Equal and value "*"

  Incorrect

  Equal compares the value literally; there is no wildcard.

• Bkey dedicated with operator Equal and an empty value

  Incorrect

  An empty value only matches a taint with an empty value.

• Ckey dedicated with operator Exists and no value

  Correct

  With operator Exists, a toleration matches any value of the key.

• DOne toleration per known team value

  Incorrect

  That works only for values known today and misses new ones.

Tolerations match taints by key, value and effect; Exists matches the key regardless of value.