9.2. 명령줄을 사용하여 애플리케이션 마이그레이션

마이그레이션을 자동화하기 위해 CLI(명령줄 인터페이스)를 사용하여 MTC API로 애플리케이션을 마이그레이션할 수 있습니다.

9.2.1. 마이그레이션 사전 요구 사항

  • 모든 클러스터에서 cluster-admin 권한이 있는 사용자로 로그인합니다.

직접 이미지 마이그레이션

  • 소스 클러스터의 보안 내부 레지스트리가 노출되었는지 확인해야 합니다.
  • 노출된 레지스트리에 대한 경로를 생성해야 합니다.

직접 볼륨 마이그레이션

  • 클러스터에서 프록시를 사용하는 경우 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는 동일한 스토리지 클래스를 보유해야 합니다.

9.2.2. 직접 이미지 마이그레이션을 위한 레지스트리 경로 생성

직접 이미지 마이그레이션의 경우 모든 원격 클러스터에서 공용 내부 레지스트리에 대한 경로를 생성해야 합니다.

사전 요구 사항

  • 내부 레지스트리는 모든 원격 클러스터의 외부 트래픽에 노출되어야 합니다.

    OpenShift Container Platform 4 레지스트리는 기본적으로 공개됩니다.

절차

  • OpenShift Container Platform 4 레지스트리에 대한 경로를 생성하려면 다음 명령을 실행합니다.

    $ oc create route passthrough --service=image-registry -n openshift-image-registry

9.2.3. 프록시 설정

OpenShift Container Platform 4.1 및 이전 버전의 경우 이러한 버전은 클러스터 전체 프록시 오브젝트를 지원하지 않기 때문에 Migration Toolkit for Containers Operator를 설치한 후 MigrationController CR(사용자 정의 리소스) 매니페스트에서 proxy를 구성해야 합니다.

OpenShift Container Platform 4.2에서 4.8로, MTC(Migration Toolkit for Containers)는 클러스터 전체 프록시 설정을 상속합니다. 클러스터 전체 프록시 설정을 재정의하려면 프록시 매개변수를 변경할 수 있습니다.

9.2.3.1. 직접 볼륨 마이그레이션

MTC 1.4.2에서 직접 볼륨 마이그레이션(DVM)이 도입되었습니다. DVM은 하나의 프록시만 지원합니다. 대상 클러스터가 프록시 뒤에 있는 경우 소스 클러스터는 대상 클러스터의 경로에 액세스할 수 없습니다.

프록시 뒤에서 소스 클러스터에서 DVM을 수행하려면 전송 계층에서 작동하는 TCP 프록시를 구성하고 자체 SSL 인증서로 암호를 해독하고 재암호화하지 않고도 SSL 연결을 투명하게 전달해야 합니다. Stunnel 프록시는 이러한 프록시의 예입니다.

9.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의 일반 프록시 구성과 다르게 유지됩니다.

9.2.3.1.2. HTTP/HTTPS 프록시 대신 TCP 프록시를 사용하는 이유는 무엇입니까?

OpenShift 경로를 통해 소스와 대상 클러스터 간에 Rsync를 실행하여 DVM을 활성화할 수 있습니다. 트래픽은 TCP 프록시인 Stunnel을 사용하여 암호화됩니다. 소스 클러스터에서 실행되는 Stunnel은 대상 Stunnel을 사용한 TLS 연결을 시작하고 암호화된 채널을 통해 데이터를 전송합니다.

OpenShift의 클러스터 전체 HTTP/HTTPS 프록시는 일반적으로 자체 TLS 세션을 외부 서버와 협상하는 중간자 모드로 구성됩니다. 그러나 이 작업은 Stunnel에서는 작동하지 않습니다. Stunnel은 프록시에서 TLS 세션을 그대로 전환해야 하므로 기본적으로 프록시를 통해 TCP 연결을 그대로 전달하는 투명한 터널로 프록시를 설정해야 합니다. 따라서 TCP 프록시를 사용해야 합니다.

9.2.3.1.3. 알려진 문제

마이그레이션 실패 오류 업그레이드 요청 필요

마이그레이션 컨트롤러는 SPDY 프로토콜을 사용하여 원격 Pod 내에서 명령을 실행합니다. 원격 클러스터가 프록시 또는 SPDY 프로토콜을 지원하지 않는 방화벽 뒤에 있는 경우 마이그레이션 컨트롤러가 원격 명령을 실행하지 못합니다. 오류 메시지 업그레이드 요청 과 함께 마이그레이션이 실패합니다. 해결방법: SPDY 프로토콜을 지원하는 프록시를 사용합니다.

SPDY 프로토콜 지원 외에도 프록시 또는 방화벽은 Upgrade HTTP 헤더를 API 서버에 전달해야 합니다. 클라이언트는 이 헤더를 사용하여 API 서버와의 websocket 연결을 엽니다. 업그레이드 헤더가 프록시 또는 방화벽에 의해 차단된 경우 마이그레이션은 오류 메시지 업그레이드 요청 필요 와 함께 실패합니다. 해결방법: 프록시가 Upgrade 헤더를 전달하도록 합니다.

