{
	"id": "7f72764c-f25e-4a4d-a5e3-83b08f146a44",
	"created_at": "2026-04-06T01:32:41.02783Z",
	"updated_at": "2026-04-10T13:12:39.877876Z",
	"deleted_at": null,
	"sha1_hash": "5601dcca39ad4c4c905f64ccd1179c3d059b37c8",
	"title": "Assigning Pods to Nodes",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 190529,
	"plain_text": "Assigning Pods to Nodes\r\nArchived: 2026-04-06 00:29:18 UTC\r\nYou can constrain a Pod so that it is restricted to run on particular node(s), or to prefer to run on particular nodes.\r\nThere are several ways to do this and the recommended approaches all use label selectors to facilitate the\r\nselection. Often, you do not need to set any such constraints; the scheduler will automatically do a reasonable\r\nplacement (for example, spreading your Pods across nodes so as not place Pods on a node with insufficient free\r\nresources). However, there are some circumstances where you may want to control which node the Pod deploys\r\nto, for example, to ensure that a Pod ends up on a node with an SSD attached to it, or to co-locate Pods from two\r\ndifferent services that communicate a lot into the same availability zone.\r\nYou can use any of the following methods to choose where Kubernetes schedules specific Pods:\r\nnodeSelector field matching against node labels\r\nAffinity and anti-affinity\r\nnodeName field\r\nPod topology spread constraints\r\nNode labels\r\nLike many other Kubernetes objects, nodes have labels. You can attach labels manually. Kubernetes also populates\r\na standard set of labels on all nodes in a cluster.\r\nNote:\r\nThe value of these labels is cloud provider specific and is not guaranteed to be reliable. For example, the value of\r\nkubernetes.io/hostname may be the same as the node name in some environments and a different value in other\r\nenvironments.\r\nNode isolation/restriction\r\nAdding labels to nodes allows you to target Pods for scheduling on specific nodes or groups of nodes. You can use\r\nthis functionality to ensure that specific Pods only run on nodes with certain isolation, security, or regulatory\r\nproperties.\r\nIf you use labels for node isolation, choose label keys that the kubelet cannot modify. This prevents a\r\ncompromised node from setting those labels on itself so that the scheduler schedules workloads onto the\r\ncompromised node.\r\nThe NodeRestriction admission plugin prevents the kubelet from setting or modifying labels with a node-restriction.kubernetes.io/ prefix.\r\nTo make use of that label prefix for node isolation:\r\nhttps://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/\r\nPage 1 of 17\n\n1. Ensure you are using the Node authorizer and have enabled the NodeRestriction admission plugin.\r\n2. Add labels with the node-restriction.kubernetes.io/ prefix to your nodes, and use those labels in your\r\nnode selectors. For example, example.com.node-restriction.kubernetes.io/fips=true or\r\nexample.com.node-restriction.kubernetes.io/pci-dss=true .\r\nnodeSelector\r\nnodeSelector is the simplest recommended form of node selection constraint. You can add the nodeSelector\r\nfield to your Pod specification and specify the node labels you want the target node to have. Kubernetes only\r\nschedules the Pod onto nodes that have each of the labels you specify.\r\nSee Assign Pods to Nodes for more information.\r\nAffinity and anti-affinity\r\nnodeSelector is the simplest way to constrain Pods to nodes with specific labels. Affinity and anti-affinity\r\nexpand the types of constraints you can define. Some of the benefits of affinity and anti-affinity include:\r\nThe affinity/anti-affinity language is more expressive. nodeSelector only selects nodes with all the\r\nspecified labels. Affinity/anti-affinity gives you more control over the selection logic.\r\nYou can indicate that a rule is soft or preferred, so that the scheduler still schedules the Pod even if it can't\r\nfind a matching node.\r\nYou can constrain a Pod using labels on other Pods running on the node (or other topological domain),\r\ninstead of just node labels, which allows you to define rules for which Pods can be co-located on a node.\r\nThe affinity feature consists of two types of affinity:\r\nNode affinity functions like the nodeSelector field but is more expressive and allows you to specify soft\r\nrules.\r\nInter-pod affinity/anti-affinity allows you to constrain Pods against labels on other Pods.\r\nNode affinity\r\nNode affinity is conceptually similar to nodeSelector , allowing you to constrain which nodes your Pod can be\r\nscheduled on based on node labels. There are two types of node affinity:\r\nrequiredDuringSchedulingIgnoredDuringExecution : The scheduler can't schedule the Pod unless the rule\r\nis met. This functions like nodeSelector , but with a more expressive syntax.\r\npreferredDuringSchedulingIgnoredDuringExecution : The scheduler tries to find a node that meets the\r\nrule. If a matching node is not available, the scheduler still schedules the Pod.\r\nNote:\r\nIn the preceding types, IgnoredDuringExecution means that if the node labels change after Kubernetes schedules\r\nthe Pod, the Pod continues to run.\r\nhttps://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/\r\nPage 2 of 17\n\nYou can specify node affinities using the .spec.affinity.nodeAffinity field in your Pod spec.\r\nFor example, consider the following Pod spec:\r\napiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n name: with-node-affinity\r\nspec:\r\n affinity:\r\n nodeAffinity:\r\n requiredDuringSchedulingIgnoredDuringExecution:\r\n nodeSelectorTerms:\r\n - matchExpressions:\r\n - key: topology.kubernetes.io/zone\r\n operator: In\r\n values:\r\n - antarctica-east1\r\n - antarctica-west1\r\n preferredDuringSchedulingIgnoredDuringExecution:\r\n - weight: 1\r\n preference:\r\n matchExpressions:\r\n - key: another-node-label-key\r\n operator: In\r\n values:\r\n - another-node-label-value\r\n containers:\r\n - name: with-node-affinity\r\n image: registry.k8s.io/pause:3.8\r\nIn this example, the following rules apply:\r\nThe node must have a label with the key topology.kubernetes.io/zone and the value of that label must\r\nbe either antarctica-east1 or antarctica-west1 .\r\nThe node preferably has a label with the key another-node-label-key and the value another-node-label-value .\r\nYou can use the operator field to specify a logical operator for Kubernetes to use when interpreting the rules.\r\nYou can use In , NotIn , Exists , DoesNotExist , Gt and Lt .\r\nRead Operators to learn more about how these work.\r\nNotIn and DoesNotExist allow you to define node anti-affinity behavior. Alternatively, you can use node taints\r\nto repel Pods from specific nodes.\r\nNote:\r\nhttps://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/\r\nPage 3 of 17\n\nIf you specify both nodeSelector and nodeAffinity , both must be satisfied for the Pod to be scheduled onto a\r\nnode.\r\nIf you specify multiple terms in nodeSelectorTerms associated with nodeAffinity types, then the Pod can be\r\nscheduled onto a node if one of the specified terms can be satisfied (terms are ORed).\r\nIf you specify multiple expressions in a single matchExpressions field associated with a term in\r\nnodeSelectorTerms , then the Pod can be scheduled onto a node only if all the expressions are satisfied\r\n(expressions are ANDed).\r\nSee Assign Pods to Nodes using Node Affinity for more information.\r\nNode affinity weight\r\nYou can specify a weight between 1 and 100 for each instance of the\r\npreferredDuringSchedulingIgnoredDuringExecution affinity type. When the scheduler finds nodes that meet all\r\nthe other scheduling requirements of the Pod, the scheduler iterates through every preferred rule that the node\r\nsatisfies and adds the value of the weight for that expression to a sum.\r\nThe final sum is added to the score of other priority functions for the node. Nodes with the highest total score are\r\nprioritized when the scheduler makes a scheduling decision for the Pod.\r\nFor example, consider the following Pod spec:\r\napiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n name: with-affinity-preferred-weight\r\nspec:\r\n affinity:\r\n nodeAffinity:\r\n requiredDuringSchedulingIgnoredDuringExecution:\r\n nodeSelectorTerms:\r\n - matchExpressions:\r\n - key: kubernetes.io/os\r\n operator: In\r\n values:\r\n - linux\r\n preferredDuringSchedulingIgnoredDuringExecution:\r\n - weight: 1\r\n preference:\r\n matchExpressions:\r\n - key: label-1\r\n operator: In\r\n values:\r\n - key-1\r\n - weight: 50\r\nhttps://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/\r\nPage 4 of 17\n\npreference:\r\n matchExpressions:\r\n - key: label-2\r\n operator: In\r\n values:\r\n - key-2\r\n containers:\r\n - name: with-node-affinity\r\n image: registry.k8s.io/pause:3.8\r\nIf there are two possible nodes that match the preferredDuringSchedulingIgnoredDuringExecution rule, one\r\nwith the label-1:key-1 label and another with the label-2:key-2 label, the scheduler considers the weight\r\nof each node and adds the weight to the other scores for that node, and schedules the Pod onto the node with the\r\nhighest final score.\r\nNote:\r\nIf you want Kubernetes to successfully schedule the Pods in this example, you must have existing nodes with the\r\nkubernetes.io/os=linux label.\r\nNode affinity per scheduling profile\r\nFEATURE STATE: Kubernetes v1.20 [beta]\r\nWhen configuring multiple scheduling profiles, you can associate a profile with a node affinity, which is useful if\r\na profile only applies to a specific set of nodes. To do so, add an addedAffinity to the args field of the\r\nNodeAffinity plugin in the scheduler configuration. For example:\r\napiVersion: kubescheduler.config.k8s.io/v1\r\nkind: KubeSchedulerConfiguration\r\nprofiles:\r\n - schedulerName: default-scheduler\r\n - schedulerName: foo-scheduler\r\n pluginConfig:\r\n - name: NodeAffinity\r\n args:\r\n addedAffinity:\r\n requiredDuringSchedulingIgnoredDuringExecution:\r\n nodeSelectorTerms:\r\n - matchExpressions:\r\n - key: scheduler-profile\r\n operator: In\r\n values:\r\n - foo\r\nhttps://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/\r\nPage 5 of 17\n\nThe addedAffinity is applied to all Pods that set .spec.schedulerName to foo-scheduler , in addition to the\r\nNodeAffinity specified in the PodSpec. That is, in order to match the Pod, nodes need to satisfy addedAffinity\r\nand the Pod's .spec.NodeAffinity .\r\nSince the addedAffinity is not visible to end users, its behavior might be unexpected to them. Use node labels\r\nthat have a clear correlation to the scheduler profile name.\r\nNote:\r\nThe DaemonSet controller, which creates Pods for DaemonSets, does not support scheduling profiles. When the\r\nDaemonSet controller creates Pods, the default Kubernetes scheduler places those Pods and honors any\r\nnodeAffinity rules in the DaemonSet controller.\r\nInter-pod affinity and anti-affinity\r\nInter-pod affinity and anti-affinity allow you to constrain which nodes your Pods can be scheduled on based on the\r\nlabels of Pods already running on that node, instead of the node labels.\r\nTypes of Inter-pod Affinity and Anti-affinity\r\nInter-pod affinity and anti-affinity take the form \"this Pod should (or, in the case of anti-affinity, should not) run in\r\nan X if that X is already running one or more Pods that meet rule Y\", where X is a topology domain like node,\r\nrack, cloud provider zone or region, or similar and Y is the rule Kubernetes tries to satisfy.\r\nYou express these rules (Y) as label selectors with an optional associated list of namespaces. Pods are namespaced\r\nobjects in Kubernetes, so Pod labels also implicitly have namespaces. Any label selectors for Pod labels should\r\nspecify the namespaces in which Kubernetes should look for those labels.\r\nYou express the topology domain (X) using a topologyKey , which is the key for the node label that the system\r\nuses to denote the domain. For examples, see Well-Known Labels, Annotations and Taints.\r\nNote:\r\nInter-pod affinity and anti-affinity require substantial amounts of processing which can slow down scheduling in\r\nlarge clusters significantly. We do not recommend using them in clusters larger than several hundred nodes.\r\nNote:\r\nPod anti-affinity requires nodes to be consistently labeled, in other words, every node in the cluster must have an\r\nappropriate label matching topologyKey . If some or all nodes are missing the specified topologyKey label, it\r\ncan lead to unintended behavior.\r\nSimilar to node affinity are two types of Pod affinity and anti-affinity as follows:\r\nrequiredDuringSchedulingIgnoredDuringExecution\r\npreferredDuringSchedulingIgnoredDuringExecution\r\nhttps://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/\r\nPage 6 of 17\n\nFor example, you could use requiredDuringSchedulingIgnoredDuringExecution affinity to tell the scheduler to\r\nco-locate Pods of two services in the same cloud provider zone because they communicate with each other a lot.\r\nSimilarly, you could use preferredDuringSchedulingIgnoredDuringExecution anti-affinity to spread Pods from\r\na service across multiple cloud provider zones.\r\nTo use inter-pod affinity, use the affinity.podAffinity field in the Pod spec. For inter-pod anti-affinity, use the\r\naffinity.podAntiAffinity field in the Pod spec.\r\nScheduling Behavior\r\nWhen scheduling a new Pod, the Kubernetes scheduler evaluates the Pod's affinity/anti-affinity rules in the context\r\nof the current cluster state:\r\n1. Hard Constraints (Node Filtering):\r\npodAffinity.requiredDuringSchedulingIgnoredDuringExecution and\r\npodAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution :\r\nThe scheduler ensures the new Pod is assigned to nodes that satisfy these required affinity\r\nand anti-affinity rules based on existing Pods.\r\n2. Soft Constraints (Scoring):\r\npodAffinity.preferredDuringSchedulingIgnoredDuringExecution and\r\npodAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution :\r\nThe scheduler scores nodes based on how well they meet these preferred affinity and anti-affinity rules to optimize Pod placement.\r\n3. Ignored Fields:\r\nExisting Pods' podAffinity.preferredDuringSchedulingIgnoredDuringExecution :\r\nThese preferred affinity rules are not considered during the scheduling decision for new\r\nPods.\r\nExisting Pods' podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution :\r\nSimilarly, preferred anti-affinity rules of existing Pods are ignored during scheduling.\r\nScheduling a Group of Pods with Inter-pod Affinity to Themselves\r\nIf the current Pod being scheduled is the first in a series that have affinity to themselves, it is allowed to be\r\nscheduled if it passes all other affinity checks. This is determined by verifying that no other Pod in the cluster\r\nmatches the namespace and selector of this Pod, that the Pod matches its own terms, and the chosen node matches\r\nall requested topologies. This ensures that there will not be a deadlock even if all the Pods have inter-pod affinity\r\nspecified.\r\nPod Affinity Example\r\nConsider the following Pod spec:\r\nhttps://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/\r\nPage 7 of 17\n\napiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n name: with-pod-affinity\r\nspec:\r\n affinity:\r\n podAffinity:\r\n requiredDuringSchedulingIgnoredDuringExecution:\r\n - labelSelector:\r\n matchExpressions:\r\n - key: security\r\n operator: In\r\n values:\r\n - S1\r\n topologyKey: topology.kubernetes.io/zone\r\n podAntiAffinity:\r\n preferredDuringSchedulingIgnoredDuringExecution:\r\n - weight: 100\r\n podAffinityTerm:\r\n labelSelector:\r\n matchExpressions:\r\n - key: security\r\n operator: In\r\n values:\r\n - S2\r\n topologyKey: topology.kubernetes.io/zone\r\n containers:\r\n - name: with-pod-affinity\r\n image: registry.k8s.io/pause:3.8\r\nThis example defines one Pod affinity rule and one Pod anti-affinity rule. The Pod affinity rule uses the \"hard\"\r\nrequiredDuringSchedulingIgnoredDuringExecution , while the anti-affinity rule uses the \"soft\"\r\npreferredDuringSchedulingIgnoredDuringExecution .\r\nThe affinity rule specifies that the scheduler is allowed to place the example Pod on a node only if that node\r\nbelongs to a specific zone where other Pods have been labeled with security=S1 . For instance, if we have a\r\ncluster with a designated zone, let's call it \"Zone V,\" consisting of nodes labeled with\r\ntopology.kubernetes.io/zone=V , the scheduler can assign the Pod to any node within Zone V, as long as there is\r\nat least one Pod within Zone V already labeled with security=S1 . Conversely, if there are no Pods with\r\nsecurity=S1 labels in Zone V, the scheduler will not assign the example Pod to any node in that zone.\r\nThe anti-affinity rule specifies that the scheduler should try to avoid scheduling the Pod on a node if that node\r\nbelongs to a specific zone where other Pods have been labeled with security=S2 . For instance, if we have a\r\ncluster with a designated zone, let's call it \"Zone R,\" consisting of nodes labeled with\r\ntopology.kubernetes.io/zone=R , the scheduler should avoid assigning the Pod to any node within Zone R, as\r\nhttps://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/\r\nPage 8 of 17\n\nlong as there is at least one Pod within Zone R already labeled with security=S2 . Conversely, the anti-affinity\r\nrule does not impact scheduling into Zone R if there are no Pods with security=S2 labels.\r\nTo get yourself more familiar with the examples of Pod affinity and anti-affinity, refer to the design proposal.\r\nYou can use the In , NotIn , Exists and DoesNotExist values in the operator field for Pod affinity and\r\nanti-affinity.\r\nRead Operators to learn more about how these work.\r\nIn principle, the topologyKey can be any allowed label key with the following exceptions for performance and\r\nsecurity reasons:\r\nFor Pod affinity and anti-affinity, an empty topologyKey field is not allowed in both\r\nrequiredDuringSchedulingIgnoredDuringExecution and\r\npreferredDuringSchedulingIgnoredDuringExecution .\r\nFor requiredDuringSchedulingIgnoredDuringExecution Pod anti-affinity rules, the admission controller\r\nLimitPodHardAntiAffinityTopology limits topologyKey to kubernetes.io/hostname . You can modify\r\nor disable the admission controller if you want to allow custom topologies.\r\nIn addition to labelSelector and topologyKey , you can optionally specify a list of namespaces which the\r\nlabelSelector should match against using the namespaces field at the same level as labelSelector and\r\ntopologyKey . If omitted or empty, namespaces defaults to the namespace of the Pod where the affinity/anti-affinity definition appears.\r\nNamespace Selector\r\nFEATURE STATE: Kubernetes v1.24 [stable]\r\nYou can also select matching namespaces using namespaceSelector , which is a label query over the set of\r\nnamespaces. The affinity term is applied to namespaces selected by both namespaceSelector and the\r\nnamespaces field. Note that an empty namespaceSelector ({}) matches all namespaces, while a null or empty\r\nnamespaces list and null namespaceSelector matches the namespace of the Pod where the rule is defined.\r\nmatchLabelKeys\r\nFEATURE STATE: Kubernetes v1.33 [stable] (enabled by default)\r\nNote:\r\nThe matchLabelKeys field is a beta-level field and is enabled by default in Kubernetes 1.35. When you want to\r\ndisable it, you have to disable it explicitly via the MatchLabelKeysInPodAffinity feature gate.\r\nKubernetes includes an optional matchLabelKeys field for Pod affinity or anti-affinity. The field specifies keys\r\nfor the labels that should match with the incoming Pod's labels, when satisfying the Pod (anti)affinity.\r\nhttps://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/\r\nPage 9 of 17\n\nThe keys are used to look up values from the Pod labels; those key-value labels are combined (using AND ) with\r\nthe match restrictions defined using the labelSelector field. The combined filtering selects the set of existing\r\nPods that will be taken into Pod (anti)affinity calculation.\r\nCaution:\r\nIt's not recommended to use matchLabelKeys with labels that might be updated directly on pods. Even if you edit\r\nthe pod's label that is specified at matchLabelKeys directly, (that is, not via a deployment), kube-apiserver\r\ndoesn't reflect the label update onto the merged labelSelector .\r\nA common use case is to use matchLabelKeys with pod-template-hash (set on Pods managed as part of a\r\nDeployment, where the value is unique for each revision). Using pod-template-hash in matchLabelKeys allows\r\nyou to target the Pods that belong to the same revision as the incoming Pod, so that a rolling upgrade won't break\r\naffinity.\r\napiVersion: apps/v1\r\nkind: Deployment\r\nmetadata:\r\n name: application-server\r\n...\r\nspec:\r\n template:\r\n spec:\r\n affinity:\r\n podAffinity:\r\n requiredDuringSchedulingIgnoredDuringExecution:\r\n - labelSelector:\r\n matchExpressions:\r\n - key: app\r\n operator: In\r\n values:\r\n - database\r\n topologyKey: topology.kubernetes.io/zone\r\n # Only Pods from a given rollout are taken into consideration when calculating pod affinity.\r\n # If you update the Deployment, the replacement Pods follow their own affinity rules\r\n # (if there are any defined in the new Pod template)\r\n matchLabelKeys:\r\n - pod-template-hash\r\nmismatchLabelKeys\r\nFEATURE STATE: Kubernetes v1.33 [stable] (enabled by default)\r\nNote:\r\nhttps://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/\r\nPage 10 of 17\n\nThe mismatchLabelKeys field is a beta-level field and is enabled by default in Kubernetes 1.35. When you want\r\nto disable it, you have to disable it explicitly via the MatchLabelKeysInPodAffinity feature gate.\r\nKubernetes includes an optional mismatchLabelKeys field for Pod affinity or anti-affinity. The field specifies\r\nkeys for the labels that should not match with the incoming Pod's labels, when satisfying the Pod (anti)affinity.\r\nCaution:\r\nIt's not recommended to use mismatchLabelKeys with labels that might be updated directly on pods. Even if you\r\nedit the pod's label that is specified at mismatchLabelKeys directly, (that is, not via a deployment), kube-apiserver doesn't reflect the label update onto the merged labelSelector .\r\nOne example use case is to ensure Pods go to the topology domain (node, zone, etc) where only Pods from the\r\nsame tenant or team are scheduled in. In other words, you want to avoid running Pods from two different tenants\r\non the same topology domain at the same time.\r\napiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n labels:\r\n # Assume that all relevant Pods have a \"tenant\" label set\r\n tenant: tenant-a\r\n...\r\nspec:\r\n affinity:\r\n podAffinity:\r\n requiredDuringSchedulingIgnoredDuringExecution:\r\n # ensure that Pods associated with this tenant land on the correct node pool\r\n - matchLabelKeys:\r\n - tenant\r\n labelSelector: {}\r\n topologyKey: node-pool\r\n podAntiAffinity:\r\n requiredDuringSchedulingIgnoredDuringExecution:\r\n # ensure that Pods associated with this tenant can't schedule to nodes used for another tenant\r\n - mismatchLabelKeys:\r\n - tenant # whatever the value of the \"tenant\" label for this Pod, prevent\r\n # scheduling to nodes in any pool where any Pod from a different\r\n # tenant is running.\r\n labelSelector:\r\n # We have to have the labelSelector which selects only Pods with the tenant label,\r\n # otherwise this Pod would have anti-affinity against Pods from daemonsets as well, for example,\r\n # which aren't supposed to have the tenant label.\r\n matchExpressions:\r\n - key: tenant\r\nhttps://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/\r\nPage 11 of 17\n\noperator: Exists\r\n topologyKey: node-pool\r\nMore practical use-cases\r\nInter-pod affinity and anti-affinity can be even more useful when they are used with higher level collections such\r\nas ReplicaSets, StatefulSets, Deployments, etc. These rules allow you to configure that a set of workloads should\r\nbe co-located in the same defined topology; for example, preferring to place two related Pods onto the same node.\r\nFor example: imagine a three-node cluster. You use the cluster to run a web application and also an in-memory\r\ncache (such as Redis). For this example, also assume that latency between the web application and the memory\r\ncache should be as low as is practical. You could use inter-pod affinity and anti-affinity to co-locate the web\r\nservers with the cache as much as possible.\r\nIn the following example Deployment for the Redis cache, the replicas get the label app=store . The\r\npodAntiAffinity rule tells the scheduler to avoid placing multiple replicas with the app=store label on a\r\nsingle node. This creates each cache in a separate node.\r\napiVersion: apps/v1\r\nkind: Deployment\r\nmetadata:\r\n name: redis-cache\r\nspec:\r\n selector:\r\n matchLabels:\r\n app: store\r\n replicas: 3\r\n template:\r\n metadata:\r\n labels:\r\n app: store\r\n spec:\r\n affinity:\r\n podAntiAffinity:\r\n requiredDuringSchedulingIgnoredDuringExecution:\r\n - labelSelector:\r\n matchExpressions:\r\n - key: app\r\n operator: In\r\n values:\r\n - store\r\n topologyKey: \"kubernetes.io/hostname\"\r\n containers:\r\n - name: redis-server\r\n image: redis:3.2-alpine\r\nhttps://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/\r\nPage 12 of 17\n\nThe following example Deployment for the web servers creates replicas with the label app=web-store . The Pod\r\naffinity rule tells the scheduler to place each replica on a node that has a Pod with the label app=store . The Pod\r\nanti-affinity rule tells the scheduler never to place multiple app=web-store servers on a single node.\r\napiVersion: apps/v1\r\nkind: Deployment\r\nmetadata:\r\n name: web-server\r\nspec:\r\n selector:\r\n matchLabels:\r\n app: web-store\r\n replicas: 3\r\n template:\r\n metadata:\r\n labels:\r\n app: web-store\r\n spec:\r\n affinity:\r\n podAntiAffinity:\r\n requiredDuringSchedulingIgnoredDuringExecution:\r\n - labelSelector:\r\n matchExpressions:\r\n - key: app\r\n operator: In\r\n values:\r\n - web-store\r\n topologyKey: \"kubernetes.io/hostname\"\r\n podAffinity:\r\n requiredDuringSchedulingIgnoredDuringExecution:\r\n - labelSelector:\r\n matchExpressions:\r\n - key: app\r\n operator: In\r\n values:\r\n - store\r\n topologyKey: \"kubernetes.io/hostname\"\r\n containers:\r\n - name: web-app\r\n image: nginx:1.16-alpine\r\nCreating the two preceding Deployments results in the following cluster layout, where each web server is co-located with a cache, on three separate nodes.\r\nhttps://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/\r\nPage 13 of 17\n\nnode-1 node-2 node-3\r\nwebserver-1 webserver-2 webserver-3\r\ncache-1 cache-2 cache-3\r\nThe overall effect is that each cache instance is likely to be accessed by a single client that is running on the same\r\nnode. This approach aims to minimize both skew (imbalanced load) and latency.\r\nYou might have other reasons to use Pod anti-affinity. See the ZooKeeper tutorial for an example of a StatefulSet\r\nconfigured with anti-affinity for high availability, using the same technique as this example.\r\nnodeName\r\nnodeName is a more direct form of node selection than affinity or nodeSelector . nodeName is a field in the Pod\r\nspec. If the nodeName field is not empty, the scheduler ignores the Pod and the kubelet on the named node tries to\r\nplace the Pod on that node. Using nodeName overrules using nodeSelector or affinity and anti-affinity rules.\r\nSome of the limitations of using nodeName to select nodes are:\r\nIf the named node does not exist, the Pod will not run, and in some cases may be automatically deleted.\r\nIf the named node does not have the resources to accommodate the Pod, the Pod will fail and its reason will\r\nindicate why, for example OutOfmemory or OutOfcpu.\r\nNode names in cloud environments are not always predictable or stable.\r\nWarning:\r\nnodeName is intended for use by custom schedulers or advanced use cases where you need to bypass any\r\nconfigured schedulers. Bypassing the schedulers might lead to failed Pods if the assigned Nodes get\r\noversubscribed. You can use node affinity or the nodeSelector field to assign a Pod to a specific Node without\r\nbypassing the schedulers.\r\nHere is an example of a Pod spec using the nodeName field:\r\napiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n name: nginx\r\nspec:\r\n containers:\r\n - name: nginx\r\n image: nginx\r\n nodeName: kube-01\r\nThe above Pod will only run on the node kube-01 .\r\nhttps://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/\r\nPage 14 of 17\n\nnominatedNodeName\r\nFEATURE STATE: Kubernetes v1.35 [beta] (enabled by default)\r\nnominatedNodeName can be used for external components to nominate node for a pending pod. This nomination is\r\nbest effort: it might be ignored if the scheduler determines the pod cannot go to a nominated node.\r\nAlso, this field can be (over)written by the scheduler:\r\nIf the scheduler finds a node to nominate via the preemption.\r\nIf the scheduler decides where the pod is going, and move it to the binding cycle.\r\nNote that, in this case, nominatedNodeName is put only when the pod has to go through\r\nWaitOnPermit or PreBind extension points.\r\nHere is an example of a Pod status using the nominatedNodeName field:\r\napiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n name: nginx\r\n...\r\nstatus:\r\n nominatedNodeName: kube-01\r\nPod topology spread constraints\r\nYou can use topology spread constraints to control how Pods are spread across your cluster among failure-domains such as regions, zones, nodes, or among any other topology domains that you define. You might do this\r\nto improve performance, expected availability, or overall utilization.\r\nRead Pod topology spread constraints to learn more about how these work.\r\nPod topology labels\r\nFEATURE STATE: Kubernetes v1.35 [beta] (enabled by default)\r\nPods inherit the topology labels ( topology.kubernetes.io/zone and topology.kubernetes.io/region ) from\r\ntheir assigned Node if those labels are present. These labels can then be utilized via the Downward API to provide\r\nthe workload with node topology awareness.\r\nHere is an example of a Pod using downward API for it's zone and region:\r\napiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n name: pod-with-topology-labels\r\nhttps://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/\r\nPage 15 of 17\n\nspec:\r\n containers:\r\n - name: app\r\n image: alpine\r\n command: [\"sh\", \"-c\", \"env\"]\r\n env:\r\n - name: MY_ZONE\r\n valueFrom:\r\n fieldRef:\r\n fieldPath: metadata.labels['topology.kubernetes.io/zone']\r\n - name: MY_REGION\r\n valueFrom:\r\n fieldRef:\r\n fieldPath: metadata.labels['topology.kubernetes.io/region']\r\nOperators\r\nThe following are all the logical operators that you can use in the operator field for nodeAffinity and\r\npodAffinity mentioned above.\r\nOperator Behavior\r\nIn The label value is present in the supplied set of strings\r\nNotIn The label value is not contained in the supplied set of strings\r\nExists A label with this key exists on the object\r\nDoesNotExist No label with this key exists on the object\r\nThe following operators can only be used with nodeAffinity .\r\nOperator Behavior\r\nGt\r\nThe field value will be parsed as an integer, and the integer that results from parsing the value of\r\na label named by this selector is greater than this integer\r\nLt\r\nThe field value will be parsed as an integer, and the integer that results from parsing the value of\r\na label named by this selector is less than this integer\r\nNote:\r\nGt and Lt operators will not work with non-integer values. If the given value doesn't parse as an integer, the\r\nPod will fail to get scheduled. Also, Gt and Lt are not available for podAffinity .\r\nWhat's next\r\nhttps://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/\r\nPage 16 of 17\n\nRead more about taints and tolerations.\r\nRead the design docs for node affinity and for inter-pod affinity/anti-affinity.\r\nLearn about how the topology manager takes part in node-level resource allocation decisions.\r\nLearn how to use nodeSelector.\r\nLearn how to use affinity and anti-affinity.\r\nSource: https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/\r\nhttps://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/\r\nPage 17 of 17",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/"
	],
	"report_names": [
		"assign-pod-node"
	],
	"threat_actors": [],
	"ts_created_at": 1775439161,
	"ts_updated_at": 1775826759,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/5601dcca39ad4c4c905f64ccd1179c3d059b37c8.pdf",
		"text": "https://archive.orkl.eu/5601dcca39ad4c4c905f64ccd1179c3d059b37c8.txt",
		"img": "https://archive.orkl.eu/5601dcca39ad4c4c905f64ccd1179c3d059b37c8.jpg"
	}
}