지원콘솔개발자평가판 시작연락처

15.4. GitOps ZTP를 사용하여 단일 노드 OpenShift 클러스터에 대한 이미지 기반 업그레이드 수행

GitOps ZTP(ZTP)를 통해 이미지 기반 업그레이드로 관리형 단일 노드 OpenShift 클러스터를 업그레이드할 수 있습니다.

클러스터에 Lifecycle Agent를 배포하면 ImageBasedUpgrade CR이 자동으로 생성됩니다. 이 CR을 업데이트하여 시드 이미지의 이미지 리포지터리를 지정하고 다른 단계를 진행합니다.

15.4.1. Lifecycle Agent 및 GitOps ZTP를 사용하여 이미지 기반 업그레이드의 Prep 단계로 이동

클러스터에 Lifecycle Agent를 배포하면 ImageBasedUpgrade CR이 자동으로 생성됩니다. 이 CR을 업데이트하여 시드 이미지의 이미지 리포지터리를 지정하고 다른 단계를 진행합니다.

ztp-site-generate 컨테이너의 ImageBasedUpgrade CR

apiVersion: lca.openshift.io/v1
kind: ImageBasedUpgrade
metadata:
  name: upgrade
spec:
  stage: Idle

사전 요구 사항

  • 이미지 기반 업그레이드에 사용되는 리소스에 대한 정책 및 ConfigMap 오브젝트를 생성합니다. 자세한 내용은 " GitOps ZTP를 사용하여 이미지 기반 업그레이드에 대한 ConfigMap 오브젝트 생성을 참조하십시오.

프로세스

  1. ibu-upgrade-ranGen.yaml 이라는 기존 그룹 PolicyGenTemplate 에 대한 Prep,Upgrade 및 Idle 단계에 대한 정책을 추가합니다. 

    apiVersion: ran.openshift.io/v1
kind: PolicyGenTemplate
metadata:
  name: example-group-ibu
  namespace: "ztp-group"
spec:
  bindingRules:
    group-du-sno: ""
  mcp: "master"
  evaluationInterval: 1
    compliant: 10s
    noncompliant: 10s
  sourceFiles:
    - fileName: ConfigMapGeneric.yaml
      complianceType: mustonlyhave
      policyName: "oadp-cm-policy"
      metadata:
        name: oadp-cm
        namespace: openshift-adp
    - fileName: ibu/ImageBasedUpgrade.yaml
      policyName: "prep-stage-policy"
      spec:
        stage: Prep
        seedImageRef: 2
          version: "4.15.0"
          image: "quay.io/user/lca-seed:4.15.0"
          pullSecretRef:
            name: "<seed_pull_secret>"
        oadpContent: 3
        - name: "oadp-cm"
          namespace: "openshift-adp"
      status:
        conditions:
          - reason: Completed
            status: "True"
            type: PrepCompleted
            message: "Prep stage completed successfully"
    - fileName: ibu/ImageBasedUpgrade.yaml
      policyName: "upgrade-stage-policy"
      spec:
        stage: Upgrade
      status:
        conditions:
          - reason: Completed
            status: "True"
            type: UpgradeCompleted
    - fileName: ibu/ImageBasedUpgrade.yaml
      policyName: "finalize-stage-policy"
      complianceType: mustonlyhave
      spec:
        stage: Idle
    - fileName: ibu/ImageBasedUpgrade.yaml
      policyName: "finalize-stage-policy"
      status:
        conditions:
          - reason: Idle
            status: "True"
            type: Idle
    1
    규정 준수 및 비준수 정책에 대한 정책 평가 간격입니다. 정책 상태가 현재 업그레이드 상태를 정확하게 반영하도록 10s 로 설정합니다.
    2
    사전 단계에서 업그레이드할 시드 이미지, OpenShift Container Platform 버전 및 풀 시크릿을 정의합니다.
    3
    백업 및 복원에 필요한 OADP ConfigMap 리소스를 정의합니다.

  2. 다음 명령을 실행하여 이미지 기반 업그레이드에 필요한 정책이 생성되었는지 확인합니다. 

    $ oc get policies -n spoke1 | grep -E "example-group-ibu"

    출력 예

    ztp-group.example-group-ibu-oadp-cm-policy             inform               NonCompliant          31h
ztp-group.example-group-ibu-prep-stage-policy          inform               NonCompliant          31h
ztp-group.example-group-ibu-upgrade-stage-policy       inform               NonCompliant          31h
ztp-group.example-group-ibu-finalize-stage-policy      inform               NonCompliant          31h
ztp-group.example-group-ibu-rollback-stage-policy      inform               NonCompliant          31h

  3. du-profile 클러스터 레이블을 대상 플랫폼 버전 또는 SiteConfig CR의 해당 정책 바인딩 레이블로 업데이트합니다. 

    apiVersion: ran.openshift.io/v1
