The pod affinity Kubernetes allows the users to specify rules for how to place pods in relation to one another.

Bobcares answers all questions no matter the size, as part of our Server Management Service

Let us take a look at Pod affinity and anti-affinity in detail.

Pod affinity

Users can provide guidelines for how pods should position themselves in relation to one another using the Kubernetes Pod affinity feature. Custom labels on nodes and label selectors specified in pods help to define the rules. Affinity/anti-affinity helps to define a pod’s affinity towards a group of pods for placement. The placement is not under the control of the node. Pod Affinity ensures that two pods are in the same node.

Pod affinity Rules

The Kubernetes pod affinity rule states that the pod can only be under the schedule to a node in the same zone. And at least one other pod already running. The user can use pod affinity to restrict which nodes their pod on the basis of the labels of other pods. Labels are key/value pairs.

If the label selector on the new pod matches the label on the current pod, Kubernetes pod affinity can instruct the scheduler to locate the new pod on the same node as the other pods. Furthermore, if the label selector on the new pod matches the label on the current pod, it can prevent the scheduler from locating a new pod on the same node as pods with the same labels.

Pod affinity rules are under two classifications two types: required and preferred.
It is important and vital to follow the rules before scheduling a node on a pod. Preferred rules state that if a rule is met, the scheduler will attempt to enforce the rules but cannot guarantee enforcement.

Configuring Pod Affinity and Anti-affinity

The pod specification files allow the users to configure pod affinity/anti-affinity. A user can specify whether a rule is required, preferred, or both. If they specify both, the node must first satisfy the required rule before attempting to satisfy the preferred rule. A pod specification configured for Kubernetes pod affinity and anti-affinity is shown in the following example.

The pod affinity rule in this example indicates that the pod can only schedule onto a node if that node already has at least one running pod with the key security and value  S1. According to the pod anti-affinity rule, the pod prefers not to schedule onto a node if that node is already running a pod with a label key security and value S2.

An example pod configuration file with pod affinity

apiVersion: v1
kind: Pod
metadata:
name: with-pod-affinity
spec:
affinity:
podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector:
matchExpressions: -
key: security
operator: In
values:
- S1
topologyKey: failure-domain.beta.kubernetes.io/zone containers:
- name: with-pod-affinity
image: docker.io/ocpqe/hello-pod

Firstly, Here in the above-mentioned example, the PodAffinity' is to configure the Pod affinity. Secondly, the requiredDuringSchedulingIgnoredDuringExecution: defines the necessary rule. And after that, the key: security and the - S1 are the key and value (label) that must be matched in order to apply the rule. Finally, The operator represents the relationship between the old pod’s label and the set of values in the  matchExpression parameters in the new pod’s specification. It is possible to be, In, NotIn, Exists, or DoesNotExist.

Pod anti-affinity sample pod configuration file.

apiVersion: v1
kind: Pod
metadata:
name: with-pod-antiaffinity s
pec:
affinity:
podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: security
operator: In
values:
- S2
topologyKey: kubernetes.io/hostname c
ontainers:
- name: with-pod-affinity
image: docker.io/ocpqe/hello-pod

Here the preferredDuringSchedulingIgnoredDuringExecution: defines and denotes a Preferred rule. The - weight: 100 Sets the weight for a preferred rule. The node with the highest weight is preferred more. And the key: security represents pod label that determines when the anti-affinity rule applies is described. Give the label a key and a value.

[Need assistance with similar queries? We are here to help]

Conclusion

To conclude, the Kubernetes pod affinity allows the users to specify the placements of the pods. And Kubernetes orchestrates the execution of containerized applications across a cluster of hosts. The user can easily assess the placement of the rules for placing the pods.