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.

Sign up for GitHub

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

Jump to bottom

Update docs to reflect affinity, taints, tolerations moving from alpha annotations to (beta) fields. #2905

Merged
merged 1 commit into from
Mar 22, 2017
Merged

Update docs to reflect affinity, taints, tolerations moving from alpha annotations to (beta) fields. #2905

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
19 changes: 12 additions & 7 deletions docs/admin/daemons.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -74,12 +74,9 @@ a node for testing.

If you specify a `.spec.template.spec.nodeSelector`, then the DaemonSet controller will
create pods on nodes which match that [node
selector](/docs/user-guide/node-selection/).
If you specify a `scheduler.alpha.kubernetes.io/affinity` annotation in `.spec.template.metadata.annotations`,
then DaemonSet controller will create pods on nodes which match that [node affinity](../../user-guide/node-selection/#alpha-feature-in-kubernetes-v12-node-affinity).

If you do not specify a `.spec.template.spec.nodeSelector` nor `node affinity`, then the DaemonSet controller will
create pods on all nodes.
selector](/docs/user-guide/node-selection/). Likewise if you specify a `.spec.template.spec.affinity`
then DaemonSet controller will create pods on nodes which match that [node affinity](../../user-guide/node-selection/index.md).
If you do not specify either, then the DaemonSet controller will create pods on all nodes.

## How Daemon Pods are Scheduled

Expand All @@ -91,8 +88,16 @@ when the pod is created, so it is ignored by the scheduler). Therefore:
by the DaemonSet controller.
- DaemonSet controller can make pods even when the scheduler has not been started, which can help cluster
bootstrap.

Daemon pods do respect [taints and tolerations](/docs/user-guide/node-selection/index.md#taints-and-tolerations-beta-feature), but they are
created with `NoExecute` tolerations for the `node.alpha.kubernetes.io/notReady` and `node.alpha.kubernetes.io/unreachable`
taints with no `tolerationSeconds`. This ensures that when the `TaintBasedEvictions` alpha feature is enabled,
they will not be evicted when there are node problems such as a network partition. (When the
`TaintBasedEvictions` feature is not enabled, they are also not evicted in these scenarios, but
due to hard-coded behavior of the NodeController rather than due to tolerations).


## Communicating with DaemonSet Pods
## Communicating with Daemon Pods

Some possible patterns for communicating with pods in a DaemonSet are:

Expand Down
2 changes: 1 addition & 1 deletion docs/admin/kube-scheduler.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -49,7 +49,7 @@ StreamingProxyRedirects=true|false (ALPHA - default=false)
--policy-config-file string File with scheduler policy configuration
--port int32 The port that the scheduler's http service runs on (default 10251)
--profiling Enable profiling via web interface host:port/debug/pprof/ (default true)
--scheduler-name string Name of the scheduler, used to select which pods will be processed by this scheduler, based on pod's annotation with key 'scheduler.alpha.kubernetes.io/name' (default "default-scheduler")
--scheduler-name string Name of the scheduler, used to select which pods will be processed by this scheduler, based on PodSpec's schedulerName field (default "default-scheduler")
```

###### Auto generated by spf13/cobra on 13-Dec-2016
Expand Down
8 changes: 3 additions & 5 deletions docs/concepts/cluster-administration/guaranteed-scheduling-critical-addon-pods.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -48,10 +48,8 @@ It's enabled by default. It can be disabled:

### Marking add-on as critical

To be critical an add-on has to run in `kube-system` namespace (configurable via flag)
and have the following annotations specified:

* `scheduler.alpha.kubernetes.io/critical-pod` set to empty string
* `scheduler.alpha.kubernetes.io/tolerations` set to `[{"key":"CriticalAddonsOnly", "operator":"Exists"}]`
Copy link
Contributor

Choose a reason for hiding this comment

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

Updating here maybe more readable

PodSpec's tolerations field set to [{"key":"CriticalAddonsOnly", "operator":"Exists"}]

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't understand -- how is what you suggested different from what I did?

Copy link
Contributor

Choose a reason for hiding this comment

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

The only difference is that modifying here can enable using short sentence and sequence based items which maybe more readable?

Copy link
Member Author

Choose a reason for hiding this comment

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

Sorry, I still don't understand. Can you write down what text I currently have, and what text you are suggesting to replace it with?

Copy link
Contributor

@gyliu513 gyliu513 Mar 18, 2017 •
edited
Loading

Choose a reason for hiding this comment

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

Sorry for the confusion, how about as following?

To be critical an add-on has to run in kube-system namespace (configurable via flag)
and have the following annotation and PodSpec field specified:

  • scheduler.alpha.kubernetes.io/critical-pod set to empty string
  • PodSpec's tolerations field set to [{"key":"CriticalAddonsOnly", "operator":"Exists"}]

Copy link
Member Author

Choose a reason for hiding this comment

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

I think the current wording is a bit clearer in distinguishing annotation vs. field. They are very similar but I think for someone who is not familiar with the concepts, the version I wrote is more explicit and thus less likely to cause confusion.

Copy link
Contributor

Choose a reason for hiding this comment

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

got it, fair enough, thanks @davidopp

To be critical an add-on has to run in `kube-system` namespace (configurable via flag) and
* have the `scheduler.alpha.kubernetes.io/critical-pod` annotation set to empty string, and
* have the PodSpec's `tolerations` field set to `[{"key":"CriticalAddonsOnly", "operator":"Exists"}]`

The first one marks a pod a critical. The second one is required by Rescheduler algorithm.