Merge branch 'master' into fullUrlImages

Author: vartikashah

docs/cloud/rahti/tutorials/pod-affinity.md

@@ -53,6 +53,38 @@ Labels:         app=celery-worker
 
 When the `affinity` block is added to this deployment, the scheduler will (re-)launch the Pods corresponding to `wes-deployment` into the same as `celery-worker` is running. As the policy used is `requiredDuringSchedulingIgnoredDuringExecution`, if there is no space in the chosen node, the deployment will not succeed. Other policy is `preferredDuringSchedulingIgnoredDuringExecution`, which means that the scheduling will not fail if there is no space in the chosen node as they will be scheduled in a different one.
 
+Regarding the pod anti-affinity, the syntax is slightly different. Here is an example:
+
+```diff
+diff --git a/charts/wes/templates/wes/wes-deployment.yaml b/charts/wes/templates/wes/wes-deployment.yaml
+index 93ca230..e64349b 100644
+--- a/charts/wes/templates/wes/wes-deployment.yaml
++++ b/charts/wes/templates/wes/wes-deployment.yaml
+@@ -12,6 +12,16 @@ spec:
+       labels:
+         app: {{ .Values.wes.appName }}
+     spec:
++      affinity:
++        podAntiAffinity:
++          requiredDuringSchedulingIgnoredDuringExecution:
++          - weight: 100
++            podAffinityTerm:
++              labelSelector:
++                matchExpressions:
++                - key: app
++                  operator: In
++                  values:
++                  - celery-worker
++            topologyKey: "kubernetes.io/hostname"
+       initContainers:
+```
+
+Two new keys are needed for the anti-affinity:
+
+- `weight` (range 1-100): The scheduler will prefer to schedule pods to nodes that satisfy the anti-affinity expressions. The node that is most preferred is the one with the greatest sum of weights, i.e. for each node that meets all of the scheduling requirements (resource request, requiredDuringScheduling anti-affinity expressions, etc.), compute a sum by iterating through the elements of this field and adding "weight" to the sum if the node has pods which matches the corresponding podAffinityTerm; the node(s) with the highest sum are the most preferred. The weights of all of the matched WeightedPodAffinityTerm fields are added per-node to find the most preferred node(s)
+
+- `podAffinityTerm`: Defines a set of pods that this pod should be not co-located (anti-affinity) with, where co-located is defined as running on a node whose value of the label with key <topologyKey> matches that of any node on which a pod of the set of pods is running
+
 More information and further examples can be found at:
 
 <https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity>