15장. 단일 노드 OpenShift 클러스터의 이미지 기반 업그레이드

15.1. 단일 노드 OpenShift 클러스터의 이미지 기반 업그레이드 이해

OpenShift Container Platform 4.14.13에서 라이프 사이클 에이전트는 단일 노드 OpenShift 클러스터의 플랫폼 버전을 업그레이드하는 다른 방법을 제공합니다. 이미지 기반 업그레이드는 표준 업그레이드 방법보다 빠르고 OpenShift Container Platform <4.y>에서 <4.y+2>로 직접 업그레이드할 수 있으며 <4.y.z>를 <4.y.z+n>으로 업그레이드할 수 있습니다.

이 업그레이드 방법은 대상 단일 노드 OpenShift 클러스터에 설치된 전용 시드 클러스터에서 생성된 OCI 이미지를 새 ostree stateroot로 활용합니다. 시드 클러스터는 대상 OpenShift Container Platform 버전, Day 2 Operator 및 모든 대상 클러스터에 공통되는 구성이 함께 배포된 단일 노드 OpenShift 클러스터입니다.

시드 클러스터에서 생성된 시드 이미지를 사용하여 초기 클러스터와 동일한 하드웨어, Day 2 Operator 및 클러스터 구성이 동일한 단일 노드 OpenShift 클러스터에서 플랫폼 버전을 업그레이드할 수 있습니다.

중요

이미지 기반 업그레이드에서는 클러스터가 실행 중인 하드웨어 플랫폼과 관련된 사용자 지정 이미지를 사용합니다. 각 하드웨어 플랫폼에는 별도의 시드 이미지가 필요합니다.

Lifecycle Agent는 참여 클러스터에서 두 개의 CR(사용자 정의 리소스)을 사용하여 업그레이드를 오케스트레이션합니다.

seed 클러스터에서 SeedGenerator CR을 사용하면 시드 이미지 생성을 허용합니다. 이 CR은 시드 이미지를 내보낼 리포지토리를 지정합니다.
대상 클러스터에서 ImageBasedUpgrade CR은 대상 클러스터 업그레이드의 시드 이미지와 워크로드의 백업 구성을 지정합니다.

SeedGenerator CR의 예

apiVersion: lca.openshift.io/v1
kind: SeedGenerator
metadata:
  name: seedimage
spec:
  seedImage: <seed_image>

ImageBasedUpgrade CR의 예

apiVersion: lca.openshift.io/v1
kind: ImageBasedUpgrade
metadata:
  name: upgrade
spec:
  stage: Idle 1
  seedImageRef: 2
    version: <target_version>
    image: <seed_container_image>
    pullSecretRef:
      name: <seed_pull_secret>
  autoRollbackOnFailure: {}
#    initMonitorTimeoutSeconds: 1800 3
  extraManifests: 4
  - name: example-extra-manifests
    namespace: openshift-lifecycle-agent
  oadpContent: 5
  - name: oadp-cm-example
    namespace: openshift-adp

1: ImageBasedUpgrade CR에 대해 원하는 단계를 정의합니다. 값은 Idle,Prep,Upgrade 또는 Rollback 일 수 있습니다.
2: 대상 플랫폼 버전, 사용할 시드 이미지, 이미지에 액세스하는 데 필요한 시크릿을 정의합니다.
3: (선택 사항) 첫 번째 재부팅 후 해당 기간 내에 업그레이드가 완료되지 않으면 롤백할 시간(초)을 지정합니다. 정의되지 않거나 0 으로 설정하면 1800 초(30분)의 기본값이 사용됩니다.
4: (선택 사항) 업그레이드 후 유지할 사용자 정의 카탈로그 소스가 포함된 ConfigMap 리소스 목록과 초기 이미지의 일부가 아닌 대상 클러스터에 적용하려면 추가 매니페스트를 지정합니다.
5: OADP Backup 및 Restore CR이 포함된 ConfigMap 리소스 목록을 지정합니다.

15.1.1. 이미지 기반 업그레이드 단계

시드 클러스터에서 시드 이미지를 생성한 후 ImageBasedUpgrade CR에서 spec.stage 필드를 다음 값 중 하나로 설정하여 대상 클러스터의 단계를 이동할 수 있습니다.

idle
prep
업그레이드
롤백 (선택 사항)

그림 15.1. 이미지 기반 업그레이드 단계

15.1.1.1. 유휴 단계

Lifecycle Agent는 Operator를 처음 배포할 때 stage: Idle 으로 설정된 ImageBasedUpgrade CR을 생성합니다. 이는 기본 단계입니다. 지속적인 업그레이드가 없으며 클러스터는 Prep 단계로 이동할 준비가 되어 있습니다.

그림 15.2. Idle 단계에서 전환

또한 다음 단계 중 하나를 수행하기 위해 Idle 단계로 이동합니다.

성공적인 업그레이드 완료
롤백 종료
업그레이드 단계의 사전 시작 단계까지 지속적인 업그레이드 를 취소

Idle 단계로 전환하면 Lifecycle Agent가 리소스를 정리하여 클러스터를 다시 업그레이드할 준비가 됩니다.

그림 15.3. Idle 단계로 전환

중요

업그레이드를 취소할 때 RHACM을 사용하는 경우 대상 관리 클러스터에서 import.open-cluster-management.io/disable-auto-import 주석을 제거하여 클러스터의 자동 가져오기를 다시 활성화해야 합니다.

15.1.1.2. Prep 단계

참고

예약된 유지 관리 기간 전에 이 단계를 완료할 수 있습니다.

Prep 단계의 경우 ImageBasedUpgrade CR에 다음 업그레이드 세부 정보를 지정합니다.

사용할 시드 이미지
백업할 리소스
적용할 추가 매니페스트 및 업그레이드 후 유지할 사용자 정의 카탈로그 소스(있는 경우)

그런 다음 사용자가 지정한 내용에 따라 현재 실행 중인 버전에 영향을 주지 않고 수명 주기 에이전트는 업그레이드를 준비합니다. 이 단계에서 라이프사이클 에이전트는 대상 클러스터가 특정 조건을 충족하는지 확인하여 업그레이드 단계로 진행할 준비가 되었는지 확인합니다. Operator는 시드 이미지에 지정된 추가 컨테이너 이미지가 있는 시드 이미지를 대상 클러스터에 가져옵니다. Lifecycle Agent는 컨테이너 스토리지 디스크에 충분한 공간이 있는지 확인하고 필요한 경우 디스크 사용량이 지정된 임계값 미만이 될 때까지 Operator는 고정 해제된 이미지를 삭제합니다. 컨테이너 스토리지 디스크 정리를 구성하거나 비활성화하는 방법에 대한 자세한 내용은 "컨테이너 스토리지 디스크의 자동 이미지 정리 구성"을 참조하십시오.

또한 OADP Operator의 Backup 및 Restore CR을 사용하여 백업 리소스를 준비합니다. 이러한 CR은 Upgrade 단계에서 클러스터를 재구성하고 RHACM에 클러스터를 등록하고 애플리케이션 아티팩트를 복원하는 데 사용됩니다.

OADP Operator 외에도 Lifecycle Agent는 ostree 버전 관리 시스템을 사용하여 업그레이드 및 롤백 후 전체 클러스터 재구성을 수행할 수 있는 백업을 생성합니다.

Prep 단계가 완료되면 Idle 단계로 이동하여 업그레이드 프로세스를 취소하거나 ImageBasedUpgrade CR의 Upgrade 단계로 이동하여 업그레이드를 시작할 수 있습니다. 업그레이드를 취소하면 Operator에서 정리 작업을 수행합니다.

그림 15.4. Prep 단계에서 전환

15.1.1.3. 업그레이드 단계

업그레이드 단계는 다음 두 단계로 구성됩니다.

pre-pivot: 새 stateroot를 피벗하기 직전에 Lifecycle Agent는 필요한 클러스터별 아티팩트를 수집하여 새 stateroot에 저장합니다. Prep 단계에 지정된 클러스터 리소스의 백업은 호환 가능한 오브젝트 스토리지 솔루션에 생성됩니다. Lifecycle Agent는 대상 클러스터에 바인딩된 ZTP 정책에 설명된 ImageBasedUpgrade CR 또는 CR의 extraManifests 필드에 지정된 CR을 내보냅니다. 사전 시작 단계가 완료되면 Lifecycle Agent에서 새 stateroot 배포를 기본 부팅 항목으로 설정하고 노드를 재부팅합니다.
post-pivot: 새 stateroot에서 부팅한 후 Lifecycle Agent는 시드 이미지의 클러스터 암호화도 다시 생성합니다. 이렇게 하면 동일한 시드 이미지로 업그레이드된 각 단일 노드 OpenShift 클러스터에 고유하고 유효한 암호화 오브젝트가 있습니다. 그런 다음 Operator는 속도 전 단계에서 수집된 클러스터별 아티팩트를 적용하여 클러스터를 재구성합니다. Operator는 저장된 모든 CR을 적용하고 백업을 복원합니다.

업그레이드가 완료되고 변경 사항에 만족하면 Idle 단계로 이동하여 업그레이드를 완료할 수 있습니다.

중요

업그레이드를 완료하면 원래 릴리스로 롤백할 수 없습니다.

그림 15.5. 업그레이드 단계에서 전환

업그레이드를 취소하려면 업그레이드 단계의 미리 알림 단계가 될 때까지 이 작업을 수행할 수 있습니다. 업그레이드 후 문제가 발생하면 수동 롤백의 롤백 단계로 이동할 수 있습니다.

15.1.1.4. 롤백 단계

롤백 단계는 실패 시 수동 또는 자동으로 시작할 수 있습니다. 롤백 단계에서 Lifecycle Agent는 원래 ostree stateroot 배포를 기본값으로 설정합니다. 그런 다음 노드가 이전 릴리스의 OpenShift Container Platform 및 애플리케이션 구성을 통해 재부팅됩니다.

주의

롤백 후 Idle 단계로 이동하는 경우 Lifecycle Agent는 업그레이드 실패 문제를 해결하는 데 사용할 수 있는 리소스를 정리합니다.

Lifecycle Agent는 업그레이드가 지정된 시간 제한 내에서 완료되지 않으면 자동 롤백을 시작합니다. 자동 롤백에 대한 자세한 내용은 "라이프사이클 에이전트로 이동" 또는 "라이프사이클 에이전트 및 GitOps ZTP" 섹션을 사용하여 롤백 단계로 이동합니다.

그림 15.6. 롤백 단계에서 전환

추가 리소스

15.1.2. 이미지 기반 업그레이드에 대한 지침

이미지 기반 업그레이드에 성공하려면 배포가 특정 요구 사항을 충족해야 합니다.

이미지 기반 업그레이드를 수행할 수 있는 다양한 배포 방법이 있습니다.

GitOps ZTP: GitOps ZTP(ZTP)를 사용하여 클러스터를 배포하고 구성합니다.
Non-GitOps: 클러스터를 수동으로 배포하고 구성합니다.

연결이 끊긴 환경에서 이미지 기반 업그레이드를 수행할 수 있습니다. 연결이 끊긴 환경의 이미지를 미러링하는 방법에 대한 자세한 내용은 "연결이 끊긴 설치의 이미지 미러링"을 참조하십시오.

추가 리소스

연결 해제된 설치를 위한 이미지 미러링

15.1.2.1. 구성 요소의 최소 소프트웨어 버전

배포 방법에 따라 이미지 기반 업그레이드에는 다음과 같은 최소 소프트웨어 버전이 필요합니다.

표 15.1. 구성 요소의 최소 소프트웨어 버전
Component	소프트웨어 버전	필수 항목
라이프사이클 에이전트	4.16	제공됨
OADP Operator	1.4.1	제공됨
관리형 클러스터 버전	4.14.13	제공됨
hub 클러스터 버전	4.16	없음
RHACM	2.10.2	없음
GitOps ZTP 플러그인	4.16	GitOps ZTP 배포 방법만
Red Hat OpenShift GitOps	1.12	GitOps ZTP 배포 방법만
토폴로지 인식 라이프사이클 관리자(TALM)	4.16	GitOps ZTP 배포 방법만
Local Storage Operator ^[1]	4.14	제공됨
LVM(Logical Volume Manager) 스토리지 ^[1]	4.14.2	제공됨

영구 스토리지는 둘 다 아닌 LVM 스토리지 또는 Local Storage Operator에서 제공해야 합니다.

15.1.2.2. hub 클러스터 지침

RHACM(Red Hat Advanced Cluster Management)을 사용하는 경우 허브 클러스터가 다음 조건을 충족해야 합니다.

시드 이미지에 RHACM 리소스를 포함하지 않으려면 시드 이미지를 생성하기 전에 선택적 RHACM 애드온을 모두 비활성화해야 합니다.
대상 단일 노드 OpenShift 클러스터에서 이미지 기반 업그레이드를 수행하기 전에 허브 클러스터를 대상 버전으로 업그레이드해야 합니다.

15.1.2.3. 시드 이미지 지침

시드 이미지는 동일한 하드웨어 및 유사한 구성으로 단일 노드 OpenShift 클러스터 세트를 대상으로 합니다. 즉, 시드 클러스터는 다음 항목에 대해 대상 클러스터 구성과 일치해야 합니다.

CPU 토폴로지
- CPU 코어 수
- 예약된 CPU 수와 같은 튜닝된 성능 구성
대상 클러스터의 MachineConfig 리소스
IP 버전
참고
이번 릴리스에서는 듀얼 스택 네트워킹이 지원되지 않습니다.
Lifecycle Agent 및 OADP Operator를 포함한 Day 2 Operator 세트
연결이 끊긴 레지스트리
FIPS 설정