kind: SiteConfig
[...]
spec:
  [...]
    clusterLabels:
      du-profile: "4.15.0"
    중요

    대상 플랫폼 버전으로 레이블을 업데이트하면 기존 정책 세트가 바인딩 해제됩니다.

  4. 업데이트된 SiteConfig CR을 Git 리포지토리로 커밋하고 내보냅니다.

  5. Prep 단계로 이동할 준비가 되면 Prep 및 OADP ConfigMap 정책을 사용하여 대상 허브 클러스터에서 ClusterGroupUpgrade CR을 생성합니다. 

    apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-ibu-prep
  namespace: default
spec:
  clusters:
  - spoke1
  enable: true
  managedPolicies:
  - example-group-ibu-oadp-cm-policy
  - example-group-ibu-prep-stage-policy
  remediationStrategy:
    canaries:
      - spoke1
    maxConcurrency: 1
    timeout: 240

  6. 다음 명령을 실행하여 Prep 정책을 적용합니다. 

    $ oc apply -f cgu-ibu-prep.yml

    OADP 리소스 및 추가 매니페스트에 ConfigMap 오브젝트를 제공하는 경우 Lifecycle Agent는 Prep 단계에서 지정된 ConfigMap 오브젝트를 검증합니다. 다음 문제가 발생할 수 있습니다.

    • Lifecycle Agent가 추가 매니페스트와 관련된 문제를 감지하면 유효성 검사 경고 또는 오류
    • Lifecycle Agent에서 oadpContent문제를 감지하는 경우 유효성 검사 오류

    검증 경고는 업그레이드 단계를 차단하지 않지만 업그레이드를 진행하는 것이 안전한지 결정해야 합니다. 이러한 경고(예: 누락된 CRD, 네임스페이스 또는 예행 실행 실패)는 경고에 대한 세부 정보를 사용하여 ImageBasedUpgrade CR의 Prep 단계 및 주석 필드에서 status.conditions 를 업데이트합니다.

    검증 경고 예

    [...]
metadata:
annotations:
  extra-manifest.lca.openshift.io/validation-warning: '...'
[...]

    그러나 MachineConfig 또는 Operator 매니페스트를 추가 매니페스트에 추가하는 것과 같은 검증 오류로 인해 Prep 단계가 실패하고 Upgrade 단계를 차단합니다.

    검증을 통과하면 클러스터에서 새 ostree stateroot를 생성합니다. 여기에는 시드 이미지를 가져오고 압축 해제하고 호스트 수준 명령을 실행하는 작업이 포함됩니다. 마지막으로 대상 클러스터에서 필요한 모든 이미지가 미리 캐시됩니다.

  7. 상태를 모니터링하고 다음 명령을 실행하여 cgu-ibu-prep ClusterGroupUpgrade 가 Completed 가 보고될 때까지 기다립니다. 

    $ oc get cgu -n default

    출력 예

    NAME                    AGE   STATE       DETAILS
cgu-ibu-prep            31h   Completed   All clusters are compliant with all the managed policies

추가 리소스

15.4.2. Lifecycle Agent 및 GitOps ZTP를 사용하여 이미지 기반 업그레이드의 업그레이드 단계로 이동

Prep 단계를 완료한 후 대상 클러스터를 업그레이드할 수 있습니다. 업그레이드 프로세스 중에 OADP Operator는 OADP CR에 지정된 아티팩트의 백업을 생성한 다음 Lifecycle Agent가 클러스터를 업그레이드합니다.

업그레이드가 실패하거나 중지되면 자동 롤백이 시작됩니다. 업그레이드 후 문제가 있는 경우 수동 롤백을 시작할 수 있습니다. 수동 롤백에 대한 자세한 내용은 "(선택 사항) 라이프사이클 에이전트 및 GitOps ZTP로 롤백 시작"을 참조하십시오.

사전 요구 사항

  • Prep 단계를 완료합니다.

프로세스

  1. Upgrade 단계로 이동할 준비가 되면 Upgrade 정책을 참조하는 대상 허브 클러스터에서 ClusterGroup Upgrade CR을 생성합니다. 

    apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-ibu-upgrade
  namespace: default
spec:
  actions:
    beforeEnable:
      addClusterAnnotations:
        import.open-cluster-management.io/disable-auto-import: "true" 1
    afterCompletion:
      removeClusterAnnotations:
      - import.open-cluster-management.io/disable-auto-import 2
  clusters:
  - spoke1
  enable: true
  managedPolicies:
  - example-group-ibu-upgrade-stage-policy
  remediationStrategy:
    canaries:
      - spoke1
    maxConcurrency: 1
    timeout: 240
    1
    업그레이드를 시작하기 전에 disable-auto-import 주석을 관리 클러스터에 적용합니다. 이 주석을 사용하면 클러스터가 준비될 때까지 업그레이드 단계에서 관리 클러스터를 자동으로 가져올 수 없습니다.
    2
    업그레이드가 완료된 후 disable-auto-import 주석을 제거합니다.

  2. 다음 명령을 실행하여 Upgrade 정책을 적용합니다. 

    $ oc apply -f cgu-ibu-upgrade.yml

  3. 다음 명령을 실행하여 상태를 모니터링하고 cgu-ibu-upgrade ClusterGroupUpgrade 가 Completed 로 보고될 때까지 기다립니다. 

    $ oc get cgu -n default

    출력 예

    NAME                              AGE   STATE       DETAILS
cgu-ibu-prep                      31h   Completed   All clusters are compliant with all the managed policies
cgu-ibu-upgrade                   31h   Completed   All clusters are compliant with all the managed policies

  4. 변경 사항에 만족하고 업그레이드를 완료할 준비가 되면 업그레이드를 완료하는 정책을 참조하는 대상 허브 클러스터에서 ClusterGroupUpgrade CR을 생성합니다. 

    apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-ibu-finalize
  namespace: default
spec:
  actions:
    beforeEnable:
      removeClusterAnnotations:
      - import.open-cluster-management.io/disable-auto-import
  clusters:
  - spoke1
  enable: true
  managedPolicies:
  - example-group-ibu-finalize-stage-policy
  remediationStrategy:
    canaries:
      - spoke1
    maxConcurrency: 1
    timeout: 240
    중요

    TALM이 지속적으로 조정되므로 다른 ClusterGroupUpgrade CR이 진행되지 않았는지 확인합니다. cgu-ibu-finalize.yaml 을 적용하기 전에 모든 "In-Progress" ClusterGroupUpgrade CR을 삭제합니다.

  5. 다음 명령을 실행하여 정책을 적용합니다. 

    $ oc apply -f cgu-ibu-finalize.yaml

  6. 상태를 모니터링하고 다음 명령을 실행하여 cgu-ibu-finalize ClusterGroupUpgrade 가 Completed 가 보고될 때까지 기다립니다. 

    $ oc get cgu -n default

    출력 예

    NAME                    AGE   STATE       DETAILS
cgu-ibu-finalize        30h   Completed   All clusters are compliant with all the managed policies
cgu-ibu-prep            31h   Completed   All clusters are compliant with all the managed policies
cgu-ibu-upgrade         31h   Completed   All clusters are compliant with all the managed policies

  7. 업그레이드 후 OADP Operator 및 해당 구성 파일을 제거할 수 있습니다.

    1. common-ranGen.yaml 파일에서 OADP Operator 네임스페이스, Operator group 및 서브스크립션에 대해 complianceType 을 mustnothave 로 변경합니다. 

      [...]
- fileName: OadpSubscriptionNS.yaml
  policyName: "subscriptions-policy"
  complianceType: mustnothave
- fileName: OadpSubscriptionOperGroup.yaml
  policyName: "subscriptions-policy"
  complianceType: mustnothave
- fileName: OadpSubscription.yaml
  policyName: "subscriptions-policy"
  complianceType: mustnothave
- fileName: OadpOperatorStatus.yaml
  policyName: "subscriptions-policy"
  complianceType: mustnothave
[...]

    2. 사이트 PolicyGenTemplate 파일에서 OADP Operator 네임스페이스, Operator group 및 서브스크립션에 대해 complianceType 을 mustnothave 로 변경합니다. 

      - fileName: OadpSecret.yaml
  policyName: "config-policy"
  complianceType: mustnothave
- fileName: OadpBackupStorageLocationStatus.yaml
  policyName: "config-policy"
  complianceType: mustnothave
