kubeadm upgrade phase

In v1.15.0, kubeadm introduced preliminary support for kubeadm upgrade node phases. Phases for other kubeadm upgrade sub-commands such as apply, could be added in the following releases.

kubeadm upgrade node phase

Using this phase you can choose to execute the separate steps of the upgrade of secondary control-plane or worker nodes. Please note that kubeadm upgrade apply still has to be called on a primary control-plane node.

Synopsis

Use this command to invoke single phase of the node workflow

Options

-h, —help
help for phase

Options inherited from parent commands

—rootfs string
[EXPERIMENTAL] The path to the ‘real’ host root filesystem.

Synopsis

Run pre-flight checks for kubeadm upgrade node.

  1. kubeadm upgrade node phase preflight [flags]

Options

-h, —help
help for preflight
—ignore-preflight-errors stringSlice
A list of checks whose errors will be shown as warnings. Example: ‘IsPrivilegedUser,Swap’. Value ‘all’ ignores errors from all checks.

Options inherited from parent commands

—rootfs string
[EXPERIMENTAL] The path to the ‘real’ host root filesystem.

Synopsis

Upgrade the control plane instance deployed on this node, if any

  1. kubeadm upgrade node phase control-plane [flags]

Options

—certificate-renewal     Default: true
Perform the renewal of certificates used by component changed during upgrades.
—dry-run
Do not change any state, just output the actions that would be performed.
—etcd-upgrade     Default: true
Perform the upgrade of etcd.
—experimental-patches string
Path to a directory that contains files named “target[suffix][+patchtype].extension”. For example, “kube-apiserver0+merge.yaml” or just “etcd.json”. “patchtype” can be one of “strategic”, “merge” or “json” and they match the patch formats supported by kubectl. The default “patchtype” is “strategic”. “extension” must be either “json” or “yaml”. “suffix” is an optional string that can be used to determine which patches are applied first alpha-numerically.
-h, —help
help for control-plane
—kubeconfig string     Default: “/etc/kubernetes/admin.conf”
The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

Options inherited from parent commands

—rootfs string
[EXPERIMENTAL] The path to the ‘real’ host root filesystem.

Synopsis

Download the kubelet configuration from a ConfigMap of the form “kubelet-config-1.X” in the cluster, where X is the minor version of the kubelet. kubeadm uses the KuberneteVersion field in the kubeadm-config ConfigMap to determine what the desired kubelet version is.

  1. kubeadm upgrade node phase kubelet-config [flags]

Options

—dry-run
Do not change any state, just output the actions that would be performed.
-h, —help
help for kubelet-config
—kubeconfig string     Default: “/etc/kubernetes/admin.conf”
The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

Options inherited from parent commands

—rootfs string
[EXPERIMENTAL] The path to the ‘real’ host root filesystem.

What’s next