다음 구성은 참여 클러스터에서만 부분적으로 일치해야 합니다.

대상 클러스터에 프록시 구성이 있는 경우 시드 클러스터에 프록시 구성도 있어야 하지만 구성이 같을 필요는 없습니다.
컨테이너 스토리지의 기본 디스크의 전용 파티션이 참여하는 모든 클러스터에 필요합니다. 그러나 파티션의 크기와 시작이 같을 필요는 없습니다. MachineConfig CR의 spec.config.storage.disks.partitions.label: varlibcontainers 라벨만 시드 및 대상 클러스터 모두에서 일치해야 합니다. 디스크 파티션을 생성하는 방법에 대한 자세한 내용은 "ostree stateroots 간에 공유 컨테이너 파티션 구성" 또는 GitOps ZTP를 사용할 때 ostree stateroots 간에 공유 컨테이너 파티션 구성"을 참조하십시오.

시드 이미지에 포함할 항목에 대한 자세한 내용은 "참조 이미지 구성" 및 "RAN DU 프로필을 사용하여 이미지 구성 참조"를 참조하십시오.

추가 리소스

15.1.2.4. OADP 백업 및 복원 지침

OADP Operator를 사용하면 ConfigMap 오브젝트에 래핑된 Backup 및 Restore CR을 사용하여 대상 클러스터에서 애플리케이션을 백업하고 복원할 수 있습니다. 업그레이드 후 복원할 수 있도록 애플리케이션이 현재 및 대상 OpenShift Container Platform 버전에서 작동해야 합니다. 백업에는 처음 생성된 리소스가 포함되어야 합니다.

다음 리소스는 백업에서 제외되어야 합니다.

pods
끝점
Controllerrevision
PodMetrics
PackageManifest
ReplicaSet
LocalVolume(LSO)을 사용하는 경우

단일 노드 OpenShift에는 두 가지 로컬 스토리지 구현이 있습니다.

LSO(Local Storage Operator): Lifecycle Agent는 localvolume 리소스 및 관련 StorageClass 리소스를 포함하여 필요한 아티팩트를 자동으로 백업하고 복원합니다. 애플리케이션 Backup CR에서 persistentvolumes 리소스를 제외해야 합니다.
LVM 스토리지: LVM 스토리지 아티팩트에 대한 Backup 및 Restore CR을 생성해야 합니다. application Backup CR에 persistentVolumes 리소스를 포함해야 합니다.

이미지 기반 업그레이드의 경우 지정된 대상 클러스터에서 하나의 Operator만 지원됩니다.

중요

두 Operator 모두 ImageBasedUpgrade CR을 통해 Operator CR을 추가 매니페스트로 적용하지 않아야 합니다.

영구 볼륨 내용은 보존되어 피벗 후 사용됩니다. DataProtectionApplication CR을 구성할 때 이미지 기반 업그레이드에 대해 .spec.configuration.restic.enable 이 false 로 설정되어 있는지 확인해야 합니다. 이렇게 하면 컨테이너 스토리지 인터페이스 통합이 비활성화됩니다.

15.1.2.4.1. lca.openshift.io/apply-wave guidelines

lca.openshift.io/apply-ECDHE 주석은 Backup 또는 Restore CR의 적용 순서를 결정합니다. 주석 값은 문자열 번호여야 합니다. Backup 또는 Restore CR에 lca.openshift.io/apply- ECDHE 주석을 정의하는 경우 주석 값에 따라 증가 순서에 따라 적용됩니다. 주석을 정의하지 않으면 함께 적용됩니다.

lca.openshift.io/apply- Cryostat 주석은 애플리케이션보다 플랫폼 Restore CR(예: RHACM 및 LVM 스토리지 아티팩트)에서 숫자만큼 작아야 합니다. 이렇게 하면 플랫폼 아티팩트가 애플리케이션보다 먼저 복원됩니다.

애플리케이션에 클러스터 범위 리소스가 포함된 경우 별도의 Backup 및 Restore CR을 생성하여 애플리케이션에 의해 생성된 특정 클러스터 범위 리소스로 백업의 범위를 지정해야 합니다. 클러스터 범위 리소스의 Restore CR을 나머지 애플리케이션 Restore CR(s)보다 먼저 복원해야 합니다.

15.1.2.4.2. lca.openshift.io/apply-label guidelines

