table of contents
OC ADM(1) | June 2016 | OC ADM(1) |
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¶
HISTORY¶
June 2016, Ported from the Kubernetes man-doc generator
Openshift CLI User Manuals | Openshift |