Merge pull request #2905 from davidopp/release-1.6

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

docs/admin/daemons.md

@@ -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
 
@@ -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:
 

docs/admin/kube-scheduler.md

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

docs/concepts/cluster-administration/guaranteed-scheduling-critical-addon-pods.md

@@ -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"}]`
+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.