lca.openshift.io/apply-label 주석을 통해서만 특정 리소스를 백업할 수 있습니다. 주석에 정의된 리소스에 따라 Lifecycle Agent는 lca.openshift.io/backup: <backup_name> 레이블을 적용하고 backup CR을 생성할 때 labelSelector.matchLabels.lca.openshift.io/backup: <backup_name > 라벨 선택기를 추가합니다.

특정 리소스를 백업하기 위해 lca.openshift.io/apply-label 주석을 사용하려면 주석에 나열된 리소스도 spec 섹션에 포함되어야 합니다. lca.openshift.io/apply-label 주석이 Backup CR에 사용되는 경우 spec 섹션에 다른 리소스 유형이 지정되어 있어도 주석에 나열된 리소스만 백업됩니다.

CR 예

apiVersion: velero.io/v1
kind: Backup
metadata:
  name: acm-klusterlet
  namespace: openshift-adp
  annotations:
    lca.openshift.io/apply-label: rbac.authorization.k8s.io/v1/clusterroles/klusterlet,apps/v1/deployments/open-cluster-management-agent/klusterlet 1
  labels:
    velero.io/storage-location: default
spec:
  includedNamespaces:
   - open-cluster-management-agent
  includedClusterScopedResources:
   - clusterroles
  includedNamespaceScopedResources:
   - deployments

1: 값은 클러스터 범위 리소스의 group/version/resource/name 형식의 쉼표로 구분된 오브젝트 목록 또는 네임스페이스 범위 리소스의 group/version/resource/namespace/name 형식이어야 하며 관련 Backup CR에 연결해야 합니다.

15.1.2.5. 추가 매니페스트 지침

Lifecycle Agent는 추가 매니페스트를 사용하여 새 stateroot 배포로 재부팅한 후 애플리케이션 아티팩트를 복원하기 전에 대상 클러스터를 복원합니다.

다른 배포 방법에는 추가 매니페스트를 적용하는 다른 방법이 필요합니다.

GitOps ZTP

lca.openshift.io/target-ocp-version: <target_ocp_version > 레이블을 사용하여 피벗 후 Lifecycle Agent에서 추출하고 적용해야 하는 추가 매니페스트를 표시합니다. ImageBasedUpgrade CR에서 lca.openshift.io/target-ocp-version /target-ocp-version- count 주석을 사용하여 lca.openshift.io/target-ocp-ocp-version으로 레이블이 지정된 매니페스트 수를 지정할 수 있습니다. 지정된 경우 라이프사이클 에이전트는 정책에서 추출된 매니페스트 수가 사전 및 업그레이드 단계에서 주석에 제공된 수와 일치하는지 확인합니다.

lca.openshift.io/target-ocp-version-manifest-count 주석의 예

apiVersion: lca.openshift.io/v1
kind: ImageBasedUpgrade
metadata:
  annotations:
    lca.openshift.io/target-ocp-version-manifest-count: "5"
  name: upgrade

비Gitops

추가 매니페스트를 lca.openshift.io/apply-ECDSA 주석 으로 표시하여 적용 순서를 결정합니다. 레이블이 지정된 추가 매니페스트는 ConfigMap 오브젝트로 래핑되고, Lifecycle Agent에서 피벗 후 사용하는 ImageBasedUpgrade CR에서 참조합니다.

대상 클러스터에서 사용자 정의 카탈로그 소스를 사용하는 경우 올바른 릴리스 버전을 가리키는 추가 매니페스트로 포함해야 합니다.

중요

다음 항목을 추가 매니페스트로 적용할 수 없습니다.

MachineConfig 오브젝트
OLM Operator 서브스크립션

추가 리소스

15장. 단일 노드 OpenShift 클러스터의 이미지 기반 업그레이드

15.1. 단일 노드 OpenShift 클러스터의 이미지 기반 업그레이드 이해

15.1.1. 이미지 기반 업그레이드 단계

15.1.1.1. 유휴 단계

15.1.1.2. Prep 단계

15.1.1.3. 업그레이드 단계

15.1.1.4. 롤백 단계

15.1.2. 이미지 기반 업그레이드에 대한 지침

15.1.2.1. 구성 요소의 최소 소프트웨어 버전

15.1.2.2. hub 클러스터 지침

15.1.2.3. 시드 이미지 지침

15.1.2.4. OADP 백업 및 복원 지침

15.1.2.4.1. lca.openshift.io/apply-wave guidelines

15.1.2.4.2. lca.openshift.io/apply-label guidelines

15.1.2.5. 추가 매니페스트 지침

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

Red Hat 소개

Red Hat legal and privacy links

Red Hat legal and privacy links