Setup tools

1 - Kubeadm

Kubeadm is a tool built to provide kubeadm init and kubeadm join as best-practice "fast paths" for creating Kubernetes clusters.

kubeadm performs the actions necessary to get a minimum viable cluster up and running. By design, it cares only about bootstrapping, not about provisioning machines. Likewise, installing various nice-to-have addons, like the Kubernetes Dashboard, monitoring solutions, and cloud-specific addons, is not in scope.

Instead, we expect higher-level and more tailored tooling to be built on top of kubeadm, and ideally, using kubeadm as the basis of all deployments will make it easier to create conformant clusters.

How to install

To install kubeadm, see the installation guide.

What's next

• kubeadm init to bootstrap a Kubernetes control-plane node
• kubeadm join to bootstrap a Kubernetes worker node and join it to the cluster
• kubeadm upgrade to upgrade a Kubernetes cluster to a newer version
• kubeadm config if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for kubeadm upgrade
• kubeadm token to manage tokens for kubeadm join
• kubeadm reset to revert any changes made to this host by kubeadm init or kubeadm join
• kubeadm certs to manage Kubernetes certificates
• kubeadm kubeconfig to manage kubeconfig files
• kubeadm version to print the kubeadm version
• kubeadm alpha to preview a set of features made available for gathering feedback from the community

1.1 - kubeadm init

This command initializes a Kubernetes control plane node.

Synopsis

Run this command in order to set up the Kubernetes control plane

The "init" command executes the following phases:

preflight                     Run pre-flight checks
certs                         Certificate generation
  /ca                           Generate the self-signed Kubernetes CA to provision identities for other Kubernetes components
  /apiserver                    Generate the certificate for serving the Kubernetes API
  /apiserver-kubelet-client     Generate the certificate for the API server to connect to kubelet
  /front-proxy-ca               Generate the self-signed CA to provision identities for front proxy
  /front-proxy-client           Generate the certificate for the front proxy client
  /etcd-ca                      Generate the self-signed CA to provision identities for etcd
  /etcd-server                  Generate the certificate for serving etcd
  /etcd-peer                    Generate the certificate for etcd nodes to communicate with each other
  /etcd-healthcheck-client      Generate the certificate for liveness probes to healthcheck etcd
  /apiserver-etcd-client        Generate the certificate the apiserver uses to access etcd
  /sa                           Generate a private key for signing service account tokens along with its public key
kubeconfig                    Generate all kubeconfig files necessary to establish the control plane and the admin kubeconfig file
  /admin                        Generate a kubeconfig file for the admin to use and for kubeadm itself
  /super-admin                  Generate a kubeconfig file for the super-admin
  /kubelet                      Generate a kubeconfig file for the kubelet to use *only* for cluster bootstrapping purposes
  /controller-manager           Generate a kubeconfig file for the controller manager to use
  /scheduler                    Generate a kubeconfig file for the scheduler to use
etcd                          Generate static Pod manifest file for local etcd
  /local                        Generate the static Pod manifest file for a local, single-node local etcd instance
control-plane                 Generate all static Pod manifest files necessary to establish the control plane
  /apiserver                    Generates the kube-apiserver static Pod manifest
  /controller-manager           Generates the kube-controller-manager static Pod manifest
  /scheduler                    Generates the kube-scheduler static Pod manifest
kubelet-start                 Write kubelet settings and (re)start the kubelet
wait-control-plane            Wait for the control plane to start
upload-config                 Upload the kubeadm and kubelet configuration to a ConfigMap
  /kubeadm                      Upload the kubeadm ClusterConfiguration to a ConfigMap
  /kubelet                      Upload the kubelet component config to a ConfigMap
upload-certs                  Upload certificates to kubeadm-certs
mark-control-plane            Mark a node as a control-plane
bootstrap-token               Generates bootstrap tokens used to join a node to a cluster
kubelet-finalize              Updates settings relevant to the kubelet after TLS bootstrap
  /enable-client-cert-rotation  Enable kubelet client certificate rotation
addon                         Install required addons for passing conformance tests
  /coredns                      Install the CoreDNS addon to a Kubernetes cluster
  /kube-proxy                   Install the kube-proxy addon to a Kubernetes cluster
show-join-command             Show the join command for control-plane and worker node

kubeadm init [flags]

Options

Options inherited from parent commands

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>.

2. 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.

3. 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).

4. 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.

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

6. 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 documents.

7. Makes all the necessary configurations for allowing node joining with the Bootstrap Tokens and TLS Bootstrap 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 for additional information.

8. 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

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:

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:

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:

sudo kubeadm init phase control-plane all --config=configfile.yaml
sudo kubeadm init phase etcd local --config=configfile.yaml
# you can now modify the control plane and etcd manifest files
sudo kubeadm init --skip-phases=control-plane,etcd --config=configfile.yaml

What this example would do is write the manifest files for the control plane and etcd in /etc/kubernetes/manifests based on the configuration in configfile.yaml. This allows you to modify the files and then skip these phases using --skip-phases. By calling the last command you will create a control plane node with the custom manifest files.

Alternatively, you can use the skipPhases field under InitConfiguration.

Using kubeadm init with a configuration file

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 using the --config flag and it must contain a ClusterConfiguration structure and optionally more structures separated by ---\n. Mixing --config with others flags may not be allowed in some cases.

The default configuration can be printed out using the kubeadm config print command.

If your configuration is not using the latest version it is recommended that you migrate using the kubeadm config migrate command.

For more information on the fields and usage of the configuration you can navigate to our API reference page.

Using kubeadm init with feature gates

kubeadm supports a set of feature gates that are unique to kubeadm and can only be applied during cluster creation with kubeadm init. These features can control the behavior of the cluster. Feature gates are removed after a feature graduates to GA.

To pass a feature gate you can either use the --feature-gates flag for kubeadm init, or you can add items into the featureGates field when you pass a configuration file using --config.

Passing feature gates for core Kubernetes components directly to kubeadm is not supported. Instead, it is possible to pass them by Customizing components with the kubeadm API.

List of feature gates:

Feature gate descriptions:

ControlPlaneKubeletLocalMode

With this feature gate enabled, when joining a new control plane node, kubeadm will configure the kubelet to connect to the local kube-apiserver. This ensures that there will not be a violation of the version skew policy during rolling upgrades.

NodeLocalCRISocket

