15.3. Lifecycle Agent를 사용하여 단일 노드 OpenShift 클러스터에 대한 이미지 기반 업그레이드 수행
Lifecycle Agent를 사용하여 단일 노드 OpenShift 클러스터의 수동 이미지 기반 업그레이드를 수행할 수 있습니다.
클러스터에 Lifecycle Agent를 배포하면 ImageBasedUpgrade
CR이 자동으로 생성됩니다. 이 CR을 업데이트하여 시드 이미지의 이미지 리포지터리를 지정하고 다른 단계를 진행합니다.
15.3.1. Lifecycle Agent를 사용하여 이미지 기반 업그레이드의 Prep 단계로 이동
클러스터에 Lifecycle Agent를 배포하면 ImageBasedUpgrade
CR(사용자 정의 리소스)이 자동으로 생성됩니다.
업그레이드 중에 필요한 모든 리소스를 생성한 후 Prep
단계로 이동할 수 있습니다. 자세한 내용은 "라이프사이클 에이전트를 사용한 이미지 기반 업그레이드에 대한 ConfigMap 오브젝트 생성" 섹션을 참조하십시오.
사전 요구 사항
- 클러스터를 백업하고 복원하는 리소스를 생성했습니다.
프로세스
ImageBasedUpgrade
CR이 패치되었는지 확인합니다.apiVersion: lca.openshift.io/v1 kind: ImageBasedUpgrade metadata: name: upgrade spec: stage: Idle seedImageRef: version: 4.15.2 1 image: <seed_container_image> 2 pullSecretRef: <seed_pull_secret> 3 autoRollbackOnFailure: {} # initMonitorTimeoutSeconds: 1800 4 extraManifests: 5 - name: example-extra-manifests-cm namespace: openshift-lifecycle-agent - name: example-catalogsources-cm namespace: openshift-lifecycle-agent oadpContent: 6 - name: oadp-cm-example namespace: openshift-adp
- 1
- 대상 플랫폼 버전. 값은 시드 이미지 버전과 일치해야 합니다.
- 2
- 대상 클러스터에서 시드 이미지를 가져올 수 있는 리포지토리입니다.
- 3
- 이미지가 프라이빗 레지스트리에 있는 경우 컨테이너 이미지를 가져오는 인증 정보가 있는 보안에 대한 참조입니다.
- 4
- 선택 사항: 첫 번째 재부팅 후 업그레이드가 완료되지 않으면 롤백할 시간(초)입니다. 정의되지 않거나
0
으로 설정하면1800
초(30분)의 기본값이 사용됩니다. - 5
- 선택 사항: 업그레이드 후 유지할 사용자 정의 카탈로그 소스와 시드 이미지에 포함되지 않은 대상 클러스터에 적용할 추가 매니페스트가 포함된
ConfigMap
리소스 목록입니다. - 6
- OADP
Backup
및Restore
CR이 포함된ConfigMap
리소스 목록입니다.
Prep
단계를 시작하려면 다음 명령을 실행하여ImageBasedUpgrade
CR의stage
필드 값을Prep
로 변경합니다.$ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Prep"}}' --type=merge -n openshift-lifecycle-agent
OADP 리소스 및 추가 매니페스트에
ConfigMap
오브젝트를 제공하는 경우 Lifecycle Agent는Prep
단계에서 지정된ConfigMap
오브젝트를 검증합니다. 다음 문제가 발생할 수 있습니다.-
Lifecycle Agent가
추가Manifests
매개변수와 관련된 문제를 감지하면 유효성 검사 경고 또는 오류입니다. -
라이프사이클 에이전트가
oadpContent
매개변수와 관련된 문제를 감지하면 유효성 검사 오류가 발생합니다.
검증 경고는
업그레이드
단계를 차단하지 않지만 업그레이드를 진행하는 것이 안전한지 결정해야 합니다. 이러한 경고(예: 누락된 CRD, 네임스페이스 또는 예행 실행 실패)는 경고에 대한 세부 정보를 사용하여ImageBasedUpgrade
CR의Prep
stage 및annotation
필드에 대한status.conditions
를 업데이트합니다.검증 경고 예
# ... metadata: annotations: extra-manifest.lca.openshift.io/validation-warning: '...' # ...
그러나
MachineConfig
또는 Operator 매니페스트를 추가 매니페스트에 추가하는 것과 같은 검증 오류로 인해Prep
단계가 실패하고Upgrade
단계를 차단합니다.검증을 통과하면 클러스터에서 새
ostree
stateroot를 생성합니다. 여기에는 시드 이미지를 가져오고 압축 해제하고 호스트 수준 명령을 실행하는 작업이 포함됩니다. 마지막으로 대상 클러스터에서 필요한 모든 이미지가 미리 캐시됩니다.-
Lifecycle Agent가
검증
다음 명령을 실행하여
ImageBasedUpgrade
CR의 상태를 확인합니다.$ oc get ibu -o yaml
출력 예
conditions: - lastTransitionTime: "2024-01-01T09:00:00Z" message: In progress observedGeneration: 13 reason: InProgress status: "False" type: Idle - lastTransitionTime: "2024-01-01T09:00:00Z" message: Prep completed observedGeneration: 13 reason: Completed status: "False" type: PrepInProgress - lastTransitionTime: "2024-01-01T09:00:00Z" message: Prep stage completed successfully observedGeneration: 13 reason: Completed status: "True" type: PrepCompleted observedGeneration: 13 validNextStages: - Idle - Upgrade
15.3.2. Lifecycle Agent를 사용하여 이미지 기반 업그레이드의 업그레이드 단계로 이동
시드 이미지를 생성하고 Prep
단계를 완료한 후 대상 클러스터를 업그레이드할 수 있습니다. 업그레이드 프로세스 중에 OADP Operator는 OADP CR(사용자 정의 리소스)에 지정된 아티팩트 백업을 생성한 다음 Lifecycle Agent가 클러스터를 업그레이드합니다.
업그레이드가 실패하거나 중지되면 자동 롤백이 시작됩니다. 업그레이드 후 문제가 있는 경우 수동 롤백을 시작할 수 있습니다. 수동 롤백에 대한 자세한 내용은 "라이프사이클 에이전트를 사용한 이미지 기반 업그레이드의 롤백 단계"를 참조하십시오.
사전 요구 사항
-
Prep
단계를 완료했습니다.
프로세스
업그레이드
단계로 이동하려면 다음 명령을 실행하여ImageBased
CR에서Upgrade
stage
필드의 값을 Upgrade로 변경합니다.$ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Upgrade"}}' --type=merge
다음 명령을 실행하여
ImageBasedUpgrade
CR의 상태를 확인합니다.$ oc get ibu -o yaml
출력 예
status: conditions: - lastTransitionTime: "2024-01-01T09:00:00Z" message: In progress observedGeneration: 5 reason: InProgress status: "False" type: Idle - lastTransitionTime: "2024-01-01T09:00:00Z" message: Prep completed observedGeneration: 5 reason: Completed status: "False" type: PrepInProgress - lastTransitionTime: "2024-01-01T09:00:00Z" message: Prep completed successfully observedGeneration: 5 reason: Completed status: "True" type: PrepCompleted - lastTransitionTime: "2024-01-01T09:00:00Z" message: |- Waiting for system to stabilize: one or more health checks failed - one or more ClusterOperators not yet ready: authentication - one or more MachineConfigPools not yet ready: master - one or more ClusterServiceVersions not yet ready: sriov-fec.v2.8.0 observedGeneration: 1 reason: InProgress status: "True" type: UpgradeInProgress observedGeneration: 1 rollbackAvailabilityExpiration: "2024-05-19T14:01:52Z" validNextStages: - Rollback
OADP Operator는 OADP
Backup
및Restore
CR에 지정된 데이터 백업을 생성하고 대상 클러스터가 재부팅됩니다.다음 명령을 실행하여 CR의 상태를 모니터링합니다.
$ oc get ibu -o yaml
업그레이드에 만족하는 경우 다음 명령을 실행하여
ImageBasedUpgrade
CR의stage
필드 값을Idle
에 패치하여 변경 사항을 완료합니다.$ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Idle"}}' --type=merge
중요업그레이드 후
Idle
단계로 이동한 후에는 변경 사항을 롤백할 수 없습니다.Lifecycle Agent는 업그레이드 프로세스 중에 생성된 모든 리소스를 삭제합니다.
- 업그레이드 후 OADP Operator 및 해당 구성 파일을 제거할 수 있습니다. 자세한 내용은 "클러스터에서 Operator 삭제"를 참조하십시오.
검증
다음 명령을 실행하여
ImageBasedUpgrade
CR의 상태를 확인합니다.$ oc get ibu -o yaml
출력 예
status: conditions: - lastTransitionTime: "2024-01-01T09:00:00Z" message: In progress observedGeneration: 5 reason: InProgress status: "False" type: Idle - lastTransitionTime: "2024-01-01T09:00:00Z" message: Prep completed observedGeneration: 5 reason: Completed status: "False" type: PrepInProgress - lastTransitionTime: "2024-01-01T09:00:00Z" message: Prep completed successfully observedGeneration: 5 reason: Completed status: "True" type: PrepCompleted - lastTransitionTime: "2024-01-01T09:00:00Z" message: Upgrade completed observedGeneration: 1 reason: Completed status: "False" type: UpgradeInProgress - lastTransitionTime: "2024-01-01T09:00:00Z" message: Upgrade completed observedGeneration: 1 reason: Completed status: "True" type: UpgradeCompleted observedGeneration: 1 rollbackAvailabilityExpiration: "2024-01-01T09:00:00Z" validNextStages: - Idle - Rollback
다음 명령을 실행하여 클러스터 복원 상태를 확인합니다.
$ oc get restores -n openshift-adp -o custom-columns=NAME:.metadata.name,Status:.status.phase,Reason:.status.failureReason
출력 예
NAME Status Reason acm-klusterlet Completed <none> 1 apache-app Completed <none> localvolume Completed <none>
- 1
acm-klusterlet
은 RHACM 환경에만 적용됩니다.
15.3.3. Lifecycle Agent를 사용하여 이미지 기반 업그레이드의 롤백 단계로 이동
재부팅 후 initMonitorTimeoutSeconds
필드에 지정된 시간 내에 업그레이드가 완료되지 않으면 자동 롤백이 시작됩니다.
ImageBasedUpgrade CR의 예
apiVersion: lca.openshift.io/v1
kind: ImageBasedUpgrade
metadata:
name: upgrade
spec:
stage: Idle
seedImageRef:
version: 4.15.2
image: <seed_container_image>
autoRollbackOnFailure: {}
# initMonitorTimeoutSeconds: 1800 1
# ...
- 1
- 선택 사항: 업그레이드가 첫 번째 재부팅 후 해당 기간 내에 완료되지 않으면 롤백할 시간(초)입니다. 정의되지 않거나
0
으로 설정하면1800
초(30분)의 기본값이 사용됩니다.
업그레이드 후 해결할 수 없는 문제가 발생하면 변경 사항을 수동으로 롤백할 수 있습니다.
사전 요구 사항
-
cluster-admin
권한이 있는 사용자로 hub 클러스터에 로그인했습니다. - 원래 stateroot의 컨트롤 플레인 인증서가 유효한지 확인했습니다. 인증서가 만료된 경우 "종료된 컨트롤 플레인 인증서에서 복구"를 참조하십시오.
프로세스
롤백 단계로 이동하려면 다음 명령을 실행하여
stage
필드의 값을ImageBasedUpgrade
CR의롤백
에 패치합니다.$ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Rollback"}}' --type=merge
Lifecycle Agent는 이전에 설치한 OpenShift Container Platform 버전으로 클러스터를 재부팅하고 애플리케이션을 복원합니다.
변경 사항에 만족하는 경우 다음 명령을 실행하여
ImageBasedUpgrade
CR의stage
필드 값을Idle
에 패치하여 롤백을 완료합니다.$ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Idle"}}' --type=merge -n openshift-lifecycle-agent
주의롤백 후
Idle
단계로 이동하는 경우 Lifecycle Agent는 업그레이드 실패 문제를 해결하는 데 사용할 수 있는 리소스를 정리합니다.
추가 리소스
15.3.4. Lifecycle Agent를 사용하여 이미지 기반 업그레이드 문제 해결
문제의 영향을 받는 관리 클러스터에서 문제 해결 단계를 수행합니다.
ImageBasedGroupUpgrade
CR을 사용하여 클러스터를 업그레이드하는 경우 관리 클러스터에서 문제 해결 또는 복구 단계를 수행한 후 lcm.openshift.io/ibgu-<stage>-completed 또는 'lcm.openshift.io/ibgu-<stage
>가 올바르게 업데이트되었는지 확인합니다. 이렇게 하면 TALM에서 클러스터의 이미지 기반 업그레이드를 계속 관리합니다.
15.3.4.1. 로그 수집
oc adm must-gather
CLI를 사용하여 디버깅 및 문제 해결을 위한 정보를 수집할 수 있습니다.
프로세스
다음 명령을 실행하여 Operator에 대한 데이터를 수집합니다.
$ oc adm must-gather \ --dest-dir=must-gather/tmp \ --image=$(oc -n openshift-lifecycle-agent get deployment.apps/lifecycle-agent-controller-manager -o jsonpath='{.spec.template.spec.containers[?(@.name == "manager")].image}') \ --image=quay.io/konveyor/oadp-must-gather:latest \// 1 --image=quay.io/openshift/origin-must-gather:latest 2
15.3.4.2. AbortFailed 또는 CryostatFailed 오류
- 문제
종료 단계 중 또는 사전 단계에서 프로세스를 중지하면 Lifecycle Agent에서 다음 리소스를 정리합니다.
- 더 이상 필요하지 않은 Stateroot
- 리소스 사전 처리
- OADP CR
-
ImageBasedUpgrade
CR
라이프 사이클 에이전트가 위의 단계를 수행하지 못하면
AbortFailed
또는 CryostatFailed 상태로 전환됩니다.조건 메시지와 log는 실패한 단계를 표시합니다.
오류 메시지의 예
message: failed to delete all the backup CRs. Perform cleanup manually then add 'lca.openshift.io/manual-cleanup-done' annotation to ibu CR to transition back to Idle observedGeneration: 5 reason: AbortFailed status: "False" type: Idle
- 해결
- 로그를 검사하여 실패가 발생한 이유를 확인합니다.
Lifecycle Agent에서 정리를 다시 시도하도록 요청하려면
lca.openshift.io/manual-cleanup-done
주석을ImageBasedUpgrade
CR에 추가합니다.이 주석을 관찰한 후 Lifecycle Agent에서 정리를 다시 시도한 후 성공한 경우
ImageBasedUpgrade
단계가Idle
으로 전환됩니다.정리가 다시 실패하면 리소스를 수동으로 정리할 수 있습니다.
15.3.4.2.1. 수동으로 stateroot 정리
- 문제
-
Prep
단계에서 중지하면 Lifecycle Agent가 새 stateroot를 정리합니다. 업그레이드 또는 롤백을 성공적으로 완료한 후 Lifecycle Agent가 이전 stateroot를 정리합니다. 이 단계가 실패하면 로그를 검사하여 실패한 이유를 확인하는 것이 좋습니다. - 해결
다음 명령을 실행하여 stateroot에 기존 배포가 있는지 확인합니다.
$ ostree admin status
해당하는 경우 다음 명령을 실행하여 기존 배포를 정리합니다.
$ ostree admin undeploy <index_of_deployment>
stateroot의 모든 배포를 정리한 후 다음 명령을 실행하여 stateroot 디렉터리를 지웁니다.
주의booted 배포가 이 stateroot에 없는지 확인합니다.
$ stateroot="<stateroot_to_delete>"
$ unshare -m /bin/sh -c "mount -o remount,rw /sysroot && rm -rf /sysroot/ostree/deploy/${stateroot}"
15.3.4.2.2. 수동으로 OADP 리소스 정리
- 문제
-
Lifecycle Agent와 S3 백엔드 간의 연결 문제로 인해 OADP 리소스의 자동 정리가 실패할 수 있습니다. 연결을 복원하고
lca.openshift.io/manual-cleanup-done
주석을 추가하면 Lifecycle Agent에서 백업 리소스를 성공적으로 정리할 수 있습니다. - 해결
다음 명령을 실행하여 백엔드 연결을 확인합니다.
$ oc get backupstoragelocations.velero.io -n openshift-adp
출력 예
NAME PHASE LAST VALIDATED AGE DEFAULT dataprotectionapplication-1 Available 33s 8d true
-
모든 백업 리소스를 제거한 다음
lca.openshift.io/manual-cleanup-done
주석을ImageBasedUpgrade
CR에 추가합니다.
15.3.4.3. LVM 스토리지 볼륨 콘텐츠가 복원되지 않음
LVM 스토리지를 사용하여 동적 영구 볼륨 스토리지를 제공하는 경우 LVM 스토리지에서 영구 볼륨 콘텐츠가 잘못 구성된 경우 복원되지 않을 수 있습니다.
15.3.4.3.1. Backup CR에서 누락된 LVM 스토리지 관련 필드
- 문제
Backup
CR은 영구 볼륨을 복원하는 데 필요한 누락된 필드일 수 있습니다. 다음을 실행하여 애플리케이션 Pod의 이벤트를 확인하여 이 문제가 있는지 확인할 수 있습니다.$ oc describe pod <your_app_name>
Backup CR에서 누락된 LVM 스토리지 관련 필드를 표시하는 출력 예
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 58s (x2 over 66s) default-scheduler 0/1 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling.. Normal Scheduled 56s default-scheduler Successfully assigned default/db-1234 to sno1.example.lab Warning FailedMount 24s (x7 over 55s) kubelet MountVolume.SetUp failed for volume "pvc-1234" : rpc error: code = Unknown desc = VolumeID is not found
- 해결
application
Backup
CR에logicalvolumes.topolvm.io
를 포함해야 합니다. 이 리소스가 없으면 애플리케이션에서 영구 볼륨 클레임 및 영구 볼륨 매니페스트를 올바르게 복원하지만 피벗 후 이 영구볼륨과 연결된 논리
볼륨이 올바르게 복원되지 않습니다.Backup CR의 예
apiVersion: velero.io/v1 kind: Backup metadata: labels: velero.io/storage-location: default name: small-app namespace: openshift-adp spec: includedNamespaces: - test includedNamespaceScopedResources: - secrets - persistentvolumeclaims - deployments - statefulsets includedClusterScopedResources: 1 - persistentVolumes - volumesnapshotcontents - logicalvolumes.topolvm.io
- 1
- 애플리케이션의 영구 볼륨을 복원하려면 다음과 같이 이 섹션을 구성해야 합니다.
15.3.4.3.2. CR 복원에서 누락된 LVM 스토리지 관련 필드
- 문제
애플리케이션에 필요한 리소스가 복원되지만 업그레이드 후에는 영구 볼륨 콘텐츠가 보존되지 않습니다.
피벗 전에 다음 명령을 실행하여 애플리케이션의 영구 볼륨을 나열합니다.
$ oc get pv,pvc,logicalvolumes.topolvm.io -A
피벗 전 출력 예
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE persistentvolume/pvc-1234 1Gi RWO Retain Bound default/pvc-db lvms-vg1 4h45m NAMESPACE NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE default persistentvolumeclaim/pvc-db Bound pvc-1234 1Gi RWO lvms-vg1 4h45m NAMESPACE NAME AGE logicalvolume.topolvm.io/pvc-1234 4h45m
피벗 후 다음 명령을 실행하여 애플리케이션의 영구 볼륨을 나열합니다.
$ oc get pv,pvc,logicalvolumes.topolvm.io -A
피벗 후 출력 예
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE persistentvolume/pvc-1234 1Gi RWO Delete Bound default/pvc-db lvms-vg1 19s NAMESPACE NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE default persistentvolumeclaim/pvc-db Bound pvc-1234 1Gi RWO lvms-vg1 19s NAMESPACE NAME AGE logicalvolume.topolvm.io/pvc-1234 18s
- 해결
이 문제의 원인은
logicalvolume
상태가Restore
CR에 유지되지 않기 때문입니다. 이 상태는 Velero가 피벗 후 보존해야 하는 볼륨을 참조하는 데 필요하기 때문에 중요합니다. 애플리케이션Restore
CR에 다음 필드를 포함해야 합니다.Restore CR의 예
apiVersion: velero.io/v1 kind: Restore metadata: name: sample-vote-app namespace: openshift-adp labels: velero.io/storage-location: default annotations: lca.openshift.io/apply-wave: "3" spec: backupName: sample-vote-app restorePVs: true 1 restoreStatus: 2 includedResources: - logicalvolumes
15.3.4.4. 실패한 Backup 및 Restore CR 디버깅
- 문제
- 아티팩트의 백업 또는 복원에 실패했습니다.
- 해결
Backup
및Restore
CR을 디버그하고 Velero CLI 툴을 사용하여 로그를 검색할 수 있습니다. Velero CLI 툴은 OpenShift CLI 툴보다 자세한 정보를 제공합니다.다음 명령을 실행하여 오류가 포함된
Backup
CR을 설명합니다.$ oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero describe backup -n openshift-adp backup-acm-klusterlet --details
다음 명령을 실행하여 오류가 포함된
Restore
CR을 설명합니다.$ oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero describe restore -n openshift-adp restore-acm-klusterlet --details
다음 명령을 실행하여 백업된 리소스를 로컬 디렉터리에 다운로드합니다.
$ oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero backup download -n openshift-adp backup-acm-klusterlet -o ~/backup-acm-klusterlet.tar.gz