diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md
index d5c10082d7..2a899e9a3e 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md
@@ -8,13 +8,9 @@ content_template: templates/concept
 weight: 50
 ---
 {{% capture overview %}}
-Beginning with v1.8.0, kubeadm uploads the configuration of your cluster to a ConfigMap called
-`kubeadm-config` in the `kube-system` namespace, and later reads the ConfigMap when upgrading.
-This enables correct configuration of system components, and provides a seamless user experience.
-
-You can execute `kubeadm config view` to view the ConfigMap. If you initialized your cluster using
-kubeadm v1.7.x or lower, you must use `kubeadm config upload` to create the ConfigMap before you
-may use `kubeadm upgrade`.
+During `kubeadm init`, kubeadm uploads the `ClusterConfiguration` object to your cluster
+in a ConfigMap called `kubeadm-config` in the `kube-system` namespace. This configuration is then read during
+`kubeadm join`, `kubeadm reset` and `kubeadm upgrade`. To view this ConfigMap call `kubeadm config view`.
 
 You can use `kubeadm config print` to print the default configuration and `kubeadm config migrate` to
 convert your old configuration files to a newer version. `kubeadm config images list` and
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md
index 7cbbfcbddb..96459887ae 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md
@@ -2,7 +2,9 @@
 title: kubeadm init phase
 weight: 90
 ---
-In v1.8.0, kubeadm introduced the `kubeadm alpha phase` command with the aim of making kubeadm more modular. In v1.13.0 this command graduated to `kubeadm init phase`. This modularity enables you to invoke atomic sub-steps of the bootstrap process. Hence, you can let kubeadm do some parts and fill in yourself where you need customizations.
+`kubeadm init phase` enables you to invoke atomic steps of the bootstrap process.
+Hence, you can let kubeadm do some of the work and you can fill in the gaps
+if you wish to apply customization.
 
 `kubeadm init phase` is consistent with the [kubeadm init workflow](/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-workflow),
 and behind the scene both use the same code.
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
index 6ff70db9dc..8fc9d3f95a 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
@@ -37,7 +37,7 @@ following steps:
    kubeconfig file for administration named `admin.conf`.
 
 1. Generates static Pod manifests for the API server,
-   controller manager and scheduler. In case an external etcd is not provided,
+   controller-manager and scheduler. In case an external etcd is not provided,
    an additional static Pod manifest is generated for etcd.
 
    Static Pod manifests are written to `/etc/kubernetes/manifests`; the kubelet
@@ -75,7 +75,7 @@ following steps:
 
 ### Using init phases with kubeadm {#init-phases}
 
-Kubeadm allows you create a control-plane node in phases. In 1.13 the `kubeadm init phase` command has graduated to GA from it’s previous alpha state under `kubeadm alpha phase`.
+Kubeadm allows you to create a control-plane node in phases using the `kubeadm init phase` command.
 
 To view the ordered list of phases and sub-phases you can call `kubeadm init --help`. The list will be located at the top of the help screen and each phase will have a description next to it.
 Note that by calling `kubeadm init` all of the phases and sub-phases will be executed in this exact order.
@@ -113,9 +113,9 @@ The config file is still considered beta and may change in future versions.
 
 It's possible to configure `kubeadm init` with a configuration file instead of command
 line flags, and some more advanced features may only be available as
-configuration file options. This file is passed in the `--config` option.
+configuration file options. This file is passed with the `--config` option.
 
