From b84f53a06e695686a1cb2f6413a0ffe127269716 Mon Sep 17 00:00:00 2001 From: Matt Dorn Date: Mon, 13 Nov 2017 17:05:47 -0600 Subject: [PATCH] Update PodAffinity/PodAntiAffinity Use-Case (#6291) * Update PodAffinity/PodAntiAffinity Use-Case Updated PodAffinity use-case to reflect use of PodAntiAffinity. Under the previous Redis deployment manifest, each replica is not guaranteed its own node. * add podAntiAffinity to web-server spec use-case * Additional changes to PodAffinity/PodAntiAffinity Use-Case --- .../concepts/configuration/assign-pod-node.md | 29 +++++++++++++++---- 1 file changed, 24 insertions(+), 5 deletions(-) diff --git a/docs/concepts/configuration/assign-pod-node.md b/docs/concepts/configuration/assign-pod-node.md index 964db539e5..e57e11ff51 100644 --- a/docs/concepts/configuration/assign-pod-node.md +++ b/docs/concepts/configuration/assign-pod-node.md @@ -219,7 +219,7 @@ be co-located in the same defined topology, eg., the same node. ##### Always co-located in the same node In a three node cluster, a web application has in-memory cache such as redis. We want the web-servers to be co-located with the cache as much as possible. -Here is the yaml snippet of a simple redis deployment with three replicas and selector label `app=store` +Here is the yaml snippet of a simple redis deployment with three replicas and selector label `app=store`. The deployment has `PodAntiAffinity` configured to ensure the scheduler does not co-locate replicas on a single node. ```yaml apiVersion: apps/v1beta1 # for versions before 1.6.0 use extensions/v1beta1 @@ -233,13 +233,22 @@ spec: labels: app: store spec: + affinity: + podAntiAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + - labelSelector: + matchExpressions: + - key: app + operator: In + values: + - store + topologyKey: "kubernetes.io/hostname" containers: - name: redis-server image: redis:3.2-alpine ``` -Below yaml snippet of the webserver deployment has `podAffinity` configured, this informs the scheduler that all its replicas are to be -co-located with pods that has selector label `app=store` +The below yaml snippet of the webserver deployment has `podAntiAffinity` and `podAffinity` configured. This informs the scheduler that all its replicas are to be co-located with pods that have selector label `app=store`. This will also ensure that each web-server replica does not co-locate on a single node. ```yaml apiVersion: apps/v1beta1 # for versions before 1.6.0 use extensions/v1beta1 @@ -254,6 +263,15 @@ spec: app: web-store spec: affinity: + podAntiAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + - labelSelector: + matchExpressions: + - key: app + operator: In + values: + - web-store + topologyKey: "kubernetes.io/hostname" podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: @@ -265,9 +283,10 @@ spec: topologyKey: "kubernetes.io/hostname" containers: - name: web-app + image: nginx:1.12-alpine ``` -if we create the above two deployments, our three node cluster could look like below. +If we create the above two deployments, our three node cluster should look like below. | node-1 | node-2 | node-3 | |:--------------------:|:-------------------:|:------------------:| @@ -287,7 +306,7 @@ web-server-1287567482-6f7v5 1/1 Running 0 7m 10.192.4 web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3.2 kube-node-2 ``` -Best practice is to configure these highly available stateful workloads such as redis with AntiAffinity rules for more guaranteed spreading, which we will see in the next section. +Best practice is to configure these highly available stateful workloads such as redis with AntiAffinity rules for more guaranteed spreading. ##### Never co-located in the same node