Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add examples for interpod configurations #4557

Merged
merged 5 commits into from
Aug 4, 2017

Conversation

dhilipkumars
Copy link
Contributor

@dhilipkumars dhilipkumars commented Aug 1, 2017

Add some illustrations for interpod affinity and anti affinity, also link it back with zookeeper example.

as per the conclusion of this issue it was reccomended to add more documentation in this section.

Allow edits from maintainers checkbox


This change is Reviewable

@k8s-ci-robot k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Aug 1, 2017
@chenopis chenopis self-assigned this Aug 1, 2017
@chenopis chenopis requested a review from bsalamat August 1, 2017 08:51
Copy link
Member

@bsalamat bsalamat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, @dhilipkumars. I have a couple minor suggestions.

@@ -206,6 +206,31 @@ If defined but empty, it means "all namespaces."
All `matchExpressions` associated with `requiredDuringSchedulingIgnoredDuringExecution` affinity and anti-affinity
must be satisfied for the pod to schedule onto a node.

#### More Practical Usage

Than directly using with pods Interpod Affinity and AnitAffinity will be more useful when they are used with higher
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would write this as:
Interpod Affinity and AntiAffinity can be even more useful when used with higher level collections such as ReplicaSets, StatefulSets, Deployments, etc.

#### More Practical Usage

Than directly using with pods Interpod Affinity and AnitAffinity will be more useful when they are used with higher
level objects such as Statefulset, Deployments, etc. One can easily configure and prefer if two workloads should
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One can easily configure that a set of workloads should be co-located in the same defined topology, e.g., the same node.

|:--------------------:|:-------------------:|:------------------:|:------------------:|
| *DB-MASTER* | *DB-REPLICA-1* | *DB-REPLICA-2* | *DB-REPLICA-3* |