With this feature gate enabled, kubeadm will read/write the CRI socket for each node from/to the file /var/lib/kubelet/instance-config.yaml instead of reading/writing it from/to the annotation kubeadm.alpha.kubernetes.io/cri-socket on the Node object. The new file is applied as an instance configuration patch, before any other user managed patches are applied when the --patches flag is used. It contains a single field containerRuntimeEndpoint from the KubeletConfiguration file format. If the feature gate is enabled during upgrade, but the file /var/lib/kubelet/instance-config.yaml does not exist yet, kubeadm will attempt to read the CRI socket value from the file /var/lib/kubelet/kubeadm-flags.env.

List of deprecated feature gates:

Feature gate descriptions:

PublicKeysECDSA

Can be used to create a cluster that uses ECDSA certificates instead of the default RSA algorithm. Renewal of existing ECDSA certificates is also supported using kubeadm certs renew, but you cannot switch between the RSA and ECDSA algorithms on the fly or during upgrades. Kubernetes versions before v1.31 had a bug where keys in generated kubeconfig files were set use RSA, even when you had enabled the PublicKeysECDSA feature gate. This feature gate is deprecated in favor of the encryptionAlgorithm functionality available in kubeadm v1beta4.

RootlessControlPlane

Setting this flag configures the kubeadm deployed control plane component static Pod containers for kube-apiserver, kube-controller-manager, kube-scheduler and etcd to run as non-root users. If the flag is not set, those components run as root. You can change the value of this feature gate before you upgrade to a newer version of Kubernetes.

List of removed feature gates:

Feature gate descriptions:

EtcdLearnerMode

When joining a new control plane node, a new etcd member will be created as a learner and promoted to a voting member only after the etcd data are fully aligned.

IPv6DualStack

This flag helps to configure components dual stack when the feature is in progress. For more details on Kubernetes dual-stack support see Dual-stack support with kubeadm.

UnversionedKubeletConfigMap

This flag controls the name of the ConfigMap where kubeadm stores kubelet configuration data. With this flag not specified or set to true, the ConfigMap is named kubelet-config. If you set this flag to false, the name of the ConfigMap includes the major and minor version for Kubernetes (for example: kubelet-config-1.35). Kubeadm ensures that RBAC rules for reading and writing that ConfigMap are appropriate for the value you set. When kubeadm writes this ConfigMap (during kubeadm init or kubeadm upgrade apply), kubeadm respects the value of UnversionedKubeletConfigMap. When reading that ConfigMap (during kubeadm join, kubeadm reset, kubeadm upgrade...), kubeadm attempts to use unversioned ConfigMap name first. If that does not succeed, kubeadm falls back to using the legacy (versioned) name for that ConfigMap.

UpgradeAddonsBeforeControlPlane

This feature gate has been removed. It was introduced in v1.28 as a deprecated feature and then removed in v1.31. For documentation on older versions, please switch to the corresponding website version.

WaitForAllControlPlaneComponents

With this feature gate enabled, kubeadm will wait for all control plane components (kube-apiserver, kube-controller-manager, kube-scheduler) on a control plane node to report status 200 on their /livez or /healthz endpoints. These checks are performed on https://ADDRESS:PORT/ENDPOINT.

• PORT is taken from --secure-port of a component.
• ADDRESS is --advertise-address for kube-apiserver and --bind-address for the kube-controller-manager and kube-scheduler.
• ENDPOINT is only /healthz for kube-controller-manager until it supports /livez as well.

If you specify custom ADDRESS or PORT in the kubeadm configuration they will be respected. Without the feature gate enabled, kubeadm will only wait for the kube-apiserver on a control plane node to become ready. The wait process starts right after the kubelet on the host is started by kubeadm. You are advised to enable this feature gate in case you wish to observe a ready state from all control plane components during the kubeadm init or kubeadm join command execution.

Adding kube-proxy parameters

For information about kube-proxy parameters in the kubeadm configuration see:

• kube-proxy reference

For information about enabling IPVS mode with kubeadm see:

• IPVS

Passing custom flags to control plane components

For information about passing flags to control plane components see:

• control-plane-flags

Running kubeadm without an Internet connection

For running kubeadm without an Internet connection you have to pre-pull the required control plane images.

You can list and pull the images using the kubeadm config images sub-command:

kubeadm config images list
kubeadm config images pull

You can pass --config to the above commands with a kubeadm configuration file to control the kubernetesVersion and imageRepository fields.

All default registry.k8s.io images that kubeadm requires support multiple architectures.

Using custom images

By default, kubeadm pulls images from registry.k8s.io. If the requested Kubernetes version is a CI label (such as ci/latest) gcr.io/k8s-staging-ci-images is used.

You can override this behavior by using kubeadm with a configuration file. Allowed customization are:

• To provide kubernetesVersion which affects the version of the images.
• To provide an alternative imageRepository to be used instead of registry.k8s.io.
• To provide a specific imageRepository and imageTag for etcd or CoreDNS.

Image paths between the default registry.k8s.io and a custom repository specified using imageRepository may differ for backwards compatibility reasons. For example, one image might have a subpath at registry.k8s.io/subpath/image, but be defaulted to my.customrepository.io/image when using a custom repository.

To ensure you push the images to your custom repository in paths that kubeadm can consume, you must:

• Pull images from the defaults paths at registry.k8s.io using kubeadm config images {list|pull}.
• Push images to the paths from kubeadm config images list --config=config.yaml, where config.yaml contains the custom imageRepository, and/or imageTag for etcd and CoreDNS.
• Pass the same config.yaml to kubeadm init.

Custom sandbox (pause) images

To set a custom image for these you need to configure this in your container runtime to use the image. Consult the documentation for your container runtime to find out how to change this setting; for selected container runtimes, you can also find advice within the Container Runtimes topic.

Uploading control plane certificates to the cluster

By adding the flag --upload-certs to kubeadm init you can temporary upload the control plane certificates to a Secret in the cluster. Please note that this Secret will expire automatically after 2 hours. The certificates are encrypted using a 32byte key that can be specified using --certificate-key. The same key can be used to download the certificates when additional control plane nodes are joining, by passing --control-plane and --certificate-key to kubeadm join.

The following phase command can be used to re-upload the certificates after expiration:

kubeadm init phase upload-certs --upload-certs --config=SOME_YAML_FILE

If a predefined certificate key is not passed to kubeadm init and kubeadm init phase upload-certs a new key will be generated automatically.