9.2.3.2. 마이그레이션을 위한 네트워크 정책 튜닝

OpenShift는 클러스터에서 사용하는 네트워크 플러그인을 기반으로 NetworkPolicy 또는 EgressFirewall 을 사용하여 Pod로 트래픽을 제한할 수 있습니다. 마이그레이션과 관련된 소스 네임스페이스가 이러한 메커니즘을 사용하여 네트워크 트래픽을 포드로 제한하는 경우 제한이 마이그레이션 중에 Rsync pod로의 트래픽을 실수로 중지할 수 있습니다.

소스 및 대상 클러스터에서 둘 다 실행되는 rsync Pod는 OpenShift 경로를 통해 서로 연결되어야 합니다. 기존 NetworkPolicy 또는 EgressNetworkPolicy 오브젝트는 이러한 트래픽 제한에서 Rsync Pod를 자동으로 제외하도록 구성할 수 있습니다.

9.2.3.2.1. NetworkPolicy 구성
9.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
9.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
9.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
9.2.3.2.3. Rsync Pod에 대한 추가 그룹 구성

PVC에서 공유 스토리지를 사용하는 경우 Pod에서 액세스를 허용하기 위해 Rsync Pod 정의에 추가 그룹을 추가하여 해당 스토리지에 대한 액세스를 구성할 수 있습니다.

표 9.2. Rsync Pod의 보조 그룹

변수유형기본값설명

src_supplemental_groups

string

설정되지 않음

소스 Rsync Pod에 대한 콤마로 구분된 추가 그룹 목록

target_supplemental_groups

string

설정되지 않음

대상 Rsync Pod에 대한 콤마로 구분된 추가 그룹 목록

사용 예

MigrationController CR을 업데이트하여 이러한 추가 그룹에 대한 값을 설정할 수 있습니다.

spec:
  src_supplemental_groups: "1000,2000"
  target_supplemental_groups: "2000,3000"

9.2.3.3. 프록시 구성

사전 요구 사항

  • 모든 클러스터에서 cluster-admin 권한이 있는 사용자로 로그인합니다.

절차

  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
      noProxy: example.com 2
    1
    직접 볼륨 마이그레이션을 위한 Stunnel 프록시 URL입니다.
    2
    프록시를 제외할 대상 도메인 이름, 도메인, IP 주소 또는 기타 네트워크 CIDR의 쉼표로 구분된 목록입니다.

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

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

  3. 매니페스트를 migration-controller.yaml로 저장합니다.
  4. 업데이트된 매니페스트를 적용합니다.

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

9.2.4. MTC API를 사용하여 애플리케이션 마이그레이션

MTC(Migration Toolkit for Containers) API를 사용하여 명령줄에서 애플리케이션을 마이그레이션할 수 있습니다.

절차

  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 CR 매니페스트를 생성합니다.

    $ 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 CR 오브젝트를 지정합니다.
    5
    원격 클러스터의 URL을 지정합니다.
  4. 모든 클러스터가 Ready 상태에 있는지 확인합니다.

    $ oc describe cluster <cluster>
  5. 복제 리포지토리의 Secret CR 매니페스트를 생성합니다.

    $ 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:
        - <source_namespace_1> 4
        - <source_namespace_2>
        - <source_namespace_3>:<destination_namespace> 5
      srcMigClusterRef:
        name: <remote_cluster> 6
        namespace: openshift-migration
    EOF
    1
    false인 경우 직접 이미지 마이그레이션이 활성화됩니다.
    2
    false인 경우 직접 볼륨 마이그레이션이 활성화됩니다.
    3
    MigStorage CR 인스턴스의 이름을 지정합니다.
    4
    하나 이상의 소스 네임스페이스를 지정합니다. 기본적으로 대상 네임스페이스의 이름은 동일합니다.
    5
    대상 네임스페이스가 소스 네임스페이스와 다른 경우 대상 네임스페이스를 지정합니다.
    6
    소스 클러스터 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

9.2.5. 상태 마이그레이션

MTC(Migration Toolkit for Containers)를 사용하여 애플리케이션 상태를 구성하는 PVC(영구 볼륨 클레임)를 마이그레이션하여 반복 가능한 상태 전용 마이그레이션을 수행할 수 있습니다. 마이그레이션 계획에서 다른 PVC를 제외하여 지정된 PVC를 마이그레이션합니다. PVC를 매핑하여 소스 및 대상 PVC가 동기화되었는지 확인할 수 있습니다. 영구 볼륨(PV) 데이터는 대상 클러스터에 복사됩니다. PV 참조는 이동되지 않으며 애플리케이션 포드는 소스 클러스터에서 계속 실행됩니다.

상태 마이그레이션은 OpenShift Gitops와 같은 외부 CD 메커니즘과 함께 사용하도록 특별히 설계되었습니다. MTC를 사용하여 상태를 마이그레이션하는 동안 GitOps를 사용하여 애플리케이션 매니페스트를 마이그레이션할 수 있습니다.

