9장. 서버리스 업그레이드
OpenShift Serverless는 릴리스 버전을 건너뛰지 않고 업그레이드해야 합니다. 이 섹션에서는 업그레이드 관련 문제를 해결하는 방법을 설명합니다.
9.1. Serverless Operator 유지 관리 릴리스 업그레이드
9.1.1. 최신 및 유지 관리 릴리스
OpenShift Serverless 1.29부터는 다음과 같이 다양한 제품 버전을 사용할 수 있습니다.
-
최신 릴리스는
stable채널을 통해 제공됩니다. 유지 관리 릴리스는 버전 기반 채널(예:
stable-1.29)을 통해 사용할 수 있습니다.참고유지 관리 릴리스는 최신 릴리스 이전 릴리스입니다. 예를 들어
stable채널에 버전 1.30이 포함된 경우stable-1.29채널에서 유지 관리 릴리스를 사용할 수 있습니다.
버전 기반 채널을 사용하면 특정 x.y 스트림 내에 있을 수 있습니다. 또한 제품의 최신 버전으로 업그레이드할 수 없으므로 변경 사항이 손상될 수 있습니다.
유지 관리 릴리스로 전환하려면 서브스크립션 오브젝트 YAML 파일의 channel 매개변수를 stable 에서 stable-1.29 와 같은 해당 버전 기반 채널로 업데이트합니다.
9.1.2. 유지 관리 릴리스를 위한 패치 및 핫픽스
안정적인 릴리스와 마찬가지로 유지 관리 릴리스에는 패치 및 핫픽스가 적용되어 중요한 버그 및 보안 수정 사항으로 배포를 최신 상태로 유지할 수 있습니다.
- 패치는 z-release로 배포되는 업데이트입니다(예: OpenShift Serverless 1.29.1은 버전 1.29.0 이후의 업데이트를 제공하는 패치입니다.
핫픽스는 다운타임이 필요하지 않고 프로덕션 환경에서 직접 사용되는 수정 프로그램입니다. 이는 최신 릴리스 버전이 아닌 고객의 배포된 버전을 업그레이드한다는 점에서 일반적인 업데이트와 다릅니다.
모든 고객이 즉시 핫픽스를 사용할 수 없습니다. 그러나 핫픽스에서 도입한 변경 사항은 향후 릴리스의 일부로 모든 고객이 사용할 수 있습니다.
배포와 관련된 핫픽스를 사용할 수 있는 경우 핫픽스 CatalogSource를 통해 서브스크립션을 업데이트하고 핫픽스를 받을 수 있습니다.
새로운 Operator 릴리스를 사용할 수 있게 되면 핫픽스가 포함된 배포된 Operator도 업그레이드할 수 있습니다. 최신 GA 버전을 사용하려면 핫픽스 대신 공개 CatalogSource를 사용하도록 서브스크립션을 수정합니다.
다음 다이어그램은 패치 및 핫픽스가 작동하는 방법을 보여줍니다.
stable stable-1.28 +--------------+ +--------------------------------------------+ | | | | | +--------+ | corresponds to | +--------+ +--------+ +--------+ | | | 1.28.0 |----------------------> | 1.28.0 | | 1.28.1 | | 1.28.2 | | | +--------+ | | +--------+ +--------+ +--------+ | | | | | ^ | | | | +-----|-------------------|------------|-----+ | +--------+ | created| |upgrades | | | 1.28.1 | | from | hotfix_xyz |to | | +--------+ | | +------------+ | | | | +-->| |--+ | | | | | | | +--------+ | upgrades to +------------+ | | | 1.29.0 |<----------------------------------------------------------+ | +--------+ | | | | | | +--------+ | | | 1.30.0 | | | +--------+ | | | +--------------+
9.1.3. 유지 관리 릴리스의 업그레이드 경로
버전 기반 채널을 사용하는 경우 언제든지 채널의 최신 버전으로 업그레이드하거나 헤드로 업그레이드할 수 있습니다. 예를 들어 stable-1.29 채널에서 1.29.0에서 1.29.2로 업그레이드할 수 있습니다.
또한 채널 헤드에서 다음 x.y 릴리스로 업그레이드할 수 있습니다. 예를 들어 1.29.2가 stable-1.29 채널의 헤드인 경우 1.29.2에서 1.30으로 업그레이드할 수 있습니다. 이러한 채널 간 업데이트는 자동으로 수행되지 않으며 관리자는 서브스크립션을 업데이트하여 채널을 수동으로 전환해야 합니다.
9.1.4. 업그레이드 예
9.1.4.1. 시나리오 1
이 시나리오에서는 다음과 같은 상황이 적용됩니다.
-
채널은
stable-1.28 -
stable채널로 전환 - 현재 설치된 버전은 1.28.0입니다.
- 1.29.0이 1.28.1 이전에 릴리스되었습니다.
-
1.30.0은
stable채널의 헤드입니다.
이 시나리오에서 의 1.28.0에서 1.29.0으로의 업그레이드 경로는 1.28.0 ~ 1.29.0입니다.
stable -1.28
stable stable-1.28 +--------------+ +--------------+ | | | | | +--------+ | | +--------+ | | | 1.28.0 | | | | 1.28.0 | | | +--------+ | | +--------+ | | | | | | | | | | | | +--------+ | | | | | | 1.29.0 |<-------- | v | | +--------+ | | | +--------+ | | | +---------| 1.28.1 | | | | | +--------+ | | +--------+ | | | | | 1.30.0 | | | | | +--------+ | | | | | | | +--------------+ +--------------+
9.1.4.2. 시나리오 2
이 시나리오에서는 다음과 같은 상황이 적용됩니다.
-
채널은
stable-1.29입니다. - 현재 설치된 버전은 1.29.0입니다.
-
1.29.1이
1.30.0이전의stable-1.29stable채널 모두에 릴리스되었습니다.
이 시나리오에서 에서 1.30.0으로 1.29.0에서 1.30.0으로의 업그레이드 경로는 1.29.0에서 1.29.1에서 1.30.0으로입니다.
stable -1.29
stable stable-1.29 +--------------+ +--------------+ | | | | | +--------+ | | +--------+ | | | 1.29.0 | | | | 1.29.0 | | | +--------+ | | +--------+ | | | | | | | | | v | | +--------+ | | +--------+ | | | 1.29.1 | | | | 1.29.1 | | | +--------+ | | +--------+ | | | | | | | | | | | | +--------+ | | | | | | 1.30.0 |<---------------------+ | | +--------+ | | | | | | | +--------------+ +--------------+
9.1.4.3. 시나리오 3
이 시나리오에서는 다음과 같은 상황이 적용됩니다.
-
채널은
stable-1.29입니다. -
stable-1.30채널로 전환하고 있습니다. - 현재 설치된 버전은 1.29.1입니다.
-
1.29.1은
stable-1.29채널의 헤드입니다.
이 시나리오의 stable-1.29 에서 1.30.0으로 1.29.1에서 1.30.0으로의 업그레이드 경로는 1.29.1 ~ 1.30.0입니다.
stable-1.29 stable-1.30 +--------------+ +--------------+ | | | | | +--------+ | | +--------+ | | | 1.29.0 | | ------> | 1.30.0 | | | +--------+ | | | +--------+ | | | | | | | | | | | | +--------+ | | | | | | 1.29.1 |-------+ | | | +--------+ | | | | | | | +--------------+ +--------------+