The following command can be used to generate a new key on demand:

kubeadm certs certificate-key

Certificate management with kubeadm

For detailed information on certificate management with kubeadm see Certificate Management with kubeadm. The document includes information about using external CA, custom certificates and certificate renewal.

Managing the kubeadm drop-in file for the kubelet

The kubeadm package ships with a configuration file for running the kubelet by systemd. Note that the kubeadm CLI never touches this drop-in file. This drop-in file is part of the kubeadm DEB/RPM package.

For further information, see Managing the kubeadm drop-in file for systemd.

Use kubeadm with CRI runtimes

By default, kubeadm attempts to detect your container runtime. For more details on this detection, see the kubeadm CRI installation guide.

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. The flag passes the appropriate --hostname-override value to the kubelet.

Be aware that overriding the hostname can interfere with cloud providers.

Automating kubeadm

Rather than copying the token you obtained from kubeadm init to each node, as in the basic kubeadm tutorial, 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, 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: [a-z0-9]{6}\.[a-z0-9]{16}.

   kubeadm can generate a token for you:

   kubeadm token generate
   

2. Start both the control plane node and the worker nodes concurrently with this token. As they come up they should find each other and form the cluster. The same --token argument can be used on both kubeadm init and kubeadm join.

3. Similar can be done for --certificate-key when joining additional control plane nodes. The key can be generated using:

   kubeadm certs certificate-key
   

Once the cluster is up, you can use the /etc/kubernetes/admin.conf file from a control plane node to talk to the cluster with administrator credentials or Generating kubeconfig files for additional users.

