Update docs to reflect affinity, taints, tolerations moving from alpha annotations to (beta) fields. #2905
Conversation
k8s-ci-robot
added
the
cncf-cla: yes
|
ref/ #2737 |
docs/admin/daemons.md
Outdated
| @@ -91,6 +88,14 @@ 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), but they are | |||
There was a problem hiding this comment.
How about use /docs/user-guide/node-selection/index.md#taints-and-tolerations-beta-feature
docs/admin/daemons.md
Outdated
| @@ -91,6 +88,14 @@ 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), but they are | |||
There was a problem hiding this comment.
Some places using Daemon pods while some places using DaemonSet pods, shall we unify the name?
There was a problem hiding this comment.
Changed the one instance of "daemonset pods" to "daemon pods"
docs/admin/daemons.md
Outdated
| @@ -91,6 +88,14 @@ 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), but they are | |||
| created with tolerations for the `node.alpha.kubernetes.io/notReady` and `node.alpha.kubernetes.io/unreachable` | |||
There was a problem hiding this comment.
How about
created with NoExecute tolerations for node.alpha.kubernetes.io/unreachable and node.alpha.kubernetes.io/notReady with no tolerationSeconds.
| 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"}]` |
There was a problem hiding this comment.
Updating here maybe more readable
PodSpec's tolerations field set to [{"key":"CriticalAddonsOnly", "operator":"Exists"}]
There was a problem hiding this comment.
I don't understand -- how is what you suggested different from what I did?
There was a problem hiding this comment.
The only difference is that modifying here can enable using short sentence and sequence based items which maybe more readable?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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-podset to empty string- PodSpec's
tolerationsfield set to[{"key":"CriticalAddonsOnly", "operator":"Exists"}]
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
got it, fair enough, thanks @davidopp
annotations to (beta) fields.
|
/lgtm, thanks @davidopp |
This change is