12.4. 일반적인 문제 및 우려 사항

이 섹션에서는 마이그레이션 중에 발생할 수 있는 일반적인 문제 및 우려 사항에 대해 설명합니다.

12.4.1. 더 이상 사용되지 않는 내부 이미지 업데이트

애플리케이션이 openshift 네임스페이스의 이미지를 사용하는 경우 필요한 이미지 버전이 대상 클러스터에 있어야 합니다.

OpenShift Container Platform 3 이미지가 OpenShift Container Platform 4.12에서 더 이상 사용되지 않는 경우 podman 을 사용하여 이미지 스트림 태그를 수동으로 업데이트할 수 있습니다.

사전 요구 사항

  • podman이 설치되어 있어야 합니다.
  • cluster-admin 권한이 있는 사용자로 로그인해야 합니다.
  • 비보안 레지스트리를 사용하는 경우 /etc/container/registries.conf[registries.insecure] 섹션에 레지스트리 호스트 값을 추가하여 Podman TLS 확인 오류가 발생하지 않도록 합니다.
  • 소스 및 대상 클러스터에 내부 레지스트리를 노출합니다.

절차

  1. 내부 레지스트리가 OpenShift Container Platform 3 및 4 클러스터에 노출되어 있는지 확인합니다.

    OpenShift 이미지 레지스트리는 기본적으로 OpenShift Container Platform 4에 노출됩니다.

  2. 비보안 레지스트리를 사용하는 경우 /etc/container/registries.conf[registries.insecure] 섹션에 레지스트리 호스트 값을 추가하여 Podman TLS 확인 오류가 발생하지 않도록 합니다.
  3. OpenShift Container Platform 3 레지스트리에 로그인합니다.

    $ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false <registry_url>:<port>
  4. OpenShift Container Platform 4 레지스트리에 로그인합니다.

    $ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false <registry_url>:<port>
  5. OpenShift Container Platform 3 이미지를 가져옵니다.

    $ podman pull <registry_url>:<port>/openshift/<image>
  6. OpenShift Container Platform 4 레지스트리에 대해 OpenShift Container Platform 3 이미지를 태그합니다.

    $ podman tag <registry_url>:<port>/openshift/<image> \ 1
      <registry_url>:<port>/openshift/<image> 2
    1
    OpenShift Container Platform 3 클러스터의 레지스트리 URL 및 포트를 지정합니다.
    2
    OpenShift Container Platform 4 클러스터의 레지스트리 URL 및 포트를 지정합니다.
  7. OpenShift Container Platform 4 레지스트리에 이미지를 푸시합니다.

    $ podman push <registry_url>:<port>/openshift/<image> 1
    1
    OpenShift Container Platform 4 클러스터를 지정합니다.
  8. 이미지에 유효한 이미지 스트림이 있는지 확인합니다.

    $ oc get imagestream -n openshift | grep <image>

    출력 예

    NAME      IMAGE REPOSITORY                                                      TAGS    UPDATED
    my_image  image-registry.openshift-image-registry.svc:5000/openshift/my_image  latest  32 seconds ago

12.4.2. 직접 볼륨 마이그레이션이 완료되지 않음

직접 볼륨 마이그레이션이 완료되지 않으면 대상 클러스터에 소스 클러스터와 동일한 node-selector 주석이 없을 수 있습니다.

MTC(Migration Toolkit for Containers)는 보안 컨텍스트 제약 조건 및 스케줄링 요구 사항을 유지하기 위해 모든 주석이 있는 네임스페이스를 마이그레이션합니다. 직접 볼륨 마이그레이션 중에 MTC는 소스 클러스터에서 마이그레이션된 네임스페이스의 대상 클러스터에서 Rsync 전송 포드를 생성합니다. 대상 클러스터 네임스페이스에 소스 클러스터 네임스페이스와 동일한 주석이 없는 경우 Rsync 전송 포드를 예약할 수 없습니다. Rsync 포드는 Pending 상태로 유지됩니다.