- fileName: DataProtectionApplication.yaml
  policyName: "config-policy"
  complianceType: mustnothave
    3. 사용자 정의 사이트 리포지토리와 변경 사항을 병합하고 ArgoCD 애플리케이션이 변경 사항을 허브 클러스터에 동기화할 때까지 기다립니다. common-subscriptions-policy 및 example-cnf-config-policy 정책의 상태가 Non-Compliant 로 변경됩니다.
    4. 토폴로지 Aware Lifecycle Manager를 사용하여 대상 클러스터에 변경 사항을 적용합니다. 구성 변경 사항 롤아웃에 대한 자세한 내용은 "관리된 클러스터에서 정책 업데이트"를 참조하십시오.

    5. 프로세스를 모니터링합니다. 대상 클러스터의 common-subscriptions-policy 및 example-cnf-config-policy 정책이 Compliant 인 경우 OADP Operator가 클러스터에서 제거되었습니다. 다음 명령을 실행하여 정책의 상태를 가져옵니다. 

      $ oc get policy -n ztp-common common-subscriptions-policy
      $ oc get policy -n ztp-site example-cnf-config-policy
    6. OADP Operator 네임스페이스, Operator group 및 서브스크립션, common-ranGen.yaml 및 사이트 PolicyGenTemplate 파일의 spec.sourceFiles 에서 구성 CR을 삭제합니다.
    7. 사용자 정의 사이트 리포지토리와 변경 사항을 병합하고 ArgoCD 애플리케이션이 변경 사항을 허브 클러스터에 동기화할 때까지 기다립니다. 정책은 그대로 유지됩니다.

추가 리소스

15.4.3. Lifecycle Agent 및 GitOps ZTP를 사용하여 이미지 기반 업그레이드의 롤백 단계로 이동

업그레이드 후 문제가 발생하면 수동 롤백을 시작할 수 있습니다.

사전 요구 사항

  • 원래 stateroot의 컨트롤 플레인 인증서가 유효한지 확인합니다. 인증서가 만료된 경우 "종료된 컨트롤 플레인 인증서에서 복구"를 참조하십시오.

프로세스

  1. site Config CR의 원래 플랫폼 버전으로 du-profile 또는 해당 policy-binding 레이블을 되돌립니다. 

    apiVersion: ran.openshift.io/v1
kind: SiteConfig
[...]
spec:
  [...]
    clusterLabels:
      du-profile: "4.14.x"

  2. 롤백을 시작할 준비가 되면 기존 그룹 PolicyGenTemplate CR에 롤백 정책을 추가합니다. 

    [...]
- fileName: ibu/ImageBasedUpgrade.yaml
  policyName: "rollback-stage-policy"
  spec:
    stage: Rollback
  status:
    conditions:
      - message: Rollback completed
        reason: Completed
        status: "True"
        type: RollbackCompleted

  3. 롤백 정책을 참조하는 대상 허브 클러스터에서 ClusterGroupUpgrade CR을 생성합니다. 

    apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-ibu-rollback
  namespace: default
spec:
  actions:
    beforeEnable:
      removeClusterAnnotations:
      - import.open-cluster-management.io/disable-auto-import
  clusters:
  - spoke1
  enable: true
  managedPolicies:
  - example-group-ibu-rollback-stage-policy
  remediationStrategy:
    canaries:
      - spoke1
    maxConcurrency: 1
    timeout: 240

  4. 다음 명령을 실행하여 롤백 정책을 적용합니다. 

    $ oc apply -f cgu-ibu-rollback.yml

  5. 변경 사항에 충족하고 롤백을 종료할 준비가 되면 롤백을 종료하는 정책을 참조하는 대상 허브 클러스터에 ClusterGroupUpgrade CR을 생성합니다. 

    apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-ibu-finalize
  namespace: default
spec:
  actions:
    beforeEnable:
      removeClusterAnnotations:
      - import.open-cluster-management.io/disable-auto-import
  clusters:
  - spoke1
  enable: true
  managedPolicies:
  - example-group-ibu-finalize-stage-policy
  remediationStrategy:
    canaries:
      - spoke1
    maxConcurrency: 1
    timeout: 240

  6. 다음 명령을 실행하여 정책을 적용합니다. 

    $ oc apply -f cgu-ibu-finalize.yml

추가 리소스

15.4.4. Lifecycle Agent를 사용하여 이미지 기반 업그레이드 문제 해결

이미지 기반 업그레이드 중에 문제가 발생할 수 있습니다.

15.4.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
    1
    (선택 사항) OADP Operator에서 자세한 정보를 수집해야 하는 경우 이 옵션을 추가할 수 있습니다.
    2
    (선택 사항) SR-IOV Operator에서 자세한 정보를 수집해야 하는 경우 이 옵션을 추가할 수 있습니다.

15.4.4.2. AbortFailed 또는 CryostatFailed 오류

문제

