절차

1. 클라이언트와 대상 클러스터 간에 애플리케이션 로드 밸런서 또는 역방향 프록시와 같은 기타 네트워크 구성 요소를 배치합니다.
2. DNS 서버의 소스 클러스터에서 애플리케이션 FQDN을 업데이트하여 가상 네트워크 구성 요소의 IP 주소를 반환합니다.
3. 소스 도메인의 애플리케이션에 대해 수신된 요청을 대상 클러스터 도메인의 로드 밸런서에 보내도록 네트워크 구성 요소를 구성합니다.
4. 소스 클러스터의 로드 밸런서의 IP 주소를 가리키는 *.apps.source.example.com 도메인에 대한 와일드카드 DNS 레코드를 만듭니다.
5. 대상 클러스터 앞의 브릿지 네트워크 구성 요소의 IP 주소를 가리키는 각 애플리케이션에 대한 DNS 레코드를 만듭니다. 특정 DNS 레코드는 와일드카드 레코드보다 우선 순위가 높으므로 애플리케이션 FQDN이 확인되면 충돌이 발생하지 않습니다.

1. 소스 클러스터에서 애플리케이션의 FQDN으로 주소가 지정된 요청을 수락하도록 구성된 대상 클러스터의 프로젝트에서 경로를 생성합니다.

   $ oc expose svc <app1-svc> --hostname <app1.apps.source.example.com> \
    -n <app1-namespace>

   이 새 경로를 적용하면 서버는 해당 FQDN에 대한 모든 요청을 수락하고 해당 애플리케이션 포드로 보냅니다. 또한 애플리케이션을 마이그레이션하면 대상 클러스터 도메인에 또 다른 경로가 생성됩니다. 요청은 이러한 호스트 이름 중 하나를 사용하여 마이그레이션된 애플리케이션에 연결합니다.

2. 소스 클러스터의 애플리케이션의 FQDN을 가리키고 대상 클러스터의 기본 로드 밸런서의 IP 주소를 가리키는 DNS 공급자를 사용하여 DNS 레코드를 생성합니다. 그러면 소스 클러스터에서 대상 클러스터로 트래픽이 리디렉션됩니다.

   애플리케이션의 FQDN은 대상 클러스터의 로드 밸런서로 확인됩니다. 기본 수신 컨트롤러 라우터는 해당 호스트 이름의 경로가 노출되므로 해당 FQDN에 대한 요청을 수락합니다.

1. 설치 프로세스 중에 생성된 기본 수신 컨트롤러의 x509 인증서를 사용자 지정 인증서로 교체합니다.

2. subjectAltName 필드에 소스 및 대상 클러스터의 와일드카드 DNS 도메인을 포함하도록 이 인증서를 구성합니다.

   새 인증서는 DNS 도메인을 사용하여 만든 연결 보안에 유효합니다.

절차

1. NooBaa 사용자 지정 리소스에서 describe 명령을 실행하여 S3 엔드포인트 AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY를 가져옵니다.

   이러한 인증 정보를 사용하여 MCG를 복제 리포지토리로 추가합니다.

절차

1. BUCKET 변수를 설정합니다.

   $ BUCKET=<your_bucket>

2. REGION 변수를 설정합니다.

   $ REGION=<your_region>

3. AWS S3 버킷을 생성합니다.

   $ aws s3api create-bucket \
       --bucket $BUCKET \
       --region $REGION \
       --create-bucket-configuration LocationConstraint=$REGION 1

   1

   us-east-1 은 LocationConstraint를 지원하지 않습니다. 해당 리전이 us-east-1 인 경우 --create-bucket-configuration LocationConstraint=$REGION 을 생략합니다.

4. IAM 사용자를 생성합니다.

   $ aws iam create-user --user-name velero 1

   1

   Velero를 사용하여 S3 버킷이 여러 개 있는 여러 클러스터를 백업하려면 각 클러스터에 고유한 사용자 이름을 생성합니다.

5. a velero-policy.json 파일을 생성합니다.

   $ cat > velero-policy.json <<EOF
   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "ec2:DescribeVolumes",
                   "ec2:DescribeSnapshots",
                   "ec2:CreateTags",
                   "ec2:CreateVolume",
                   "ec2:CreateSnapshot",
                   "ec2:DeleteSnapshot"
               ],
               "Resource": "*"
           },
           {
               "Effect": "Allow",
               "Action": [
                   "s3:GetObject",
                   "s3:DeleteObject",
                   "s3:PutObject",
                   "s3:AbortMultipartUpload",
                   "s3:ListMultipartUploadParts"
               ],
               "Resource": [
                   "arn:aws:s3:::${BUCKET}/*"
               ]
           },
           {
               "Effect": "Allow",
               "Action": [
                   "s3:ListBucket"
               ],
               "Resource": [
                   "arn:aws:s3:::${BUCKET}"
               ]
           }
       ]
   }
   EOF

6. velero 사용자에게 필요한 권한을 부여하도록 정책을 연결합니다.

   $ aws iam put-user-policy \
     --user-name velero \
     --policy-name velero \
     --policy-document file://velero-policy.json

7. velero 사용자에 대한 액세스 키를 생성합니다.

   $ aws iam create-access-key --user-name velero

   출력 예

   {
     "AccessKey": {
           "UserName": "velero",
           "Status": "Active",
           "CreateDate": "2017-07-31T22:24:41.576Z",
           "SecretAccessKey": <AWS_SECRET_ACCESS_KEY>,
           "AccessKeyId": <AWS_ACCESS_KEY_ID>
     }
   }

   AWS_SECRET_ACCESS_KEY 및 AWS_ACCESS_KEY_ID 를 기록합니다. 인증 정보를 사용하여 AWS를 복제 리포지토리로 추가합니다.

프로세스

1. GCP에 로그인합니다.

   $ gcloud auth login

2. BUCKET 변수를 설정합니다.

   $ BUCKET=<bucket> 1

   1

   버킷 이름을 지정합니다.

3. 스토리지 버킷을 생성합니다.

   $ gsutil mb gs://$BUCKET/

4. PROJECT_ID 변수를 활성 프로젝트로 설정합니다.

   $ PROJECT_ID=$(gcloud config get-value project)

5. 서비스 계정을 생성합니다.

   $ gcloud iam service-accounts create velero \
       --display-name "Velero service account"

6. 서비스 계정을 나열합니다.

   $ gcloud iam service-accounts list

7. 이메일 값과 일치하도록 SERVICE_ACCOUNT_EMAIL 변수를 설정합니다.

   $ SERVICE_ACCOUNT_EMAIL=$(gcloud iam service-accounts list \
       --filter="displayName:Velero service account" \
       --format 'value(email)')

8. velero 사용자에게 필요한 권한을 부여하도록 정책을 연결합니다.

   $ ROLE_PERMISSIONS=(
       compute.disks.get
       compute.disks.create
       compute.disks.createSnapshot
       compute.snapshots.get
       compute.snapshots.create
       compute.snapshots.useReadOnly
       compute.snapshots.delete
       compute.zones.get
   )

9. velero.server 사용자 정의 역할을 생성합니다.

   $ gcloud iam roles create velero.server \
       --project $PROJECT_ID \
       --title "Velero Server" \
       --permissions "$(IFS=","; echo "${ROLE_PERMISSIONS[*]}")"

10. 프로젝트에 IAM 정책 바인딩을 추가합니다.

    $ gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member serviceAccount:$SERVICE_ACCOUNT_EMAIL \
        --role projects/$PROJECT_ID/roles/velero.server

11. IAM 서비스 계정을 업데이트합니다.

    $ gsutil iam ch serviceAccount:$SERVICE_ACCOUNT_EMAIL:objectAdmin gs://${BUCKET}

12. IAM 서비스 계정 키를 현재 디렉터리의 credentials-velero 파일에 저장합니다.

    $ gcloud iam service-accounts keys create credentials-velero \
        --iam-account $SERVICE_ACCOUNT_EMAIL

    credentials-velero 파일을 사용하여 GCP를 복제 리포지토리로 추가합니다.

프로세스

1. Azure에 로그인합니다.

   $ az login

2. AZURE_RESOURCE_GROUP 변수를 설정합니다.

   $ AZURE_RESOURCE_GROUP=Velero_Backups

3. Azure 리소스 그룹을 생성합니다.

   $ az group create -n $AZURE_RESOURCE_GROUP --location CentralUS 1

   1

   위치를 지정합니다.

4. AZURE_STORAGE_ACCOUNT_ID 변수를 설정합니다.

   $ AZURE_STORAGE_ACCOUNT_ID="velero$(uuidgen | cut -d '-' -f5 | tr '[A-Z]' '[a-z]')"

5. Azure 스토리지 계정을 생성합니다.

   $ az storage account create \
       --name $AZURE_STORAGE_ACCOUNT_ID \
       --resource-group $AZURE_BACKUP_RESOURCE_GROUP \
       --sku Standard_GRS \
       --encryption-services blob \
       --https-only true \
       --kind BlobStorage \
       --access-tier Hot

6. BLOB_CONTAINER 변수를 설정합니다.

   $ BLOB_CONTAINER=velero

7. Azure Blob 스토리지 컨테이너를 생성합니다.

   $ az storage container create \
     -n $BLOB_CONTAINER \
     --public-access off \
     --account-name $AZURE_STORAGE_ACCOUNT_ID

8. velero에 대한 서비스 주체 및 자격 증명을 생성합니다.

   $ AZURE_SUBSCRIPTION_ID=`az account list --query '[?isDefault].id' -o tsv` \
     AZURE_TENANT_ID=`az account list --query '[?isDefault].tenantId' -o tsv` \
     AZURE_CLIENT_SECRET=`az ad sp create-for-rbac --name "velero" \
     --role "Contributor" --query 'password' -o tsv` \
     AZURE_CLIENT_ID=`az ad sp list --display-name "velero" \
     --query '[0].appId' -o tsv`

9. credentials-velero 파일에 서비스 주체 자격 증명을 저장합니다.

   $ cat << EOF > ./credentials-velero
   AZURE_SUBSCRIPTION_ID=${AZURE_SUBSCRIPTION_ID}
   AZURE_TENANT_ID=${AZURE_TENANT_ID}
   AZURE_CLIENT_ID=${AZURE_CLIENT_ID}
   AZURE_CLIENT_SECRET=${AZURE_CLIENT_SECRET}
   AZURE_RESOURCE_GROUP=${AZURE_RESOURCE_GROUP}
   AZURE_CLOUD_NAME=AzurePublicCloud
   EOF

   credentials-velero 파일을 사용하여 Azure를 복제 리포지토리로 추가합니다.

절차

1. NooBaa 사용자 지정 리소스에서 describe 명령을 실행하여 S3 엔드포인트 AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY를 가져옵니다.

절차

1. MTC를 설치한 OpenShift Container Platform 클러스터에 로그인합니다.

2. 다음 명령을 입력하여 MTC 웹 콘솔 URL을 확보합니다.

   $ oc get -n openshift-migration route/migration -o go-template='https://{{ .spec.host }}'

   출력은 https://migration-openshift-migration.apps.cluster.openshift.com과 유사합니다.

3. 브라우저를 시작하고 MTC 웹 콘솔로 이동합니다.

   참고

   Migration Toolkit for Containers Operator를 설치한 직후 MTC 웹 콘솔에 액세스하려고 하면 Operator가 여전히 클러스터를 구성하고 있기 때문에 콘솔이 로드되지 않을 수 있습니다. 몇 분 기다렸다가 다시 시도하십시오.

4. 자체 서명된 CA 인증서를 사용하는 경우 소스 클러스터 API 서버의 CA 인증서를 수락하라는 메시지가 표시됩니다. 웹 페이지는 나머지 인증서 수락 프로세스를 안내합니다.
5. OpenShift Container Platform 사용자 이름 및 암호로 로그인합니다.

절차

1. 클러스터에 로그인합니다.

2. migration-controller 서비스 계정 토큰을 확보합니다.

   $ oc sa get-token migration-controller -n openshift-migration

   출력 예

   eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJtaWciLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoibWlnLXRva2VuLWs4dDJyIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6Im1pZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImE1YjFiYWMwLWMxYmYtMTFlOS05Y2NiLTAyOWRmODYwYjMwOCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDptaWc6bWlnIn0.xqeeAINK7UXpdRqAtOj70qhBJPeMwmgLomV9iFxr5RoqUgKchZRG2J2rkqmPm6vr7K-cm7ibD1IBpdQJCcVDuoHYsFgV4mp9vgOfn9osSDp2TGikwNz4Az95e81xnjVUmzh-NjDsEpw71DH92iHV_xt2sTwtzftS49LpPW2LjrV0evtNBP_t_RfskdArt5VSv25eORl7zScqfe1CiMkcVbf2UqACQjo3LbkpfN26HAioO2oH0ECPiRzT0Xyh-KwFutJLS9Xgghyw-LD9kPKcE_xbbJ9Y4Rqajh7WdPYuB0Jd9DPVrslmzK-F6cgHHYoZEv0SvLQi-PO0rpDrcjOEQQ