Note that this style of bootstrap has some relaxed security guarantees because it does not allow the root CA hash to be validated with --discovery-token-ca-cert-hash (since it's not generated when the nodes are provisioned). For details, see the kubeadm join.

What's next

• kubeadm init phase to understand more about kubeadm init phases
• kubeadm join to bootstrap a Kubernetes worker node and join it to the cluster
• kubeadm upgrade to upgrade a Kubernetes cluster to a newer version
• kubeadm reset to revert any changes made to this host by kubeadm init or kubeadm join

1.2 - kubeadm join

This command initializes a new Kubernetes node and joins it to the existing cluster.

Run this on any machine you wish to join an existing cluster

Synopsis

When joining a kubeadm initialized cluster, we need to establish bidirectional trust. This is split into discovery (having the Node trust the Kubernetes Control Plane) and TLS bootstrap (having the Kubernetes Control Plane trust the Node).

There are 2 main schemes for discovery. The first is to use a shared token along with the IP address of the API server. The second is to provide a file - a subset of the standard kubeconfig file. The discovery/kubeconfig file supports token, client-go authentication plugins ("exec"), "tokenFile", and "authProvider". This file can be a local file or downloaded via an HTTPS URL. The forms are kubeadm join --discovery-token abcdef.1234567890abcdef 1.2.3.4:6443, kubeadm join --discovery-file path/to/file.conf, or kubeadm join --discovery-file https://url/file.conf. Only one form can be used. If the discovery information is loaded from a URL, HTTPS must be used. Also, in that case the host installed CA bundle is used to verify the connection.

If you use a shared token for discovery, you should also pass the --discovery-token-ca-cert-hash flag to validate the public key of the root certificate authority (CA) presented by the Kubernetes Control Plane. The value of this flag is specified as "<hash-type>:<hex-encoded-value>", where the supported hash type is "sha256". The hash is calculated over the bytes of the Subject Public Key Info (SPKI) object (as in RFC7469). This value is available in the output of "kubeadm init" or can be calculated using standard tools. The --discovery-token-ca-cert-hash flag may be repeated multiple times to allow more than one public key.

If you cannot know the CA public key hash ahead of time, you can pass the --discovery-token-unsafe-skip-ca-verification flag to disable this verification. This weakens the kubeadm security model since other nodes can potentially impersonate the Kubernetes Control Plane.

The TLS bootstrap mechanism is also driven via a shared token. This is used to temporarily authenticate with the Kubernetes Control Plane to submit a certificate signing request (CSR) for a locally created key pair. By default, kubeadm will set up the Kubernetes Control Plane to automatically approve these signing requests. This token is passed in with the --tls-bootstrap-token abcdef.1234567890abcdef flag.

Often times the same token is used for both parts. In this case, the --token flag can be used instead of specifying each token individually.

The "join [api-server-endpoint]" command executes the following phases:

preflight               Run join pre-flight checks
control-plane-prepare   Prepare the machine for serving a control plane
  /download-certs         Download certificates shared among control-plane nodes from the kubeadm-certs Secret
  /certs                  Generate the certificates for the new control plane components
  /kubeconfig             Generate the kubeconfig for the new control plane components
  /control-plane          Generate the manifests for the new control plane components
kubelet-start           Write kubelet settings, certificates and (re)start the kubelet
etcd-join               Join etcd for control plane nodes
kubelet-wait-bootstrap  Wait for the kubelet to bootstrap itself
control-plane-join      Join a machine as a control plane instance
  /mark-control-plane     Mark a node as a control-plane
wait-control-plane      Wait for the control plane to start

kubeadm join [api-server-endpoint] [flags]

Options

Options inherited from parent commands

The join workflow

kubeadm join bootstraps a Kubernetes worker node or a control-plane node and adds it to the cluster. This action consists of the following steps for worker nodes:

1. kubeadm downloads necessary cluster information from the API server. By default, it uses the bootstrap token and the CA key hash to verify the authenticity of that data. The root CA can also be discovered directly via a file or URL.

2. Once the cluster information is known, kubelet can start the TLS bootstrapping process.

   The TLS bootstrap uses the shared token to temporarily authenticate with the Kubernetes API server to submit a certificate signing request (CSR); by default the control plane signs this CSR request automatically.

3. Finally, kubeadm configures the local kubelet to connect to the API server with the definitive identity assigned to the node.

For control-plane nodes additional steps are performed:

1. Downloading certificates shared among control-plane nodes from the cluster (if explicitly requested by the user).

2. Generating control-plane component manifests, certificates and kubeconfig.

3. Adding new local etcd member.

Using join phases with kubeadm

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. Note that by calling kubeadm join 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:

kubeadm join phase kubelet-start --help

Similar to the kubeadm init phase command, kubeadm join phase allows you to skip a list of phases using the --skip-phases flag.

For example:

sudo kubeadm join --skip-phases=preflight --config=config.yaml

Alternatively, you can use the skipPhases field in JoinConfiguration.

Discovering what cluster CA to trust

The kubeadm discovery has several options, each with security tradeoffs. The right method for your environment depends on how you provision nodes and the security expectations you have about your network and node lifecycles.

Token-based discovery with CA pinning

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.

The CA key hash has the format sha256:<hex_encoded_hash>. By default, the hash value is printed at the end of the kubeadm init command or in the output from the kubeadm token create --print-join-command command. It is in a standard format (see RFC7469) and can also be calculated by 3rd party tools or provisioning systems. For example, using the OpenSSL CLI:

openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'

Example kubeadm join commands:

For worker nodes:

kubeadm join --discovery-token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:1234..cdef 1.2.3.4:6443

For control-plane nodes:

kubeadm join --discovery-token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:1234..cdef --control-plane 1.2.3.4:6443

You can also call join for a control-plane node with --certificate-key to copy certificates to this node, if the kubeadm init command was called with --upload-certs.

Advantages:

• Allows bootstrapping nodes to securely discover a root of trust for the control-plane node even if other worker nodes or the network are compromised.

• Convenient to execute manually since all of the information required fits into a single kubeadm join command.

Disadvantages:

• 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.

Token-based discovery without CA pinning

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. 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:

kubeadm join --token abcdef.1234567890abcdef --discovery-token-unsafe-skip-ca-verification 1.2.3.4:6443

Advantages:

• Still protects against many network-level attacks.

• The token can be generated ahead of time and shared with the control-plane node and worker nodes, which can then bootstrap in parallel without coordination. This allows it to be used in many provisioning scenarios.

Disadvantages:

• If an attacker is able to steal a bootstrap token via some vulnerability, they can use that token (along with network-level access) to impersonate the control-plane node to other bootstrapping nodes. This may or may not be an appropriate 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. The format of the discovery file is a regular Kubernetes kubeconfig file.

In case the discovery file does not contain credentials, the TLS discovery token will be used.

Example kubeadm join commands:

• kubeadm join --discovery-file path/to/file.conf (local file)

• kubeadm join --discovery-file https://url/file.conf (remote HTTPS URL)

Advantages:

• Allows bootstrapping nodes to securely discover a root of trust for the control-plane node even if the network or other worker nodes are compromised.

Disadvantages:

• Requires that you have some way to carry the discovery information from the control-plane node to the bootstrapping nodes. If the discovery file contains credentials you must keep it secret and transfer it over a secure channel. This might be possible with your cloud provider or provisioning tool.

Use of custom kubelet credentials with kubeadm join

To allow kubeadm join to use predefined kubelet credentials and skip client TLS bootstrap and CSR approval for a new node:

1. From a working control plane node in the cluster that has /etc/kubernetes/pki/ca.key execute kubeadm kubeconfig user --org system:nodes --client-name system:node:$NODE > kubelet.conf. $NODE must be set to the name of the new node.
2. Modify the resulted kubelet.conf manually to adjust the cluster name and the server endpoint, or run kubeadm kubeconfig user --config (it accepts InitConfiguration).

If your cluster does not have the ca.key file, you must sign the embedded certificates in the kubelet.conf externally. For additional information, see PKI certificates and requirements and Certificate Management with kubeadm.

1. Copy the resulting kubelet.conf to /etc/kubernetes/kubelet.conf on the new node.
2. Execute kubeadm join with the flag --ignore-preflight-errors=FileAvailable--etc-kubernetes-kubelet.conf on the new node.

Securing your installation even more

The defaults for kubeadm may not work for everyone. This section documents how to tighten up a kubeadm installation at the cost of some usability.

Turning off auto-approval of node client certificates

By default, there is a CSR auto-approver enabled that basically approves any client certificate request for a kubelet when a Bootstrap Token was used when authenticating. If you don't want the cluster to automatically approve kubelet client certs, you can turn it off by executing this command:

kubectl delete clusterrolebinding kubeadm:node-autoapprove-bootstrap

After that, kubeadm join will block until the admin has manually approved the CSR in flight:

1. Using kubectl get csr, you can see that the original CSR is in the Pending state.

   kubectl get csr
   

   The output is similar to this:

   NAME                                                   AGE       REQUESTOR                 CONDITION
   node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ   18s       system:bootstrap:878f07   Pending
   

2. kubectl certificate approve allows the admin to approve CSR.This action tells a certificate signing controller to issue a certificate to the requestor with the attributes requested in the CSR.

   kubectl certificate approve node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ
   

   The output is similar to this:

   certificatesigningrequest "node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ" approved
   

3. This would change the CSR resource to Active state.

   kubectl get csr
   

   The output is similar to this:

   NAME                                                   AGE       REQUESTOR                 CONDITION
   node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ   1m        system:bootstrap:878f07   Approved,Issued
   

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

In order to achieve the joining flow using the token as the only piece of validation information, a ConfigMap with some data needed for validation of the control-plane node's identity is exposed publicly by default. While there is no private data in this ConfigMap, some users might wish to turn it off regardless. Doing so will disable the ability to use the --discovery-token flag of the kubeadm join flow. Here are the steps to do so:

• Fetch the cluster-info file from the API Server:

kubectl -n kube-public get cm cluster-info -o jsonpath='{.data.kubeconfig}' | tee cluster-info.yaml

The output is similar to this:

apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority-data: <ca-cert>
    server: https://<ip>:<port>
  name: ""
contexts: []
current-context: ""
preferences: {}
users: []

• Use the cluster-info.yaml file as an argument to kubeadm join --discovery-file.

• Turn off public access to the cluster-info ConfigMap:

kubectl -n kube-public delete rolebinding kubeadm:bootstrap-signer-clusterinfo

These commands should be run after kubeadm init but before kubeadm join.

Using kubeadm join with a configuration file

It's possible to configure kubeadm join 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 using the --config flag and it must contain a JoinConfiguration structure. Mixing --config with others flags may not be allowed in some cases.

The default configuration can be printed out using the kubeadm config print command.

If your configuration is not using the latest version it is recommended that you migrate using the kubeadm config migrate command.

For more information on the fields and usage of the configuration you can navigate to our API reference.

What's next

• kubeadm init to bootstrap a Kubernetes control-plane node.
• kubeadm token to manage tokens for kubeadm join.
• kubeadm reset to revert any changes made to this host by kubeadm init or kubeadm join.

1.3 - kubeadm upgrade

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 guidance

The steps for performing an upgrade using kubeadm are outlined in this document. For older versions of kubeadm, please refer to older documentation sets of the Kubernetes website.

You can use kubeadm upgrade diff to see the changes that would be applied to static pod manifests.

In Kubernetes v1.15.0 and later, kubeadm upgrade apply and kubeadm upgrade node will also automatically renew the kubeadm managed certificates on this node, including those stored in kubeconfig files. To opt-out, it is possible to pass the flag --certificate-renewal=false. For more details about certificate renewal see the certificate management documentation.

kubeadm upgrade plan

Synopsis

Check which versions are available to upgrade to and validate whether your current cluster is upgradeable. This command can only run on the control plane nodes where the kubeconfig file "admin.conf" exists. To skip the internet check, pass in the optional [version] parameter.

kubeadm upgrade plan [version] [flags]

Options

Options inherited from parent commands

kubeadm upgrade apply

Synopsis

Upgrade your Kubernetes cluster to the specified version

The "apply [version]" command executes the following phases:

preflight        Run preflight checks before upgrade
control-plane    Upgrade the control plane
upload-config    Upload the kubeadm and kubelet configurations to ConfigMaps
  /kubeadm         Upload the kubeadm ClusterConfiguration to a ConfigMap
  /kubelet         Upload the kubelet configuration to a ConfigMap
kubelet-config   Upgrade the kubelet configuration for this node
bootstrap-token  Configures bootstrap token and cluster-info RBAC rules
addon            Upgrade the default kubeadm addons
  /coredns         Upgrade the CoreDNS addon
  /kube-proxy      Upgrade the kube-proxy addon
post-upgrade     Run post upgrade tasks

kubeadm upgrade apply [version]

Options

Options inherited from parent commands

kubeadm upgrade diff

Synopsis

Show what differences would be applied to existing static pod manifests. See also: kubeadm upgrade apply --dry-run

kubeadm upgrade diff [version] [flags]

Options

Options inherited from parent commands

kubeadm upgrade node

Synopsis

Upgrade commands for a node in the cluster

The "node" command executes the following phases:

preflight       Run upgrade node pre-flight checks
control-plane   Upgrade the control plane instance deployed on this node, if any
kubelet-config  Upgrade the kubelet configuration for this node
addon           Upgrade the default kubeadm addons
  /coredns        Upgrade the CoreDNS addon
  /kube-proxy     Upgrade the kube-proxy addon
post-upgrade    Run post upgrade tasks

kubeadm upgrade node [flags]

Options

Options inherited from parent commands

What's next

• kubeadm config if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for kubeadm upgrade

1.4 - kubeadm upgrade phases

kubeadm upgrade apply phase

Using the phases of kubeadm upgrade apply, you can choose to execute the separate steps of the initial upgrade of a control plane node.

• phase
• preflight
• control-plane
• upload-config
• kubelet-config
• bootstrap-token
• addon
• post-upgrade

kubeadm upgrade apply phase [flags]

kubeadm upgrade apply phase preflight [flags]

kubeadm upgrade apply phase control-plane [flags]

kubeadm upgrade apply phase upload-config [flags]

kubeadm upgrade apply phase kubelet-config [flags]

kubeadm upgrade apply phase bootstrap-token [flags]

kubeadm upgrade apply phase addon [flags]

kubeadm upgrade apply phase post-upgrade [flags]

kubeadm upgrade node phase

Using the phases of kubeadm upgrade node you can choose to execute the separate steps of the upgrade of secondary control-plane or worker nodes.

• phase
• preflight
• control-plane
• kubelet-config
• addon
• post-upgrade

kubeadm upgrade node phase [flags]

kubeadm upgrade node phase preflight [flags]

kubeadm upgrade node phase control-plane [flags]

kubeadm upgrade node phase kubelet-config [flags]

kubeadm upgrade node phase addon [flags]

kubeadm upgrade node phase post-upgrade [flags]

What's next

• kubeadm init to bootstrap a Kubernetes control-plane node
• kubeadm join to connect a node to the cluster
• kubeadm reset to revert any changes made to this host by kubeadm init or kubeadm join
• kubeadm upgrade to upgrade a kubeadm node
• kubeadm alpha to try experimental functionality

1.5 - kubeadm config

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.

You can use kubeadm config print to print the default static configuration that kubeadm uses for kubeadm init and kubeadm join.

For more information on init and join navigate to Using kubeadm init with a configuration file or Using kubeadm join with a configuration file.

For more information on using the kubeadm configuration API navigate to Customizing components with the kubeadm API.

You can use kubeadm config migrate to convert your old configuration files that contain a deprecated API version to a newer, supported API version.

kubeadm config validate can be used for validating a configuration file.

kubeadm config images list and kubeadm config images pull can be used to list and pull the images that kubeadm requires.

kubeadm config print

Print configuration

Synopsis

This command prints configurations for subcommands provided. For details, see: https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#section-directories

kubeadm config print [flags]

Options

Options inherited from parent commands

kubeadm config print init-defaults

Print default init configuration, that can be used for 'kubeadm init'

Synopsis

This command prints objects such as the default init configuration that is used for 'kubeadm init'.

Note that sensitive values like the Bootstrap Token fields are replaced with placeholder values like "abcdef.0123456789abcdef" in order to pass validation but not perform the real computation for creating a token.

kubeadm config print init-defaults [flags]

Options

Options inherited from parent commands

kubeadm config print join-defaults

Print default join configuration, that can be used for 'kubeadm join'

Synopsis

This command prints objects such as the default join configuration that is used for 'kubeadm join'.

Note that sensitive values like the Bootstrap Token fields are replaced with placeholder values like "abcdef.0123456789abcdef" in order to pass validation but not perform the real computation for creating a token.

kubeadm config print join-defaults [flags]

Options

Options inherited from parent commands

kubeadm config migrate

Read an older version of the kubeadm configuration API types from a file, and output the similar config object for the newer version

Synopsis

This command lets you convert configuration objects of older versions to the latest supported version, locally in the CLI tool without ever touching anything in the cluster. In this version of kubeadm, the following API versions are supported:

• kubeadm.k8s.io/v1beta4

Further, kubeadm can only write out config of version "kubeadm.k8s.io/v1beta4", but read both types. So regardless of what version you pass to the --old-config parameter here, the API object will be read, deserialized, defaulted, converted, validated, and re-serialized when written to stdout or --new-config if specified.

In other words, the output of this command is what kubeadm actually would read internally if you submitted this file to "kubeadm init"

kubeadm config migrate [flags]

Options

Options inherited from parent commands

kubeadm config validate

Read a file containing the kubeadm configuration API and report any validation problems

Synopsis

This command lets you validate a kubeadm configuration API file and report any warnings and errors. If there are no errors the exit status will be zero, otherwise it will be non-zero. Any unmarshaling problems such as unknown API fields will trigger errors. Unknown API versions and fields with invalid values will also trigger errors. Any other errors or warnings may be reported depending on contents of the input file.

In this version of kubeadm, the following API versions are supported:

• kubeadm.k8s.io/v1beta4

kubeadm config validate [flags]

Options

Options inherited from parent commands

kubeadm config images list

Synopsis

Print a list of images kubeadm will use. The configuration file is used in case any images or image repositories are customized

kubeadm config images list [flags]

Options

Options inherited from parent commands

kubeadm config images pull

Synopsis

Pull images used by kubeadm

kubeadm config images pull [flags]

Options

Options inherited from parent commands

What's next

• kubeadm upgrade to upgrade a Kubernetes cluster to a newer version

1.6 - kubeadm reset

Performs a best effort revert of changes made by kubeadm init or kubeadm join.

Synopsis

Performs a best effort revert of changes made to this host by 'kubeadm init' or 'kubeadm join'

The "reset" command executes the following phases:

preflight           Run reset pre-flight checks
remove-etcd-member  Remove a local etcd member.
cleanup-node        Run cleanup node.

kubeadm reset [flags]

Options

Options inherited from parent commands

Reset workflow

kubeadm reset is responsible for cleaning up a node local file system from files that were created using the kubeadm init or kubeadm join commands. For control-plane nodes reset also removes the local stacked etcd member of this node from the etcd cluster.

kubeadm reset phase can be used to execute the separate phases of the above workflow. To skip a list of phases you can use the --skip-phases flag, which works in a similar way to the kubeadm join and kubeadm init phase runners.

kubeadm reset also supports the --config flag for passing a ResetConfiguration structure.

Cleanup of external etcd members

kubeadm reset will not delete any etcd data if external etcd is used. This means that if you run kubeadm init again using the same etcd endpoints, you will see state from previous clusters.

To wipe etcd data it is recommended you use a client like etcdctl, such as:

etcdctl del "" --prefix

See the etcd documentation for more information.

Cleanup of CNI configuration

CNI plugins use the directory /etc/cni/net.d to store their configuration. The kubeadm reset command does not cleanup that directory. Leaving the configuration of a CNI plugin on a host can be problematic if the same host is later used as a new Kubernetes node and a different CNI plugin happens to be deployed in that cluster. It can result in a configuration conflict between CNI plugins.

To cleanup the directory, backup its contents if needed and then execute the following command:

sudo rm -rf /etc/cni/net.d

Cleanup of network traffic rules

The kubeadm reset command does not clean any iptables, nftables or IPVS rules applied to the host by kube-proxy. A control loop in kube-proxy ensures that the rules on each node host are synchronized. For additional details please see Virtual IPs and Service Proxies.

Leaving the rules without cleanup should not cause any issues if the host is later reused as a Kubernetes node or if it will serve a different purpose.

If you wish to perform this cleanup, you can use the same kube-proxy container which was used in your cluster and the --cleanup flag of the kube-proxy binary:

docker run --privileged --rm registry.k8s.io/kube-proxy:v1.35.0 sh -c "kube-proxy --cleanup && echo DONE"

The output of the above command should print DONE at the end. Instead of Docker, you can use your preferred container runtime to start the container.

Cleanup of $HOME/.kube

The $HOME/.kube directory typically contains configuration files and kubectl cache. While not cleaning the contents of $HOME/.kube/cache is not an issue, there is one important file in the directory. That is $HOME/.kube/config and it is used by kubectl to authenticate to the Kubernetes API server. After kubeadm init finishes, the user is instructed to copy the /etc/kubernetes/admin.conf file to the $HOME/.kube/config location and grant the current user access to it.

The kubeadm reset command does not clean any of the contents of the $HOME/.kube directory. Leaving the $HOME/.kube/config file without deleting it, can be problematic depending on who will have access to this host after kubeadm reset was called. If the same cluster continues to exist, it is highly recommended to delete the file, as the admin credentials stored in it will continue to be valid.

To cleanup the directory, examine its contents, perform backup if needed and execute the following command:

rm -rf $HOME/.kube

Graceful kube-apiserver shutdown

If you have your kube-apiserver configured with the --shutdown-delay-duration flag, you can run the following commands to attempt a graceful shutdown for the running API server Pod, before you run kubeadm reset:

yq eval -i '.spec.containers[0].command = []' /etc/kubernetes/manifests/kube-apiserver.yaml
timeout 60 sh -c 'while pgrep kube-apiserver >/dev/null; do sleep 1; done' || true

What's next

• kubeadm init to bootstrap a Kubernetes control-plane node
• kubeadm join to bootstrap a Kubernetes worker node and join it to the cluster

1.7 - kubeadm token

Bootstrap tokens are used for establishing bidirectional trust between a node joining the cluster and a control-plane node, as described in authenticating with bootstrap tokens.

kubeadm init creates an initial token with a 24-hour TTL. The following commands allow you to manage such a token and also to create and manage new ones.

kubeadm token create

Create bootstrap tokens on the server

Synopsis

This command will create a bootstrap token for you. You can specify the usages for this token, the "time to live" and an optional human friendly description.

The [token] is the actual token to write. This should be a securely generated random token of the form "[a-z0-9]{6}.[a-z0-9]{16}". If no [token] is given, kubeadm will generate a random token instead.

kubeadm token create [token]

Options

Options inherited from parent commands

kubeadm token delete

Delete bootstrap tokens on the server

Synopsis

This command will delete a list of bootstrap tokens for you.

The [token-value] is the full Token of the form "[a-z0-9]{6}.[a-z0-9]{16}" or the Token ID of the form "[a-z0-9]{6}" to delete.

kubeadm token delete [token-value] ...

Options

Options inherited from parent commands

kubeadm token generate

Generate and print a bootstrap token, but do not create it on the server

Synopsis

This command will print out a randomly-generated bootstrap token that can be used with the "init" and "join" commands.

You don't have to use this command in order to generate a token. You can do so yourself as long as it is in the format "[a-z0-9]{6}.[a-z0-9]{16}". This command is provided for convenience to generate tokens in the given format.

You can also use "kubeadm init" without specifying a token and it will generate and print one for you.

kubeadm token generate [flags]

Options

Options inherited from parent commands

kubeadm token list

List bootstrap tokens on the server

Synopsis

This command will list all bootstrap tokens for you.

kubeadm token list [flags]

Options

Options inherited from parent commands

What's next

• kubeadm join to bootstrap a Kubernetes worker node and join it to the cluster

1.8 - kubeadm version

This command prints the version of kubeadm.

Synopsis

Print the version of kubeadm

kubeadm version [flags]

Options

Options inherited from parent commands

1.9 - kubeadm alpha

Currently there are no experimental commands under kubeadm alpha.

What's next

• kubeadm init to bootstrap a Kubernetes control-plane node
• kubeadm join to connect a node to the cluster
• kubeadm reset to revert any changes made to this host by kubeadm init or kubeadm join

1.10 - kubeadm certs

kubeadm certs provides utilities for managing certificates. For more details on how these commands can be used, see Certificate Management with kubeadm.

kubeadm certs

A collection of operations for operating Kubernetes certificates.

• overview

kubeadm certs [flags]

kubeadm certs renew

You can renew all Kubernetes certificates using the all subcommand or renew them selectively. For more details see Manual certificate renewal.

• renew
• all
• admin.conf
• apiserver-etcd-client
• apiserver-kubelet-client
• apiserver
• controller-manager.conf
• etcd-healthcheck-client
• etcd-peer
• etcd-server
• front-proxy-client
• scheduler.conf
• super-admin.conf

kubeadm certs renew [flags]

kubeadm certs renew all [flags]

kubeadm certs renew admin.conf [flags]

kubeadm certs renew apiserver-etcd-client [flags]

kubeadm certs renew apiserver-kubelet-client [flags]

kubeadm certs renew apiserver [flags]

kubeadm certs renew controller-manager.conf [flags]

kubeadm certs renew etcd-healthcheck-client [flags]

kubeadm certs renew etcd-peer [flags]

kubeadm certs renew etcd-server [flags]

kubeadm certs renew front-proxy-client [flags]

kubeadm certs renew scheduler.conf [flags]

kubeadm certs renew super-admin.conf [flags]

kubeadm certs certificate-key

This command can be used to generate a new control-plane certificate key. The key can be passed as --certificate-key to kubeadm init and kubeadm join to enable the automatic copy of certificates when joining additional control-plane nodes.

• certificate-key

kubeadm certs certificate-key [flags]

kubeadm certs check-expiration

This command checks expiration for the certificates in the local PKI managed by kubeadm. For more details see Check certificate expiration.

• check-expiration

kubeadm certs check-expiration [flags]

kubeadm certs generate-csr

This command can be used to generate keys and CSRs for all control-plane certificates and kubeconfig files. The user can then sign the CSRs with a CA of their choice. To read more information on how to use the command see Signing certificate signing requests (CSR) generated by kubeadm.

• generate-csr

kubeadm certs generate-csr [flags]

  # The following command will generate keys and CSRs for all control-plane certificates and kubeconfig files:
  kubeadm certs generate-csr --kubeconfig-dir /tmp/etc-k8s --cert-dir /tmp/etc-k8s/pki

What's next

• kubeadm init to bootstrap a Kubernetes control-plane node
• kubeadm join to connect a node to the cluster
• kubeadm reset to revert any changes made to this host by kubeadm init or kubeadm join

1.11 - kubeadm init phase

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, and behind the scene both use the same code.

kubeadm init phase preflight

Using this command you can execute preflight checks on a control-plane node.

• preflight

kubeadm init phase preflight [flags]

  # Run pre-flight checks for kubeadm init using a config file.
  kubeadm init phase preflight --config kubeadm-config.yaml

kubeadm init phase kubelet-start

This phase will write the kubelet configuration file and environment file and then start the kubelet.

• kubelet-start

kubeadm init phase kubelet-start [flags]

  # Writes a dynamic environment file with kubelet flags from a InitConfiguration file.
  kubeadm init phase kubelet-start --config config.yaml

kubeadm init phase certs

Can be used to create all required certificates by kubeadm.

• certs
• all
• ca
• apiserver
• apiserver-kubelet-client
• front-proxy-ca
• front-proxy-client
• etcd-ca
• etcd-server
• etcd-peer
• healthcheck-client
• apiserver-etcd-client
• sa

kubeadm init phase certs [flags]

kubeadm init phase certs all [flags]

kubeadm init phase certs ca [flags]

kubeadm init phase certs apiserver [flags]

kubeadm init phase certs apiserver-kubelet-client [flags]

kubeadm init phase certs front-proxy-ca [flags]

kubeadm init phase certs front-proxy-client [flags]

kubeadm init phase certs etcd-ca [flags]

kubeadm init phase certs etcd-server [flags]

kubeadm init phase certs etcd-peer [flags]

kubeadm init phase certs etcd-healthcheck-client [flags]

kubeadm init phase certs apiserver-etcd-client [flags]

kubeadm init phase certs sa [flags]

kubeadm init phase kubeconfig

You can create all required kubeconfig files by calling the all subcommand or call them individually.

• kubeconfig
• all
• admin
• kubelet
• controller-manager
• scheduler
• super-admin

kubeadm init phase kubeconfig [flags]

kubeadm init phase kubeconfig all [flags]

kubeadm init phase kubeconfig admin [flags]

kubeadm init phase kubeconfig kubelet [flags]

kubeadm init phase kubeconfig controller-manager [flags]

kubeadm init phase kubeconfig scheduler [flags]

kubeadm init phase kubeconfig super-admin [flags]

kubeadm init phase control-plane

Using this phase you can create all required static Pod files for the control plane components.

• control-plane
• all
• apiserver
• controller-manager
• scheduler

kubeadm init phase control-plane [flags]

kubeadm init phase control-plane all [flags]

  # Generates all static Pod manifest files for control plane components,
  # functionally equivalent to what is generated by kubeadm init.
  kubeadm init phase control-plane all
  
  # Generates all static Pod manifest files using options read from a configuration file.
  kubeadm init phase control-plane all --config config.yaml

kubeadm init phase control-plane apiserver [flags]

kubeadm init phase control-plane controller-manager [flags]

kubeadm init phase control-plane scheduler [flags]

kubeadm init phase etcd

Use the following phase to create a local etcd instance based on a static Pod file.

• etcd
• local

kubeadm init phase etcd [flags]

kubeadm init phase etcd local [flags]

  # Generates the static Pod manifest file for etcd, functionally
  # equivalent to what is generated by kubeadm init.
  kubeadm init phase etcd local
  
  # Generates the static Pod manifest file for etcd using options
  # read from a configuration file.
  kubeadm init phase etcd local --config config.yaml

kubeadm init phase upload-config

You can use this command to upload the kubeadm configuration to your cluster. Alternatively, you can use kubeadm config.

• upload-config
• all
• kubeadm
• kubelet

kubeadm init phase upload-config [flags]

kubeadm init phase upload-config all [flags]

kubeadm init phase upload-config kubeadm [flags]

  # upload the configuration of your cluster
  kubeadm init phase upload-config kubeadm --config=myConfig.yaml

kubeadm init phase upload-config kubelet [flags]

  # Upload the kubelet configuration from the kubeadm Config file to a ConfigMap in the cluster.
  kubeadm init phase upload-config kubelet --config kubeadm.yaml

kubeadm init phase upload-certs

Use the following phase to upload control-plane certificates to the cluster. By default the certs and encryption key expire after two hours.

• upload-certs

kubeadm init phase upload-certs [flags]

kubeadm init phase mark-control-plane

Use the following phase to label and taint the node as a control plane node.

• mark-control-plane

kubeadm init phase mark-control-plane [flags]

  # Applies control-plane label and taint to the current node, functionally equivalent to what executed by kubeadm init.
  kubeadm init phase mark-control-plane --config config.yaml
  
  # Applies control-plane label and taint to a specific node
  kubeadm init phase mark-control-plane --node-name myNode

kubeadm init phase bootstrap-token

Use the following phase to configure bootstrap tokens.

• bootstrap-token

kubeadm init phase bootstrap-token [flags]

  # Make all the bootstrap token configurations and create an initial token, functionally
  # equivalent to what generated by kubeadm init.
  kubeadm init phase bootstrap-token

kubeadm init phase kubelet-finalize

Use the following phase to update settings relevant to the kubelet after TLS bootstrap. You can use the all subcommand to run all kubelet-finalize phases.

• kubelet-finalize
• kubelet-finalize-all
• kubelet-finalize-enable-client-cert-rotation

kubeadm init phase kubelet-finalize [flags]

  # Updates settings relevant to the kubelet after TLS bootstrap"
  kubeadm init phase kubelet-finalize all --config

kubeadm init phase kubelet-finalize all [flags]

  # Updates settings relevant to the kubelet after TLS bootstrap"
  kubeadm init phase kubelet-finalize all --config

kubeadm init phase kubelet-finalize enable-client-cert-rotation [flags]

kubeadm init phase addon

You can install all the available addons with the all subcommand, or install them selectively.

• addon
• all
• coredns
• kube-proxy

kubeadm init phase addon [flags]

kubeadm init phase addon all [flags]

kubeadm init phase addon coredns [flags]

kubeadm init phase addon kube-proxy [flags]

For more details on each field in the v1beta4 configuration you can navigate to our API reference pages.

What's next

• kubeadm init to bootstrap a Kubernetes control-plane node
• kubeadm join to connect a node to the cluster
• kubeadm reset to revert any changes made to this host by kubeadm init or kubeadm join
• kubeadm alpha to try experimental functionality

1.12 - kubeadm join phase

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, and behind the scene both use the same code.

kubeadm join phase

• phase

kubeadm join phase [flags]

kubeadm join phase preflight

Using this phase you can execute preflight checks on a joining node.

• preflight

kubeadm join phase preflight [api-server-endpoint] [flags]

  # Run join pre-flight checks using a config file.
  kubeadm join phase preflight --config kubeadm-config.yaml

kubeadm join phase control-plane-prepare

Using this phase you can prepare a node for serving a control-plane.

• control-plane-prepare
• all
• download-certs
• certs
• kubeconfig
• control-plane

kubeadm join phase control-plane-prepare [flags]

  # Prepares the machine for serving a control plane
  kubeadm join phase control-plane-prepare all

kubeadm join phase control-plane-prepare all [api-server-endpoint] [flags]

kubeadm join phase control-plane-prepare download-certs [api-server-endpoint] [flags]

kubeadm join phase control-plane-prepare certs [api-server-endpoint] [flags]

kubeadm join phase control-plane-prepare kubeconfig [api-server-endpoint] [flags]

kubeadm join phase control-plane-prepare control-plane [flags]

kubeadm join phase kubelet-start

Using this phase you can write the kubelet settings, certificates and (re)start the kubelet.

• kubelet-start

kubeadm join phase kubelet-start [api-server-endpoint] [flags]

kubeadm join phase control-plane-join

Using this phase you can join a node as a control-plane instance.

• control-plane-join
• all
• etcd
• mark-control-plane

kubeadm join phase control-plane-join [flags]

  # Joins a machine as a control plane instance
  kubeadm join phase control-plane-join all

kubeadm join phase control-plane-join all [flags]

kubeadm join phase control-plane-join etcd [flags]

kubeadm join phase control-plane-join mark-control-plane [flags]

What's next

• kubeadm init to bootstrap a Kubernetes control-plane node
• kubeadm join to connect a node to the cluster
• kubeadm reset to revert any changes made to this host by kubeadm init or kubeadm join
• kubeadm alpha to try experimental functionality

1.13 - kubeadm kubeconfig

kubeadm kubeconfig provides utilities for managing kubeconfig files.

For examples on how to use kubeadm kubeconfig user see Generating kubeconfig files for additional users.

kubeadm kubeconfig

• overview

kubeadm kubeconfig user

This command can be used to output a kubeconfig file for an additional user.

• user

kubeadm kubeconfig user [flags]

  # Output a kubeconfig file for an additional user named foo
  kubeadm kubeconfig user --client-name=foo
  
  # Output a kubeconfig file for an additional user named foo using a kubeadm config file bar
  kubeadm kubeconfig user --client-name=foo --config=bar