이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Chapter 4. Upgrading from Previous Versions


The following sections describe how to upgrade from previous major or minor versions to the most current supported version of OpenShift Enterprise using the ose-upgrade tool. If you are deploying OpenShift Enterprise for the first time, see Section 6.3, “Using the Sample Deployment Steps” for installation instructions. If you are attempting to apply the latest errata within a minor release of OpenShift Enterprise 2 (for example, updating from release 2.1.6 to 2.1.8), see Chapter 15, Asynchronous Errata Updates for specific update instructions.
Upgrades across major or minor versions must be taken one upgrade at a time. For example, to upgrade from 2.0 to 2.2, you must first use the ose-upgrade tool to upgrade from 2.0 to 2.1, then use the tool again to upgrade from 2.1 to 2.2.
These upgrade processes require outages:
  • Broker services are disabled during the upgrade.
  • Applications are unavailable during certain steps of the upgrade. During the outage, users can still access their gears using SSH, but should be advised against performing any Git pushes. See the section on your relevant upgrade path for more specific outage information.
  • Although it may not be necessary, Red Hat recommends rebooting all hosts after an upgrade. Due to the scheduled outage, this is a good time to apply any kernel updates that are included.
The updated OpenShift Enterprise packages are distributed in new channel repositories on Red Hat Network so that the upgrade process occurs in a prescribed order, and to avoid accidental upgrades with a yum update command.

4.1. Upgrade Tool

The upgrade process is managed as a series of steps that vary depending on the type of host, and is guided by the ose-upgrade tool.
  • Each step typically consists of one or more scripts to be executed and varies depending on the type of host.
  • Upgrade steps and scripts must be executed in a given order, and are tracked by the ose-upgrade tool. The upgrade tool tracks all steps that have been executed and those that have failed. The next step or script is not executed when a previous one has failed.
  • Failed steps can be reattempted after the issues are resolved. Note that only scripts that previously failed are executed again, so ensure you are aware of the impact and that the issue has been resolved correctly. If necessary, use the --skip option to mark a step complete and proceed to the next step. However, only do this when absolutely required.
  • The ose-upgrade tool log file is stored at /var/log/openshift/upgrade.log for review if required.
At any time, use the ose-upgrade status command to list the known steps and view the next step that must be performed. Performing all the steps without pausing with the ose-upgrade all command is only recommended for node hosts. For broker hosts, Red Hat recommends that you pause after each step to better understand the process, and understand the next step to be performed.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat