diff --git a/docs/admin/authentication.md b/docs/admin/authentication.md
index 37903ee844..38341dc35b 100644
--- a/docs/admin/authentication.md
+++ b/docs/admin/authentication.md
@@ -151,8 +151,8 @@ authentication is currently supported for convenience while we finish making the
 more secure modes described above easier to use.
 
 The basic auth file is a csv file with a minimum of 3 columns: password, user name, user id.
-In Kubernetes version 1.6 and later, you can specify an optional fourth column containing 
-comma-separated group names. If you have more than one group, you must enclose the fourth 
+In Kubernetes version 1.6 and later, you can specify an optional fourth column containing
+comma-separated group names. If you have more than one group, you must enclose the fourth
 column value in double quotes ("). See the following example:
 
 ```conf
@@ -181,7 +181,7 @@ talk to the API server. Accounts may be explicitly associated with pods using th
 NOTE: `serviceAccountName` is usually omitted because this is done automatically.
 
 ```
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: nginx-deployment
@@ -568,13 +568,13 @@ For example, on a server with token authentication configured, and anonymous acc
 a request providing an invalid bearer token would receive a `401 Unauthorized` error.
 A request providing no bearer token would be treated as an anonymous request.
 
-In 1.5.1-1.5.x, anonymous access is disabled by default, and can be enabled by 
+In 1.5.1-1.5.x, anonymous access is disabled by default, and can be enabled by
 passing the `--anonymous-auth=false` option to the API server.
 
 In 1.6+, anonymous access is enabled by default if an authorization mode other than `AlwaysAllow`
 is used, and can be disabled by passing the `--anonymous-auth=false` option to the API server.
-Starting in 1.6, the ABAC and RBAC authorizers require explicit authorization of the 
-`system:anonymous` user or the `system:unauthenticated` group, so legacy policy rules 
+Starting in 1.6, the ABAC and RBAC authorizers require explicit authorization of the
+`system:anonymous` user or the `system:unauthenticated` group, so legacy policy rules
 that grant access to the `*` user or `*` group do not include anonymous users.
 
 ## Plugin Development
diff --git a/docs/admin/multiple-schedulers/my-scheduler.yaml b/docs/admin/multiple-schedulers/my-scheduler.yaml
index 5e97f46434..dde31f119a 100644
--- a/docs/admin/multiple-schedulers/my-scheduler.yaml
+++ b/docs/admin/multiple-schedulers/my-scheduler.yaml
@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   labels:
@@ -10,7 +10,7 @@ spec:
   replicas: 1
   template:
     metadata:
-      labels: 
+      labels:
         component: scheduler
         tier: control-plane
         version: second
diff --git a/docs/concepts/abstractions/nginx-deployment.yaml b/docs/concepts/abstractions/nginx-deployment.yaml
index 7a0dd431ef..2aabf5e7b1 100644
--- a/docs/concepts/abstractions/nginx-deployment.yaml
+++ b/docs/concepts/abstractions/nginx-deployment.yaml
@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: nginx-deployment
diff --git a/docs/concepts/cluster-administration/manage-deployment.md b/docs/concepts/cluster-administration/manage-deployment.md
index aef8bbfaf8..3595a4b337 100644
--- a/docs/concepts/cluster-administration/manage-deployment.md
+++ b/docs/concepts/cluster-administration/manage-deployment.md
@@ -85,8 +85,8 @@ NAME           CLUSTER-IP   EXTERNAL-IP   PORT(S)      AGE
 my-nginx-svc   10.0.0.208                 80/TCP       0s
 ```
 
-With the above commands, we first create resources under docs/user-guide/nginx/ and print the resources created with `-o name` output format 
-(print each resource as resource/name). Then we `grep` only the "service", and then print it with `kubectl get`. 
+With the above commands, we first create resources under docs/user-guide/nginx/ and print the resources created with `-o name` output format
+(print each resource as resource/name). Then we `grep` only the "service", and then print it with `kubectl get`.
 
 If you happen to organize your resources across several subdirectories within a particular directory, you can recursively perform the operations on the subdirectories also, by specifying `--recursive` or `-R` alongside the `--filename,-f` flag.
 
@@ -102,7 +102,7 @@ project/k8s/development
     └── my-pvc.yaml
 ```
 
-By default, performing a bulk operation on `project/k8s/development` will stop at the first level of the directory, not processing any subdirectories. If we tried to create the resources in this directory using the following command, we'd encounter an error: 
+By default, performing a bulk operation on `project/k8s/development` will stop at the first level of the directory, not processing any subdirectories. If we tried to create the resources in this directory using the following command, we'd encounter an error:
 
 ```shell
 $ kubectl create -f project/k8s/development
@@ -131,7 +131,7 @@ deployment "my-deployment" created
 persistentvolumeclaim "my-pvc" created
 ```
 
-If you're interested in learning more about `kubectl`, go ahead and read [kubectl Overview](/docs/user-guide/kubectl-overview). 
+If you're interested in learning more about `kubectl`, go ahead and read [kubectl Overview](/docs/user-guide/kubectl-overview).
 
 ## Using labels effectively
 
@@ -185,9 +185,9 @@ guestbook-redis-slave-qgazl   1/1       Running   0          3m
 
 ## Canary deployments
 
-Another scenario where multiple labels are needed is to distinguish deployments of different releases or configurations of the same component. It is common practice to deploy a *canary* of a new application release (specified via image tag in the pod template) side by side with the previous release so that the new release can receive live production traffic before fully rolling it out. 
+Another scenario where multiple labels are needed is to distinguish deployments of different releases or configurations of the same component. It is common practice to deploy a *canary* of a new application release (specified via image tag in the pod template) side by side with the previous release so that the new release can receive live production traffic before fully rolling it out.
 
-For instance, you can use a `track` label to differentiate different releases. 
+For instance, you can use a `track` label to differentiate different releases.
 
 The primary, stable release would have a `track` label with value as `stable`:
 
@@ -227,13 +227,13 @@ The frontend service would span both sets of replicas by selecting the common su
 ```
 
 You can tweak the number of replicas of the stable and canary releases to determine the ratio of each release that will receive live production traffic (in this case, 3:1).
-Once you're confident, you can update the stable track to the new application release and remove the canary one. 
+Once you're confident, you can update the stable track to the new application release and remove the canary one.
 
 For a more concrete example, check the [tutorial of deploying Ghost](https://github.com/kelseyhightower/talks/tree/master/kubecon-eu-2016/demo#deploy-a-canary).
 
 ## Updating labels
 
-Sometimes existing pods and other resources need to be relabeled before creating new resources. This can be done with `kubectl label`. 
+Sometimes existing pods and other resources need to be relabeled before creating new resources. This can be done with `kubectl label`.
 For example, if you want to label all your nginx pods as frontend tier, simply run:
 
 ```shell
@@ -243,8 +243,8 @@ pod "my-nginx-2035384211-u2c7e" labeled
 pod "my-nginx-2035384211-u3t6x" labeled
 ```
 
-This first filters all pods with the label "app=nginx", and then labels them with the "tier=fe". 
-To see the pods you just labeled, run: 
+This first filters all pods with the label "app=nginx", and then labels them with the "tier=fe".
+To see the pods you just labeled, run:
 
 ```shell
 $ kubectl get pods -l app=nginx -L tier
@@ -284,7 +284,7 @@ $ kubectl scale deployment/my-nginx --replicas=1
 deployment "my-nginx" scaled
 ```
 
-Now you only have one pod managed by the deployment. 
+Now you only have one pod managed by the deployment.
 
 ```shell
 $ kubectl get pods -l app=nginx
@@ -294,25 +294,25 @@ my-nginx-2035384211-j5fhi   1/1       Running   0          30m
 
 To have the system automatically choose the number of nginx replicas as needed, ranging from 1 to 3, do:
 
-```shell 
+```shell
 $ kubectl autoscale deployment/my-nginx --min=1 --max=3
 deployment "my-nginx" autoscaled
 ```
 
-Now your nginx replicas will be scaled up and down as needed, automatically. 
+Now your nginx replicas will be scaled up and down as needed, automatically.
 
 For more information, please see [kubectl scale](/docs/user-guide/kubectl/kubectl_scale/), [kubectl autoscale](/docs/user-guide/kubectl/kubectl_autoscale/) and [horizontal pod autoscaler](/docs/user-guide/horizontal-pod-autoscaler/) document.
 
 
 ## In-place updates of resources
 
-Sometimes it's necessary to make narrow, non-disruptive updates to resources you've created. 
+Sometimes it's necessary to make narrow, non-disruptive updates to resources you've created.
 
 ### kubectl apply
 
 It is suggested to maintain a set of configuration files in source control (see [configuration as code](http://martinfowler.com/bliki/InfrastructureAsCode.html)),
 so that they can be maintained and versioned along with the code for the resources they configure.
-Then, you can use [`kubectl apply`](/docs/user-guide/kubectl/kubectl_apply/) to push your configuration changes to the cluster. 
+Then, you can use [`kubectl apply`](/docs/user-guide/kubectl/kubectl_apply/) to push your configuration changes to the cluster.
 
 This command will compare the version of the configuration that you're pushing with the previous version and apply the changes you've made, without overwriting any automated changes to properties you haven't specified.
 
@@ -357,13 +357,13 @@ For more information, please see [kubectl edit](/docs/user-guide/kubectl/kubectl
 Suppose you want to fix a typo of the container's image of a Deployment. One way to do that is with `kubectl patch`:
 
 ```shell
-# Suppose you have a Deployment with a container named "nginx" and its image "nignx" (typo), 
+# Suppose you have a Deployment with a container named "nginx" and its image "nignx" (typo),
 # use container name "nginx" as a key to update the image from "nignx" (typo) to "nginx"
 $ kubectl get deployment my-nginx -o yaml
 ```
 
 ```yaml
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 ...
 spec:
@@ -382,7 +382,7 @@ $ kubectl get pod my-nginx-1jgkf -o yaml
 ```
 
 ```yaml
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 ...
 spec:
@@ -414,8 +414,8 @@ deployment "my-nginx" replaced
 
 At some point, you'll eventually need to update your deployed application, typically by specifying a new image or image tag, as in the canary deployment scenario above. `kubectl` supports several update operations, each of which is applicable to different scenarios.
 
-We'll guide you through how to create and update applications with Deployments. If your deployed application is managed by Replication Controllers, 
-you should read [how to use `kubectl rolling-update`](/docs/tasks/run-application/rolling-update-replication-controller/) instead. 
+We'll guide you through how to create and update applications with Deployments. If your deployed application is managed by Replication Controllers,
+you should read [how to use `kubectl rolling-update`](/docs/tasks/run-application/rolling-update-replication-controller/) instead.
 
 Let's say you were running version 1.7.9 of nginx:
 
@@ -424,7 +424,7 @@ $ kubectl run my-nginx --image=nginx:1.7.9 --replicas=3
 deployment "my-nginx" created
 ```
 
-To update to version 1.9.1, simply change `.spec.template.spec.containers[0].image` from `nginx:1.7.9` to `nginx:1.9.1`, with the kubectl commands we learned above. 
+To update to version 1.9.1, simply change `.spec.template.spec.containers[0].image` from `nginx:1.7.9` to `nginx:1.9.1`, with the kubectl commands we learned above.
 
 ```shell
 $ kubectl edit deployment/my-nginx
diff --git a/docs/concepts/cluster-administration/nginx-app.yaml b/docs/concepts/cluster-administration/nginx-app.yaml
index 8ae449d806..bc7e095646 100644
--- a/docs/concepts/cluster-administration/nginx-app.yaml
+++ b/docs/concepts/cluster-administration/nginx-app.yaml
@@ -11,7 +11,7 @@ spec:
   selector:
     app: nginx
 ---
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: my-nginx
diff --git a/docs/concepts/overview/working-with-objects/nginx-deployment.yaml b/docs/concepts/overview/working-with-objects/nginx-deployment.yaml
index 7a0dd431ef..2aabf5e7b1 100644
--- a/docs/concepts/overview/working-with-objects/nginx-deployment.yaml
+++ b/docs/concepts/overview/working-with-objects/nginx-deployment.yaml
@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: nginx-deployment
diff --git a/docs/concepts/services-networking/curlpod.yaml b/docs/concepts/services-networking/curlpod.yaml
index a4bb99277b..0741a58e7f 100644
--- a/docs/concepts/services-networking/curlpod.yaml
+++ b/docs/concepts/services-networking/curlpod.yaml
@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: curl-deployment
diff --git a/docs/concepts/services-networking/nginx-secure-app.yaml b/docs/concepts/services-networking/nginx-secure-app.yaml
index f23f8a3585..9e4a16791e 100644
--- a/docs/concepts/services-networking/nginx-secure-app.yaml
+++ b/docs/concepts/services-networking/nginx-secure-app.yaml
@@ -17,7 +17,7 @@ spec:
   selector:
     run: my-nginx
 ---
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: my-nginx
diff --git a/docs/concepts/services-networking/run-my-nginx.yaml b/docs/concepts/services-networking/run-my-nginx.yaml
index 1c6fc84928..b3d8e336cd 100644
--- a/docs/concepts/services-networking/run-my-nginx.yaml
+++ b/docs/concepts/services-networking/run-my-nginx.yaml
@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: my-nginx
diff --git a/docs/getting-started-guides/meanstack.md b/docs/getting-started-guides/meanstack.md
index ca34d32753..b47ac1150a 100644
--- a/docs/getting-started-guides/meanstack.md
+++ b/docs/getting-started-guides/meanstack.md
@@ -198,7 +198,7 @@ Now, we need to create a Deployment that will run the database. I'm using a Depl
 ### `db-deployment.yml`
 
 ```yaml
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: mongo-deployment
@@ -317,7 +317,7 @@ Let's look at the Deployment configuration:
 ### `web-deployment.yml`
 
 ```yaml
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: web-deployment
@@ -371,7 +371,7 @@ At this point, the local directory looks like this
 ```shell
 $ ls
 
-Dockerfile 
+Dockerfile
 app
 db-deployment.yml
 db-service.yml
diff --git a/docs/tasks/administer-cluster/dns-horizontal-autoscaler.yaml b/docs/tasks/administer-cluster/dns-horizontal-autoscaler.yaml
index ce6a7c4b09..a919015f3c 100644
--- a/docs/tasks/administer-cluster/dns-horizontal-autoscaler.yaml
+++ b/docs/tasks/administer-cluster/dns-horizontal-autoscaler.yaml
@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: kube-dns-autoscaler
diff --git a/docs/tutorials/connecting-apps/frontend.yaml b/docs/tutorials/connecting-apps/frontend.yaml
index a084f75582..62ff60c0df 100644
--- a/docs/tutorials/connecting-apps/frontend.yaml
+++ b/docs/tutorials/connecting-apps/frontend.yaml
@@ -12,7 +12,7 @@ spec:
       targetPort: 80
   type: LoadBalancer
 ---
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: frontend
diff --git a/docs/tutorials/connecting-apps/hello.yaml b/docs/tutorials/connecting-apps/hello.yaml
index 97e3a79df1..61e4ea4a17 100644
--- a/docs/tutorials/connecting-apps/hello.yaml
+++ b/docs/tutorials/connecting-apps/hello.yaml
@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: hello
diff --git a/docs/tutorials/object-management-kubectl/declarative-object-management-configuration.md b/docs/tutorials/object-management-kubectl/declarative-object-management-configuration.md
index 02ab4e485b..f38b62656b 100644
--- a/docs/tutorials/object-management-kubectl/declarative-object-management-configuration.md
+++ b/docs/tutorials/object-management-kubectl/declarative-object-management-configuration.md
@@ -89,7 +89,7 @@ metadata:
     # This is the json representation of simple_deployment.yaml
     # It was written by kubectl apply when the object was created
     kubectl.kubernetes.io/last-applied-configuration: |
-      {"apiVersion":"extensions/v1beta1","kind":"Deployment",
+      {"apiVersion":"apps/v1beta1","kind":"Deployment",
       "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
       "spec":{"minReadySeconds":5,"template":{"metadata":{"labels":{"app":"nginx"}},
       "spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx",
@@ -160,7 +160,7 @@ metadata:
     # This is the json representation of simple_deployment.yaml
     # It was written by kubectl apply when the object was created
     kubectl.kubernetes.io/last-applied-configuration: |
-      {"apiVersion":"extensions/v1beta1","kind":"Deployment",
+      {"apiVersion":"apps/v1beta1","kind":"Deployment",
       "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
       "spec":{"minReadySeconds":5,"template":{"metadata":{"labels":{"app":"nginx"}},
       "spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx",
@@ -204,7 +204,7 @@ The output shows that the `replicas` field has been set to 2, and the `last-appl
 annotation does not contain a `replicas` field:
 
 ```
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   annotations:
@@ -212,7 +212,7 @@ metadata:
     # note that the annotation does not contain replicas
     # because it was not updated through apply
     kubectl.kubernetes.io/last-applied-configuration: |
-      {"apiVersion":"extensions/v1beta1","kind":"Deployment",
+      {"apiVersion":"apps/v1beta1","kind":"Deployment",
       "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
       "spec":{"minReadySeconds":5,"template":{"metadata":{"labels":{"app":"nginx"}},
       "spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx",
@@ -264,7 +264,7 @@ The output shows the following changes to the live configuration:
 - The `last-applied-configuration` annotation no longer contains the `minReadySeconds` field.
 
 ```shell
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   annotations:
@@ -272,7 +272,7 @@ metadata:
     # The annotation contains the updated image to nginx 1.11.9,
     # but does not contain the updated replicas to 2
     kubectl.kubernetes.io/last-applied-configuration: |
-      {"apiVersion":"extensions/v1beta1","kind":"Deployment",
+      {"apiVersion":"apps/v1beta1","kind":"Deployment",
       "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
       "spec":{"template":{"metadata":{"labels":{"app":"nginx"}},
       "spec":{"containers":[{"image":"nginx:1.11.9","name":"nginx",
@@ -395,7 +395,7 @@ Here's an example. Suppose this is the configuration file for a Deployment objec
 Also, suppose this is the live configuration for the same Deployment object:
 
 ```shell
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   annotations:
@@ -403,7 +403,7 @@ metadata:
     # note that the annotation does not contain replicas
     # because it was not updated through apply
     kubectl.kubernetes.io/last-applied-configuration: |
-      {"apiVersion":"extensions/v1beta1","kind":"Deployment",
+      {"apiVersion":"apps/v1beta1","kind":"Deployment",
       "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
       "spec":{"minReadySeconds":5,"template":{"metadata":{"labels":{"app":"nginx"}},
       "spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx",
@@ -446,7 +446,7 @@ Here are the merge calculations that would be performed by `kubectl apply`:
 Here is the live configuration that is the result of the merge:
 
 ```shell
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   annotations:
@@ -454,7 +454,7 @@ metadata:
     # The annotation contains the updated image to nginx 1.11.9,
     # but does not contain the updated replicas to 2
     kubectl.kubernetes.io/last-applied-configuration: |
-      {"apiVersion":"extensions/v1beta1","kind":"Deployment",
+      {"apiVersion":"apps/v1beta1","kind":"Deployment",
       "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
       "spec":{"template":{"metadata":{"labels":{"app":"nginx"}},
       "spec":{"containers":[{"image":"nginx:1.11.9","name":"nginx",
@@ -693,7 +693,7 @@ The output shows that the API server set several fields to default values in the
 configuration. These fields were not specified in the configuration file.
 
 ```shell
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 # ...
 spec:
diff --git a/docs/tutorials/object-management-kubectl/simple_deployment.yaml b/docs/tutorials/object-management-kubectl/simple_deployment.yaml
index 0348883c24..9ebff9e78e 100644
--- a/docs/tutorials/object-management-kubectl/simple_deployment.yaml
+++ b/docs/tutorials/object-management-kubectl/simple_deployment.yaml
@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: nginx-deployment
diff --git a/docs/tutorials/object-management-kubectl/update_deployment.yaml b/docs/tutorials/object-management-kubectl/update_deployment.yaml
index d2c2d82010..1e2c858ebd 100644
--- a/docs/tutorials/object-management-kubectl/update_deployment.yaml
+++ b/docs/tutorials/object-management-kubectl/update_deployment.yaml
@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: nginx-deployment
diff --git a/docs/tutorials/stateful-application/mysql-deployment.yaml b/docs/tutorials/stateful-application/mysql-deployment.yaml
index 3b2aa22f6c..8be6ae7b3d 100644
--- a/docs/tutorials/stateful-application/mysql-deployment.yaml
+++ b/docs/tutorials/stateful-application/mysql-deployment.yaml
@@ -20,7 +20,7 @@ spec:
     requests:
       storage: 20Gi
 ---
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: mysql
diff --git a/docs/tutorials/stateless-application/deployment-scale.yaml b/docs/tutorials/stateless-application/deployment-scale.yaml
index 7259c97603..01351c3b5a 100644
--- a/docs/tutorials/stateless-application/deployment-scale.yaml
+++ b/docs/tutorials/stateless-application/deployment-scale.yaml
@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: nginx-deployment
diff --git a/docs/tutorials/stateless-application/deployment-update.yaml b/docs/tutorials/stateless-application/deployment-update.yaml
index 6ed990be47..8f0ac0b48c 100644
--- a/docs/tutorials/stateless-application/deployment-update.yaml
+++ b/docs/tutorials/stateless-application/deployment-update.yaml
@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: nginx-deployment
diff --git a/docs/tutorials/stateless-application/deployment.yaml b/docs/tutorials/stateless-application/deployment.yaml
index aaa6f65a83..8d14e2ef08 100644
--- a/docs/tutorials/stateless-application/deployment.yaml
+++ b/docs/tutorials/stateless-application/deployment.yaml
@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: nginx-deployment
diff --git a/docs/user-guide/bad-nginx-deployment.yaml b/docs/user-guide/bad-nginx-deployment.yaml
index 70afeaf2ee..e93cf309b4 100644
--- a/docs/user-guide/bad-nginx-deployment.yaml
+++ b/docs/user-guide/bad-nginx-deployment.yaml
@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: nginx-deployment
diff --git a/docs/user-guide/curlpod.yaml b/docs/user-guide/curlpod.yaml
index a4bb99277b..0741a58e7f 100644
--- a/docs/user-guide/curlpod.yaml
+++ b/docs/user-guide/curlpod.yaml
@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: curl-deployment
diff --git a/docs/user-guide/debugging-services.md b/docs/user-guide/debugging-services.md
index 6a1a692e8a..408f1860b3 100644
--- a/docs/user-guide/debugging-services.md
+++ b/docs/user-guide/debugging-services.md
@@ -83,12 +83,12 @@ $ kubectl run hostnames --image=gcr.io/google_containers/serve_hostname \
 deployment "hostnames" created
 ```
 
-`kubectl` commands will print the type and name of the resource created or mutated, which can then be used in subsequent commands. 
+`kubectl` commands will print the type and name of the resource created or mutated, which can then be used in subsequent commands.
 Note that this is the same as if you had started the `Deployment` with
 the following YAML:
 
 ```yaml
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: hostnames
diff --git a/docs/user-guide/deployment.yaml b/docs/user-guide/deployment.yaml
index 98e614ceb2..8cdf1692ef 100644
--- a/docs/user-guide/deployment.yaml
+++ b/docs/user-guide/deployment.yaml
@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1 
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: nginx-deployment
diff --git a/docs/user-guide/deployments.md b/docs/user-guide/deployments.md
index 8a8cc0935b..6fbd347d25 100644
--- a/docs/user-guide/deployments.md
+++ b/docs/user-guide/deployments.md
@@ -19,9 +19,9 @@ by new ones.
 A typical use case is:
 
 * Create a Deployment to bring up a Replica Set and Pods.
-* Check the status of a Deployment to see if it succeeds or not. 
+* Check the status of a Deployment to see if it succeeds or not.
 * Later, update that Deployment to recreate the Pods (for example, to use a new image).
-* Rollback to an earlier Deployment revision if the current Deployment isn't stable. 
+* Rollback to an earlier Deployment revision if the current Deployment isn't stable.
 * Pause and resume a Deployment.
 
 ## Creating a Deployment
@@ -48,7 +48,7 @@ NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
 nginx-deployment   3         0         0            0           1s
 ```
 
-This indicates that the Deployment's number of desired replicas is 3 (according to deployment's `.spec.replicas`), the number of current replicas (`.status.replicas`) is 0, the number of up-to-date replicas (`.status.updatedReplicas`) is 0, and the number of available replicas (`.status.availableReplicas`) is also 0. 
+This indicates that the Deployment's number of desired replicas is 3 (according to deployment's `.spec.replicas`), the number of current replicas (`.status.replicas`) is 0, the number of up-to-date replicas (`.status.updatedReplicas`) is 0, and the number of available replicas (`.status.availableReplicas`) is also 0.
 
 Running the `get` again a few seconds later, should give:
 
@@ -63,10 +63,10 @@ This indicates that the Deployment has created all three replicas, and all repli
 ```shell
 $ kubectl get rs
 NAME                          DESIRED   CURRENT   READY   AGE
-nginx-deployment-2035384211   3         3         0       18s 
+nginx-deployment-2035384211   3         3         0       18s
 ```
 
-You may notice that the name of the Replica Set is always `<the name of the Deployment>-<hash value of the pod template>`. 
+You may notice that the name of the Replica Set is always `<the name of the Deployment>-<hash value of the pod template>`.
 
 ```shell
 $ kubectl get pods --show-labels
@@ -83,8 +83,8 @@ The created Replica Set will ensure that there are three nginx Pods at all times
 
 ## Updating a Deployment
 
-**Note:** a Deployment's rollout is triggered if and only if the Deployment's pod template (i.e. `.spec.template`) is changed, 
-e.g. updating labels or container images of the template. Other updates, such as scaling the Deployment, will not trigger a rollout. 
+**Note:** a Deployment's rollout is triggered if and only if the Deployment's pod template (i.e. `.spec.template`) is changed,
+e.g. updating labels or container images of the template. Other updates, such as scaling the Deployment, will not trigger a rollout.
 
 Suppose that we now want to update the nginx Pods to start using the `nginx:1.9.1` image
 instead of the `nginx:1.7.9` image.
@@ -117,9 +117,9 @@ NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
 nginx-deployment   3         3         3            3           36s
 ```
 
-The number of up-to-date replicas indicates that the Deployment has updated the replicas to the latest configuration. 
-The current replicas indicates the total replicas this Deployment manages, and the available replicas indicates the 
-number of current replicas that are available. 
+The number of up-to-date replicas indicates that the Deployment has updated the replicas to the latest configuration.
+The current replicas indicates the total replicas this Deployment manages, and the available replicas indicates the
+number of current replicas that are available.
 
 We can run `kubectl get rs` to see that the Deployment updated the Pods by creating a new Replica Set and scaling it up to 3 replicas, as well as scaling down the old Replica Set to 0 replicas.
 
@@ -143,10 +143,10 @@ nginx-deployment-1564180365-z9gth   1/1       Running   0          14s
 Next time we want to update these Pods, we only need to update the Deployment's pod template again.
 
 Deployment can ensure that only a certain number of Pods may be down while they are being updated. By
-default, it ensures that at least 1 less than the desired number of Pods are
-up (1 max unavailable).
+default, it ensures that at least 25% less than the desired number of Pods are
+up (25% max unavailable).
 
-Deployment can also ensure that only a certain number of Pods may be created above the desired number of Pods. By default, it ensures that at most 1 more than the desired number of Pods are up (1 max surge). 
+Deployment can also ensure that only a certain number of Pods may be created above the desired number of Pods. By default, it ensures that at most 25% more than the desired number of Pods are up (25% max surge).
 
 For example, if you look at the above Deployment closely, you will see that
 it first created a new Pod, then deleted some old Pods and created new ones. It
@@ -204,13 +204,13 @@ before changing course.
 ## Rolling Back a Deployment
 
 Sometimes you may want to rollback a Deployment; for example, when the Deployment is not stable, such as crash looping.
-By default, all of the Deployment's rollout history is kept in the system so that you can rollback anytime you want 
-(you can change that by specifying [revision history limit](/docs/user-guide/deployments/#revision-history-limit)). 
+By default, two previous Deployment's rollout history are kept in the system so that you can rollback anytime you want
+(you can change that by modifying [revision history limit](/docs/user-guide/deployments/#revision-history-limit)).
 
-**Note:** a Deployment's revision is created when a Deployment's rollout is triggered. This means that the new revision is created 
-if and only if the Deployment's pod template (i.e. `.spec.template`) is changed, e.g. updating labels or container images of the template. 
+**Note:** a Deployment's revision is created when a Deployment's rollout is triggered. This means that the new revision is created
+if and only if the Deployment's pod template (i.e. `.spec.template`) is changed, e.g. updating labels or container images of the template.
 Other updates, such as scaling the Deployment, will not create a Deployment revision -- so that we can facilitate simultaneous manual- or
-auto-scaling. This implies that when you rollback to an earlier revision, only the Deployment's pod template part will be rolled back.  
+auto-scaling. This implies that when you rollback to an earlier revision, only the Deployment's pod template part will be rolled back.
 
 Suppose that we made a typo while updating the Deployment, by putting the image name as `nginx:1.91` instead of `nginx:1.9.1`:
 
@@ -222,7 +222,7 @@ deployment "nginx-deployment" image updated
 The rollout will be stuck.
 
 ```shell
-$ kubectl rollout status deployments nginx-deployment 
+$ kubectl rollout status deployments nginx-deployment
 Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
 ```
 
@@ -241,7 +241,7 @@ nginx-deployment-3066724191   2         2         2       6s
 Looking at the Pods created, you will see that the 2 Pods created by new Replica Set are stuck in an image pull loop.
 
 ```shell
-$ kubectl get pods 
+$ kubectl get pods
 NAME                                READY     STATUS             RESTARTS   AGE
 nginx-deployment-1564180365-70iae   1/1       Running            0          25s
 nginx-deployment-1564180365-jbqqo   1/1       Running            0          25s
@@ -278,7 +278,7 @@ Events:
   13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-3066724191 to 2
 ```
 
-To fix this, we need to rollback to a previous revision of Deployment that is stable. 
+To fix this, we need to rollback to a previous revision of Deployment that is stable.
 
 ### Checking Rollout History of a Deployment
 
@@ -293,7 +293,7 @@ REVISION    CHANGE-CAUSE
 3           kubectl set image deployment/nginx-deployment nginx=nginx:1.91
 ```
 
-Because we recorded the command while creating this Deployment using `--record`, we can easily see the changes we made in each revision. 
+Because we recorded the command while creating this Deployment using `--record`, we can easily see the changes we made in each revision.
 
 To further see the details of each revision, run:
 
@@ -330,16 +330,16 @@ $ kubectl rollout undo deployment/nginx-deployment --to-revision=2
 deployment "nginx-deployment" rolled back
 ```
 
-For more details about rollout related commands, read [`kubectl rollout`](/docs/user-guide/kubectl/kubectl_rollout/). 
+For more details about rollout related commands, read [`kubectl rollout`](/docs/user-guide/kubectl/kubectl_rollout/).
 
-The Deployment is now rolled back to a previous stable revision. As you can see, a `DeploymentRollback` event for rolling back to revision 2 is generated from Deployment controller. 
+The Deployment is now rolled back to a previous stable revision. As you can see, a `DeploymentRollback` event for rolling back to revision 2 is generated from Deployment controller.
 
 ```shell
-$ kubectl get deployment 
+$ kubectl get deployment
 NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
 nginx-deployment   3         3         3            3           30m
 
-$ kubectl describe deployment 
+$ kubectl describe deployment
 Name:           nginx-deployment
 Namespace:      default
 CreationTimestamp:  Tue, 15 Mar 2016 14:48:04 -0700
@@ -369,8 +369,8 @@ Events:
 
 ### Clean up Policy
 
-You can set `.spec.revisionHistoryLimit` field to specify how much revision history of this deployment you want to keep. By default, 
-all revision history will be kept; explicitly setting this field to `0` disallows a deployment being rolled back. 
+You can set `.spec.revisionHistoryLimit` field to specify how much revision history of this deployment you want to keep. By default,
+all revision history will be kept; explicitly setting this field to `0` disallows a deployment being rolled back.
 
 ## Scaling a Deployment
 
@@ -441,9 +441,9 @@ nginx-deployment-1989198191   7         7         0         7m
 nginx-deployment-618515232    11        11        11        7m
 ```
 
-## Pausing and Resuming a Deployment 
+## Pausing and Resuming a Deployment
 
-You can also pause a Deployment mid-way and then resume it. A use case is to support canary deployment. 
+You can also pause a Deployment mid-way and then resume it. A use case is to support canary deployment.
 
 Update the Deployment again and then pause the Deployment with `kubectl rollout pause`:
 
@@ -453,12 +453,12 @@ deployment "nginx-deployment" image updated
 deployment "nginx-deployment" paused
 ```
 
-Note that any current state of the Deployment will continue its function, but new updates to the Deployment will not have an effect as long as the Deployment is paused. 
+Note that any current state of the Deployment will continue its function, but new updates to the Deployment will not have an effect as long as the Deployment is paused.
 
-The Deployment was still in progress when we paused it, so the actions of scaling up and down Replica Sets are paused too. 
+The Deployment was still in progress when we paused it, so the actions of scaling up and down Replica Sets are paused too.
 
 ```shell
-$ kubectl get rs 
+$ kubectl get rs
 NAME                          DESIRED   CURRENT   READY   AGE
 nginx-deployment-1564180365   2         2         2       1h
 nginx-deployment-2035384211   2         2         0       1h
@@ -468,7 +468,7 @@ nginx-deployment-3066724191   0         0         0       1h
 In a separate terminal, watch for rollout status changes and you'll see the rollout won't continue:
 
 ```shell
-$ kubectl rollout status deployment/nginx-deployment 
+$ kubectl rollout status deployment/nginx-deployment
 Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
 ```
 
@@ -482,7 +482,7 @@ deployment "nginx-deployment" resumed
 Then the Deployment will continue and finish the rollout:
 
 ```shell
-$ kubectl rollout status deployment/nginx-deployment 
+$ kubectl rollout status deployment/nginx-deployment
 Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
 Waiting for deployment spec update to be observed...
 Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
@@ -490,7 +490,7 @@ deployment nginx-deployment successfully rolled out
 ```
 
 ```shell
-$ kubectl get rs 
+$ kubectl get rs
 NAME                          DESIRED   CURRENT   READY   AGE
 nginx-deployment-1564180365   3         3         3       1h
 nginx-deployment-2035384211   0         0         0       1h
@@ -518,7 +518,7 @@ You can monitor the progress for a Deployment by using `kubectl rollout status`.
 
 ### Complete Deployment
 
-Kubernetes marks a Deployment as _complete_ when it has the following characteristics: 
+Kubernetes marks a Deployment as _complete_ when it has the following characteristics:
 
 * The Deployment has minimum availability. Minimum availability means that the Deployment's number of available replicas
 equals or exceeds the number required by the Deployment strategy.
@@ -659,12 +659,12 @@ $ echo $?
 All actions that apply to a complete Deployment also apply to a failed Deployment. You can scale it up/down, roll back
 to a previous revision, or even pause it if you need to apply multiple tweaks in the Deployment pod template.
 
-## Use Cases 
+## Use Cases
 
 ### Canary Deployment
 
 If you want to roll out releases to a subset of users or servers using the Deployment, you can create multiple Deployments, one for each release,
-following the canary pattern described in [managing resources](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments). 
+following the canary pattern described in [managing resources](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments).
 
 ## Writing a Deployment Spec
 
@@ -696,7 +696,7 @@ to 1.
 ### Selector
 
 `.spec.selector` is an optional field that specifies a [label selector](/docs/user-guide/labels/#label-selectors) for the Pods
-targeted by this deployment. 
+targeted by this deployment.
 
 If specified, `.spec.selector` must match `.spec.template.metadata.labels`, or it will
 be rejected by the API.  If `.spec.selector` is unspecified, `.spec.selector.matchLabels` will be defaulted to
@@ -774,32 +774,32 @@ If specified, this field needs to be greater than `.spec.minReadySeconds`.
 
 ### Min Ready Seconds
 
-`.spec.minReadySeconds` is an optional field that specifies the
+`.spec.minReadySeconds` is an optional field (with default value of 600s) that specifies the
 minimum number of seconds for which a newly created Pod should be ready
 without any of its containers crashing, for it to be considered available.
 This defaults to 0 (the Pod will be considered available as soon as it is ready).
 To learn more about when a Pod is considered ready, see [Container Probes](/docs/user-guide/pod-states/#container-probes).
 
-### Rollback To 
+### Rollback To
 
-`.spec.rollbackTo` is an optional field with the configuration the Deployment is rolling back to. Setting this field will trigger a rollback, and this field will be cleared every time a rollback is done. 
+`.spec.rollbackTo` is an optional field with the configuration the Deployment is rolling back to. Setting this field will trigger a rollback, and this field will be cleared every time a rollback is done.
 
 #### Revision
 
-`.spec.rollbackTo.revision` is an optional field specifying the revision to rollback to. This defaults to 0, meaning rollback to the last revision in history. 
+`.spec.rollbackTo.revision` is an optional field specifying the revision to rollback to. This defaults to 0, meaning rollback to the last revision in history.
 
 ### Revision History Limit
 
-A deployment's revision history is stored in the replica sets it controls. 
+A deployment's revision history is stored in the replica sets it controls.
 
-`.spec.revisionHistoryLimit` is an optional field that specifies the number of old Replica Sets to retain to allow rollback. Its ideal value depends on the frequency and stability of new deployments. All old Replica Sets will be kept by default, consuming resources in `etcd` and crowding the output of `kubectl get rs`, if this field is not set. The configuration of each Deployment revision is stored in its Replica Sets; therefore, once an old Replica Set is deleted, you lose the ability to rollback to that revision of Deployment. 
+`.spec.revisionHistoryLimit` is an optional field (with default value of two) that specifies the number of old Replica Sets to retain to allow rollback. Its ideal value depends on the frequency and stability of new deployments. All old Replica Sets will be kept by default, consuming resources in `etcd` and crowding the output of `kubectl get rs`, if this field is not set. The configuration of each Deployment revision is stored in its Replica Sets; therefore, once an old Replica Set is deleted, you lose the ability to rollback to that revision of Deployment.
 
-More specifically, setting this field to zero means that all old replica sets with 0 replica will be cleaned up. 
+More specifically, setting this field to zero means that all old replica sets with 0 replica will be cleaned up.
 In this case, a new deployment rollout cannot be undone, since its revision history is cleaned up.
 
 ### Paused
 
-`.spec.paused` is an optional boolean field for pausing and resuming a Deployment. It defaults to false (a Deployment is not paused). 
+`.spec.paused` is an optional boolean field for pausing and resuming a Deployment. It defaults to false (a Deployment is not paused).
 
 ## Alternative to Deployments
 
diff --git a/docs/user-guide/horizontal-pod-autoscaling/hpa-php-apache.yaml b/docs/user-guide/horizontal-pod-autoscaling/hpa-php-apache.yaml
index 7ccdcabafd..efe4bc149b 100644
--- a/docs/user-guide/horizontal-pod-autoscaling/hpa-php-apache.yaml
+++ b/docs/user-guide/horizontal-pod-autoscaling/hpa-php-apache.yaml
@@ -5,7 +5,7 @@ metadata:
   namespace: default
 spec:
   scaleTargetRef:
-    apiVersion: extensions/v1beta1
+    apiVersion: apps/v1beta1
     kind: Deployment
     name: php-apache
   minReplicas: 1
diff --git a/docs/user-guide/horizontal-pod-autoscaling/walkthrough.md b/docs/user-guide/horizontal-pod-autoscaling/walkthrough.md
index 1532c47a76..bfedfde954 100644
--- a/docs/user-guide/horizontal-pod-autoscaling/walkthrough.md
+++ b/docs/user-guide/horizontal-pod-autoscaling/walkthrough.md
@@ -147,7 +147,7 @@ metadata:
   namespace: default
 spec:
   scaleTargetRef:
-    apiVersion: extensions/v1beta1
+    apiVersion: apps/v1beta1
     kind: Deployment
     name: php-apache
   minReplicas: 1
@@ -227,7 +227,7 @@ metadata:
   namespace: default
 spec:
   scaleTargetRef:
-    apiVersion: extensions/v1beta1
+    apiVersion: apps/v1beta1
     kind: Deployment
     name: php-apache
   minReplicas: 1
@@ -280,7 +280,7 @@ metadata:
   namespace: default
 spec:
   scaleTargetRef:
-    apiVersion: extensions/v1beta1
+    apiVersion: apps/v1beta1
     kind: Deployment
     name: php-apache
   minReplicas: 1
diff --git a/docs/user-guide/introspection-and-debugging.md b/docs/user-guide/introspection-and-debugging.md
index 26f09e41c7..c0c45cf7e8 100644
--- a/docs/user-guide/introspection-and-debugging.md
+++ b/docs/user-guide/introspection-and-debugging.md
@@ -17,7 +17,7 @@ your pods. But there are a number of ways to get even more information about you
 For this example we'll use a Deployment to create two pods, similar to the earlier example.
 
 ```yaml
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: nginx-deployment
@@ -87,7 +87,7 @@ Containers:
     Environment Variables:
 Conditions:
   Type        Status
-  Ready     True 
+  Ready     True
 Volumes:
   default-token-4bcbi:
     Type:    Secret (a volume populated by a Secret)
@@ -137,7 +137,7 @@ $ kubectl describe pod nginx-deployment-1370807587-fz9sd
   Node:        /
   Labels:        app=nginx,pod-template-hash=1370807587
   Status:        Pending
-  IP:        
+  IP:
   Controllers:    ReplicaSet/nginx-deployment-1370807587
   Containers:
     nginx:
@@ -275,7 +275,7 @@ Labels:            kubernetes.io/hostname=kubernetes-node-861h
 CreationTimestamp:    Fri, 10 Jul 2015 14:32:29 -0700
 Conditions:
   Type        Status        LastHeartbeatTime            LastTransitionTime            Reason                    Message
-  Ready     Unknown     Fri, 10 Jul 2015 14:34:32 -0700     Fri, 10 Jul 2015 14:35:15 -0700     Kubelet stopped posting node status.     
+  Ready     Unknown     Fri, 10 Jul 2015 14:34:32 -0700     Fri, 10 Jul 2015 14:35:15 -0700     Kubelet stopped posting node status.
 Addresses:    10.240.115.55,104.197.0.26
 Capacity:
  cpu:        1
diff --git a/docs/user-guide/new-nginx-deployment.yaml b/docs/user-guide/new-nginx-deployment.yaml
index 47c57adefb..67bb9fd10f 100644
--- a/docs/user-guide/new-nginx-deployment.yaml
+++ b/docs/user-guide/new-nginx-deployment.yaml
@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: nginx-deployment
diff --git a/docs/user-guide/nginx-app.yaml b/docs/user-guide/nginx-app.yaml
index 8ae449d806..bc7e095646 100644
--- a/docs/user-guide/nginx-app.yaml
+++ b/docs/user-guide/nginx-app.yaml
@@ -11,7 +11,7 @@ spec:
   selector:
     app: nginx
 ---
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: my-nginx
diff --git a/docs/user-guide/nginx-deployment.yaml b/docs/user-guide/nginx-deployment.yaml
index 7a0dd431ef..2aabf5e7b1 100644
--- a/docs/user-guide/nginx-deployment.yaml
+++ b/docs/user-guide/nginx-deployment.yaml
@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: nginx-deployment
diff --git a/docs/user-guide/nginx-lifecycle-deployment.yaml b/docs/user-guide/nginx-lifecycle-deployment.yaml
index 3429cf5533..52bbbe23d7 100644
--- a/docs/user-guide/nginx-lifecycle-deployment.yaml
+++ b/docs/user-guide/nginx-lifecycle-deployment.yaml
@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: nginx
diff --git a/docs/user-guide/nginx-probe-deployment.yaml b/docs/user-guide/nginx-probe-deployment.yaml
index 3aa009efe5..d1d849efef 100644
--- a/docs/user-guide/nginx-probe-deployment.yaml
+++ b/docs/user-guide/nginx-probe-deployment.yaml
@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: nginx
diff --git a/docs/user-guide/nginx-secure-app.yaml b/docs/user-guide/nginx-secure-app.yaml
index f23f8a3585..9e4a16791e 100644
--- a/docs/user-guide/nginx-secure-app.yaml
+++ b/docs/user-guide/nginx-secure-app.yaml
@@ -17,7 +17,7 @@ spec:
   selector:
     run: my-nginx
 ---
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: my-nginx
diff --git a/docs/user-guide/nginx/nginx-deployment.yaml b/docs/user-guide/nginx/nginx-deployment.yaml
index 01a44ec420..2495ef353e 100644
--- a/docs/user-guide/nginx/nginx-deployment.yaml
+++ b/docs/user-guide/nginx/nginx-deployment.yaml
@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: my-nginx
diff --git a/docs/user-guide/redis-deployment.yaml b/docs/user-guide/redis-deployment.yaml
index 892eee876f..eacaa6feea 100644
--- a/docs/user-guide/redis-deployment.yaml
+++ b/docs/user-guide/redis-deployment.yaml
@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: redis
diff --git a/docs/user-guide/redis-resource-deployment.yaml b/docs/user-guide/redis-resource-deployment.yaml
index e7a0ca8cf6..f597f9bb74 100644
--- a/docs/user-guide/redis-resource-deployment.yaml
+++ b/docs/user-guide/redis-resource-deployment.yaml
@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: redis
diff --git a/docs/user-guide/redis-secret-deployment.yaml b/docs/user-guide/redis-secret-deployment.yaml
index e26063fda0..a7201802ec 100644
--- a/docs/user-guide/redis-secret-deployment.yaml
+++ b/docs/user-guide/redis-secret-deployment.yaml
@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: redis
@@ -12,7 +12,7 @@ spec:
       volumes:
         - name: data
           emptyDir: {}
-        - name: supersecret # The "mysecret" secret populates this "supersecret" volume. 
+        - name: supersecret # The "mysecret" secret populates this "supersecret" volume.
           secret:
             secretName: mysecret
       containers:
diff --git a/docs/user-guide/run-my-nginx.yaml b/docs/user-guide/run-my-nginx.yaml
index 1c6fc84928..b3d8e336cd 100644
--- a/docs/user-guide/run-my-nginx.yaml
+++ b/docs/user-guide/run-my-nginx.yaml
@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: my-nginx
diff --git a/docs/user-guide/walkthrough/deployment-update.yaml b/docs/user-guide/walkthrough/deployment-update.yaml
index 9e9b28ec0b..8f0ac0b48c 100644
--- a/docs/user-guide/walkthrough/deployment-update.yaml
+++ b/docs/user-guide/walkthrough/deployment-update.yaml
@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: nginx-deployment
@@ -13,4 +13,4 @@ spec:
       - name: nginx
         image: nginx:1.8 # Update the version of nginx from 1.7.9 to 1.8
         ports:
-        - containerPort: 80
\ No newline at end of file
+        - containerPort: 80
diff --git a/docs/user-guide/walkthrough/deployment.yaml b/docs/user-guide/walkthrough/deployment.yaml
index 50c15d8b11..8d14e2ef08 100644
--- a/docs/user-guide/walkthrough/deployment.yaml
+++ b/docs/user-guide/walkthrough/deployment.yaml
@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: nginx-deployment
@@ -15,4 +15,4 @@ spec:
       - name: nginx
         image: nginx:1.7.9
         ports:
-        - containerPort: 80
\ No newline at end of file
+        - containerPort: 80