kubeadm init [page]deterministic

reference

This command initializes a Kubernetes control plane node.

### Init workflow {#init-workflow}

`kubeadm init` bootstraps a Kubernetes control plane node by executing the following steps:

1. Runs a series of pre-flight checks to validate the system state before making changes. Some checks only trigger warnings, others are considered errors and will exit kubeadm until the problem is corrected or the user specifies `--ignore-preflight-errors=<list-of-errors>`.

1. Generates a self-signed CA to set up identities for each component in the cluster. The user can provide their own CA cert and/or key by dropping it in the cert directory configured via `--cert-dir` (`/etc/kubernetes/pki` by default). The API server certs will have additional SAN entries for any `--apiserver-cert-extra-sans` arguments, lowercased if necessary.

1. Writes kubeconfig files in `/etc/kubernetes/` for the kubelet, the controller-manager, and the scheduler to connect to the API server, each with its own identity. Also additional kubeconfig files are written, for kubeadm as administrative entity (`admin.conf`) and for a super admin user that can bypass RBAC (`super-admin.conf`).

1. Generates static Pod manifests for the API server, 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 watches this directory for Pods to create on startup.

Once control plane Pods are up and running, the `kubeadm init` sequence can continue.

1. Apply labels and taints to the control plane node so that no additional workloads will run there.

1. Generates the token that additional nodes can use to register themselves with a control plane in the future. Optionally, the user can provide a token via `--token`, as described in the [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token/) documents.

1. Makes all the necessary configurations for allowing node joining with the [Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) and [TLS Bootstrap](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) mechanism:

Write a ConfigMap for making available all the information required for joining, and set up related RBAC access rules.

Let Bootstrap Tokens access the CSR signing API.

Configure auto-approval for new CSR requests.

See [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) for additional information.

1. Installs a DNS server (CoreDNS) and the kube-proxy addon components via the API server. In Kubernetes version 1.11 and later CoreDNS is the default DNS server. Please note that although the DNS server is deployed, it will not be scheduled until CNI is installed.

> Warning: kube-dns usage with kubeadm is deprecated as of v1.18 and is removed in v1.21.

### Using init phases with kubeadm {#init-phases}

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.

Some phases have unique flags, so if you want to have a look at the list of available options add `--help`, for example:

```shell sudo kubeadm init phase control-plane controller-manager --help ```

You can also use `--help` to see the list of sub-phases for a certain parent phase:

```shell sudo kubeadm init phase control-plane --help ```

`kubeadm init` also exposes a flag called `--skip-phases` that can be used to skip certain phases. The flag accepts a list of phase names and the names can be taken from the above ordered list.

An example:

```shell sudo kubeadm ini …(trimmed)