15.4. GitOps ZTP를 사용하여 단일 노드 OpenShift 클러스터에 대한 이미지 기반 업그레이드 수행
모든 단계에서 선택한 관리 클러스터 그룹에서 이미지 기반 업그레이드를 관리하려면 hub 클러스터인 ImageBasedGroupUpgrade
사용자 정의 리소스(CR)에서 단일 리소스를 사용할 수 있습니다. TALM( topology Aware Lifecycle Manager)은 ImageBasedGroupUpgrade
CR을 조정하고 수동으로 제어하거나 완전히 자동화된 업그레이드 흐름에서 정의된 스테이지 전환을 완료하기 위한 기본 리소스를 만듭니다.
이미지 기반 업그레이드에 대한 자세한 내용은 "단일 노드 OpenShift 클러스터의 이미지 기반 업그레이드 이해"를 참조하십시오.
15.4.1. 허브의 ImageBasedGroupUpgrade
CR을 사용하여 대규모의 이미지 기반 업그레이드 관리
ImageBasedGroupUpgrade
CR은 ImageBasedUpgrade
및 ClusterGroupUpgrade
API를 결합합니다. 예를 들어 ClusterGroupUpgrade
API와 동일한 방식으로 ImageBasedGroupUpgrade
API를 사용하여 클러스터 선택 및 롤아웃 전략을 정의할 수 있습니다. 스테이지 전환은 ImageBasedUpgrade
API와 다릅니다. ImageBasedGroupUpgrade
API를 사용하면 작업이라고도 하는 여러 단계 전환을 하나의 롤아웃 전략을 공유하는 하나의 단계로 결합할 수 있습니다.
Example ImageBasedGroupUpgrade.yaml
apiVersion: lcm.openshift.io/v1alpha1 kind: ImageBasedGroupUpgrade metadata: name: <filename> namespace: default spec: clusterLabelSelectors: 1 - matchExpressions: - key: name operator: In values: - spoke1 - spoke4 - spoke6 ibuSpec: seedImageRef: 2 image: quay.io/seed/image:4.17.0-rc.1 version: 4.17.0-rc.1 pullSecretRef: name: "<seed_pull_secret>" extraManifests: 3 - name: example-extra-manifests namespace: openshift-lifecycle-agent oadpContent: 4 - name: oadp-cm namespace: openshift-adp plan: 5 - actions: ["Prep", "Upgrade", "FinalizeUpgrade"] rolloutStrategy: maxConcurrency: 200 6 timeout: 2400 7
15.4.1.1. 지원되는 작업 조합
작업은 선택한 클러스터 그룹에 대한 업그레이드 계획 단계에서 TALM이 완료하는 스테이지 전환 목록입니다. ImageBasedGroupUpgrade
CR의 각 작업
항목은 별도의 단계이며 단계에는 동일한 롤아웃 전략을 공유하는 하나 이상의 작업이 포함됩니다. 작업을 단계로 분리하여 각 작업에 대한 롤아웃 전략을 보다 효과적으로 제어할 수 있습니다.
이러한 작업은 업그레이드 계획에서 다르게 결합할 수 있으며 나중에 후속 단계를 추가할 수 있습니다. 계획에 단계를 추가하기 전에 이전 단계가 완료되거나 실패할 때까지 기다립니다. 이전 단계에서 실패한 클러스터에 대해 추가된 단계의 첫 번째 작업은 Abort
또는 Rollback
이어야 합니다.
진행 중인 계획에서 작업 또는 단계를 제거할 수 없습니다.
다음 표는 롤아웃 전략에 대한 다양한 수준의 제어 계획에 대한 예제 계획을 보여줍니다.
계획 예 | 설명 |
---|---|
plan: - actions: ["Prep", "Upgrade", "FinalizeUpgrade"] rolloutStrategy: maxConcurrency: 200 timeout: 60 | 모든 작업이 동일한 전략을 공유합니다. |
plan: - actions: ["Prep", "Upgrade"] rolloutStrategy: maxConcurrency: 200 timeout: 60 - actions: ["FinalizeUpgrade"] rolloutStrategy: maxConcurrency: 500 timeout: 10 | 일부 작업은 동일한 전략을 공유합니다. |
plan: - actions: ["Prep"] rolloutStrategy: maxConcurrency: 200 timeout: 60 - actions: ["Upgrade"] rolloutStrategy: maxConcurrency: 200 timeout: 20 - actions: ["FinalizeUpgrade"] rolloutStrategy: maxConcurrency: 500 timeout: 10 | 모든 작업에는 다른 전략이 있습니다. |
작업 중 하나에 실패하는 클러스터는 동일한 단계에서 나머지 작업을 건너뜁니다.
ImageBasedGroupUpgrade
API는 다음 작업을 허용합니다.
prep
-
Prep
단계로 이동하여 업그레이드 리소스 준비를 시작합니다. 업그레이드
-
업그레이드 단계로 이동하여
업그레이드
를 시작합니다. FinalizeUpgrade
-
Idle
단계로 이동하여 업그레이드 작업을 완료한 선택한 클러스터에서업그레이드
를 완료합니다. rollback
-
롤백 단계로 이동하여 성공적으로 업그레이드된 클러스터에서만
롤백
을 시작합니다. FinalizeRollback
-
Idle
단계로 이동하여 롤백을 완료합니다. AbortOnFailure
-
Idle
단계로 이동하여 사전 또는업그레이드
작업에 실패한 선택한 클러스터에서 업그레이드를 취소합니다. Abort
-
Idle
단계로 이동하여 아직 업그레이드되지 않은 클러스터에서만 지속적인 업그레이드를 취소합니다.
다음과 같은 동작 조합이 지원됩니다. 한 쌍의 대괄호는 plan
섹션의 한 단계를 나타냅니다.
-
["Prep"]
,["Abort"]
-
["Prep", "Upgrade", "FinalizeUpgrade"]
-
["Prep"]
,["bortOnFailure"]
,["Upgrade"]
,["bortOnFailure"]
,["FinalizeUpgrade"]]
-
["Rollback", "FinalizeRollback"]
완전히 새로운 ImageBasedGroupUpgrade
CR에서 지속적인 업그레이드를 다시 시작하거나 취소해야 하는 경우 다음 조합 중 하나를 사용합니다.
-
["Upgrade","FinalizeUpgrade"]
-
["FinalizeUpgrade"]
-
["FinalizeRollback"]
-
["Abort"]
-
["AbortOnFailure"]
15.4.1.2. 클러스터 선택 라벨링
초기 클러스터 선택에 spec.clusterLabelSelectors
필드를 사용합니다. 또한 TALM은 마지막 단계 전환 결과에 따라 관리 클러스터에 레이블을 지정합니다.
단계가 완료되거나 실패하면 TALM은 다음 레이블이 있는 관련 클러스터를 표시합니다.
-
lcm.openshift.io/ibgu-<stage>-completed
-
lcm.openshift.io/ibgu-<stage>-failed
이러한 클러스터 레이블을 사용하여 발생할 수 있는 문제를 해결한 후 클러스터 그룹에서 업그레이드를 취소하거나 롤백합니다.
ImageBasedGroupUpgrade
CR을 사용하여 클러스터를 업그레이드하는 경우 관리 클러스터에서 문제 해결 또는 복구 단계를 수행한 후 lcm.openshift.io/ibgu-<stage>
>가 제대로 업데이트되었는지 확인합니다. 이렇게 하면 TALM에서 클러스터의 이미지 기반 업그레이드를 계속 관리합니다.
-completed
또는 lcm.openshift.io/ibgu-<stage
예를 들어 업그레이드를 성공적으로 완료한 클러스터를 제외하고 모든 관리 클러스터의 업그레이드를 취소하려면 계획에 Abort
작업을 추가할 수 있습니다. Abort
작업은 ImageBasedUpgrade
CR을 Idle
단계로 다시 이동하여 아직 업그레이드되지 않은 클러스터에서 업그레이드를 취소합니다. 별도의 Abort
작업을 추가하면 TALM에서 lcm.openshift.io/ibgu-upgrade-completed
레이블이 있는 클러스터에서 Abort
작업을 수행하지 않습니다.
업그레이드를 성공적으로 취소하거나 종료한 후 클러스터 레이블이 제거됩니다.
15.4.1.3. 상태 모니터링
ImageBasedGroupUpgrade
CR은 한 곳에서 집계된 모든 클러스터에 대한 포괄적인 상태 보고를 통해 개선된 모니터링 환경을 보장합니다. 다음 작업을 모니터링할 수 있습니다.
status.clusters.completedActions
-
계획
섹션에 정의된 모든 완료된 작업을 표시합니다. status.clusters.currentAction
- 현재 진행 중인 모든 작업을 표시합니다.
status.clusters.failedActions
- 실패한 모든 작업을 자세한 오류 메시지와 함께 표시합니다.
15.4.2. 여러 단계에서 대규모로 관리 클러스터에서 이미지 기반 업그레이드 수행
업그레이드가 서비스를 중단하는 시기를 더 잘 제어해야 하는 경우 이전 단계가 완료된 후 작업 추가와 함께 ImageBasedGroupUpgrade
CR을 사용하여 관리 클러스터 세트를 업그레이드할 수 있습니다. 이전 단계의 결과를 평가한 후 다음 업그레이드 단계로 이동하거나 절차 전체에서 실패한 단계를 해결할 수 있습니다.
지원되는 작업 조합에 특정 작업 조합만 지원 및 나열됩니다.
사전 요구 사항
-
cluster-admin
권한이 있는 사용자로 hub 클러스터에 로그인했습니다. -
이미지 기반 업그레이드에 사용되는 리소스에 대한 정책 및
ConfigMap
오브젝트가 생성되어 있습니다. - hub 클러스터를 통해 모든 관리 클러스터에 Lifecycle Agent 및 OADP Operator를 설치했습니다.
프로세스
ImageBasedGroupUpgrade
CR이 포함된 허브 클러스터에 YAML 파일을 생성합니다.apiVersion: lcm.openshift.io/v1alpha1 kind: ImageBasedGroupUpgrade metadata: name: <filename> namespace: default spec: clusterLabelSelectors: 1 - matchExpressions: - key: name operator: In values: - spoke1 - spoke4 - spoke6 ibuSpec: seedImageRef: 2 image: quay.io/seed/image:4.16.0-rc.1 version: 4.16.0-rc.1 pullSecretRef: name: "<seed_pull_secret>" extraManifests: 3 - name: example-extra-manifests namespace: openshift-lifecycle-agent oadpContent: 4 - name: oadp-cm namespace: openshift-adp plan: 5 - actions: ["Prep"] rolloutStrategy: maxConcurrency: 2 timeout: 2400
hub 클러스터에서 다음 명령을 실행하여 생성된 파일을 적용합니다.
$ oc apply -f <filename>.yaml
hub 클러스터에서 다음 명령을 실행하여 상태 업데이트를 모니터링합니다.
$ oc get ibgu -o yaml
출력 예
# ... status: clusters: - completedActions: - action: Prep name: spoke1 - completedActions: - action: Prep name: spoke4 - failedActions: - action: Prep name: spoke6 # ...
예제 계획의 이전 출력은
Prep
단계에서만 시작되고 이전 단계의 결과에 따라 계획에 작업을 추가합니다. TALM은 업그레이드가 성공하거나 실패했는지 표시하는 레이블을 클러스터에 추가합니다. 예를 들어lcm.openshift.io/ibgu-prep-failed
가Prep
단계에 실패한 클러스터에 적용됩니다.실패를 조사한 후 업그레이드 계획에
AbortOnFailure
단계를 추가할 수 있습니다.lcm.openshift.io/ibgu-<action
>으로 레이블이 지정된 클러스터를Idle
단계로 다시 이동합니다. 선택한 클러스터의 업그레이드와 관련된 모든 리소스가 삭제됩니다.선택 사항: 다음 명령을 실행하여 기존
ImageBasedGroupUpgrade
CR에AbortOnFailure
작업을 추가합니다.$ oc patch ibgu <filename> --type=json -p \ '[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["AbortOnFailure"], "rolloutStrategy": {"maxConcurrency": 5, "timeout": 10}}}]'
다음 명령을 실행하여 상태 업데이트를 계속 모니터링합니다.
$ oc get ibgu -o yaml
다음 명령을 실행하여 기존
ImageBasedGroupUpgrade
CR에 작업을 추가합니다.$ oc patch ibgu <filename> --type=json -p \ '[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["Upgrade"], "rolloutStrategy": {"maxConcurrency": 2, "timeout": 30}}}]'
선택 사항: 다음 명령을 실행하여 기존
ImageBasedGroupUpgrade
CR에AbortOnFailure
작업을 추가합니다.$ oc patch ibgu <filename> --type=json -p \ '[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["AbortOnFailure"], "rolloutStrategy": {"maxConcurrency": 5, "timeout": 10}}}]'
다음 명령을 실행하여 상태 업데이트를 계속 모니터링합니다.
$ oc get ibgu -o yaml
다음 명령을 실행하여 기존
ImageBasedGroupUpgrade
CR에 작업을 추가합니다.$ oc patch ibgu <filename> --type=json -p \ '[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["FinalizeUpgrade"], "rolloutStrategy": {"maxConcurrency": 10, "timeout": 3}}}]'
검증
다음 명령을 실행하여 상태 업데이트를 모니터링합니다.
$ oc get ibgu -o yaml
출력 예
# ... status: clusters: - completedActions: - action: Prep - action: AbortOnFailure failedActions: - action: Upgrade name: spoke1 - completedActions: - action: Prep - action: Upgrade - action: FinalizeUpgrade name: spoke4 - completedActions: - action: AbortOnFailure failedActions: - action: Prep name: spoke6 # ...
15.4.3. 1단계의 확장 시 관리형 클러스터에서 이미지 기반 업그레이드 수행
서비스 중단이 중요하지 않은 사용 사례의 경우 한 단계로 하나의 롤아웃 전략을 사용하여 ImageBasedGroupUpgrade
CR을 사용하여 관리 클러스터 세트를 업그레이드할 수 있습니다. 하나의 롤아웃 전략을 사용하면 업그레이드 시간을 줄일 수 있지만 업그레이드 계획이 완료된 후 실패한 클러스터만 문제를 해결할 수 있습니다.
사전 요구 사항
-
cluster-admin
권한이 있는 사용자로 hub 클러스터에 로그인했습니다. -
이미지 기반 업그레이드에 사용되는 리소스에 대한 정책 및
ConfigMap
오브젝트가 생성되어 있습니다. - hub 클러스터를 통해 모든 관리 클러스터에 Lifecycle Agent 및 OADP Operator를 설치했습니다.
프로세스
ImageBasedGroupUpgrade
CR이 포함된 허브 클러스터에 YAML 파일을 생성합니다.apiVersion: lcm.openshift.io/v1alpha1 kind: ImageBasedGroupUpgrade metadata: name: <filename> namespace: default spec: clusterLabelSelectors: 1 - matchExpressions: - key: name operator: In values: - spoke1 - spoke4 - spoke6 ibuSpec: seedImageRef: 2 image: quay.io/seed/image:4.17.0-rc.1 version: 4.17.0-rc.1 pullSecretRef: name: "<seed_pull_secret>" extraManifests: 3 - name: example-extra-manifests namespace: openshift-lifecycle-agent oadpContent: 4 - name: oadp-cm namespace: openshift-adp plan: 5 - actions: ["Prep", "Upgrade", "FinalizeUpgrade"] rolloutStrategy: maxConcurrency: 200 6 timeout: 2400 7
hub 클러스터에서 다음 명령을 실행하여 생성된 파일을 적용합니다.
$ oc apply -f <filename>.yaml
검증
다음 명령을 실행하여 상태 업데이트를 모니터링합니다.
$ oc get ibgu -o yaml
출력 예
# ... status: clusters: - completedActions: - action: Prep failedActions: - action: Upgrade name: spoke1 - completedActions: - action: Prep - action: Upgrade - action: FinalizeUpgrade name: spoke4 - failedActions: - action: Prep name: spoke6 # ...
15.4.4. 규모에 따라 관리 클러스터에서 이미지 기반 업그레이드 취소
Prep
단계를 완료한 관리 클러스터 세트에서 업그레이드를 취소할 수 있습니다.
지원되는 작업 조합에 특정 작업 조합만 지원 및 나열됩니다.
사전 요구 사항
-
cluster-admin
권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
프로세스
ImageBasedGroupUpgrade
CR이 포함된 허브 클러스터에 별도의 YAML 파일을 생성합니다.apiVersion: lcm.openshift.io/v1alpha1 kind: ImageBasedGroupUpgrade metadata: name: <filename> namespace: default spec: clusterLabelSelectors: - matchExpressions: - key: name operator: In values: - spoke4 ibuSpec: seedImageRef: image: quay.io/seed/image:4.16.0-rc.1 version: 4.16.0-rc.1 pullSecretRef: name: "<seed_pull_secret>" extraManifests: - name: example-extra-manifests namespace: openshift-lifecycle-agent oadpContent: - name: oadp-cm namespace: openshift-adp plan: - actions: ["Abort"] rolloutStrategy: maxConcurrency: 5 timeout: 10
Prep
단계를 완료한 모든 관리형 클러스터는Idle
단계로 다시 이동합니다.hub 클러스터에서 다음 명령을 실행하여 생성된 파일을 적용합니다.
$ oc apply -f <filename>.yaml
검증
다음 명령을 실행하여 상태 업데이트를 모니터링합니다.
$ oc get ibgu -o yaml
출력 예
# ... status: clusters: - completedActions: - action: Prep currentActions: - action: Abort name: spoke4 # ...
추가 리소스
15.4.5. 규모에 따라 관리 클러스터에서 이미지 기반 업그레이드 롤백
업그레이드에 성공한 후 확인할 수 없는 문제가 발생하면 일련의 관리 클러스터에서 변경 사항을 롤백합니다. 별도의 ImageBasedGroupUpgrade
CR을 생성하고 롤백할 관리 클러스터 세트를 정의해야 합니다.
지원되는 작업 조합에 특정 작업 조합만 지원 및 나열됩니다.
사전 요구 사항
-
cluster-admin
권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
프로세스
ImageBasedGroupUpgrade
CR이 포함된 허브 클러스터에 별도의 YAML 파일을 생성합니다.apiVersion: lcm.openshift.io/v1alpha1 kind: ImageBasedGroupUpgrade metadata: name: <filename> namespace: default spec: clusterLabelSelectors: - matchExpressions: - key: name operator: In values: - spoke4 ibuSpec: seedImageRef: image: quay.io/seed/image:4.17.0-rc.1 version: 4.17.0-rc.1 pullSecretRef: name: "<seed_pull_secret>" extraManifests: - name: example-extra-manifests namespace: openshift-lifecycle-agent oadpContent: - name: oadp-cm namespace: openshift-adp plan: - actions: ["Rollback", "FinalizeRollback"] rolloutStrategy: maxConcurrency: 200 timeout: 2400
hub 클러스터에서 다음 명령을 실행하여 생성된 파일을 적용합니다.
$ oc apply -f <filename>.yaml
정의된 라벨과 일치하는 모든 관리형 클러스터는
롤백
으로 다시 이동한 다음Idle
단계를 수행하여 롤백을 완료합니다.
검증
다음 명령을 실행하여 상태 업데이트를 모니터링합니다.
$ oc get ibgu -o yaml
출력 예
# ... status: clusters: - completedActions: - action: Rollback - action: FinalizeRollback name: spoke4 # ...
추가 리소스
15.4.6. Lifecycle Agent를 사용하여 이미지 기반 업그레이드 문제 해결
문제의 영향을 받는 관리 클러스터에서 문제 해결 단계를 수행합니다.
ImageBasedGroupUpgrade
CR을 사용하여 클러스터를 업그레이드하는 경우 관리 클러스터에서 문제 해결 또는 복구 단계를 수행한 후 lcm.openshift.io/ibgu-<stage>-completed 또는 'lcm.openshift.io/ibgu-<stage
>가 올바르게 업데이트되었는지 확인합니다. 이렇게 하면 TALM에서 클러스터의 이미지 기반 업그레이드를 계속 관리합니다.
15.4.6.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.4.6.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.4.6.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.4.6.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.4.6.3. LVM 스토리지 볼륨 콘텐츠가 복원되지 않음
LVM 스토리지를 사용하여 동적 영구 볼륨 스토리지를 제공하는 경우 LVM 스토리지에서 영구 볼륨 콘텐츠가 잘못 구성된 경우 복원되지 않을 수 있습니다.
15.4.6.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.4.6.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.4.6.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