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
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Address final review comments
dhilipkumars committed Aug 4, 2017
commit 752509038ffe91aa961e18bcd95d82bdb7346b7e
2 changes: 1 addition & 1 deletion docs/concepts/configuration/assign-pod-node.md
Original file line number Diff line number Diff line change
@@ -283,7 +283,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
```

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.

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.
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.

##### Never co-located in the same node