Controlling Pod placement with labels and affinity rules
1. Controlling Pod placement with labels and affinity rules
Pod placement in GKE refers to the process of controlling where your application's Pods are deployed across the cluster's nodes. This process plays a crucial role in optimizing performance, ensuring availability, and managing resource allocation within your GKE environment. In GKE Standard mode, you can control and manage Pod placement by using labels, affinity rules, taints, and tolerations. Let’s begin by exploring labels and affinity rules. To identify the appropriate location to place a Pod, GKE uses a Pod’s specifications–like resource requests and limits. Then, the scheduler automatically spreads Pods across nodes within their capacity limits. Upon startup, nodes automatically receive zone-specific labels from the kubelet. This ensures accurate tracking even when nodes span across compute zones. But what if you want certain application types to run on a specific node? In GKE Standard mode, you can use the nodeSelector field within a Pod's configuration to specify its preferred node labels. Think of it as a checklist the Pod uses to find a compatible home. Node labels can be automatically assigned, or can be manually added to identify nodes with specific characteristics. This creates a system of matching between Pod preferences and node capabilities. If your Pods need more CPU or memory than the general-purpose class allows, or if they require a specific CPU type, you can use the nodeSelector field in a Pod's specification to request the "Balanced" compute class. This will ensure Pods are placed on nodes with the resources they need. Autopilot can do this for you, just be sure to add the cloud.google.com/compute-class label in the nodeSelector rule for the Pods to be placed on a specific compute class. This can also be accomplished with node affinity rules. If a node's capabilities match the Pod’s preferences, then the node is considered a suitable host for that Pod. As an example, let’s say a Pod needs a node from the "ssd" node pool to run. In this case, if a node doesn't have an “ssd” label, the Pod will stay in waiting mode. However, please note that future label changes won’t impact Pods that are already running. Like nodeSelectors, affinity rules can also be used to influence Pod placement. Node affinity and anti-affinity are label-based Pod placement approaches, but with more flexible and expressive rules. Affinity rules can be used to ensure that two or more pods are placed together on the same node, and anti-affinity rules can be used to spread Pods across different nodes. Unlike nodeSlectors, which only schedule Pods if they meet requirements, node affinity lets you define rules as preferences instead of requirements. Affinity and anti-affinity rules can be expressed by using two specific keywords: 'requiredDuringSchedulingIgnoredDuringExecution' and ‘preferredDuringSchedulingIgnoredDuringExecution’. ‘RequiredDuringScheduling’ enforces a strict requirement that must be met when scheduling Pods, whereas ‘PreferredDuringScheduling’ indicates a flexible preference that isn’t mandatory. You can set a weight for this preference, where 1 is the weakest and 100 is the strongest. The stronger the weight, the more the scheduler will try to favor nodes that match your preference. ‘IgnoredDuringExecution’ indicates that changes to labels will not affect Pods that are already running. Now let’s say there is a scenario where the NodeSelectorTerms field is used and the node must meet all matchExpression requirements. This is an example of affinity, where a single matchExpression–accelerator-type–is specified. Logically, the matchExpression values are joined using the boolean AND. From there, the In operator would indicate that only one of the listed values must match the preferences. Other operators, like ‘NotIn’, can be used to configure a node anti-affinity rule. Let’s explore another example, this time one that indicates a flexible preference. You might recall that you can set a weight for a preference. So if the weight has been set to 90, it signals a strong preference. After the scheduler evaluates each available node, it will assign the Pod to the node that earns the highest overall score, and it will take this preference and its weight into account. The node affinity rules in this example are set to express a strong preference for nodes that are in the n1-highmem-4 or n1highnem-8 node pools. It’s recommended that node pool names indicate the type of compute instances that will be used to create the nodes. All nodes within a node pool share identical configurations, so a descriptive name accurately reflects their hardware specifications. Also, GKE automatically assigns labels to nodes based on their node pool names. This empowers you to easily create preferences for specific hardware types using those labels during Pod scheduling. Affinity and anti-affinity rules aren't limited to individual nodes—they can be applied at broader levels of infrastructure organization. You can achieve this by using topologyKeys, which allow you to define preferences based on broader topology domains like zones and regions. For example, you can use a topologyKey to indicate that you prefer not to schedule a Pod to a webserver zone if other Pods are already running in that zone. And if you need more granular control, inter-pod affinity and anti-affinity features can be used, because they consider the labels of other Pods already running on nodes.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.