다음 절차를 수행하여 이 문제를 확인하고 수정할 수 있습니다.

프로세스

  1. MigMigration CR의 상태를 확인합니다.

    $ oc describe migmigration <pod> -n openshift-migration

    출력에는 다음 상태 메시지가 포함됩니다.

    출력 예

    Some or all transfer pods are not running for more than 10 mins on destination cluster

  2. 소스 클러스터에서 마이그레이션된 네임스페이스의 세부 정보를 가져옵니다.

    $ oc get namespace <namespace> -o yaml 1
    1
    마이그레이션된 네임스페이스를 지정합니다.
  3. 대상 클러스터에서 마이그레이션된 네임스페이스를 편집합니다.

    $ oc edit namespace <namespace>
  4. 다음 예와 같이 마이그레이션된 네임스페이스에 누락된 openshift.io/node-selector 주석을 추가합니다.

    apiVersion: v1
    kind: Namespace
    metadata:
      annotations:
        openshift.io/node-selector: "region=east"
    ...
  5. 마이그레이션 계획을 다시 실행합니다.

12.4.3. 오류 메시지 및 해결 방법

이 섹션에서는 MTC(Migration Toolkit for Containers)에 발생할 수 있는 일반적인 오류 메시지와 근본적인 원인을 해결하는 방법을 설명합니다.

12.4.3.1. MTC 콘솔에 처음 액세스할 때 표시되는 CA 인증서 오류

MTC 콘솔에 액세스하려고 할 때 CA certificate error 메시지가 표시되면 클러스터 중 하나에서 자체 서명된 CA 인증서를 사용할 가능성이 높습니다.

이 문제를 해결하려면 오류 메시지에 표시된 oauth-authorization-server URL로 이동하여 인증서를 수락합니다. 이 문제를 영구적으로 해결하려면 웹 브라우저의 신뢰 저장소에 인증서를 추가합니다.

인증서를 승인한 후 Unauthorized 메시지가 표시되면 MTC 콘솔로 이동하여 웹 페이지를 새로 고칩니다.

12.4.3.2. MTC 콘솔의 OAuth 시간제한 오류

자체 서명 인증서를 허용한 후 MTC 콘솔에 connection has timed out 메시지가 표시되면 원인은 다음과 같습니다.

시간 초과 원인을 확인히려면 다음을 수행합니다.

  • 브라우저 웹 검사기를 사용하여 MTC 콘솔 웹 페이지를 확인합니다.
  • Migration UI pod 로그에 오류가 있는지 확인합니다.

12.4.3.3. 알 수 없는 권한 오류로 서명된 인증서

자체 서명된 인증서를 사용하여 MTC(Migration Toolkit for Containers)의 클러스터 또는 복제 리포지토리를 보호하는 경우 Certificate signed by unknown authority 오류 메시지와 함께 인증서 확인에 실패할 수 있습니다.

사용자 정의 CA 인증서 번들 파일을 생성하고 클러스터 또는 복제 리포지토리를 추가할 때 MTC 웹 콘솔에 업로드할 수 있습니다.

프로세스

원격 끝점에서 CA 인증서를 다운로드하여 CA 번들 파일로 저장합니다.

$ echo -n | openssl s_client -connect <host_FQDN>:<port> \ 1
  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > <ca_bundle.cert> 2
1
끝점의 호스트 FQDN 및 포트를 지정합니다(예: api.my-cluster.example.com:6443).
2
CA 번들 파일의 이름을 지정합니다.

12.4.3.4. Velero pod 로그의 백업 스토리지 위치 오류

Velero Backup 사용자 정의 리소스에 존재하지 않는 백업 스토리지 위치(BSL)에 대한 참조가 포함된 경우 Velero Pod 로그에 다음과 같은 오류 메시지가 표시될 수 있습니다.

$ oc logs <Velero_Pod> -n openshift-migration

출력 예

