NAME¶

oc adm upgrade - Upgrade a cluster or adjust the upgrade channel

SYNOPSIS¶

oc adm upgrade [OPTIONS]

DESCRIPTION¶

Check on upgrade status or upgrade the cluster to a newer version

This command assists with cluster upgrades. If no arguments are passed the command will retrieve the current version info and display whether an upgrade is in progress or whether any errors might prevent an upgrade, as well as show the suggested updates available to the cluster. Information about compatible updates is periodically retrieved from the update server and cached on the cluster - these are updates that are known to be supported as upgrades from the current version.

Passing --to=VERSION or --to-image=IMAGE will upgrade the cluster to one of the available updates or report an error if no such version exists. The cluster will then upgrade itself and report status that is available via "oc get clusterversion" and "oc describe clusterversion".

Passing --to-multi-arch will upgrade the cluster from a single-architecture to a multi-architecture cluster at the current version.

If there are no versions available, or a bug in the cluster version operator prevents updates from being retrieved, --to-image may be combined with the more powerful and dangerous --allow-explicit-upgrade. This instructs the cluster to upgrade to the contents of the specified release image, regardless of whether that upgrade is known to be recommended for the current version. While rolling back to a previous patch (z stream) version (4.1.2 -> 4.1.1) may be safe, upgrading more than one minor version ahead (4.1 -> 4.3) or downgrading one minor version (4.2 -> 4.1) is likely to cause data corruption or to completely break a cluster.

There are two layers of upgrade guards: client-side and cluster-side.

Client-side guards include checks for whether the cluster is already being upgraded, or if the cluster is reporting a failure. It is usually best to give these conditions time to resolve, or to actively work to resolve them. But if you decide to trigger the update regardless of these concerns, use --allow-upgrade-with-warnings.

Cluster-side guards include checks for release verification and upgradeable conditions. Again, it is usually best to give these conditions time to resolve, or to actively work to resolve them. But if you decide to trigger the update regardless of these concerns, use --force, which is passed through to ClusterVersion's spec.desiredUpdate.force.

OPTIONS¶

--allow-explicit-upgrade=false
Upgrade even if the upgrade target is not listed in the available versions list.

--allow-not-recommended=false
Allows upgrade to a version when it is supported but not recommended for updates.

--allow-upgrade-with-warnings=false
Upgrade regardless of client-side guard failures, such as upgrades in progress or failing clusters.

--clear=false
If an upgrade has been requested but not yet downloaded, cancel the update. This has no effect once the update has started.

--force=false
Upgrade regardless of cluster-side guard failures, such as release verification or upgradeable conditions.

--include-not-recommended=false
Display additional updates which are not recommended based on your cluster configuration.

--to=""
Specify the version to upgrade to. The version must be on the list of available updates.

--to-image=""
Provide a release image to upgrade to.

--to-latest=false
Use the next available version.

--to-multi-arch=false
Upgrade current version to multi architecture.

OPTIONS INHERITED FROM PARENT COMMANDS¶

--as=""
Username to impersonate for the operation. User could be a regular user or a service account in a namespace.

--as-group=[]
Group to impersonate for the operation, this flag can be repeated to specify multiple groups.

--as-uid=""
UID to impersonate for the operation.

--cache-dir="/home/abuild/.kube/cache"
Default cache directory

--certificate-authority=""
Path to a cert file for the certificate authority

--client-certificate=""
Path to a client certificate file for TLS

--client-key=""
Path to a client key file for TLS

--cluster=""
The name of the kubeconfig cluster to use

--context=""
The name of the kubeconfig context to use

--disable-compression=false
If true, opt-out of response compression for all requests to the server

--insecure-skip-tls-verify=false
If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure

--kubeconfig=""
Path to the kubeconfig file to use for CLI requests.

--match-server-version=false
Require server version to match client version

-n, --namespace=""
If present, the namespace scope for this CLI request

--profile="none"
Name of profile to capture. One of (none|cpu|heap|goroutine|threadcreate|block|mutex)

--profile-output="profile.pprof"
Name of the file to write the profile to

--request-timeout="0"
The length of time to wait before giving up on a single server request. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A value of zero means don't timeout requests.

-s, --server=""
The address and port of the Kubernetes API server

--tls-server-name=""
Server name to use for server certificate validation. If it is not provided, the hostname used to contact the server is used

--token=""
Bearer token for authentication to the API server

--user=""
The name of the kubeconfig user to use

--warnings-as-errors=false
Treat warnings received from the server as errors and exit with a non-zero exit code

EXAMPLE¶

  # View the update status and available cluster updates


  oc adm upgrade


  


  # Update to the latest version


  oc adm upgrade --to-latest=true

SEE ALSO¶

oc-adm(1), oc-adm-upgrade-channel(1),

HISTORY¶

June 2016, Ported from the Kubernetes man-doc generator