-In Kubernetes 1.11 and later, the default configuration can be printed out using the
+The default configuration can be printed out using the
 [kubeadm config print](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command.
 
 It is **recommended** that you migrate your old `v1beta1` configuration to `v1beta2` using
@@ -139,8 +139,8 @@ For information about passing flags to control plane components see:
 
 ### Using custom images {#custom-images}
 
-By default, kubeadm pulls images from `k8s.gcr.io`, unless
-the requested Kubernetes version is a CI version. In this case,
+By default, kubeadm pulls images from `k8s.gcr.io`. If the
+requested Kubernetes version is a CI label (such as `ci/latest`)
 `gcr.io/kubernetes-ci-images` is used.
 
 You can override this behavior by using [kubeadm with a configuration file](#config-file).
@@ -187,11 +187,10 @@ To do so, you must place them in whatever directory is specified by the
 `--cert-dir` flag or `CertificatesDir` configuration file key. By default this
 is `/etc/kubernetes/pki`.
 
-If a given certificate and private key pair exists, kubeadm skips the
-generation step and existing files are used for the prescribed
-use case. This means you can, for example, copy an existing CA into `/etc/kubernetes/pki/ca.crt`
-and `/etc/kubernetes/pki/ca.key`, and kubeadm will use this CA for signing the rest
-of the certs.
+If a given certificate and private key pair exists before running `kubeadm init`,
+kubeadm will not overwrite them. This means you can, for example, copy an existing
+CA into `/etc/kubernetes/pki/ca.crt` and `/etc/kubernetes/pki/ca.key`,
+and kubeadm will use this CA for signing the rest of the certificates.
 
 #### External CA mode {#external-ca-mode}
 
@@ -212,47 +211,14 @@ For further information, see [Managing the kubeadm drop-in file for systemd](/do
 
 ### Use kubeadm with CRI runtimes
 
-Since v1.6.0, Kubernetes has enabled the use of CRI, Container Runtime Interface, by default.
-The container runtime used by default is Docker, which is enabled through the built-in
-`dockershim` CRI implementation inside of the `kubelet`.
-
-Other CRI-based runtimes include:
-
-- [cri-containerd](https://github.com/containerd/cri-containerd)
-- [cri-o](https://github.com/kubernetes-incubator/cri-o)
-- [frakti](https://github.com/kubernetes/frakti)
-- [rkt](https://github.com/kubernetes-incubator/rktlet)
-
-Refer to the [CRI installation instructions](/docs/setup/cri) for more information.
-
-After you have successfully installed `kubeadm` and `kubelet`, execute
-these two additional steps:
-
-1. Install the runtime shim on every node, following the installation
-   document in the runtime shim project listing above.
-
-1. Configure kubelet to use the remote CRI runtime. Please remember to change
-   `RUNTIME_ENDPOINT` to your own value like `/var/run/{your_runtime}.sock`:
-
-```shell
-cat > /etc/systemd/system/kubelet.service.d/20-cri.conf <<EOF
-[Service]
-Environment="KUBELET_EXTRA_ARGS=--container-runtime=remote --container-runtime-endpoint=$RUNTIME_ENDPOINT"
-EOF
-systemctl daemon-reload
-```
-
-Now `kubelet` is ready to use the specified CRI runtime, and you can continue
-with the `kubeadm init` and `kubeadm join` workflow to deploy Kubernetes cluster.
-
-You may also want to set `--cri-socket` to `kubeadm init` and `kubeadm reset` when
-using an external CRI implementation.
+By default kubeadm attempts to detect your container runtime. For more details on this detection, see
+the [kubeadm CRI installation guide](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime).
 
 ### Setting the node name
 
-By default, `kubeadm` assigns a node name based on a machine's host address. You can override this setting with the `--node-name`flag.
+By default, `kubeadm` assigns a node name based on a machine's host address. You can override this setting with the `--node-name` flag.
 The flag passes the appropriate [`--hostname-override`](/docs/reference/command-line-tools-reference/kubelet/#options)
-to the kubelet.
+value to the kubelet.
 
 Be aware that overriding the hostname can [interfere with cloud providers](https://github.com/kubernetes/website/pull/8873).
 
@@ -260,25 +226,25 @@ Be aware that overriding the hostname can [interfere with cloud providers](https
 
 For running kubeadm without an internet connection you have to pre-pull the required control-plane images.
 
-In Kubernetes 1.11 and later, you can list and pull the images using the `kubeadm config images` sub-command:
+You can list and pull the images using the `kubeadm config images` sub-command:
 
 ```shell
 kubeadm config images list
 kubeadm config images pull
 ```
 
-In Kubernetes 1.12 and later, the `k8s.gcr.io/kube-*`, `k8s.gcr.io/etcd` and `k8s.gcr.io/pause` images
-don't require an `-${ARCH}` suffix.
+All images that kubeadm requires such as `k8s.gcr.io/kube-*`, `k8s.gcr.io/etcd` and `k8s.gcr.io/pause` support multiple architectures.
 
 ### Automating kubeadm
 
 Rather than copying the token you obtained from `kubeadm init` to each node, as
 in the [basic kubeadm tutorial](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/), you can parallelize the
 token distribution for easier automation. To implement this automation, you must
-know the IP address that the control-plane node will have after it is started.
+know the IP address that the control-plane node will have after it is started,
+or use a DNS name or an address of a load balancer.
 
 1.  Generate a token. This token must have the form  `<6 character string>.<16
-    character string>`.  More formally, it must match the regex:
+    character string>`. More formally, it must match the regex:
     `[a-z0-9]{6}\.[a-z0-9]{16}`.
 
     kubeadm can generate a token for you:
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join-phase.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join-phase.md
index bb993fa113..c26c0a2e4b 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join-phase.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join-phase.md
@@ -2,8 +2,9 @@
 title: kubeadm join phase
 weight: 90
 ---
-In v1.14.0, kubeadm introduces the `kubeadm join phase` command with the aim of making kubeadm more modular. This modularity enables you to invoke atomic sub-steps of the join process.
-Hence, you can let kubeadm do some parts and fill in yourself where you need customizations.
+`kubeadm join phase` enables you to invoke atomic steps of the join process.
+Hence, you can let kubeadm do some of the work and you can fill in the gaps
+if you wish to apply customization.
 
 `kubeadm join phase` is consistent with the [kubeadm join workflow](/docs/reference/setup-tools/kubeadm/kubeadm-join/#join-workflow),
 and behind the scene both use the same code.
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md
index 817c279d84..2cff0b810d 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md
@@ -47,7 +47,7 @@ For control-plane nodes additional steps are performed:
 
 ### Using join phases with kubeadm {#join-phases}
 
-Kubeadm allows you join a node to the cluster in phases. The `kubeadm join phase` command was added in v1.14.0.
+Kubeadm allows you join a node to the cluster in phases using `kubeadm join phase`.
 
 To view the ordered list of phases and sub-phases you can call `kubeadm join --help`. The list will be located
 at the top of the help screen and each phase will have a description next to it.
@@ -76,7 +76,7 @@ security expectations you have about your network and node lifecycles.
 
 #### Token-based discovery with CA pinning
 
-This is the default mode in Kubernetes 1.8 and above. In this mode, kubeadm downloads
+This is the default mode in kubeadm. In this mode, kubeadm downloads
 the cluster configuration (including root CA) and validates it using the token
 as well as validating that the root CA public key matches the provided hash and
 that the API server certificate is valid under the root CA.
@@ -117,15 +117,14 @@ if the `kubeadm init` command was called with `--upload-certs`.
  - The CA hash is not normally known until the control-plane node has been provisioned,
    which can make it more difficult to build automated provisioning tools that
    use kubeadm. By generating your CA in beforehand, you may workaround this
-   limitation though.
+   limitation.
 
 #### Token-based discovery without CA pinning
 
-_This was the default in Kubernetes 1.7 and earlier_, but comes with some
-important caveats. This mode relies only on the symmetric token to sign
+This mode relies only on the symmetric token to sign
 (HMAC-SHA256) the discovery information that establishes the root of trust for
-the control-plane. It's still possible in Kubernetes 1.8 and above using the
-`--discovery-token-unsafe-skip-ca-verification` flag, but you should consider
+the control-plane. To use the mode the joining nodes must skip the hash validation of the
+CA public key, using `--discovery-token-unsafe-skip-ca-verification`. You should consider
 using one of the other modes if possible.
 
 **Example `kubeadm join` command:**
@@ -150,9 +149,13 @@ kubeadm join --token abcdef.1234567890abcdef --discovery-token-unsafe-skip-ca-ve
    tradeoff in your environment.
 
 #### File or HTTPS-based discovery
+
 This provides an out-of-band way to establish a root of trust between the control-plane node
-and bootstrapping nodes.   Consider using this mode if you are building automated provisioning
-using kubeadm.
+and bootstrapping nodes. Consider using this mode if you are building automated provisioning
+using kubeadm. The format of the discovery file is a regular Kubernetes
+[kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) file.
+
+In case the discovery file does not contain credentials, the TLS discovery token will be used.
 
 **Example `kubeadm join` commands:**
 
@@ -215,7 +218,7 @@ NAME                                                   AGE       REQUESTOR
 node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ   1m        system:bootstrap:878f07   Approved,Issued
 ```
 
-Only after `kubectl certificate approve` has been run, `kubeadm join` can proceed.
+This forces the workflow that `kubeadm join` will only succeed if `kubectl certificate approve` has been run.
 
 #### Turning off public access to the cluster-info ConfigMap
 
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md
index 6d17e73c09..663bb67e24 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md
@@ -2,8 +2,9 @@
 title: kubeadm reset phase
 weight: 90
 ---
-In v1.15.0, kubeadm introduces the `kubeadm reset phase` command with the aim of making kubeadm more modular. This modularity enables you to invoke atomic sub-steps of the reset process.
-Hence, you can let kubeadm do some parts and fill in yourself where you need customizations.
+`kubeadm reset phase` enables you to invoke atomic steps of the node reset process.
+Hence, you can let kubeadm do some of the work and you can fill in the gaps
+if you wish to apply customization.
 
 `kubeadm reset phase` is consistent with the [kubeadm reset workflow](/docs/reference/setup-tools/kubeadm/kubeadm-reset/#reset-workflow),
 and behind the scene both use the same code.
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md
index 2f389b851e..3ef16db288 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md
@@ -8,26 +8,18 @@ content_template: templates/concept
 weight: 40
 ---
 {{% capture overview %}}
-`kubeadm upgrade` is a user-friendly command that wraps complex upgrading logic behind one command, with support
-for both planning an upgrade and actually performing it. `kubeadm upgrade` can also be used for downgrading
-cluster if necessary.
+`kubeadm upgrade` is a user-friendly command that wraps complex upgrading logic
+behind one command, with support for both planning an upgrade and actually performing it.
 {{% /capture %}}
 
 {{% capture body %}}
 
 ## kubeadm upgrade guidance
 
-Every upgrade process might be a bit different, so we've documented each minor upgrade process individually.
-For more version-specific upgrade guidance, see the following resources:
+The steps for performing a upgrade using kubeadm are outlined in [this document](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/).
+For older versions of kubeadm, please refer to older documentation sets of the Kubernetes website.
 
- * [1.12 to 1.13 upgrades](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-13/)
- * [1.13 to 1.14 upgrades](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-14/)
- * [1.14 to 1.15 upgrades](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15/)
-
-_For older versions, please refer to older documentation sets on the Kubernetes website._
-
-In Kubernetes v1.11.0 and later, you can use `kubeadm upgrade diff` to see the changes that would be
-applied to static pod manifests.
+You can use `kubeadm upgrade diff` to see the changes that would be applied to static pod manifests.
 
 To use kube-dns with upgrades in Kubernetes v1.13.0 and later please follow [this guide](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon).