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


모든 단계에서 선택한 관리 클러스터 그룹에서 이미지 기반 업그레이드를 관리하려면 hub 클러스터인 ImageBasedGroupUpgrade 사용자 정의 리소스(CR)에서 단일 리소스를 사용할 수 있습니다. TALM( topology Aware Lifecycle Manager)은 ImageBasedGroupUpgrade CR을 조정하고 수동으로 제어하거나 완전히 자동화된 업그레이드 흐름에서 정의된 스테이지 전환을 완료하기 위한 기본 리소스를 만듭니다.

이미지 기반 업그레이드에 대한 자세한 내용은 "단일 노드 OpenShift 클러스터의 이미지 기반 업그레이드 이해"를 참조하십시오.

15.4.1. 허브의 ImageBasedGroupUpgrade CR을 사용하여 대규모의 이미지 기반 업그레이드 관리

ImageBasedGroupUpgrade CR은 ImageBasedUpgradeClusterGroupUpgrade 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

1
업그레이드할 클러스터입니다.
2
대상 플랫폼 버전, 사용할 시드 이미지, 이미지에 액세스하는 데 필요한 시크릿입니다.
3
선택 사항: 시드 이미지에 없는 추가 매니페스트를 대상 클러스터에 적용합니다. 사용자 정의 카탈로그 소스에 ConfigMap 오브젝트도 적용합니다.
4
OADP BackupRestore CR이 포함된 ConfigMap 리소스입니다.
5
업그레이드 계획 세부 정보.
6
일괄로 업데이트할 클러스터 수입니다.
7
작업을 완료하는 시간 제한(분)입니다.

15.4.1.1. 지원되는 작업 조합

작업은 선택한 클러스터 그룹에 대한 업그레이드 계획 단계에서 TALM이 완료하는 스테이지 전환 목록입니다. ImageBasedGroupUpgrade CR의 각 작업 항목은 별도의 단계이며 단계에는 동일한 롤아웃 전략을 공유하는 하나 이상의 작업이 포함됩니다. 작업을 단계로 분리하여 각 작업에 대한 롤아웃 전략을 보다 효과적으로 제어할 수 있습니다.

이러한 작업은 업그레이드 계획에서 다르게 결합할 수 있으며 나중에 후속 단계를 추가할 수 있습니다. 계획에 단계를 추가하기 전에 이전 단계가 완료되거나 실패할 때까지 기다립니다. 이전 단계에서 실패한 클러스터에 대해 추가된 단계의 첫 번째 작업은 Abort 또는 Rollback 이어야 합니다.

중요

진행 중인 계획에서 작업 또는 단계를 제거할 수 없습니다.

다음 표는 롤아웃 전략에 대한 다양한 수준의 제어 계획에 대한 예제 계획을 보여줍니다.

표 15.5. 업그레이드 계획의 예
계획 예설명
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> -completed 또는 lcm.openshift.io/ibgu-<stage >가 제대로 업데이트되었는지 확인합니다. 이렇게 하면 TALM에서 클러스터의 이미지 기반 업그레이드를 계속 관리합니다.

예를 들어 업그레이드를 성공적으로 완료한 클러스터를 제외하고 모든 관리 클러스터의 업그레이드를 취소하려면 계획에 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를 설치했습니다.

프로세스

  1. 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
    1
    업그레이드할 클러스터입니다.
    2
    대상 플랫폼 버전, 사용할 시드 이미지, 이미지에 액세스하는 데 필요한 시크릿입니다.
    3
    선택 사항: 시드 이미지에 없는 추가 매니페스트를 대상 클러스터에 적용합니다. 사용자 정의 카탈로그 소스에 ConfigMap 오브젝트도 적용합니다.
    4
    OADP BackupRestore CR이 포함된 ConfigMap 리소스 목록입니다.
    5
    업그레이드 계획 세부 정보.
  2. hub 클러스터에서 다음 명령을 실행하여 생성된 파일을 적용합니다.

    $ oc apply -f <filename>.yaml
  3. 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-failedPrep 단계에 실패한 클러스터에 적용됩니다.

    실패를 조사한 후 업그레이드 계획에 AbortOnFailure 단계를 추가할 수 있습니다. lcm.openshift.io/ibgu-<action >으로 레이블이 지정된 클러스터를 Idle 단계로 다시 이동합니다. 선택한 클러스터의 업그레이드와 관련된 모든 리소스가 삭제됩니다.

  4. 선택 사항: 다음 명령을 실행하여 기존 ImageBasedGroupUpgrade CR에 AbortOnFailure 작업을 추가합니다.

    $ oc patch ibgu <filename> --type=json -p \
    '[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["AbortOnFailure"], "rolloutStrategy": {"maxConcurrency": 5, "timeout": 10}}}]'
    1. 다음 명령을 실행하여 상태 업데이트를 계속 모니터링합니다.

      $ oc get ibgu -o yaml
  5. 다음 명령을 실행하여 기존 ImageBasedGroupUpgrade CR에 작업을 추가합니다.

    $ oc patch ibgu <filename> --type=json -p \
    '[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["Upgrade"], "rolloutStrategy": {"maxConcurrency": 2, "timeout": 30}}}]'
  6. 선택 사항: 다음 명령을 실행하여 기존 ImageBasedGroupUpgrade CR에 AbortOnFailure 작업을 추가합니다.

    $ oc patch ibgu <filename> --type=json -p \
    '[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["AbortOnFailure"], "rolloutStrategy": {"maxConcurrency": 5, "timeout": 10}}}]'
    1. 다음 명령을 실행하여 상태 업데이트를 계속 모니터링합니다.

      $ oc get ibgu -o yaml
  7. 다음 명령을 실행하여 기존 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를 설치했습니다.

프로세스

  1. 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
    1
    업그레이드할 클러스터입니다.
    2
    대상 플랫폼 버전, 사용할 시드 이미지, 이미지에 액세스하는 데 필요한 시크릿입니다.
    3
    선택 사항: 시드 이미지에 없는 추가 매니페스트를 대상 클러스터에 적용합니다. 사용자 정의 카탈로그 소스에 ConfigMap 오브젝트도 적용합니다.
    4
    OADP BackupRestore CR이 포함된 ConfigMap 리소스입니다.
    5
    업그레이드 계획 세부 정보.
    6
    일괄로 업데이트할 클러스터 수입니다.
    7
    작업을 완료하는 시간 제한(분)입니다.
  2. 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 클러스터에 로그인했습니다.

프로세스

  1. 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 단계로 다시 이동합니다.

  2. 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 클러스터에 로그인했습니다.

프로세스

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

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

해결
  1. 로그를 검사하여 실패가 발생한 이유를 확인합니다.
  2. 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를 정리합니다. 이 단계가 실패하면 로그를 검사하여 실패한 이유를 확인하는 것이 좋습니다.
해결
  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.6.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.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 스토리지 관련 필드
문제

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

  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
애플리케이션의 영구 볼륨을 유지하려면 restorePVtrue 로 설정해야 합니다.
2
애플리케이션의 영구 볼륨을 유지하려면 표시된 대로 이 섹션을 구성해야 합니다.

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

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

BackupRestore 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.