CI/CD 파이프라인이 있는 경우 대상 클러스터에 배포하여 상태 비저장 구성 요소를 마이그레이션할 수 있습니다. 그런 다음 MTC를 사용하여 상태 저장 구성 요소를 마이그레이션할 수 있습니다.

클러스터 간에 또는 동일한 클러스터 내에서 상태 마이그레이션을 수행할 수 있습니다.

중요

상태 마이그레이션은 애플리케이션 상태를 구성하는 구성 요소만 마이그레이션합니다. 전체 네임스페이스를 마이그레이션하려면 stage 또는 cutover 마이그레이션을 사용합니다.

사전 요구 사항

  • 소스 클러스터의 애플리케이션 상태는 PersistentVolumeClaim s 를 통해 프로비저닝된 PersistentVolume 에 유지됩니다.
  • 애플리케이션의 매니페스트는 소스와 대상 클러스터에서 모두 액세스할 수 있는 중앙 리포지토리에서 사용할 수 있습니다.

절차

  1. 소스에서 대상 클러스터로 영구 볼륨 데이터를 마이그레이션합니다.

    이 단계는 필요한 만큼 여러 번 수행할 수 있습니다. 소스 애플리케이션이 계속 실행됩니다.

  2. 소스 애플리케이션을 격리합니다.

    소스 클러스터에서 직접 워크로드 리소스의 복제본을 0 으로 설정하거나 GitHub에서 매니페스트를 업데이트하고 Argo CD 애플리케이션을 다시 동기화하여 이를 수행할 수 있습니다.

  3. 대상 클러스터에 애플리케이션 매니페스트를 복제합니다.

    Argo CD를 사용하여 애플리케이션 매니페스트를 대상 클러스터에 복제할 수 있습니다.

  4. 나머지 볼륨 데이터를 소스에서 대상 클러스터로 마이그레이션합니다.

    최종 데이터 마이그레이션을 수행하여 상태 마이그레이션 프로세스 중에 애플리케이션이 생성한 새 데이터를 마이그레이션합니다.

  5. 복제된 애플리케이션이 정지된 상태인 경우 정지되지 않습니다.
  6. DNS 레코드를 대상 클러스터로 전환하여 사용자 트래픽을 마이그레이션된 애플리케이션으로 리디렉션합니다.
참고

MTC 1.6 상태 마이그레이션을 수행할 때 자동으로 애플리케이션을 격리할 수 없습니다. PV 데이터만 마이그레이션할 수 있습니다. 따라서 애플리케이션 정지 또는 정지를 위해 CD 메커니즘을 사용해야 합니다.

MTC 1.7은 명시적 단계 및 Cutover 흐름을 소개합니다. 스테이징을 사용하여 필요에 따라 초기 데이터 전송을 여러 번 수행할 수 있습니다. 그런 다음 소스 애플리케이션이 자동으로 초기화되는 cutover를 수행할 수 있습니다.

사전 요구 사항

  • 소스 클러스터의 애플리케이션 상태는 PersistentVolumeClaim s 를 통해 프로비저닝된 PersistentVolume 에 유지됩니다.
  • 애플리케이션의 매니페스트는 소스와 대상 클러스터에서 모두 액세스할 수 있는 중앙 리포지토리에서 사용할 수 있습니다.

절차

  1. 소스에서 대상 클러스터로 영구 볼륨 데이터를 마이그레이션합니다.

    이 단계는 필요한 만큼 여러 번 수행할 수 있습니다. 소스 애플리케이션이 계속 실행됩니다.

  2. 소스 애플리케이션을 격리합니다.

    소스 클러스터에서 직접 워크로드 리소스의 복제본을 0 으로 설정하거나 GitHub에서 매니페스트를 업데이트하고 Argo CD 애플리케이션을 다시 동기화하여 이를 수행할 수 있습니다.

  3. 대상 클러스터에 애플리케이션 매니페스트를 복제합니다.

    Argo CD를 사용하여 애플리케이션 매니페스트를 대상 클러스터에 복제할 수 있습니다.

  4. 나머지 볼륨 데이터를 소스에서 대상 클러스터로 마이그레이션합니다.

    최종 데이터 마이그레이션을 수행하여 상태 마이그레이션 프로세스 중에 애플리케이션이 생성한 새 데이터를 마이그레이션합니다.

  5. 복제된 애플리케이션이 정지된 상태인 경우 정지되지 않습니다.
  6. DNS 레코드를 대상 클러스터로 전환하여 사용자 트래픽을 마이그레이션된 애플리케이션으로 리디렉션합니다.
참고

MTC 1.6 상태 마이그레이션을 수행할 때 자동으로 애플리케이션을 격리할 수 없습니다. PV 데이터만 마이그레이션할 수 있습니다. 따라서 애플리케이션 정지 또는 정지를 위해 CD 메커니즘을 사용해야 합니다.

MTC 1.7은 명시적 단계 및 Cutover 흐름을 소개합니다. 스테이징을 사용하여 필요에 따라 초기 데이터 전송을 여러 번 수행할 수 있습니다. 그런 다음 소스 애플리케이션이 자동으로 초기화되는 cutover를 수행할 수 있습니다.

추가 리소스