kubeadm: update reference docs

- kubeadm alpha phase was moved to kubeadm init phase
- new commands were added under kubeadm alpha

content/en/docs/reference/setup-tools/kubeadm/implementation-details.md

@@ -71,7 +71,7 @@ in a majority of cases, and the most intuitive location; other constants paths a
 The `kubeadm init` [internal workflow](/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-workflow) consists of a sequence of atomic work tasks to perform,
 as described in `kubeadm init`.
 
-The [`kubeadm alpha phase`](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/) command allows users to invoke individually each task, and ultimately offers a reusable and composable
+The [`kubeadm init phase`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/) command allows users to invoke individually each task, and ultimately offers a reusable and composable
 API/toolbox that can be used by other Kubernetes bootstrap tools, by any IT automation tool or by advanced user
 for creating custom clusters.
 
@@ -122,7 +122,7 @@ In any case the user can skip specific preflight checks (or eventually all prefl
 
 Please note that:
 
-1. Preflight checks can be invoked individually with the [`kubeadm alpha phase preflight`](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-phase-preflight) command
+1. Preflight checks can be invoked individually with the [`kubeadm init phase preflight`](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-phase-preflight) command
 
 ### Generate the necessary certificates
 
@@ -158,7 +158,7 @@ Certificates are stored by default in `/etc/kubernetes/pki`, but this directory
 3. If kubeadm is running in [ExternalCA mode](/docs/reference/setup-tools/kubeadm/kubeadm-init/#external-ca-mode); all the certificates must be provided by the user,
    because kubeadm cannot generate them by itself
 4. In case of kubeadm is executed in the `--dry-run` mode, certificates files are written in a temporary folder
-5. Certificate generation can be invoked individually with the [`kubeadm alpha phase certs all`](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-phase-certs) command
+5. Certificate generation can be invoked individually with the [`kubeadm init phase certs`](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-phase-certs) command
 
 ### Generate kubeconfig files for control plane components
 
@@ -186,7 +186,7 @@ Please note that:
 2. If a given kubeconfig file exists, and its content is evaluated compliant with the above specs, the existing file will be used and the generation phase for the given kubeconfig skipped
 3. If kubeadm is running in [ExternalCA mode](/docs/reference/setup-tools/kubeadm/kubeadm-init/#external-ca-mode), all the required kubeconfig must be provided by the user as well, because kubeadm cannot generate any of them by itself
 4. In case of kubeadm is executed in the `--dry-run` mode, kubeconfig files are written in a temporary folder
-5. Kubeconfig files generation can be invoked individually with the [`kubeadm alpha phase kubeconfig all`](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-phase-kubeconfig) command
+5. Kubeconfig files generation can be invoked individually with the [`kubeadm init phase kubeconfig`](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-phase-kubeconfig) command
 
 ### Generate static Pod manifests for control plane components
 
@@ -213,7 +213,7 @@ Please note that:
    should be used for all control plane components, this one will be used. see [using custom images](/docs/reference/setup-tools/kubeadm/kubeadm-init/#custom-images)
    for more details
 2. In case of kubeadm is executed in the `--dry-run` mode, static Pods files are written in a temporary folder
-3. Static Pod manifest generation for master components can be invoked individually with the [`kubeadm alpha phase controlplane all`](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-phase-controlplane) command
+3. Static Pod manifest generation for master components can be invoked individually with the [`kubeadm init phase control-plane`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-control-plane) command
 
 #### API server
 
@@ -226,10 +226,6 @@ The static Pod manifest for the API server is affected by following parameters p
    if an external etcd server is not be provided, a local etcd will be used (via host network)
  - If a cloud provider is specified, the corresponding `--cloud-provider` is configured, together with  the  `--cloud-config` path
    if such file exists (this is experimental, alpha and will be removed in a future version)
- - If kubeadm is invoked with `--feature-gates=HighAvailability`, the flag `--endpoint-reconciler-type=lease` is set, thus enabling
-   automatic reconciliation of endpoints for the internal API server VIP
- - If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig`,  the corresponding feature on API server is activated
-   with the `--feature-gates=DynamicKubeletConfig=true` flag
 
 Other API server flags that are set unconditionally are:
 
@@ -309,11 +305,11 @@ Please note that:
 1. The etcd image will be pulled from `k8s.gcr.io`. In case an alternative image repository is specified this one will be used;
    In case an alternative image name is specified, this one will be used. see [using custom images](/docs/reference/setup-tools/kubeadm/kubeadm-init/#custom-images) for more details
 2. in case of kubeadm is executed in the `--dry-run` mode, the etcd static Pod manifest is written in a temporary folder
-3. Static Pod manifest generation for local etcd can be invoked individually with the [`kubeadm alpha phase etcd local`](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-phase-etcd) command
+3. Static Pod manifest generation for local etcd can be invoked individually with the [`kubeadm init phase etcd local`](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-phase-etcd) command
 
-### (optional and alpha in v1.9) Write init kubelet configuration
+### Optional Dynamic Kublet Configuration
 
-If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig`, it writes the kubelet init configuration
+To use this functionality call `kubeadm alpha kubelet config enable-dynamic`. It writes the kubelet init configuration
 into `/var/lib/kubelet/config/init/kubelet` file.
 
 The init configuration is used for starting the kubelet on this specific node, providing an alternative for the kubelet drop-in file;
@@ -358,7 +354,7 @@ state and make new decisions based on that data.
 Please note that:
 
 1. Before uploading, sensitive information like e.g. the token are stripped from the configuration
-2. Upload of master configuration can be invoked individually with the [`kubeadm alpha phase upload-config`](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-phase-upload-config) command
+2. Upload of master configuration can be invoked individually with the [`kubeadm init phase upload-config`](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-phase-upload-config) command
 3. If you initialized your cluster using kubeadm v1.7.x or lower, you must create manually the master configuration ConfigMap
    before `kubeadm upgrade` to v1.8 . In order to facilitate this task, the [`kubeadm config upload (from-flags|from-file)`](/docs/reference/setup-tools/kubeadm/kubeadm-config/)
    was implemented
@@ -372,7 +368,7 @@ As soon as the control plane is available, kubeadm executes following actions:
 
 Please note that:
 
-1. Mark master phase can be invoked individually with the [`kubeadm alpha phase mark-master`](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-phase-mark-master) command
+1. Mark master phase can be invoked individually with the [`kubeadm init phase mark-control-plane`](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-phase-mark-master) command
 
 ### Configure TLS-Bootstrapping for node joining
 
@@ -383,7 +379,7 @@ existing cluster; for more details see also [design proposal](https://github.com
 setting API server and controller flags as already described in previous paragraphs.
 Please note that:
 
-1. TLS bootstrapping for nodes can be configured with the [`kubeadm alpha phase bootstrap-token all`](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-phase-bootstrap-token)  
+1. TLS bootstrapping for nodes can be configured with the [`kubeadm init phase bootstrap-token`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-bootstrap-token)  
    command, executing all the configuration steps described in following paragraphs; alternatively, each step can be invoked individually
 
 #### Create a bootstrap token
@@ -441,7 +437,7 @@ can handle to serving the `cluster-info` ConfigMap.
 Kubeadm installs the internal DNS server and the kube-proxy addon components via the API server.
 Please note that:
 
-1. This phase can be invoked individually with the [`kubeadm alpha phase addon all`](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-phase-addon) command.
+1. This phase can be invoked individually with the [`kubeadm init phase addon`](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-phase-addon) command.
 
 #### proxy
 
@@ -468,11 +464,11 @@ Deploy the `kube-dns` Deployment and Service:
 - It's the upstream CoreDNS deployment relatively unmodified
 - The `kube-dns` ServiceAccount is bound to the privileges in the `system:kube-dns` ClusterRole
 
-### (Optional and alpha in v1.9) self-hosting
+### Optional self-hosting
 
-This phase is performed only if `kubeadm init` is invoked with `—features-gates=selfHosting`
+To enable self hosting on a existing static Pod control-plane use `kubeadm alpha selfhosting pivot`.
 
-The self hosting phase basically replaces static Pods for control plane components with DaemonSets; this is achieved by executing
+Self hosting basically replaces static Pods for control plane components with DaemonSets; this is achieved by executing
 following procedure for API server, scheduler and controller manager static Pods:
 
 - Load the static Pod specification from disk
@@ -485,21 +481,9 @@ following procedure for API server, scheduler and controller manager static Pods
 - Create the DaemonSet resource in `kube-system` namespace. Wait until the Pods are running.
 - Remove the static Pod manifest file. The kubelet will stop the original static Pod-hosted component that was running
 
-Please note that:
-
-1. Self hosting is not yet resilient to node restarts; this can be fixed with external checkpointing or with kubelet checkpointing
+Please note that self hosting is not yet resilient to node restarts; this can be fixed with external checkpointing or with kubelet checkpointing
    for the control plane Pods. See [self-hosting](/docs/reference/setup-tools/kubeadm/kubeadm-init/#self-hosting) for more details.
 
-2. If invoked with `—features-gates=StoreCertsInSecrets`  following additional steps will be executed
-
-   - Creation of `ca`,  `apiserver`,  `apiserver-kubelet-client`, `sa`, `front-proxy-ca`, `front-proxy-client` TLS secrets
-     in `kube-system` namespace with respective certificates and keys.
-     Important! storing the CA key in a Secret might have security implications
-   - Creation of `schedler.conf` and `controller-manager.conf` secrets in`kube-system` namespace with respective kubeconfig files
-   - Mutation of all the Pod specs by replacing host path volumes with projected volumes from the secrets above
-
-3. This phase can be invoked individually with the [`kubeadm alpha phase selfhosting convert-from-staticpods`](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-phase-self-hosting) command.
-
 ## kubeadm join phases internal design
 
 Similarly to `kubeadm init`, also `kubeadm join` internal workflow consists of a sequence of atomic work tasks to perform.

content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md

@@ -11,12 +11,12 @@ weight: 90
  from the community. Please try it out and give us feedback!
 {{< /caution >}}
 
-In v1.8.0, kubeadm introduced the `kubeadm alpha phase` command with the aim of making kubeadm more modular. This modularity enables you to invoke atomic sub-steps of the bootstrap process; you can let kubeadm do some parts and fill in yourself where you need customizations.
+In v1.8.0, kubeadm introduced the `kubeadm init phase` command with the aim of making kubeadm more modular. This modularity enables you to invoke atomic sub-steps of the bootstrap process; you can let kubeadm do some parts and fill in yourself where you need customizations.
 
-`kubeadm alpha phase` is consistent with [kubeadm init workflow](/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-workflow),
+`kubeadm init phase` is consistent with [kubeadm init workflow](/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-workflow),
 and behind the scene both use the same code.
 
-## kubeadm alpha phase preflight {#cmd-phase-preflight}
+## kubeadm init phase preflight {#cmd-phase-preflight}
 
 You can execute preflight checks both for the master node, like in `kubeadm init`, or for the worker node
 like in `kubeadm join`.
@@ -27,7 +27,7 @@ like in `kubeadm join`.
 {{< /tabs >}}
 
 
-## kubeadm alpha phase certs {#cmd-phase-certs}
+## kubeadm init phase certs {#cmd-phase-certs}
 
 You can create all required certificates with the `all` subcommand or selectively create certificates.
 
@@ -41,7 +41,7 @@ You can create all required certificates with the `all` subcommand or selectivel
 {{< tab name="front-proxy-client" include="generated/kubeadm_alpha_phase_certs_front-proxy-client.md" />}}
 {{< /tabs >}}
 
-## kubeadm alpha phase certs renew {#cmd-phase-certs-renew}
+## kubeadm init phase certs renew {#cmd-phase-certs-renew}
 
 You can renew all Kubernetes certificates using the `all` subcommand or renew them selectively.
 
@@ -56,7 +56,7 @@ You can renew all Kubernetes certificates using the `all` subcommand or renew th
 {{< tab name="front-proxy-client" include="generated/kubeadm_alpha_phase_certs_renew_front-proxy-client.md" />}}
 {{< /tabs >}}
 
-## kubeadm alpha phase kubeconfig {#cmd-phase-kubeconfig}
+## kubeadm init phase kubeconfig {#cmd-phase-kubeconfig}
 
 You can create all required kubeconfig files with the `all` subcommand, or selectively create the files.
 Additionally, the `user` subcommand supports the creation of kubeconfig files for additional users.
@@ -70,7 +70,7 @@ Additionally, the `user` subcommand supports the creation of kubeconfig files fo
 {{< tab name="user" include="generated/kubeadm_alpha_phase_kubeconfig_user.md" />}}
 {{< /tabs >}}
 
-## kubeadm alpha phase kubelet {#cmd-phase-kubelet}
+## kubeadm init phase kubelet {#cmd-phase-kubelet}
 
 Use the following commands to manage the kubelet phase.
 
@@ -83,7 +83,7 @@ Use the following commands to manage the kubelet phase.
 {{< tab name="write-env-file" include="generated/kubeadm_alpha_phase_kubelet_write-env-file.md" />}}
 {{< /tabs >}}
 
-## kubeadm alpha phase controlplane {#cmd-phase-controlplane}
+## kubeadm init phase controlplane {#cmd-phase-controlplane}
 
 You can create all required static Pod files for the control plane components with the `all` subcommand,
 or selectively create the files.
@@ -96,7 +96,7 @@ or selectively create the files.
 {{< /tabs >}}
 
 
-## kubeadm alpha phase etcd {#cmd-phase-etcd}
+## kubeadm init phase etcd {#cmd-phase-etcd}
 
 Use the following command to create a self-hosted, local etcd instance based on a static Pod file.
 
@@ -105,7 +105,7 @@ Use the following command to create a self-hosted, local etcd instance based on
 {{< /tabs >}}
 
 
-## kubeadm alpha phase mark-master {#cmd-phase-mark-master}
+## kubeadm init phase mark-master {#cmd-phase-mark-master}
 
 Use the following command to label and taint the node with the `node-role.kubernetes.io/master=""` key-value pair.
 
@@ -114,7 +114,7 @@ Use the following command to label and taint the node with the `node-role.kubern
 {{< /tabs >}}
 
 
-## kubeadm alpha phase bootstrap-token {#cmd-phase-bootstrap-token}
+## kubeadm init phase bootstrap-token {#cmd-phase-bootstrap-token}
 
 Use the following actions to fully configure bootstrap tokens.
 You can fully configure bootstrap tokens with the `all` subcommand,
@@ -129,7 +129,7 @@ or selectively configure single elements.
 {{< /tabs >}}
 
 
-## kubeadm alpha phase upload-config {#cmd-phase-upload-config}
+## kubeadm init phase upload-config {#cmd-phase-upload-config}
 
 You can use this command to upload the kubeadm configuration to your cluster.
 Alternatively, you can use [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config/).
@@ -139,7 +139,7 @@ Alternatively, you can use [kubeadm config](/docs/reference/setup-tools/kubeadm/
 {{< /tabs >}}
 
 
-## kubeadm alpha phase addon {#cmd-phase-addon}
+## kubeadm init phase addon {#cmd-phase-addon}
 
 You can install all the available addons with the `all` subcommand, or
 install them selectively.
@@ -155,7 +155,7 @@ install them selectively.
 {{< /tabs >}}
 
 
-## kubeadm alpha phase self-hosting {#cmd-phase-self-hosting}
+## kubeadm init phase self-hosting {#cmd-phase-self-hosting}
 
 {{< caution >}}
 **Caution:** Self-hosting is an alpha feature. See [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) documentation for self-hosting limitations.

content/en/docs/setup/independent/create-cluster-kubeadm.md

@@ -505,7 +505,7 @@ and `scp` using that other user instead.
 The `admin.conf` file gives the user _superuser_ privileges over the cluster.
 This file should be used sparingly. For normal users, it's recommended to
 generate an unique credential to which you whitelist privileges. You can do
-this with the `kubeadm alpha phase kubeconfig user --client-name <CN>`
+this with the `kubeadm alpha kubeconfig user --client-name <CN>`
 command. That command will print out a KubeConfig file to STDOUT which you
 should save to a file and distribute to your user. After that, whitelist
 privileges by using `kubectl create (cluster)rolebinding`.