10.2. 명령줄을 사용하여 애플리케이션 마이그레이션
마이그레이션을 자동화하기 위해 CLI(명령줄 인터페이스)를 사용하여 MTC API로 애플리케이션을 마이그레이션할 수 있습니다.
10.2.1. 마이그레이션 사전 요구 사항
-
모든 클러스터에서
cluster-admin
권한이 있는 사용자로 로그인합니다.
직접 이미지 마이그레이션
- 소스 클러스터의 보안 OpenShift 이미지 레지스트리가 노출되었는지 확인해야 합니다.
- 노출된 레지스트리에 대한 경로를 생성해야 합니다.
직접 볼륨 마이그레이션
- 클러스터에서 프록시를 사용하는 경우 Stunnel TCP 프록시를 구성해야 합니다.
클러스터
- 소스 클러스터를 최신 MTC z-stream 릴리스로 업그레이드해야 합니다.
- MTC 버전은 모든 클러스터에서 동일해야 합니다.
네트워크
- 클러스터는 서로 및 복제 리포지토리에 제한 없이 네트워크 액세스할 수 있습니다.
-
move
를 사용하여 영구 볼륨을 복사하는 경우 클러스터에 원격 볼륨에 대한 무제한 네트워크 액세스 권한이 있어야 합니다. OpenShift Container Platform 4 클러스터에서 다음 포트를 활성화해야 합니다.
-
6443
(API 서버) -
443
(라우트) -
53
(DNS)
-
-
TLS를 사용하는 경우 복제 리포지토리에서 포트
443
을 활성화해야 합니다.
영구 볼륨 (PV)
- PV가 유효해야 합니다.
- PV를 영구 볼륨 클레임에 바인딩해야 합니다.
스냅샷을 사용하여 PV를 복사하는 경우 다음과 같은 추가 사전 요구 사항이 적용됩니다.
- 클라우드 공급자는 스냅샷을 지원해야 합니다.
- PV는 동일한 클라우드 공급자에 있어야 합니다.
- PV는 동일한 지역 리전에 있어야 합니다.
- PV는 동일한 스토리지 클래스를 보유해야 합니다.
10.2.2. 직접 이미지 마이그레이션을 위한 레지스트리 경로 생성
직접 이미지 마이그레이션의 경우 모든 원격 클러스터에서 노출된 OpenShift 이미지 레지스트리에 대한 경로를 생성해야 합니다.
사전 요구 사항
OpenShift 이미지 레지스트리는 모든 원격 클러스터의 외부 트래픽에 노출되어야 합니다.
OpenShift Container Platform 4 레지스트리는 기본적으로 공개됩니다.
프로세스
OpenShift Container Platform 4 레지스트리에 대한 경로를 생성하려면 다음 명령을 실행합니다.
$ oc create route passthrough --service=image-registry -n openshift-image-registry
10.2.3. 프록시 설정
OpenShift Container Platform 4.1 및 이전 버전의 경우 이러한 버전은 클러스터 전체 프록시 오브젝트를 지원하지 않기 때문에 Migration Toolkit for Containers Operator를 설치한 후 MigrationController
CR(사용자 정의 리소스) 매니페스트에서 proxy
를 구성해야 합니다.
OpenShift Container Platform 4.2 to 4.15의 경우 MTC(Migration Toolkit for Containers)는 클러스터 전체 프록시 설정을 상속합니다. 클러스터 전체 프록시 설정을 재정의하려면 프록시 매개변수를 변경할 수 있습니다.
10.2.3.1. 직접 볼륨 마이그레이션
MTC 1.4.2에서 직접 볼륨 마이그레이션(DVM)이 도입되었습니다. DVM은 하나의 프록시만 지원합니다. 대상 클러스터가 프록시 뒤에 있는 경우 소스 클러스터는 대상 클러스터의 경로에 액세스할 수 없습니다.
프록시 뒤에서 소스 클러스터에서 DVM을 수행하려면 전송 계층에서 작동하는 TCP 프록시를 구성하고 자체 SSL 인증서로 암호를 해독하고 재암호화하지 않고도 SSL 연결을 투명하게 전달해야 합니다. Stunnel 프록시는 이러한 프록시의 예입니다.
10.2.3.1.1. DVM용 TCP 프록시 설정
TCP 프록시를 통해 소스와 대상 클러스터 간에 직접 연결하고 프록시를 사용하도록 MigrationController
CR에서 stunnel_tcp_proxy
변수를 구성할 수 있습니다.
apiVersion: migration.openshift.io/v1alpha1 kind: MigrationController metadata: name: migration-controller namespace: openshift-migration spec: [...] stunnel_tcp_proxy: http://username:password@ip:port
직접 볼륨 마이그레이션(DVM)은 프록시에 대한 기본 인증만 지원합니다. 또한 DVM은 TCP 연결을 투명하게 터널링할 수 있는 프록시 뒤에서만 작동합니다. 중간자 모드에서 HTTP/HTTPS 프록시가 작동하지 않습니다. 기존 클러스터 전체 프록시에서 이 동작을 지원하지 않을 수 있습니다. 결과적으로 DVM의 프록시 설정은 의도적으로 MTC의 일반 프록시 구성과 다르게 유지됩니다.
10.2.3.1.2. HTTP/HTTPS 프록시 대신 TCP 프록시를 사용하는 이유는 무엇입니까?
OpenShift 경로를 통해 소스와 대상 클러스터 간에 Rsync를 실행하여 DVM을 활성화할 수 있습니다. 트래픽은 TCP 프록시인 Stunnel을 사용하여 암호화됩니다. 소스 클러스터에서 실행되는 Stunnel은 대상 Stunnel을 사용한 TLS 연결을 시작하고 암호화된 채널을 통해 데이터를 전송합니다.
OpenShift의 클러스터 전체 HTTP/HTTPS 프록시는 일반적으로 자체 TLS 세션을 외부 서버와 협상하는 중간자 모드로 구성됩니다. 그러나 이 작업은 Stunnel에서는 작동하지 않습니다. Stunnel은 프록시에서 TLS 세션을 그대로 전환해야 하므로 기본적으로 프록시를 통해 TCP 연결을 그대로 전달하는 투명한 터널로 프록시를 설정해야 합니다. 따라서 TCP 프록시를 사용해야 합니다.
10.2.3.1.3. 알려진 문제
마이그레이션 실패 오류 Upgrade request required
마이그레이션 컨트롤러는 SPDY 프로토콜을 사용하여 원격 Pod 내에서 명령을 실행합니다. 원격 클러스터가 프록시 또는 SPDY 프로토콜을 지원하지 않는 방화벽 뒤에 있는 경우 마이그레이션 컨트롤러가 원격 명령을 실행하지 못합니다. 오류 메시지 Upgrade request required
와 함께 마이그레이션이 실패합니다. 해결방법: SPDY 프로토콜을 지원하는 프록시를 사용합니다.
SPDY 프로토콜 지원 외에도 프록시 또는 방화벽은 Upgrade
HTTP 헤더를 API 서버에 전달해야 합니다. 클라이언트는 이 헤더를 사용하여 API 서버와의 websocket 연결을 엽니다. Upgrade
헤더가 프록시 또는 방화벽에 의해 차단된 경우 마이그레이션은 오류 메시지 Upgrade request required
와 함께 실패합니다. 해결방법: 프록시가 Upgrade
헤더를 전달하도록 합니다.
10.2.3.2. 마이그레이션을 위한 네트워크 정책 튜닝
OpenShift는 클러스터에서 사용하는 네트워크 플러그인을 기반으로 NetworkPolicy 또는 EgressFirewall을 사용하여 Pod로 트래픽을 제한할 수 있습니다. 마이그레이션과 관련된 소스 네임스페이스가 이러한 메커니즘을 사용하여 네트워크 트래픽을 포드로 제한하는 경우 제한이 마이그레이션 중에 Rsync pod로의 트래픽을 실수로 중지할 수 있습니다.
소스 및 대상 클러스터에서 둘 다 실행되는 rsync Pod는 OpenShift 경로를 통해 서로 연결되어야 합니다. 기존 NetworkPolicy 또는 EgressNetworkPolicy 오브젝트는 이러한 트래픽 제한에서 Rsync Pod를 자동으로 제외하도록 구성할 수 있습니다.
10.2.3.2.1. NetworkPolicy 구성
10.2.3.2.1.1. Rsync Pod의 송신 트래픽
소스 또는 대상 네임스페이스의 NetworkPolicy
구성이 이러한 유형의 트래픽을 차단하는 경우 Rsync Pod의 고유한 레이블을 사용하여 송신 트래픽이 해당 트래픽에서 전달되도록 허용할 수 있습니다. 다음 정책은 네임스페이스의 Rsync Pod에서 모든 송신 트래픽을 허용합니다.
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all-egress-from-rsync-pods spec: podSelector: matchLabels: owner: directvolumemigration app: directvolumemigration-rsync-transfer egress: - {} policyTypes: - Egress
10.2.3.2.1.2. Rsync pod로의 수신 트래픽
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all-egress-from-rsync-pods spec: podSelector: matchLabels: owner: directvolumemigration app: directvolumemigration-rsync-transfer ingress: - {} policyTypes: - Ingress
10.2.3.2.2. EgressNetworkPolicy 구성
EgressNetworkPolicy
오브젝트 또는 Egress Firewalls 는 클러스터를 나가는 송신 트래픽을 차단하도록 설계된 OpenShift 구조입니다.
NetworkPolicy
오브젝트와 달리 Egress Firewall은 네임스페이스의 모든 포드에 적용되므로 프로젝트 수준에서 작동합니다. 따라서 Rsync Pod의 고유 레이블은 제한 사항에서 Rsync Pod만 제외하지 않습니다. 그러나 두 클러스터 간에 직접 연결을 설정할 수 있도록 소스 또는 대상 클러스터의 CIDR 범위를 정책의 허용 규칙에 추가할 수 있습니다.
Egress Firewall이 있는 클러스터를 기반으로 다른 클러스터의 CIDR 범위를 추가하여 둘 사이의 송신 트래픽을 허용할 수 있습니다.
apiVersion: network.openshift.io/v1 kind: EgressNetworkPolicy metadata: name: test-egress-policy namespace: <namespace> spec: egress: - to: cidrSelector: <cidr_of_source_or_target_cluster> type: Deny
10.2.3.2.3. 데이터 전송을 위한 대체 끝점 선택
기본적으로 DVM은 OpenShift Container Platform 경로를 끝점으로 사용하여 PV 데이터를 대상 클러스터로 전송합니다. 클러스터 토폴로지가 허용하는 경우 다른 유형의 지원되는 끝점을 선택할 수 있습니다.
각 클러스터에 대해 MigrationController
CR의 적절한 대상 클러스터에서 rsync_endpoint_type
변수를 설정하여 끝점을 구성할 수 있습니다.
apiVersion: migration.openshift.io/v1alpha1 kind: MigrationController metadata: name: migration-controller namespace: openshift-migration spec: [...] rsync_endpoint_type: [NodePort|ClusterIP|Route]
10.2.3.2.4. Rsync Pod에 대한 추가 그룹 구성
PVC에서 공유 스토리지를 사용하는 경우 Pod에서 액세스를 허용하기 위해 Rsync Pod 정의에 추가 그룹을 추가하여 해당 스토리지에 대한 액세스를 구성할 수 있습니다.
Variable | 유형 | Default | 설명 |
---|---|---|---|
| string | 설정되지 않음 | 소스 Rsync Pod에 대한 콤마로 구분된 추가 그룹 목록 |
| string | 설정되지 않음 | 대상 Rsync Pod에 대한 콤마로 구분된 추가 그룹 목록 |
사용 예
MigrationController
CR을 업데이트하여 이러한 추가 그룹에 대한 값을 설정할 수 있습니다.
spec: src_supplemental_groups: "1000,2000" target_supplemental_groups: "2000,3000"
10.2.3.3. 프록시 구성
사전 요구 사항
-
모든 클러스터에서
cluster-admin
권한이 있는 사용자로 로그인합니다.
프로세스
MigrationController
CR 매니페스트를 가져옵니다.$ oc get migrationcontroller <migration_controller> -n openshift-migration
프록시 매개변수를 업데이트합니다.
apiVersion: migration.openshift.io/v1alpha1 kind: MigrationController metadata: name: <migration_controller> namespace: openshift-migration ... spec: stunnel_tcp_proxy: http://<username>:<password>@<ip>:<port> 1 noProxy: example.com 2
하위 도메인과 일치하려면 도메인 앞에
.
을 입력합니다. 예를 들어,.y.com
은x.y.com
과 일치하지만y.com
은 일치하지 않습니다.*
를 사용하여 모든 대상에 대해 프록시를 바이패스합니다.networking.machineNetwork[].cidr
필드에 의해 정의된 네트워크에 포함되어 있지 않은 작업자를 설치 구성에서 확장하려면 연결 문제를 방지하기 위해 이 목록에 해당 작업자를 추가해야 합니다.httpProxy
또는httpsProxy
필드가 설정되지 않은 경우 이 필드는 무시됩니다.-
매니페스트를
migration-controller.yaml
로 저장합니다. 업데이트된 매니페스트를 적용합니다.
$ oc replace -f migration-controller.yaml -n openshift-migration
10.2.4. MTC API를 사용하여 애플리케이션 마이그레이션
MTC(Migration Toolkit for Containers) API를 사용하여 명령줄에서 애플리케이션을 마이그레이션할 수 있습니다.
프로세스
호스트 클러스터에 대한
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
각 원격 클러스터에 대한
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
각 원격 클러스터에 대해
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
모든 클러스터가
Ready
상태에 있는지 확인합니다.$ oc describe MigCluster <cluster>
복제 리포지토리의
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
AWS 인증 정보는 기본적으로 base64로 인코딩됩니다. 다른 스토리지 공급자의 경우 각 키로 다음 명령을 실행하여 인증 정보를 인코딩해야 합니다.
$ echo -n "<key>" | base64 -w 0 1
- 1
- 키 ID 또는 시크릿 키를 지정합니다. 두 키 모두 base64로 인코딩되어야 합니다.
복제 리포지토리에 대한
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
MigStorage
CR이Ready
상태에 있는지 확인합니다.$ oc describe migstorage <migstorage>
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: - <source_namespace_1> 4 - <source_namespace_2> - <source_namespace_3>:<destination_namespace> 5 srcMigClusterRef: name: <remote_cluster> 6 namespace: openshift-migration EOF
MigPlan
인스턴스가Ready
상태인지 확인합니다.$ oc describe migplan <migplan> -n openshift-migration
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
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
10.2.5. 상태 마이그레이션
MTC(Migration Toolkit for Containers)를 사용하여 애플리케이션 상태를 구성하는 PVC(영구 볼륨 클레임)를 마이그레이션하여 반복 가능한 상태 전용 마이그레이션을 수행할 수 있습니다. 마이그레이션 계획에서 다른 PVC를 제외하여 지정된 PVC를 마이그레이션합니다. PVC를 매핑하여 소스 및 대상 PVC가 동기화되었는지 확인할 수 있습니다. 영구 볼륨(PV) 데이터는 대상 클러스터에 복사됩니다. PV 참조가 이동하지 않으며 애플리케이션 Pod는 소스 클러스터에서 계속 실행됩니다.
상태 마이그레이션은 OpenShift Gitops와 같은 외부 CD 메커니즘과 함께 사용하도록 특별히 설계되었습니다. MTC를 사용하여 상태를 마이그레이션하는 동안 GitOps를 사용하여 애플리케이션 매니페스트를 마이그레이션할 수 있습니다.
CI/CD 파이프라인이 있는 경우 대상 클러스터에 배포하여 상태 비저장 구성 요소를 마이그레이션할 수 있습니다. 그런 다음 MTC를 사용하여 상태 저장 구성 요소를 마이그레이션할 수 있습니다.
클러스터 간에 또는 동일한 클러스터 내에서 상태 마이그레이션을 수행할 수 있습니다.
상태 마이그레이션은 애플리케이션 상태를 구성하는 구성 요소만 마이그레이션합니다. 전체 네임스페이스를 마이그레이션하려면 스테이지(stage) 또는 컷오버(cutover) 마이그레이션을 사용합니다.
사전 요구 사항
-
소스 클러스터의 애플리케이션 상태는
PersistentVolumeClaims
를 통해 프로비저닝된PersistentVolumes
에서 유지됩니다. - 애플리케이션의 매니페스트는 소스 및 대상 클러스터 모두에서 액세스할 수 있는 중앙 리포지토리에서 사용할 수 있습니다.
프로세스
소스에서 대상 클러스터로 영구 볼륨 데이터를 마이그레이션합니다.
이 단계는 필요에 따라 여러 번 수행할 수 있습니다. 소스 애플리케이션이 계속 실행됩니다.
소스 애플리케이션을 중지합니다.
이를 위해 소스 클러스터에서 직접 또는 GitHub에서 매니페스트를 업데이트하고 Argo CD 애플리케이션을 다시 동기화하여 워크로드 리소스의 복제본을
0
으로 설정할 수 있습니다.애플리케이션 매니페스트를 대상 클러스터에 복제합니다.
Argo CD를 사용하여 애플리케이션 매니페스트를 대상 클러스터에 복제할 수 있습니다.
나머지 볼륨 데이터를 소스에서 대상 클러스터로 마이그레이션합니다.
최종 데이터 마이그레이션을 수행하여 상태 마이그레이션 프로세스 중에 애플리케이션에서 생성한 새 데이터를 마이그레이션합니다.
- 복제된 애플리케이션이 중지된 상태인 경우 중지되지 않습니다.
- DNS 레코드를 대상 클러스터로 전환하여 마이그레이션된 애플리케이션으로 사용자 트래픽을 리디렉션합니다.
MTC 1.6 상태 마이그레이션을 수행할 때 애플리케이션을 자동으로 정지할 수 없습니다. PV 데이터만 마이그레이션할 수 있습니다. 따라서 애플리케이션 처리 또는 정지를 위해 CD 메커니즘을 사용해야 합니다.
MTC 1.7은 명시적 단계 및 컷오버 (Cutover) 흐름을 도입합니다. 스테이징을 사용하여 필요에 따라 초기 데이터 전송을 여러 번 수행할 수 있습니다. 그런 다음 소스 애플리케이션이 자동으로 중지되는 컷오버를 수행할 수 있습니다.
추가 리소스
- 상태 마이그레이션의 경우 PVC를 선택하려면 마이그레이션에서 PVC 제외를 참조하십시오.
- 대상 클러스터 의 프로비저닝된 PVC로 소스 PV 데이터를 마이그레이션하기 위한 PVC 매핑을 참조하십시오.
- 애플리케이션 상태를 구성하는 Kubernetes 오브젝트를 마이그레이션하려면 Kubernetes 오브젝트 마이그레이션을 참조하십시오.