Workloads & Scheduling

The question asks how to configure a Pod to be scheduled on nodes that have a specific taint (key 'dedicated', value 'database', effect 'NoSchedule'). To allow a Pod to be scheduled on tainted nodes, you must add a matching toleration to the Pod specification.

The correct approach is to add a toleration with:
- key: 'dedicated'
- value: 'database'
- operator: 'Equal'
- effect: 'NoSchedule'

This toleration exactly matches the taint on the nodes, allowing the Pod to tolerate that taint and be scheduled on those nodes.

The other options are incorrect for the following reasons:

Using nodeSelector with key 'dedicated' and value 'database' is wrong because nodeSelector is used to select nodes based on labels, not taints. Labels and taints are different concepts in Kubernetes. A nodeSelector would only work if the node had a label with that key-value pair, not a taint.

Using a toleration with operator 'Exists' and effect 'NoExecute' is incorrect for two reasons: First, the effect must match the taint's effect, which is 'NoSchedule', not 'NoExecute'. Second, while 'Exists' operator would match any value for the key 'dedicated', the mismatched effect means it won't tolerate the actual taint.

Using node affinity with requiredDuringSchedulingIgnoredDuringExecution is also incorrect because node affinity rules work with node labels, not taints. Node affinity is used to attract Pods to specific nodes based on label criteria, but it cannot override or tolerate taints. Even if a Pod has affinity for a tainted node, it will still be rejected due to the taint unless it has a matching toleration.

The correct answer is Deployment with replicas set to 3.

A Deployment is the most commonly used Kubernetes resource for managing stateless applications where you need to maintain a specific number of identical Pod replicas. When you set replicas to 3, the Deployment controller continuously monitors the cluster state and ensures exactly 3 Pods are running at all times. If a Pod fails, gets deleted, or becomes unhealthy, the Deployment controller automatically creates a replacement Pod to maintain the desired state.

Why the other options are not the best choice:

StatefulSet with replicas set to 3: While a StatefulSet can also maintain 3 replicas, it is designed specifically for stateful applications that require stable network identities, persistent storage, and ordered deployment/scaling. For simple containerized applications where Pods are identical and interchangeable (as described in the question), a Deployment is the standard and most commonly used approach. StatefulSets add unnecessary complexity when stateful features are not needed.

Pod manifest with restartPolicy Always: A standalone Pod manifest only defines a single Pod. The restartPolicy setting only affects container restart behavior within that single Pod - it does not create additional Pods or replace the Pod if the entire Pod object is deleted from the cluster. You cannot achieve 3 replicas or automatic Pod replacement using just a Pod manifest.

DaemonSet configured for specific nodes: A DaemonSet ensures that a copy of a Pod runs on each selected node in the cluster. It does not allow you to specify a fixed number of replicas like 3. Instead, the number of Pods depends on the number of nodes matching the selection criteria. DaemonSets are typically used for node-level services like log collectors or monitoring agents, not for maintaining a specific replica count.

The question asks for an operator that excludes nodes where a specific label KEY is present. The key distinction here is that we want to avoid nodes that have the label key 'environment' at all, not just nodes where environment=production.

The DoesNotExist operator is the correct choice because it checks whether a label key exists on the node. When using DoesNotExist with the key 'environment', pods will only be scheduled on nodes that do not have the 'environment' label key present at all. This perfectly matches the requirement to schedule pods on nodes that do NOT have a specific label key present.

The NotIn operator with an empty values array would not work as expected for this use case. NotIn with an empty values array essentially means 'the key exists but has no matching values in an empty list' - this would match all nodes where the key exists with any value, which is the opposite of what we want.

The Exists operator combined with a negative weight is incorrect for two reasons: First, the Exists operator matches nodes WHERE the label key is present, not where it's absent. Second, weight values are only used with preferredDuringSchedulingIgnoredDuringExecution (soft preference), not with requiredDuringSchedulingIgnoredDuringExecution (hard requirement) which the question specifically mentions.

The NotIn operator with 'production' in the values array would only exclude nodes where environment=production specifically. This means pods could still be scheduled on nodes that have the environment label with different values (like environment=staging), which doesn't fully satisfy the requirement of avoiding nodes where the label KEY is present.