Kubernetes-hosted application checklist (part 2)

Posted on October 13, 2017  •  2 minutes  • 239 words

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.

Node selector

Simpleast form of constraint for pod placement. You attach labels to nodes and you specify 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.