3. MTC 웹 콘솔에서 클러스터를 클릭합니다.
4. 클러스터 추가를 클릭합니다.

5. 다음 필드를 작성합니다.

   • 클러스터 이름: 클러스터 이름은 소문자(a-z) 및 숫자(0-9)를 포함할 수있습니다. 공백이나 국제 문자를 포함해서는 안 됩니다.
   • URL: API 서버 URL을 지정합니다(예: https://<www.example.com>:8443 ).
   • 서비스 계정 토큰: migration-controller 서비스 계정 토큰을 붙여넣습니다.

   • 이미지 레지스트리에 노출된 경로 호스트: 직접 이미지 마이그레이션을 사용하는 경우 소스 클러스터의 이미지 레지스트리에 노출된 경로를 지정합니다(예: www.example.apps.cluster.com).

     포트를 지정할 수 있습니다. 기본 포트는 5000입니다.

   • Azure 클러스터: Azure 스냅샷을 사용하여 데이터를 복사하는 경우 이 옵션을 선택해야 합니다.
   • Azure 리소스 그룹: Azure 클러스터가 선택된 경우 이 필드가 표시됩니다. Azure 리소스 그룹을 지정합니다.
   • SSL 확인 필요 : 선택 사항: 이 옵션을 선택하여 클러스터에 대한 SSL 연결을 확인합니다.
   • CA 번들 파일: Require SSL 확인이 선택되어 있으면 이 필드가 표시됩니다. 자체 서명된 인증서에 대한 사용자 정의 CA 인증서 번들 파일을 생성한 경우 찾아보기를 클릭하고 CA 번들 파일을 선택하여 업로드합니다.

6. 클러스터 추가를 클릭합니다.

   클러스터가 클러스터 목록에 나타납니다.

프로세스

1. MTC 웹 콘솔에서 복제 리포지토리를 클릭합니다.
2. 리포지토리 추가를 클릭합니다.

3. 스토리지 공급자 유형을 선택하고 다음 필드를 작성합니다.

   • AWS 및 MCG를 포함한 S3 공급자용 AWS:

     • 복제 리포지터리 이름: MTC 웹 콘솔에서 복제 리포지토리 이름을 지정합니다.
     • S3 버킷 이름: S3 버킷의 이름을 지정합니다.
     • S3 버킷 영역: S3 버킷 리전을 지정합니다. AWS S3의 경우 필수입니다. 일부 S3 공급자의 경우 선택 사항입니다. S3 공급자의 제품 문서에서 예상되는 값을 확인합니다.
     • S3 끝점: 버킷이 아닌 S3 서비스의 URL을 지정합니다(예: https://<s3-storage.apps.cluster.com&gt;). 일반 S3 공급자의 경우 필수입니다. https:// 접두사를 사용해야 합니다.
     • S3 공급자 액세스 키: AWS의 경우 <AWS_SECRET_ACCESS_KEY> 또는 MCG 및 기타 S3 공급자의 경우 S3 공급자 액세스 키를 지정합니다.
     • S3 공급자 보안 액세스 키: AWS의 경우 <AWS_ACCESS_KEY_ID> 또는 MCG 및 기타 S3 공급자의 경우 S3 공급자 보안 액세스 키를 지정합니다.
     • SSL 확인 필요 : 일반 S3 공급자를 사용하는 경우 이 확인란을 지웁니다.
     • 자체 서명된 인증서에 대한 사용자 정의 CA 인증서 번들 파일을 생성한 경우 검색을 클릭하고 Base64로 인코딩된 파일을 검색합니다.

   • GCP:

     • 복제 리포지터리 이름: MTC 웹 콘솔에서 복제 리포지토리 이름을 지정합니다.
     • GCP 버킷 이름: GCP 버킷의 이름을 지정합니다.
     • GCP 자격 증명 JSON blob: credentials-velero 파일에서 문자열을 지정합니다.

   • Azure:

     • 복제 리포지터리 이름: MTC 웹 콘솔에서 복제 리포지토리 이름을 지정합니다.
     • Azure 리소스 그룹: Azure Blob 스토리지의 리소스 그룹을 지정합니다.
     • Azure 스토리지 계정 이름: Azure Blob 스토리지 계정 이름을 지정합니다.
     • Azure 인증 정보 - INI 파일 콘텐츠: credentials-velero 파일에서 문자열을 지정합니다.
4. 리포지토리 추가를 클릭하고 연결 유효성 검사를 기다립니다.

5. 닫기를 클릭합니다.

   새 리포지토리가 복제 리포지토리 목록에 나타납니다.

절차

1. MTC 웹 콘솔에서 마이그레이션 계획을 클릭합니다.
2. 마이그레이션 계획 추가를 클릭합니다.

3. 계획 이름을 입력합니다.

   마이그레이션 계획 이름에서 253자의 소문자 영숫자(a-z, 0-9)를 초과해서는 안 되며 공백이나 밑줄(_)을 포함해서는 안 됩니다.

4. 소스 클러스터, 대상 클러스터, 리포지토리를 선택하고 다음을 클릭합니다.
5. 네임스페이스 페이지에서 마이그레이션할 프로젝트를 선택하고 다음을 클릭합니다.

6. 영구 볼륨 페이지에서 각 PV의 마이그레이션 유형을 클릭합니다.

   • 복사 옵션은 소스 클러스터의 PV에 있는 데이터를 복제 리포지토리에 복사한 다음 대상 클러스터에서 비슷한 특성을 가진 새로 생성된 PV에 데이터를 복원합니다.
   • 이동 옵션은 소스 클러스터에서 원격 볼륨(예: NFS)을 마운트 해제하고 원격 볼륨을 가리키는 대상 클러스터에 PV 리소스를 생성한 다음 대상 클러스터에 원격 볼륨을 마운트합니다. 대상 클러스터에서 실행되는 애플리케이션은 소스 클러스터와 동일한 원격 볼륨을 사용합니다.
7. 다음을 클릭합니다.

8. 복사 옵션 페이지에서 각 PV에 대한 복사 방법을 선택합니다.

   • 스냅샷 복사는 클라우드 공급자의 스냅샷 기능을 사용하여 데이터를 백업 및 복원합니다. 파일 시스템 복사.보다 훨씬 빠릅니다.

   • 파일 시스템 복사는 소스 클러스터에서 파일을 백업하고 대상 클러스터에서 해당 파일을 복원합니다.

     직접 볼륨 마이그레이션에는 파일 시스템 복사 방법이 필요합니다.

9. 복사 확인을 선택하여 파일 시스템 복사로 마이그레이션된 데이터를 확인할 수 있습니다. 데이터는 각 소스 파일에 대한 체크섬을 생성하고 복원 후 체크섬을 확인합니다. 데이터 확인으로 성능이 크게 저하합니다.

10. 대상 스토리지 클래스를 선택합니다.

    파일 시스템 복사를 선택한 경우 대상 스토리지 클래스를 변경할 수 있습니다.

11. 다음을 클릭합니다.

12. 마이그레이션 옵션 페이지에서 소스 클러스터에 대해 노출된 이미지 레지스트리 경로를 지정한 경우 직접 이미지 마이그레이션 옵션이 선택됩니다. 파일 시스템 복사로 데이터를 마이그레이션하는 경우 직접 PV 마이그레이션 옵션이 선택됩니다.

    직접 마이그레이션 옵션은 소스 클러스터에서 대상 클러스터로 직접 이미지 및 파일을 복사합니다. 이 옵션은 소스 클러스터에서 복제 리포지토리로 이미지 및 파일을 복사한 다음 복제 리포지토리에서 대상 클러스터로 복사합니다.

13. 다음을 클릭합니다.

14. 선택 사항: 후크 페이지에서 후크 추가를 클릭하여 마이그레이션 계획에 후크를 추가합니다.

    후크는 사용자 지정 코드를 실행합니다. 단일 마이그레이션 계획에 최대 4개의 후크를 추가할 수 있습니다. 각 후크는 다른 마이그레이션 단계에서 실행됩니다.

    1. 웹 콘솔에 표시할 후크 이름을 입력합니다.
    2. 후크가 Ansible 플레이북인 경우 Ansible 플레이북을 선택하고 찾아보기를 클릭하여 플레이북을 업로드하거나 필드에 플레이북 콘텐츠를 붙여넣습니다.
    3. 선택 사항: 기본 후크 이미지를 사용하지 않는 경우 Ansible 런타임 이미지를 지정합니다.

    4. 후크가 Ansible 플레이북이 아닌 경우 사용자 정의 컨테이너 이미지를 선택하고 이미지 이름과 경로를 지정합니다.

       사용자 정의 컨테이너 이미지에는 Ansible 플레이북이 포함될 수 있습니다.

    5. 소스 클러스터 또는 대상 클러스터를 선택합니다.
    6. 서비스 계정 이름과 서비스 계정 네임스페이스를 입력합니다.

    7. 후크의 마이그레이션 단계를 선택합니다.

       • preBackup: 애플리케이션 워크로드를 소스 클러스터에서 백업하기 전에
       • postBackup: 소스 클러스터에서 애플리케이션 워크로드를 백업한 후
       • preRestore: 대상 클러스터에서 애플리케이션 워크로드를 복원하기 전에
       • postRestore: 대상 클러스터에서 애플리케이션 워크로드를 복원한 후
    8. 추가를 클릭합니다.

15. 완료를 클릭합니다.

    마이그레이션 계획이 마이그레이션 계획 목록에 표시됩니다.

절차

1. MTC 웹 콘솔에 로그인하고 마이그레이션 계획을 클릭합니다.

2. 마이그레이션 계획 옆에 있는 옵션 메뉴를 클릭하고 마이그레이션에서 다음 옵션 중 하나를 선택합니다.

   • 스테이지에서는 애플리케이션을 중지하지 않고 소스 클러스터에서 대상 클러스터로 데이터를 복사합니다.

   • 컷오버는 소스 클러스터에서 트랜잭션을 중지하고 리소스를 대상 클러스터로 이동합니다.

     선택 사항: 단축 마이그레이션 대화 상자에서 마이그레이션 중에 소스 클러스터에서 Halt 트랜잭션을 지울 수 있습니다.

   • 스테이지는 애플리케이션 상태를 구성하는 선택한 PVC(영구 볼륨 클레임) 및 Kubernetes 리소스를 복사합니다. 상태 마이그레이션을 사용하여 동일한 클러스터 내에서 네임스페이스를 마이그레이션할 수 있습니다.

     중요

     클러스터 간에 네임스페이스를 마이그레이션하는 데 상태 마이그레이션을 사용하지 마십시오. 대신 스테이지 또는 컷오버 마이그레이션을 사용합니다.

     • 상태 마이그레이션 대화 상자에서 하나 이상의 PVC를 선택하고 마이그레이션을 클릭합니다.

3. 마이그레이션이 완료되면 OpenShift Container Platform 웹 콘솔에서 애플리케이션이 성공적으로 마이그레이션되었는지 확인합니다.

   1. 홈 → 프로젝트를 클릭합니다.
   2. 마이그레이션된 프로젝트를 클릭하여 상태를 봅니다.
   3. 경로 섹션에서 위치를 클릭하여 해당되는 경우 애플리케이션이 작동하는지 확인합니다.
   4. 워크로드 → 포드를 클릭하여 포드가 마이그레이션된 네임스페이스에서 실행 중인지 확인합니다.
   5. 스토리지 → 영구 볼륨을 클릭하여 마이그레이션된 영구 볼륨이 올바르게 프로비저닝되었는지 확인합니다.

절차

1. MigrationController CR 매니페스트를 가져옵니다.

   $ oc get migrationcontroller <migration_controller> -n openshift-migration

2. 프록시 매개변수를 업데이트합니다.

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigrationController
   metadata:
     name: <migration_controller>
     namespace: openshift-migration
   ...
   spec:
     stunnel_tcp_proxy: http://<username>:<password>@<ip>:<port> 1
     httpProxy: http://<username>:<password>@<ip>:<port> 2
     httpsProxy: http://<username>:<password>@<ip>:<port> 3
     noProxy: example.com 4

   1

   직접 볼륨 마이그레이션을 위한 Stunnel 프록시 URL입니다.

   2

   클러스터 외부에서 HTTP 연결을 생성하기 위한 프록시 URL입니다. URL 스키마는 http여야 합니다.

   3

   클러스터 외부에서 HTTPS 연결을 생성하기 위한 프록시 URL입니다. 이 값을 지정하지 않으면 HTTP 및 HTTPS 연결에 모두 httpProxy가 사용됩니다.

   4

   프록시를 제외할 대상 도메인 이름, 도메인, IP 주소 또는 기타 네트워크 CIDR의 쉼표로 구분된 목록입니다.

   하위 도메인과 일치하려면 도메인 앞에 .을 입력합니다. 예를 들어, .y.com은 x.y.com과 일치하지만 y.com은 일치하지 않습니다. *를 사용하여 모든 대상에 대해 프록시를 바이패스합니다. networking.machineNetwork[].cidr 필드에 의해 정의된 네트워크에 포함되어 있지 않은 작업자를 설치 구성에서 확장하려면 연결 문제를 방지하기 위해 이 목록에 해당 작업자를 추가해야 합니다.

   httpProxy 또는 httpsProxy 필드가 설정되지 않은 경우 이 필드는 무시됩니다.

3. 매니페스트를 migration-controller.yaml로 저장합니다.

4. 업데이트된 매니페스트를 적용합니다.

   $ oc replace -f migration-controller.yaml -n openshift-migration

절차

1. 호스트 클러스터에 대한 MigCluster CR 매니페스트를 생성합니다.

   $ cat << EOF | oc apply -f -
   apiVersion: migration.openshift.io/v1alpha1
   kind: MigCluster
   metadata:
     name: <host_cluster>
     namespace: openshift-migration
   spec:
     isHostCluster: true
   EOF

2. 각 원격 클러스터에 대한 Secret 오브젝트 매니페스트를 생성합니다.

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Secret
   metadata:
     name: <cluster_secret>
     namespace: openshift-config
   type: Opaque
   data:
     saToken: <sa_token> 1
   EOF

   1

   원격 클러스터의 base64로 인코딩된 migration-controller 서비스 계정(SA) 토큰을 지정합니다. 다음 명령을 실행하여 토큰을 가져올 수 있습니다.

   $ oc sa get-token migration-controller -n openshift-migration | base64 -w 0

3. 각 원격 클러스터에 대해 MigCluster CR 매니페스트를 생성합니다.

   $ cat << EOF | oc apply -f -
   apiVersion: migration.openshift.io/v1alpha1
   kind: MigCluster
   metadata:
     name: <remote_cluster> 1
     namespace: openshift-migration
   spec:
     exposedRegistryPath: <exposed_registry_route> 2
     insecure: false 3
     isHostCluster: false
     serviceAccountSecretRef:
       name: <remote_cluster_secret> 4
       namespace: openshift-config
     url: <remote_cluster_url> 5
   EOF

   1

   원격 클러스터의 Cluster CR을 지정합니다.

   2

   선택 사항: 직접 이미지 마이그레이션의 경우 노출된 레지스트리 경로를 지정합니다.

   3

   false인 경우 SSL 확인이 활성화됩니다. CA 인증서가 필요하지 않거나 true인 경우 확인되지 않습니다.

   4

   원격 클러스터의 Secret 오브젝트를 지정합니다.

   5

   원격 클러스터의 URL을 지정합니다.

4. 모든 클러스터가 Ready 상태에 있는지 확인합니다.

   $ oc describe cluster <cluster>

5. 복제 리포지토리의 Secret 오브젝트 매니페스트를 생성합니다.

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Secret
   metadata:
     namespace: openshift-config
     name: <migstorage_creds>
   type: Opaque
   data:
     aws-access-key-id: <key_id_base64> 1
     aws-secret-access-key: <secret_key_base64> 2
   EOF

   1

   base64 형식으로 키 ID를 지정합니다.

   2

   base64 형식으로 시크릿 키를 지정합니다.

   AWS 인증 정보는 기본적으로 base64로 인코딩됩니다. 다른 스토리지 공급자의 경우 각 키로 다음 명령을 실행하여 인증 정보를 인코딩해야 합니다.

   $ echo -n "<key>" | base64 -w 0 1

   1

   키 ID 또는 시크릿 키를 지정합니다. 두 키 모두 base64로 인코딩되어야 합니다.

6. 복제 리포지토리에 대한 MigStorage CR 매니페스트를 생성합니다.

   $ cat << EOF | oc apply -f -
   apiVersion: migration.openshift.io/v1alpha1
   kind: MigStorage
   metadata:
     name: <migstorage>
     namespace: openshift-migration
   spec:
     backupStorageConfig:
       awsBucketName: <bucket> 1
       credsSecretRef:
         name: <storage_secret> 2
         namespace: openshift-config
     backupStorageProvider: <storage_provider> 3
     volumeSnapshotConfig:
       credsSecretRef:
         name: <storage_secret> 4
         namespace: openshift-config
     volumeSnapshotProvider: <storage_provider> 5
   EOF

   1

   버킷 이름을 지정합니다.

   2

   오브젝트 스토리지의 Secrets CR을 지정합니다. 오브젝트 스토리지의 Secrets CR에 저장된 인증 정보가 올바른지 확인해야 합니다.

   3

   스토리지 공급자를 지정합니다.

   4

   선택 사항: 스냅샷을 사용하여 데이터를 복사하는 경우 오브젝트 스토리지의 Secrets CR을 지정합니다. 오브젝트 스토리지의 Secrets CR에 저장된 인증 정보가 올바른지 확인해야 합니다.

   5

   선택 사항: 스냅샷을 사용하여 데이터를 복사하는 경우 스토리지 공급자를 지정합니다.

7. MigStorage CR이 Ready 상태에 있는지 확인합니다.

   $ oc describe migstorage <migstorage>

8. MigPlan CR 매니페스트를 생성합니다.

   $ cat << EOF | oc apply -f -
   apiVersion: migration.openshift.io/v1alpha1
   kind: MigPlan
   metadata:
     name: <migplan>
     namespace: openshift-migration
   spec:
     destMigClusterRef:
       name: <host_cluster>
       namespace: openshift-migration
     indirectImageMigration: true 1
     indirectVolumeMigration: true 2
     migStorageRef:
       name: <migstorage> 3
       namespace: openshift-migration
     namespaces:
       - <application_namespace> 4
     srcMigClusterRef:
       name: <remote_cluster> 5
       namespace: openshift-migration
   EOF

   1

   false인 경우 직접 이미지 마이그레이션이 활성화됩니다.

   2

   false인 경우 직접 볼륨 마이그레이션이 활성화됩니다.

   3

   MigStorage CR 인스턴스의 이름을 지정합니다.

   4

   하나 이상의 소스 네임스페이스를 지정합니다. 기본적으로 대상 네임스페이스의 이름은 동일합니다.

   5

   소스 클러스터 MigCluster 인스턴스의 이름을 지정합니다.

9. MigPlan 인스턴스가 Ready 상태인지 확인합니다.

   $ oc describe migplan <migplan> -n openshift-migration

10. MigPlan 인스턴스에 정의된 마이그레이션을 시작하도록 MigMigration CR 매니페스트를 생성합니다.

    $ cat << EOF | oc apply -f -
    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      name: <migmigration>
      namespace: openshift-migration
    spec:
      migPlanRef:
        name: <migplan> 1
        namespace: openshift-migration
      quiescePods: true 2
      stage: false 3
      rollback: false 4
    EOF

    1

    MigPlan CR 이름을 지정합니다.

    2

    true인 경우 마이그레이션 전에 소스 클러스터의 포드가 중지됩니다.

    3

    애플리케이션을 중지하지 않고 대부분의 데이터를 복사하는 단계 마이그레이션이 true인 경우 수행됩니다.

    4

    true인 경우 완료된 마이그레이션이 롤백됩니다.

11. MigMigration CR의 진행 상황을 확인하여 마이그레이션을 확인합니다.

    $ oc watch migmigration <migmigration> -n openshift-migration

    출력은 다음과 유사합니다.

    출력 예

    Name:         c8b034c0-6567-11eb-9a4f-0bc004db0fbc
    Namespace:    openshift-migration
    Labels:       migration.openshift.io/migplan-name=django
    Annotations:  openshift.io/touch: e99f9083-6567-11eb-8420-0a580a81020c
    API Version:  migration.openshift.io/v1alpha1
    Kind:         MigMigration
    ...
    Spec:
      Mig Plan Ref:
        Name:       migplan
        Namespace:  openshift-migration
      Stage:        false
    Status:
      Conditions:
        Category:              Advisory
        Last Transition Time:  2021-02-02T15:04:09Z
        Message:               Step: 19/47
        Reason:                InitialBackupCreated
        Status:                True
        Type:                  Running
        Category:              Required
        Last Transition Time:  2021-02-02T15:03:19Z
        Message:               The migration is ready.
        Status:                True
        Type:                  Ready
        Category:              Required
        Durable:               true
        Last Transition Time:  2021-02-02T15:04:05Z
        Message:               The migration registries are healthy.
        Status:                True
        Type:                  RegistriesHealthy
      Itinerary:               Final
      Observed Digest:         7fae9d21f15979c71ddc7dd075cb97061895caac5b936d92fae967019ab616d5
      Phase:                   InitialBackupCreated
      Pipeline:
        Completed:  2021-02-02T15:04:07Z
        Message:    Completed
        Name:       Prepare
        Started:    2021-02-02T15:03:18Z
        Message:    Waiting for initial Velero backup to complete.
        Name:       Backup
        Phase:      InitialBackupCreated
        Progress:
          Backup openshift-migration/c8b034c0-6567-11eb-9a4f-0bc004db0fbc-wpc44: 0 out of estimated total of 0 objects backed up (5s)
        Started:        2021-02-02T15:04:07Z
        Message:        Not started
        Name:           StageBackup
        Message:        Not started
        Name:           StageRestore
        Message:        Not started
        Name:           DirectImage
        Message:        Not started
        Name:           DirectVolume
        Message:        Not started
        Name:           Restore
        Message:        Not started
        Name:           Cleanup
      Start Timestamp:  2021-02-02T15:03:18Z
    Events:
      Type    Reason   Age                 From                     Message
      ----    ------   ----                ----                     -------
      Normal  Running  57s                 migmigration_controller  Step: 2/47
      Normal  Running  57s                 migmigration_controller  Step: 3/47
      Normal  Running  57s (x3 over 57s)   migmigration_controller  Step: 4/47
      Normal  Running  54s                 migmigration_controller  Step: 5/47
      Normal  Running  54s                 migmigration_controller  Step: 6/47
      Normal  Running  52s (x2 over 53s)   migmigration_controller  Step: 7/47
      Normal  Running  51s (x2 over 51s)   migmigration_controller  Step: 8/47
      Normal  Ready    50s (x12 over 57s)  migmigration_controller  The migration is ready.
      Normal  Running  50s                 migmigration_controller  Step: 9/47
      Normal  Running  50s                 migmigration_controller  Step: 10/47

절차

1. MigrationController 사용자 지정 매니페스트를 편집합니다.

   $ oc edit migrationcontroller <migration_controller> -n openshift-migration

2. 특정 리소스를 제외하는 매개 변수를 추가하거나 자체 제외 매개 변수가 없는 경우 excluded_resources 매개 변수에 리소스를 추가하여 spec 섹션을 업데이트합니다.

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigrationController
   metadata:
     name: migration-controller
     namespace: openshift-migration
   spec:
     disable_image_migration: true 1
     disable_pv_migration: true 2
     ...
     excluded_resources: 3
     - imagetags
     - templateinstances
     - clusterserviceversions
     - packagemanifests
     - subscriptions
     - servicebrokers
     - servicebindings
     - serviceclasses
     - serviceinstances
     - serviceplans
     - operatorgroups
     - events
     - events.events.k8s.io

   1

   마이그레이션에서 이미지 스트림을 제외하려면 disable_image_migration: true를 추가합니다. excluded_resources 매개 변수를 편집하지 마십시오. MigrationController Pod가 다시 시작되면 imagestreams 가 excluded_resources 에 추가됩니다.

   2

   마이그레이션 계획에서 PV를 제외하려면 disable_pv_migration: true를 추가합니다. excluded_resources 매개 변수를 편집하지 마십시오. MigrationController Pod가 다시 시작되면 persistentvolumes 및 persistentvolumeclaims 가 excluded_resources 에 추가됩니다. PV 마이그레이션을 비활성화하면 마이그레이션 계획을 생성할 때 PV 검색도 비활성화됩니다.

   3

   OpenShift Container Platform 리소스를 excluded_resources 목록에 추가할 수 있습니다. 기본 제외 리소스를 삭제하지 마십시오. 이러한 리소스는 마이그레이션에 문제가 있으므로 제외해야 합니다.

3. 변경 사항이 적용되도록 MigrationController 포드가 다시 시작될 때까지 2분 정도 기다립니다.

4. 리소스가 제외되었는지 확인합니다.

   $ oc get deployment -n openshift-migration migration-controller -o yaml | grep EXCLUDED_RESOURCES -A1

   출력에는 제외된 리소스가 포함됩니다.

   출력 예

       - name: EXCLUDED_RESOURCES
         value:
         imagetags,templateinstances,clusterserviceversions,packagemanifests,subscriptions,servicebrokers,servicebindings,serviceclasses,serviceinstances,serviceplans,imagestreams,persistentvolumes,persistentvolumeclaims

절차

1. MigrationController 사용자 지정 (CR) 매니페스트를 편집합니다.

   $ oc edit migrationcontroller -n openshift-migration

2. 다음 매개 변수를 업데이트합니다.

   ...
   mig_controller_limits_cpu: "1" 1
   mig_controller_limits_memory: "10Gi" 2
   ...
   mig_controller_requests_cpu: "100m" 3
   mig_controller_requests_memory: "350Mi" 4
   ...
   mig_pv_limit: 100 5
   mig_pod_limit: 100 6
   mig_namespace_limit: 10 7
   ...

   1

   MigrationController CR에서 사용할 수 있는 CPU 수를 지정합니다.

   2

   MigrationController CR에서 사용할 수 있는 메모리 양을 지정합니다.

   3

   MigrationController CR 요청에 사용할 수 있는 CPU 단위 수를 지정합니다. 100m은 0.1 CPU 단위(100 * 1e-3)를 나타냅니다.

   4

   MigrationController CR 요청에 사용할 수 있는 메모리 양을 지정합니다.

   5

   마이그레이션할 수 있는 영구 볼륨 수를 지정합니다.

   6

   마이그레이션할 수 있는 포드 수를 지정합니다.

   7

   마이그레이션할 수 있는 네임스페이스 수를 지정합니다.

3. 업데이트된 매개 변수를 사용하여 변경 사항을 확인하는 마이그레이션 계획을 생성합니다.

   마이그레이션 계획이 MigrationController CR 제한을 초과하는 경우 MTC 콘솔은 마이그레이션 계획을 저장할 때 경고 메시지를 표시합니다.

절차

1. 호스트 클러스터에 로그인합니다.

2. MigrationController CR의 패치를 적용하여 PV 크기 조정을 활성화합니다.

   $ oc patch migrationcontroller migration-controller -p '{"spec":{"enable_dvm_pv_resizing":true}}' \ 1
     --type='merge' -n openshift-migration

   1

   PV 크기 조정을 비활성화하려면 값을 false로 설정합니다.

3. 선택 사항: pv_resizing_threshold 매개변수를 업데이트하여 임계값을 늘립니다.

   $ oc patch migrationcontroller migration-controller -p '{"spec":{"pv_resizing_threshold":41}}' \ 1
     --type='merge' -n openshift-migration

   1

   기본값은 3입니다.

   임계값을 초과하면 MigPlan CR 상태에 다음 상태 정보 메시지가 표시됩니다.

   status:
     conditions:
   ...
     - category: Warn
       durable: true
       lastTransitionTime: "2021-06-17T08:57:01Z"
       message: 'Capacity of the following volumes will be automatically adjusted to avoid disk capacity issues in the target cluster:  [pvc-b800eb7b-cf3b-11eb-a3f7-0eae3e0555f3]'
       reason: Done
       status: "False"
       type: PvCapacityAdjustmentRequired

   참고

   AWS gp2 스토리지의 경우 gp2에서 볼륨 사용량과 크기를 계산하는 방식 때문에 pv_resizing_threshold가 42% 이상인 경우 이 메시지가 표시되지 않습니다. (BZ#1973148)

절차

1. 다음 명령을 실행하여 캐시된 클라이언트를 활성화합니다.

   $ oc -n openshift-migration patch migrationcontroller migration-controller --type=json --patch \
     '[{ "op": "replace", "path": "/spec/mig_controller_enable_cache", "value": true}]'

2. 선택 사항: 다음 명령을 실행하여 MigrationController CR 메모리 제한을 늘립니다.

   $ oc -n openshift-migration patch migrationcontroller migration-controller --type=json --patch \
     '[{ "op": "replace", "path": "/spec/mig_controller_limits_memory", "value": <10Gi>}]'

3. 선택 사항: 다음 명령을 실행하여 MigrationController CR 메모리 요청을 늘립니다.

   $ oc -n openshift-migration patch migrationcontroller migration-controller --type=json --patch \
     '[{ "op": "replace", "path": "/spec/mig_controller_requests_memory", "value": <350Mi>}]'

절차

1. MTC 웹 콘솔에서 마이그레이션 계획을 클릭합니다.
2. 마이그레이션 계획 옆에 있는 마이그레이션 번호를 클릭하면 마이그레이션 페이지가 표시됩니다.
3. 마이그레이션을 클릭하여 마이그레이션 세부 정보를 확인합니다.

4. 마이그레이션 리소스를 확장하여 목록 보기에서 마이그레이션 리소스 및 해당 상태를 봅니다.

   참고

   실패한 마이그레이션 문제를 해결하려면 실패한 상위 수준 리소스부터 시작한 다음 리소스 트리를 하위 수준 리소스로 이동합니다.

5. 리소스 옆에 있는 옵션 메뉴 를 클릭하고 다음 옵션 중 하나를 선택합니다.

   • oc describe 복사 명령은 명령을 클립보드에 복사합니다.

     • 관련 클러스터에 로그인한 다음 명령을 실행합니다.

       리소스의 조건 및 이벤트는 YAML 형식으로 표시됩니다.

   • oc logs 복사 명령은 명령을 클립보드에 복사합니다.

     • 관련 클러스터에 로그인한 다음 명령을 실행합니다.

       리소스가 로그 필터링을 지원하는 경우 필터링된 로그가 표시됩니다.

   • JSON 보기는 웹 브라우저에서 JSON 형식으로 리소스 데이터를 표시합니다.

     데이터는 oc get <resource> 명령의 출력과 동일합니다.

절차

1. MTC 웹 콘솔에서 마이그레이션 계획을 클릭합니다.
2. 마이그레이션 계획 옆에 있는 마이그레이션 번호를 클릭합니다.
3. 로그 보기를 클릭합니다.
4. 복사 아이콘을 클릭하여 oc logs 명령을 클립보드에 복사합니다.

5. 해당 클러스터에 로그인하고 CLI에 명령을 입력합니다.

   마이그레이션 계획에 대해 집계된 로그가 표시됩니다.

절차

1. mig-log-reader 포드를 가져옵니다.

   $ oc -n openshift-migration get pods | grep log

2. 단일 마이그레이션 로그를 표시하려면 다음 명령을 입력합니다.

   $ oc -n openshift-migration logs -f <mig-log-reader-pod> -c color 1

   1

   -c plain 옵션은 색상 없이 로그를 표시합니다.

절차

1. OpenShift Container Platform 웹 콘솔에서 모니터링 → 메트릭 을 클릭합니다.

2. PromQL 쿼리를 입력하고 표시할 시간 창을 선택한 다음 Run Queries(쿼리 실행 )를 클릭합니다.

   웹 브라우저에 모든 결과가 표시되지 않으면 Prometheus 콘솔을 사용합니다.

절차

1. must-gather 데이터를 저장하려는 디렉터리로 이동합니다.

2. 다음 데이터 수집 옵션 중 하나에 대해 oc adm must-gather 명령을 실행합니다.

   • 지난 시간 동안 데이터를 수집하려면 다음을 수행하십시오.

     $ oc adm must-gather --image=registry.redhat.io/rhmtc/openshift-migration-must-gather-rhel8:v1.6

     데이터는 must-gather/must-gather.tar.gz 로 저장됩니다. Red Hat 고객 포털에서 해당 지원 사례에 이 파일을 업로드할 수 있습니다.

   • 지난 24 시간 동안 데이터를 수집하려면 다음을 수행하십시오.

     $ oc adm must-gather --image=registry.redhat.io/rhmtc/openshift-migration-must-gather-rhel8:v1.6 \
       -- /usr/bin/gather_metrics_dump

     이 작업에는 오랜 시간이 걸릴 수 있습니다. 데이터는 must-gather/metrics/prom_data.tar.gz 로 저장됩니다.

절차

1. prom_data.tar.gz 파일의 압축을 풉니다.

   $ tar -xvzf must-gather/metrics/prom_data.tar.gz

2. 로컬 Prometheus 인스턴스를 생성합니다.

   $ make prometheus-run

   이 명령은 Prometheus URL을 출력합니다.

   출력 결과

   Started Prometheus on http://localhost:9090

3. 웹 브라우저를 시작하고 URL로 이동하여 Prometheus 웹 콘솔을 사용하여 데이터를 확인합니다.

4. 데이터를 보고 나면 Prometheus 인스턴스 및 데이터를 삭제합니다.

   $ make prometheus-cleanup

절차

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

   $ oc get migmigration <migmigration> -o yaml

   출력 예

   status:
     conditions:
     - category: Warn
       durable: true
       lastTransitionTime: "2021-01-26T20:48:40Z"
       message: 'Final Restore openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf: partially failed on destination cluster'
       status: "True"
       type: VeleroFinalRestorePartiallyFailed
     - category: Advisory
       durable: true
       lastTransitionTime: "2021-01-26T20:48:42Z"
       message: The migration has completed with warnings, please look at `Warn` conditions.
       reason: Completed
       status: "True"
       type: SucceededWithWarnings

2. Velero describe 명령을 사용하여 Restore CR의 상태를 확인합니다.

   $ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore describe <restore>

   출력 예

   Phase:  PartiallyFailed (run 'velero restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf' for more information)
   
   Errors:
     Velero:     <none>
     Cluster:    <none>
     Namespaces:
       migration-example:  error restoring example.com/migration-example/migration-example: the server could not find the requested resource

3. Velero logs 명령을 사용하여 Restore CR 로그를 확인합니다.

   $ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore logs <restore>

   출력 예

   time="2021-01-26T20:48:37Z" level=info msg="Attempting to restore migration-example: migration-example" logSource="pkg/restore/restore.go:1107" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf
   time="2021-01-26T20:48:37Z" level=info msg="error restoring migration-example: the server could not find the requested resource" logSource="pkg/restore/restore.go:1170" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

   Restore CR 로그 오류 메시지인 the server could not find the requested resource은 부분적으로 실패한 마이그레이션의 원인을 나타냅니다.

프로세스

1. openshift-migration 네임스페이스에 MigMigration CR을 나열합니다.

   $ oc get migmigration -n openshift-migration

   출력 예

   NAME                                   AGE
   88435fe0-c9f8-11e9-85e6-5d593ce65e10   6m42s

2. MigMigration CR을 검사합니다.

   $ oc describe migmigration 88435fe0-c9f8-11e9-85e6-5d593ce65e10 -n openshift-migration

   출력은 다음 예제와 유사합니다.

프로세스

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

   기본적으로 내부 레지스트리는 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

절차

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. 마이그레이션 계획을 다시 실행합니다.

프로세스

1. MTC 웹 콘솔에서 마이그레이션 계획을 클릭합니다.
2. 마이그레이션 계획 옆의 옵션 메뉴 를 클릭하고 마이그레이션에서 롤백을 선택합니다.

3. 롤백을 클릭하고 롤백이 완료될 때까지 기다립니다.

   마이그레이션 계획 세부 사항에서 롤백 성공이 표시됩니다.

4. 소스 클러스터의 OpenShift Container Platform 웹 콘솔에서 롤백이 성공했는지 확인합니다.

   1. 홈 → 프로젝트를 클릭합니다.
   2. 마이그레이션된 프로젝트를 클릭하여 상태를 봅니다.
   3. 경로 섹션에서 위치를 클릭하여 해당되는 경우 애플리케이션이 작동하는지 확인합니다.
   4. 워크로드 → 포드를 클릭하여 포드가 마이그레이션된 네임스페이스에서 실행 중인지 확인합니다.
   5. 스토리지 → 영구 볼륨을 클릭하여 마이그레이션된 영구 볼륨이 올바르게 프로비저닝되었는지 확인합니다.

프로세스

1. 다음 예제를 기반으로 MigMigration CR을 생성합니다.

   $ cat << EOF | oc apply -f -
   apiVersion: migration.openshift.io/v1alpha1
   kind: MigMigration
   metadata:
     labels:
       controller-tools.k8s.io: "1.0"
     name: <migmigration>
     namespace: openshift-migration
   spec:
   ...
     rollback: true
   ...
     migPlanRef:
       name: <migplan> 1
       namespace: openshift-migration
   EOF

   1

   연결된 MigPlan CR의 이름을 지정합니다.

2. MTC 웹 콘솔에서 마이그레이션된 프로젝트 리소스가 대상 클러스터에서 제거되었는지 확인합니다.
3. 마이그레이션된 프로젝트 리소스가 소스 클러스터에 있고 애플리케이션이 실행 중인지 확인합니다.

프로세스

1. 모든 클러스터에서 stage Pod를 삭제합니다.

   $ oc delete $(oc get pods -l migration.openshift.io/is-stage-pod -n <namespace>) 1

   1

   MigPlan CR에 지정된 네임스페이스입니다.

2. 복제본을 사전 마이그레이션 번호로 확장하여 소스 클러스터에서 애플리케이션 정지를 해제합니다.

   $ oc scale deployment <deployment> --replicas=<premigration_replicas>

   Deployment CR의 migration.openshift.io/preQuiesceReplicas 주석에는 복제본의 사전 마이그레이션 수가 표시됩니다.

   apiVersion: extensions/v1beta1
   kind: Deployment
   metadata:
     annotations:
       deployment.kubernetes.io/revision: "1"
       migration.openshift.io/preQuiesceReplicas: "1"

3. 애플리케이션 pod가 소스 클러스터에서 실행 중인지 확인합니다.

   $ oc get pod -n <namespace>