text: This document provides information on how to use kubeadm’s advanced options.
  kubeadm init
  kubeadm join
  kubeadm completion
  kubeadm config
  kubeadm reset
  kubeadm token
  kubeadm alpha phases
  Running
  kubeadm init bootstraps a Kubernetes master node. via
  --token, as described in the
  section on managing tokens below.
  (
  /etc/kubernetes/pki by default) this step is skipped as described in the
  section on using custom certificates.
  kubeadm writes kubeconfig files in
  /etc/kubernetes/ for
  the kubelet, the controller-manager and the scheduler to use to connect to the
  API server, each one with their respective identities, as well as an additional
  kubeconfig file for administration.
  kubeadm 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 will be generated for etcd.
  Static Pod manifests are written in
  /etc/kubernetes/manifests; the kubelet
  watches this directory for Pods to create on startup, as described in
  the section about kubelet drop-in.
  Once control plane Pods are up and running kubeadm init sequence can continue.
  kubeadm “labels” and “taints” the master node so that only control plane components will run there.
  kubeadm 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.
  Ensure access to the CSR signing API for bootstrap tokens.
  Configure auto approval for new CSR requests.
  See Securing your installation for hardening.
  kubeadm installs add-on components via the API server. Right now this is the internal DNS server and the kube-proxy DaemonSet.
  If
  kubeadm init is invoked with the alpha self-hosting feature enabled,
  (
  --feature-gates=SelfHosting=true), the static Pod based control plane will
  be transformed into a self-hosted control plane.
  Running
  kubeadm join on each node in the cluster.
  Once the cluster information are known, kubelet can start the TLS bootstrapping process (in v.1.7 this step was managed by kubeadm).
  The TLS bootstrap uses the shared token to temporarily authenticate with the Kubernetes Master to submit a certificate signing request (CSR); by default the control plane will sign this CSR request automatically.
  Finally, kubeadm will configure the local kubelet to connect to the API server with the definitive identity assigned to the node..
  Exceptions to this are documented below..
  Options for
  kubeadm init:
  -: Since 1.8, other flags are not allowed alongside
  --config except
  for flags used to define kubeadm behaviour (not configuration) such as
  --skip-preflight-checks.
  --dry-run
  This flag tells kubeadm to don’t apply any changes; just output what would be done.
  --feature-gates
  A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:
  See self-hosted control plane for more detail.
  -.
  --node-name
  Allow to specify the node name, if something different than O.S. hostname should be used e.g. in case of Amazon EC2 instances.
  The node-name is also added to the certificate that the API Server uses.
  - services.
  By default, kubeadm prints the token at the end of the init procedure.. The default is 24 hours. two main schemes for discovery:
  Using a shared token along with the IP address of the API server and a hash of the root CA key:
  kubeadm join --discovery-token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:1234..cdef 1.2.3.4:6443
  Using a file (a subset of the standard kubeconfig file). This file can be a local file or downloaded via an HTTPS URL:
  kubeadm join --discovery-file path/to/file.conf
  kubeadm join --discovery-file
  Only one form can be used. If the discovery information is loaded from a URL, HTTPS must be used and the host installed CA bundle is used to verify the connection. For details on the security tradeoffs of these mechanisms, see the security model section below. --discovery-token-ca-cert-hash sha256:1234..cdef 192.168.1.1:6443
  Options for
  kubeadm join:
  --config
  Extended options are specified in the kubeadm specific config file.
  -.
  --discovery-token-ca-cert-hash
  The CA key hash is used to verify the full root CA certificate discovered during
  token-based bootstrapping. It has the format
  sha256:<hex_encoded_hash>. By
  default, the hash value is returned in the
  kubeadm join command printed at the
  end of
  kubeadm init./^.* //'
  Skipping this flag is allowed in Kubernetes 1.8, but makes certain spoofing
  attacks possible. See the security model for details.
  Pass
  --discovery-token-unsafe-skip-ca-verification to silence warnings (which
  will become errors in Kubernetes 1.9).
  --discovery-token-unsafe-skip-ca-verification
  Disable the warning/error that occurs when
  --discovery-token-ca-cert-hash is
  not provided. Passing this flag is an acknowledgement of the
  security tradeoffs involved in skipping this verification
  (which may or may not be appropriate in your environment).
  --node-name
  Specify the Node name. The default is to use the OS hostname. This is useful on some cloud providers such as AWS. This name is also added to the node’s TLS certificate.
  -.
  --skip-preflight-checks
  By default, kubeadm runs a series of preflight checks to validate the system before making any changes. Advanced users can use this flag to bypass these if necessary.
  kubeadm completion
  Output shell completion code for the specified shell (bash or zsh).
  kubeadm config
  Kubeadm v1.8.0+ automatically creates a ConfigMap with all the parameters
  used during
  kubeadm init.
  If you initialized your cluster using kubeadm v1.7.x or lower, you must use
  the
  kubeadm config upload command to create this ConfigMap in order
  for
  kubeadm upgrade to be able to configure your upgraded cluster correctly.
  kubeadm reset
  Reverts any changes made to this host by
  kubeadm init or
  kubeadm join.
  kubeadm token
  Manage tokens on a running cluster. See managing tokens below for further details.
  kubeadm alpha phases
  WARNING: While kubeadm command line interface is in beta, commands under this entry is still considered alpha and may change in future versions.
  kubeadm phase introduces a set of kubeadm CLI commands allowing to invoke
  individually each phase of the kubeadm init sequence; phases provide a reusable
  and composable API/toolbox for building your own automated cluster installer.
  Options for
  kubeadm phases:
  Each kubeadm phase exposes a subset of relevant options from
  kubeadm init.> dataDir: <path|string> extraArgs: <argument>: <value|string> <argument>: <value|string> image: <string> networking: dnsDomain: <string> serviceSubnet: <cidr> podSubnet: <cidr> kubernetesVersion: <string> cloudProvider: <string> nodeName: > imageRepository: <string> unifiedControlPlaneImage: <string> featureGates: <feature>: <bool> <feature>: <bool>> nodeName: <string> tlsBootstrapToken: <string> token: <string> discoveryTokenCACertHashes: - <SHA-256 hash|string> - <SHA-256 hash|string> discoveryTokenUnsafeSkipCAVerification: <bool>
  The defaults for kubeadm may not work for everyone. This section documents how to tighten up a kubeadm install off public access to the
  cluster-info ConfigMap:
  $ kubectl -n kube-public delete rolebinding kubeadm:bootstrap-signer-clusterinfo
  These commands - List tokens (along with their expirations, usages, and groups).
  kubeadm token create - Create a new token.
  --description <description>
  Set the human-readable description for the new token.
  --ttl <duration>
  Set the expiration time-to-live of the token relative to the current time.
  Default is 24 hours. A value of 0 means “never expire”. The default unit
  of the duration is seconds but other units can be specified (e.g.,
  15m,
  1h).
  --usages <usage>[,<usage>...]
  Set the ways that the token can be used. The default is
  --groups <group>[,<group>...]
  Add extra bootstrap groups that the new token will authenticate as. Can be
  specified multiple times. Each extra group must start with
  system:bootstrappers:. This is an advanced feature meant for custom
  bootstrap scenarios where you want to change how CSR approval works for
  different groups of nodes.
  kubeadm token delete <token id>|<token id>.<token secret> - Delete a token.
  The token can either be identified with just an ID or with the entire token value. Only the ID is used; the token is still deleted if the secret does not match.
  kubeadm token generate - Generate a token locally.
  Locally generate a token but do not create it on the server. security model.
  The kubeadm discovery system 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.
  This is the default mode in Kubernetes 1.8. 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. --discovery:
  Requires that you have some way to carry the discovery information from the master to the bootstrapping nodes. This might be possible, for example, via your cloud provider or provisioning tool. The information in this file is not secret, but HTTPS or equivalent is required to ensure its integrity.
  Less convenient to use manually since the file is difficult to copy and paste between nodes.
  Since Kubernetes 1.6 release,
  Kubernetes container runtimes have been transferred to using CRI by default.
  Currently, the built-in container runtime is Docker which is enabled by built.
  By default, kubeadm will pull images from
  gcr.io/google_containers, unless
  requested kubernetes version is a ci version; in this case
  gcr.io/kubernetes-ci-image will be used.
  This behaviour can be overridden by using kubeadm with a configuration file.
  Allowed customization are:
  - provide an alternative
  imageRepository to be used instead of
  gcr.io/google_containers (NB. does not works for ci version)
  - provide an
  unifiedControlPlaneImage to be used instead of single image
  for control plane components
  - provide an
  etcd.image name to be used loop provider.
  Note: These environment variables are deprecated and will stop functioning in v1.8!
  There are some environment variables that modify the way that kubeadm works. Most users will have no need to set these. These environment variables are a short-term solution, eventually they will be integrated in the kubeadm configuration file..
  Only for the CA, it is possible to provide the
  ca.crt file but not the
  ca.key
  file; if all other certificates and kubeconfig files already are in place kubeadm
  recognise this condition and activates the so called “ExternalCA” mode, which also
  implies the csrsignercontroller in controller-manager won’t be started.
  As of 1.8, kubeadm.
  Self-hosting is alpha in kubeadm 1.8 but is expected to become the default in
  a future version. To create a self-hosted cluster, pass the
  --feature-gates=SelfHosting=true
  flag to
  kubeadm init.
  Kubeadm self-hosting in 1.8 has some important limitations. In particular, a self-hosted cluster cannot currently 1.8, the self-hosted portion of the control plane does not include etcd, which still runs as a static pod.
  The self-hosting bootstrap process is documented in the kubeadm 1.8 design
  document.
  In summary,
  kubeadm init --feature-gates=SelfHosting=true works as follows:
  As usual, kubeadm creates static pod YAML files in
  /etc/kubernetes/manifests/.
  Kubelet loads these files and launches the initial static control plane.
  Kubeadm waits for this initial static control plane to be running and
  healthy. This is identical to the
  kubeadm init process without self-hosting.
  Kubeadm uses the static control plane pod manifests to construct a set of DaemonSet manifests that will run the self-hosted control plane.
  Kubeadm creates DaemonSets in the
  kube-system namespace and waits for the
  resulting pods to be running.
  Once the new control plane is running (but not yet active), kubeadm deletes the static pod YAML files. This triggers kubelet to stop those static pods.
  When the original static control plane stops, the new self-hosted control plane is able to bind to listening ports and become active.
  This process (steps 3-6) can also be triggered with
  kubeadm phase selfhosting convert-from-staticpods.