This part is about how to define constraint to the scheduler on where/how you want your app container to be deployed on the k8s cluster.
Simpleast form of constraint for pod placement. You attach labels to nodes and
nodeSelector in your pod configuration.
When to use
- you want to deploy redis instance to memory-optimized (R3, R4) instance group for example.
Affinity and anti-affinity
Affinity and anti-affinity is like
nodeSelector but much more advanced, with
more type of constraints you can apply to the default scheduler.
- the language is more expressive (not just “AND of exact match”)
- you can indicate that the rule is “soft”/”preference” rather than a hard requirement, so if the scheduler can’t satisfy it, the pod will still be scheduled
- you can constrain against labels on other pods running on the node (or other topological domain), rather than against labels on the node itself, which allows rules about which pods can and cannot be co-located
requiredDuringSchedulingIgnoredDuringExecution is the hard type and
preferredDuringSchedulingIgnoredDuringExecution is the soft/preference type.
In short, affinity rules define rules/preferences to where a pod deploys and anti-affinity is the opposite.
When to use
affinity and anti-affinity should be used when necessary only. It has a side effect of reducing the speed of deployment.
affinity use case example: web server and redis server should be in the same node
anti-affinity example: 3 redis slaves should not be deployed in the same node.