Change:
image: nginx:1.16-alpine ``` <del> If we create the above two deployments, our three node cluster should look like below. </del> <ins> Creating the two preceding Deployments results in the following cluster layout, where each web server is co-located with a cache, on three separate nodes. </ins> |       node-1         |       node-2        |       node-3       | |:--------------------:|:-------------------:|:------------------:| | *webserver-1*        |   *webserver-2*     |    *webserver-3*   | |  *cache-1*           |     *cache-2*       |     *cache-3*      | <del> As you can see, all the 3 replicas of the `web-server` are automatically co-located with the cache as expected. ``` kubectl get pods -o wide ``` The output is similar to this: ``` NAME                           READY     STATUS    RESTARTS   AGE       IP           NODE redis-cache-1450370735-6dzlj   1/1       Running   0          8m        10.192.4.2   kube-node-3 redis-cache-1450370735-j2j96   1/1       Running   0          8m        10.192.2.2   kube-node-1 redis-cache-1450370735-z73mh   1/1       Running   0          8m        10.192.3.1   kube-node-2 web-server-1287567482-5d4dz    1/1       Running   0          7m        10.192.2.3   kube-node-1 web-server-1287567482-6f7v5    1/1       Running   0          7m        10.192.4.3   kube-node-3 web-server-1287567482-s330j    1/1       Running   0          7m        10.192.3.2   kube-node-2 ``` ##### Never co-located in the same node The above example uses `PodAntiAffinity` rule with `topologyKey: "kubernetes.io/hostname"` to deploy the redis cluster so that no two instances are located on the same host. See [ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure) for an example of a StatefulSet configured with anti-affinity for high availability, using the same technique. </del> <ins> See the [ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure) for an example of a StatefulSet configured with anti-affinity for high availability, using the same technique as this example. </ins> ## nodeName <del> `nodeName` is the simplest form of node selection constraint, but due to its limitations it is typically not used.  `nodeName` is a field of PodSpec.  If it is non-empty, the scheduler ignores the pod and the kubelet running on the named node tries to run the pod.  Thus, if `nodeName` is provided in the PodSpec, it takes precedence over the above methods for node selection. </del> <ins> `nodeName` is a more direct form of node selection than affinity or `nodeSelector`. `nodeName` is a field in the Pod spec. If the `nodeName` field is not empty, the scheduler ignores the Pod and the kubelet on the named node tries to place the Pod on that node. Using `nodeName` overrules using `nodeSelector` or affinity and anti-affinity rules. </ins> Some of the limitations of using `nodeName` to select nodes are: <del> -   If the named node does not exist, the pod will not be run, and in </del> <ins> -   If the named node does not exist, the Pod will not run, and in </ins> some cases may be automatically deleted. -   If the named node does not have the resources to accommodate the <del> pod, the pod will fail and its reason will indicate why, </del> <ins> Pod, the Pod will fail and its reason will indicate why, </ins> for example OutOfmemory or OutOfcpu. -   Node names in cloud environments are not always predictable or stable. <del> Here is an example of a pod config file using the `nodeName` field: </del> <ins> Here is an example of a Pod spec using the `nodeName` field: </ins> ```yaml apiVersion: v1

Discussion:
Page: This page could use a review and update for consistency, clarity, and style. Some sections read like tasks instead of conceptual information, and there's a few areas where the headings and readability are not in line with our style guidelines. /assign /sig docs /triage accepted /language en /kind cleanup
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/lifecycle frozen

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: The description provide in the following section is somewhat missing out the details. It is not justifying the value of weight one should configure in the affinity section of a deployment. Proposed Solution: It would be best if this page can contain a legitimate example around the weight in Node affinity. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--v1.18 <!--Additional Information:--What is the significance of weight: 1 as compared to weight: 100 ? Creating first issue in GIT, apologies if I have missed out something. Would be happy to hear from you.
/language en /sig scheduling
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at .

/lifecycle rotten
/remove-lifecycle rotten
/priority backlog
From what I understand, the scheduler iterates through each field for each matched affinity term and computes a sum, then places pods in nodes that meet the scheduling requirements by order of highest weight sum. Is this correct?
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
fixes this.
/remove-lifecycle rotten
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at .