종료 단계 중 또는 사전 단계에서 프로세스를 중지하면 Lifecycle Agent에서 다음 리소스를 정리합니다.

  • 더 이상 필요하지 않은 Stateroot
  • 리소스 사전 처리
  • OADP CR
  • ImageBasedUpgrade CR

라이프 사이클 에이전트가 위의 단계를 수행하지 못하면 AbortFailed 또는 FinalizeFailed 상태로 전환됩니다. 조건 메시지와 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

해결
  1. 로그를 검사하여 실패가 발생한 이유를 확인합니다.

  2. Lifecycle Agent에서 정리를 다시 시도하도록 요청하려면 lca.openshift.io/manual-cleanup-done 주석을 ImageBasedUpgrade CR에 추가합니다.

    이 주석을 관찰한 후 Lifecycle Agent에서 정리를 다시 시도한 후 성공한 경우 ImageBasedUpgrade 단계가 Idle 으로 전환됩니다.

    정리가 다시 실패하면 리소스를 수동으로 정리할 수 있습니다.

15.4.4.2.1. 수동으로 stateroot 정리
문제
Prep 단계에서 중지하면 Lifecycle Agent가 새 stateroot를 정리합니다. 업그레이드 또는 롤백을 성공적으로 완료한 후 Lifecycle Agent가 이전 stateroot를 정리합니다. 이 단계가 실패하면 로그를 검사하여 실패한 이유를 확인하는 것이 좋습니다.
해결

  1. 다음 명령을 실행하여 stateroot에 기존 배포가 있는지 확인합니다. 

    $ ostree admin status

  2. 해당하는 경우 다음 명령을 실행하여 기존 배포를 정리합니다. 

    $ ostree admin undeploy <index_of_deployment>

  3. 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.4.2.2. 수동으로 OADP 리소스 정리
문제
Lifecycle Agent와 S3 백엔드 간의 연결 문제로 인해 OADP 리소스의 자동 정리가 실패할 수 있습니다. 연결을 복원하고 lca.openshift.io/manual-cleanup-done 주석을 추가하면 Lifecycle Agent에서 백업 리소스를 성공적으로 정리할 수 있습니다.
해결

  1. 다음 명령을 실행하여 백엔드 연결을 확인합니다. 

    $ oc get backupstoragelocations.velero.io -n openshift-adp

    출력 예

    NAME                          PHASE       LAST VALIDATED   AGE   DEFAULT
dataprotectionapplication-1   Available   33s              8d    true

  2. 모든 백업 리소스를 제거한 다음 lca.openshift.io/manual-cleanup-done 주석을 ImageBasedUpgrade CR에 추가합니다.

15.4.4.3. LVM 스토리지 볼륨 콘텐츠가 복원되지 않음

LVM 스토리지를 사용하여 동적 영구 볼륨 스토리지를 제공하는 경우 LVM 스토리지에서 영구 볼륨 콘텐츠가 잘못 구성된 경우 복원되지 않을 수 있습니다.

15.4.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.4.4.3.2. CR 복원에서 누락된 LVM 스토리지 관련 필드
문제

애플리케이션에 필요한 리소스가 복원되지만 업그레이드 후에는 영구 볼륨 콘텐츠가 보존되지 않습니다.

  1. 피벗 전에 다음 명령을 실행하여 애플리케이션의 영구 볼륨을 나열합니다. 

    $ 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

  2. 피벗 후 다음 명령을 실행하여 애플리케이션의 영구 볼륨을 나열합니다. 

    $ 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

1
애플리케이션의 영구 볼륨을 유지하려면 restorePV 를 true 로 설정해야 합니다.
2
애플리케이션의 영구 볼륨을 유지하려면 표시된 대로 이 섹션을 구성해야 합니다.

15.4.4.4. 실패한 Backup 및 Restore CR 디버깅

문제
아티팩트의 백업 또는 복원에 실패했습니다.
해결

Backup 및 Restore CR을 디버그하고 Velero CLI 툴을 사용하여 로그를 검색할 수 있습니다. Velero CLI 툴은 OpenShift CLI 툴보다 자세한 정보를 제공합니다.

  1. 다음 명령을 실행하여 오류가 포함된 Backup CR을 설명합니다. 

    $ oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero describe backup -n openshift-adp backup-acm-klusterlet --details

  2. 다음 명령을 실행하여 오류가 포함된 Restore CR을 설명합니다. 

    $ oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero describe restore -n openshift-adp restore-acm-klusterlet --details

  3. 다음 명령을 실행하여 백업된 리소스를 로컬 디렉터리에 다운로드합니다. 

    $ 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
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.