[Here](https://kubernetes.io/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure) is an example of zookeper statefulset configued with anti-affinity for high availablity.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/configued/configured

@dhilipkumars
Copy link
Contributor Author

@bsalamat Thanks for taking a look, updated the PR with corrections PTAL,

Have also re-based it.

Copy link
Member

@bsalamat bsalamat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for addressing the comments.

#### More Practical Usage

Interpod Affinity and AnitAffinity can be even more useful when they are used with higher
level collections such as ReplicaSets, Statefulset, Deployments, etc. One can easily configure that a set of workloads should
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/Statefulset/StatefulSets


Interpod Affinity and AnitAffinity can be even more useful when they are used with higher
level collections such as ReplicaSets, Statefulset, Deployments, etc. One can easily configure that a set of workloads should
be co-located in the same defined topology, eg., the same node.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/eg./e.g.

|:--------------------:|:-------------------:|:------------------:|
| *webserver-1* | *webserver-2* | *webserver-3* |
| *cache-1* | *cache-2* | *cache-3* |

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking that it would be more helpful if we provided examples of ReplicaSet configurations for the web server and and the cache here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, i think we want our users to use things like deployments and statefulsets directly instead of replicasets. What do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure. StatefulSets or Deployments are totally fine. The affinity/anti-affinity rules are the same for all of them and that's the important piece of the config in this example. I have no particular preference about type of the collection.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for response, I'll update later today.

@@ -206,6 +206,31 @@ If defined but empty, it means "all namespaces."
All `matchExpressions` associated with `requiredDuringSchedulingIgnoredDuringExecution` affinity and anti-affinity
must be satisfied for the pod to schedule onto a node.

#### More Practical Usage
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/Usage/Use-cases

@dhilipkumars
Copy link
Contributor Author

@bsalamat PTAL.

Copy link
Member

@bsalamat bsalamat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! One more suggestion for the example.

labels:
app: web-store
spec:
affinity:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we go with the example of 3 web servers and 3 redis caches, the web-server will need anti-affinity to web-store to make sure multiple pods of this replicaset are not scheduled on the same node.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO, we may not need anit-affinity for web-store (even in production) as default selector-spread in the schedule might anyways spread the workloads across the eligible nodes also we may need more web-store than the number of available nodes based on the traffic? Please let me know if you think it would still make sense to add it. (Plus we are re-directing the reader to zookeeper with anti-affinity example?)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Running multiple web-servers on a single machine rarely makes sense, especially if the intent is to handle traffic load. Well known web servers are multi-threaded and a single process can use multiple CPU cores on a machine. Besides, there is a potential of having port conflicts if you run multiple web server to serve one service point.
Scheduler tries to spread pods, but users shouldn't assume that pods of a single collection will never land on a single machine without proper anti-affinity rules.

All that said, I agree with you that for the sake of this example which is co-location we may want to keep the config simple. How about this:

  1. Change the number of instances of redis and web servers to 3 instances, which is the same as the number of nodes.
  2. Keep the rest of the config the same as it is now.
  3. Add a note at the bottom of the example to point out that if spreading of web-servers or redis instances is desired, proper anti-affinity rules should be added and refer to the next example for anti-affinity.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done PTAL,
what i was trying to say is stateless web-servers can coexist in the same node if there is enough room in it without hurting each other, they don't have to specifically prefer (using antiAffinity) not to be placed next to each other, on the other hand stateful workloads such as DB, KV Store , caches should mention antiAffinity explicitly as they need to be highly available.

metadata:
labels:
app: store
spec:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The spec needs an anti-affinity to 'store' to ensure that the pods are not scheduled on a single node.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm, i considered this also but we were trying to emphasis podAffinity in this example we are separately linking the user to a zookeeper example for podAnitAffinity, i was thinking we should keep this example simple and clear. We may very well add a sentence saying the best practice would be to add anti-affinity for app=store workload. What do you think?

metadata:
name: redis-cache
spec:
replicas: 2
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be a better example if we created the same number of cache instances as the web server instances. Given that this is a 3 node cluster, I would use 3 replicas for both web server and redis cache.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, i did that first. But when i tried with only 2 redis replicas and 4 web-store it appeared to me that affinity concept was better demonstrated as node-2 was ignored by the scheduler even though it had enough capacity. I felt it could make it easier for the reader to understand. What do you think?

@k8sio-netlify-preview-bot
Copy link
Collaborator

k8sio-netlify-preview-bot commented Aug 4, 2017

Deploy preview ready!

Built with commit 7525090

https://deploy-preview-4557--kubernetes-io-master-staging.netlify.com

web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3.2 kube-node-2
```

Best practise is to configure these highly available stateful workloads such as redis with antiAffinity rules for more guaranteed spread, which we will see in the next section.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/practise/practice
s/antiAffinity/AntiAffinity
s/more guaranteed spread/guaranteed spreading

@bsalamat
Copy link
Member

bsalamat commented Aug 4, 2017

Thanks, @dhilipkumars! Looks good. Just a minor comment.

@dhilipkumars
Copy link
Contributor Author

@bsalamat Thanks for your quick response, please take a look now.

@bsalamat
Copy link
Member

bsalamat commented Aug 4, 2017

Thanks! Please squash your commits.

/lgtm

@chenopis chenopis merged commit cdf4cc3 into kubernetes:master Aug 4, 2017
chenopis added a commit that referenced this pull request Aug 4, 2017
…hub.io into chenopis-vnext-staging-noindex

* 'master' of https://github.com/kubernetes/kubernetes.github.io:
  Add network overlay details to cloud routes flag
  Revert "Update volumes.md"
  add examples for interpod configurations (#4557)
  Update "readonly" in abac
  include _headers (#4636)
chenopis added a commit that referenced this pull request Aug 4, 2017
…hub.io into release-1.8

* 'master' of https://github.com/kubernetes/kubernetes.github.io:
  fix noindex for vnext-staging (#4640)
  Add network overlay details to cloud routes flag
  Revert "Update volumes.md"
  add examples for interpod configurations (#4557)
  Update "readonly" in abac
chenopis added a commit that referenced this pull request Aug 4, 2017
…hub.io into release-1.7

* 'master' of https://github.com/kubernetes/kubernetes.github.io:
  fix noindex for vnext-staging (#4640)
  Add network overlay details to cloud routes flag
  Revert "Update volumes.md"
  add examples for interpod configurations (#4557)
  Update "readonly" in abac
chenopis added a commit that referenced this pull request Aug 4, 2017
…hub.io into chenopis-user-journeys

* 'master' of https://github.com/kubernetes/kubernetes.github.io: (26 commits)
  fix noindex for vnext-staging (#4640)
  Add network overlay details to cloud routes flag
  Revert "Update volumes.md"
  add examples for interpod configurations (#4557)
  Update "readonly" in abac
  include _headers (#4636)
  Update callouts.css
  Update callouts.css
  fix command
  Add noindex to vnext-staging
  Add note for 1.8 release. (#4632)
  fix create-cluster-kubeadm docs
  Update aws.md
  add newline above kube-apiserver
  Update scheduling-gpus.md
  Fix spacing with shell commands
  Documenting another (potential) callout issue (#4604)
  Update reference docs with most recent version of brodocs (#4600)
  Update kubernetes-api.md
  fix spelling mistake
  ...
@dhilipkumars
Copy link
Contributor Author

@bsalamat Thanks for LGTM, @chenopis Thanks for squashing and merging the commits for me.

jesscodez pushed a commit that referenced this pull request Sep 22, 2017
* add examples for interpod configurations

* re-word and fix typo based on review comments

* explain podAffinity with examples

* review comments: make replicas 3 for both workload types

* Address final review comments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cncf-cla: yes Indicates the PR's author has signed the CNCF CLA.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants