Merged master into release-1.10 and resolved merge conflicts.

docs/concepts/api-extension/custom-resources.md

@@ -159,7 +159,7 @@ Aggregated APIs offer more advanced API features and customization of other feat
 | Multi-versioning | Allows serving the same object through two API versions. Can help ease API changes like renaming fields. Less important if you control your client versions. | No | Yes |
 | Custom Storage | If you need storage with a different performance mode (for example, time-series database instead of key-value store) or isolation for security (for example, encryption secrets or different | No | Yes |
 | Custom Business Logic | Perform arbitrary checks or actions when creating, reading, updating or deleting an object | No, but can get some of the same effects with Initializers or Finalizers (requires programming) | Yes |
-| Subresources | {::nomarkdown}<ul><li>Add extra operations other than CRUD, such as "scale" or "exec"</li><li>Allows systems like like HorizontalPodAutoscaler and PodDisruptionBudget interact with your new resource</li><li>Finer-grained access control: user writes spec section, controller writes status section.</li><li>Allows incrementing object Generation on custom resource data mutation (requires separate spec and status sections in the resource)</li></ul>{:/} | `status` and `scale` subresources are supported | Yes, any Subresource |
+| Subresources | {::nomarkdown}<ul><li>Add extra operations other than CRUD, such as "scale" or "exec"</li><li>Allows systems like HorizontalPodAutoscaler and PodDisruptionBudget interact with your new resource</li><li>Finer-grained access control: user writes spec section, controller writes status section.</li><li>Allows incrementing object Generation on custom resource data mutation (requires separate spec and status sections in the resource)</li></ul>{:/} | No but planned | Yes, any Subresource |
 | strategic-merge-patch | The new endpoints support PATCH with `Content-Type: application/strategic-merge-patch+json`. Useful for updating objects that may be modified both locally, and by the server. For more information, see ["Update API Objects in Place Using kubectl patch"](/docs/tasks/run-application/update-api-object-kubectl-patch/) | No | Yes |
 | Protocol Buffers | The new resource supports clients that want to use Protocol Buffers | No | Yes |
 | OpenAPI Schema | Is there an OpenAPI (swagger) schema for the types that can be dynamically fetched from the server? Is the user protected from misspelling field names by ensuring only allowed fields are set? Are types enforced (in other words, don't put an `int` in a `string` field?) | No but planned | Yes |

docs/concepts/cluster-administration/sysctl-cluster.md

@@ -130,10 +130,13 @@ to schedule those pods onto the right nodes.
 
 ## PodSecurityPolicy Annotations
 
-The use of sysctl in pods can be controlled via annotations on the PodSecurityPolicy.
+The use of sysctl in pods can be controlled via annotation on the PodSecurityPolicy.
 
-Here is an example, it authorizes binding user creating pod with corresponding
-_safe_ and _unsafe_ sysctls.
+Sysctl annotation represents a whitelist of allowed safe and unsafe sysctls
+in a pod spec. It's a comma-separated list of plain sysctl names or sysctl patterns
+(which end in `*`). The string `*` matches all sysctls.
+
+Here is an example, it authorizes binding user creating pod with corresponding sysctls.
 
 ```yaml
 apiVersion: extensions/v1beta1
@@ -141,8 +144,7 @@ kind: PodSecurityPolicy
 metadata:
   name: sysctl-psp
   annotations:
-    security.alpha.kubernetes.io/sysctls: 'kernel.shm_rmid_forced'
-    security.alpha.kubernetes.io/unsafe-sysctls: 'net.ipv4.route.*,kernel.msg*'
+    security.alpha.kubernetes.io/sysctls: 'net.ipv4.route.*,kernel.msg*'
 spec:
  ...
 ```

docs/concepts/configuration/pod-priority-preemption.md

@@ -220,10 +220,11 @@ can be scheduled on N. P might become feasible on N only if a Pod on another
 Node is preempted. Here's an example:
 
 * Pod P is being considered for Node N.
-* Pod Q is running on another Node in the same zone as Node N.
-* Pod P has anti-affinity with Pod Q.
-* There are no other cases of anti-affinity between Pod P and other Pods in the zone.
-* In order to schedule Pod P on Node N, Pod Q should be preempted, but scheduler
+* Pod Q is running on another Node in the same Zone as Node N.
+* Pod P has Zone-wide anti-affinity with Pod Q
+(`topologyKey: failure-domain.beta.kubernetes.io/zone`).
+* There are no other cases of anti-affinity between Pod P and other Pods in the Zone.
+* In order to schedule Pod P on Node N, Pod Q can be preempted, but scheduler
 does not perform cross-node preemption. So, Pod P will be deemed unschedulable
 on Node N.
 

docs/concepts/overview/kubernetes-api.md

@@ -24,7 +24,7 @@ What constitutes a compatible change and how to change the API are detailed by t
 
 ## OpenAPI and Swagger definitions
 
-Complete API details are documented using [Swagger v1.2](http://swagger.io/) and [OpenAPI](https://www.openapis.org/). The Kubernetes apiserver (aka "master") exposes an API that can be used to retrieve the Swagger v1.2 Kubernetes API spec located at `/swaggerapi`. You can also enable a UI to browse the API documentation at `/swagger-ui` by passing the `--enable-swagger-ui=true` flag to apiserver.
+Complete API details are documented using [Swagger v1.2](http://swagger.io/) and [OpenAPI](https://www.openapis.org/). The Kubernetes apiserver (aka "master") exposes an API that can be used to retrieve the Swagger v1.2 Kubernetes API spec located at `/swaggerapi`.
 
 Starting with Kubernetes 1.4, OpenAPI spec is also available at [`/swagger.json`](https://git.k8s.io/kubernetes/api/openapi-spec/swagger.json). While we are transitioning from Swagger v1.2 to OpenAPI (aka Swagger v2.0), some of the tools such as kubectl and swagger-ui are still using v1.2 spec. OpenAPI spec is in Beta as of Kubernetes 1.5.
 

docs/concepts/services-networking/ingress.md

@@ -60,7 +60,7 @@ kind: Ingress
 metadata:
   name: test-ingress
   annotations:
-    ingress.kubernetes.io/rewrite-target: /
+    nginx.ingress.kubernetes.io/rewrite-target: /
 spec:
   rules:
   - http:

docs/concepts/storage/volumes.md

@@ -70,6 +70,7 @@ Kubernetes supports several types of Volumes:
    * `azureFile`
    * `cephfs`
    * `configMap`
+   * `csi`
    * `downwardAPI`
    * `emptyDir`
    * `fc` (fibre channel)