level=error msg="Error checking repository for stale locks" error="error getting backup storage location: BackupStorageLocation.velero.io \"ts-dpa-1\" not found" error.file="/remote-source/src/github.com/vmware-tanzu/velero/pkg/restic/repository_manager.go:259"

이러한 오류 메시지는 무시해도 됩니다. 누락된 BSL로 인해 마이그레이션이 실패하지는 않습니다.

12.4.3.5. Velero Pod 로그의 Pod 볼륨 백업 시간 초과 오류

Restic 시간제한으로 인해 마이그레이션이 실패하면 Velero pod 로그에 다음 오류가 표시됩니다.

level=error msg="Error backing up item" backup=velero/monitoring error="timed out waiting for all PodVolumeBackups to complete" error.file="/go/src/github.com/heptio/velero/pkg/restic/backupper.go:165" error.function="github.com/heptio/velero/pkg/restic.(*backupper).BackupPodVolumes" group=v1

restic_timeout의 기본값은 1 시간입니다. 값이 클수록 오류 메시지 반환이 지연될 수 있다는 점을 염두에 두고 대규모 마이그레이션의 경우 이 매개 변수를 늘릴 수 있습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 Operator설치된 Operator로 이동합니다.
  2. Migration Toolkit for Containers Operator를 클릭합니다.
  3. MigrationController 탭에서 migration-controller를 클릭합니다.
  4. YAML 탭에서 다음 매개 변수 값을 업데이트합니다.

    spec:
      restic_timeout: 1h 1
    1
    유효한 단위는 h(시간), m(분) 및 s(초)입니다(예: 3h30m15s).
  5. 저장을 클릭합니다.

12.4.3.6. MigMigration 사용자 지정 리소스의 제한적 유효성 검사 오류

파일 시스템 데이터 복사 방법을 사용하여 영구 볼륨을 마이그레이션할 때 데이터 확인에 실패하면 MigMigration CR에 다음 오류가 표시됩니다.

출력 예

status:
  conditions:
  - category: Warn
    durable: true
    lastTransitionTime: 2020-04-16T20:35:16Z
    message: There were verify errors found in 1 Restic volume restores. See restore `<registry-example-migration-rvwcm>`
      for details 1
    status: "True"
    type: ResticVerifyErrors 2

1
오류 메시지는 Restore CR 이름을 식별합니다.
2
ResticVerifyErrors는 확인 오류가 포함된 일반적인 오류 경고 유형입니다.
참고

데이터 확인 오류로 인해 마이그레이션 프로세스가 실패하지 않습니다.

Restore CR을 확인하여 데이터 확인 오류의 원인을 식별할 수 있습니다.

프로세스

  1. 대상 클러스터에 로그인합니다.
  2. Restore CR을 보기:

    $ oc describe <registry-example-migration-rvwcm> -n openshift-migration

    출력은 PodVolumeRestore 오류가 있는 영구 볼륨을 식별합니다.

    출력 예

    status:
      phase: Completed
      podVolumeRestoreErrors:
      - kind: PodVolumeRestore
        name: <registry-example-migration-rvwcm-98t49>
        namespace: openshift-migration
      podVolumeRestoreResticErrors:
      - kind: PodVolumeRestore
        name: <registry-example-migration-rvwcm-98t49>
        namespace: openshift-migration

  3. PodVolumeRestore CR 보기:

    $ oc describe <migration-example-rvwcm-98t49>

    출력은 오류를 기록한 Restic pod를 식별합니다.

    출력 예

      completionTimestamp: 2020-05-01T20:49:12Z
      errors: 1
      resticErrors: 1
      ...
      resticPod: <restic-nr2v5>

  4. Restic pod 로그를 보고 오류를 찾습니다.

    $ oc logs -f <restic-nr2v5>

12.4.3.7. root_squash가 활성화된 NFS 스토리지에서 마이그레이션할 때 Restic 권한 오류

NFS 스토리지에서 데이터를 마이그레이션 중이고 root_squash가 활성화된 경우 Resticnfsnobody에 매핑되고 마이그레이션을 수행할 수 있는 권한이 없습니다. Restic Pod 로그에 다음 오류가 표시됩니다.

출력 예

backup=openshift-migration/<backup_id> controller=pod-volume-backup error="fork/exec /usr/bin/restic: permission denied" error.file="/go/src/github.com/vmware-tanzu/velero/pkg/controller/pod_volume_backup_controller.go:280" error.function="github.com/vmware-tanzu/velero/pkg/controller.(*podVolumeBackupController).processBackup" logSource="pkg/controller/pod_volume_backup_controller.go:280" name=<backup_id> namespace=openshift-migration

Restic의 추가 그룹을 생성하고 MigrationController CR 매니페스트에 그룹 ID를 추가하여 이 문제를 해결할 수 있습니다.

절차

  1. NFS 스토리지에서 Restic에 대한 보조 그룹을 생성합니다.
  2. 그룹 소유권이 상속되도록 NFS 디렉터리에 setgid 비트를 설정합니다.
  3. 소스 및 대상 클러스터의 MigrationController CR 매니페스트에 restic_supplemental_groups 매개변수를 추가합니다.

    spec:
      restic_supplemental_groups: <group_id> 1
    1
    보조 그룹 ID를 지정합니다.
  4. 변경 사항을 적용할 수 있도록 Restic Pod가 다시 시작될 때까지 기다립니다.

12.4.4. 확인된 문제

이 릴리스에는 다음과 같은 알려진 문제가 있습니다.

  • 마이그레이션 중에 MTC(Migration Toolkit for Containers)는 다음 네임스페이스 주석을 유지합니다.

    • openshift.io/sa.scc.mcs
    • openshift.io/sa.scc.supplemental-groups
    • openshift.io/sa.scc.uid-range

      이러한 주석은 UID 범위를 유지하여 컨테이너가 대상 클러스터에 대한 파일 시스템 권한을 유지하도록 합니다. 마이그레이션된 UID가 대상 클러스터의 기존 또는 향후 네임스페이스 내에서 UID를 복제할 위험이 있습니다. (BZ#1748440)

  • 대부분의 클러스터 범위 리소스는 아직 MTC에서 처리되지 않습니다. 애플리케이션에 클러스터 범위의 리소스가 필요한 경우 대상 클러스터에서 수동으로 리소스를 생성해야 할 수 있습니다.
  • 마이그레이션이 실패하면 마이그레이션 계획에 quiesced 포드의 사용자 정의 PV 설정이 유지되지 않습니다. 마이그레이션을 수동으로 롤백하고 마이그레이션 계획을 삭제하고 PV 설정으로 새 마이그레이션 계획을 생성해야 합니다. (BZ#1784899)
  • Restic 시간이 초과되어 대규모 마이그레이션이 실패하는 경우 MigrationController 사용자 지정 (CR) 매니페스트에서 restic_timeout 매개 변수 값(기본값: 1h)을 늘릴 수 있습니다.
  • 파일 시스템 복사 방법으로 마이그레이션된 PV에 대해 데이터 확인 옵션을 선택하면 성능이 상당히 느려집니다.
  • NFS 스토리지에서 데이터를 마이그레이션하고 root_squash가 활성화된 경우 Resticnfsnobody에 매핑합니다. 마이그레이션이 실패하고 Restic pod 로그에 권한 오류가 표시됩니다. (BZ#1873641)

    Restic에 대한 추가 그룹을 MigrationController CR 매니페스트에 추가하여 이 문제를 해결할 수 있습니다.

    spec:
    ...
      restic_supplemental_groups:
      - 5555
      - 6666
  • 다른 가용성 영역 또는 가용성 세트에 있는 노드에서 직접 볼륨 마이그레이션을 수행하는 경우 마이그레이션된 Pod가 PVC에 액세스할 수 없기 때문에 마이그레이션이 실패할 수 있습니다. (BZ#1947487)