Merge branch 'master' into release-1.8

docs/admin/authentication.md

@@ -43,7 +43,7 @@ with the request:
 
 * Username: a string which identifies the end user. Common values might be `kube-admin` or `jane@example.com`.
 * UID: a string which identifies the end user and attempts to be more consistent and unique than username.
-* Groups: a set of strings which associate users with as set of commonly grouped users.
+* Groups: a set of strings which associate users with a set of commonly grouped users.
 * Extra fields: a map of strings to list of strings which holds additional information authorizers may find useful.
 
 All values are opaque to the authentication system and only hold significance

docs/admin/kubeadm.md

@@ -79,7 +79,7 @@ cluster.  This is also the address used to construct the suggested `kubeadm
 join` line at the end of the init process.  If not set (or set to 0.0.0.0) then
 IP for the default interface will be used.
 
-This address is also added to the certifcate that the API Server uses.
+This address is also added to the certificate that the API Server uses.
 
 - `--apiserver-bind-port`
 

docs/admin/multiple-zones.md

@@ -73,6 +73,18 @@ available and can tolerate the loss of a zone, the control plane is
 located in a single zone.  Users that want a highly available control
 plane should follow the [high availability](/docs/admin/high-availability) instructions.
 
+* StatefulSet volume zone spreading when using dynamic provisioning is currently not compatible with
+pod affinity or anti-affinity policies.
+
+* If the name of the StatefulSet contains dashes ("-"), volume zone spreading
+may not provide a uniform distribution of storage across zones.
+
+* When specifying multiple PVCs in a Deployment or Pod spec, the StorageClass
+needs to be configured for a specific, single zone, or the PVs need to be
+statically provisioned in a specific zone. Another workaround is to use a
+StatefulSet, which will ensure that all the volumes for a replica are
+provisioned in the same zone.
+
 
 ## Walkthrough