검색

Migration Toolkit for Containers

download PDF
OpenShift Container Platform 4.15

OpenShift Container Platform 4로 마이그레이션

Red Hat OpenShift Documentation Team

초록

이 문서에서는 OpenShift Container Platform 4 클러스터 간에 상태 저장 애플리케이션 워크로드를 마이그레이션하는 방법을 설명합니다.

1장. Migration Toolkit for Containers 정보

MTC(Migration Toolkit for Containers)를 사용하면 네임스페이스 단위로 OpenShift Container Platform 4 클러스터 간에 상태 저장 애플리케이션 워크로드를 마이그레이션할 수 있습니다.

참고

상태 마이그레이션을 사용하여 동일한 클러스터 내에서 또는 클러스터 간에 애플리케이션을 마이그레이션할 수 있습니다.

MTC는 마이그레이션을 제어하고 애플리케이션 다운타임을 최소화할 수 있도록 Kubernetes 사용자 지정 리소스를 기반으로 하는 웹 콘솔 및 API를 제공합니다.

MTC 콘솔은 기본적으로 대상 클러스터에 설치되어 있습니다. 원격 클러스터에 콘솔을 설치하도록 Migration Toolkit for Containers Operator를 구성할 수 있습니다.

다음 항목에 대한 자세한 내용은 고급 마이그레이션 옵션을 참조하십시오.

  • 마이그레이션 후크 및 MTC API를 사용하여 마이그레이션 자동화.
  • 리소스를 제외하고 대규모 마이그레이션을 지원하며 직접 볼륨 마이그레이션을 위해 자동 PV 크기 조정을 활성화하도록 마이그레이션 계획을 구성.

1.1. 용어

표 1.1. MTC 용어
용어정의

소스 클러스터

애플리케이션이 마이그레이션되는 클러스터입니다.

대상 클러스터[1]

애플리케이션이 마이그레이션될 대상 클러스터입니다.

복제 리포지토리

간접 마이그레이션 중 또는 직접 볼륨 마이그레이션 또는 직접 이미지 마이그레이션 중에 Kubernetes 오브젝트에 대한 이미지, 볼륨 및 Kubernetes 오브젝트 복사에 사용되는 오브젝트 스토리지입니다.

복제 리포지토리는 모든 클러스터에서 액세스할 수 있어야 합니다.

호스트 클러스터

migration-controller pod 및 웹 콘솔이 실행 중인 클러스터입니다. host 클러스터는 일반적으로 대상 클러스터이지만 필수는 아닙니다.

호스트 클러스터에 직접 이미지 마이그레이션을 위해 노출된 레지스트리 경로가 필요하지 않습니다.

원격 클러스터

원격 클러스터는 일반적으로 소스 클러스터이지만 필수는 아닙니다.

원격 클러스터에는 migration-controller 서비스 계정 토큰이 포함된 Secret 사용자 정의 리소스가 필요합니다.

원격 클러스터에는 직접 이미지 마이그레이션을 위해 노출된 보안 레지스트리 경로가 필요합니다.

간접 마이그레이션

이미지, 볼륨 및 Kubernetes 오브젝트는 소스 클러스터에서 복제 리포지토리로 복사한 다음 복제 리포지토리에서 대상 클러스터로 복사됩니다.

직접 볼륨 마이그레이션

영구 볼륨은 소스 클러스터에서 대상 클러스터로 직접 복사됩니다.

직접 이미지 마이그레이션

이미지가 소스 클러스터에서 대상 클러스터로 직접 복사됩니다.

마이그레이션 단계

애플리케이션을 중지하지 않고 데이터가 대상 클러스터에 복사됩니다.

단계적 마이그레이션을 여러 번 실행하면 컷오버 마이그레이션 기간이 단축됩니다.

컷오버 마이그레이션

소스 클러스터에서 애플리케이션이 중지되고 해당 리소스가 대상 클러스터로 마이그레이션됩니다.

상태 마이그레이션

애플리케이션 상태는 특정 영구 볼륨 클레임을 대상 클러스터에 복사하여 마이그레이션됩니다.

마이그레이션 롤백

마이그레이션 롤백은 완료된 마이그레이션을 롤백합니다.

1 MTC 웹 콘솔에서 대상 클러스터를 호출합니다.

1.2. MTC 워크플로

MTC(Migration Toolkit for Containers) 웹 콘솔 또는 Kubernetes API를 사용하여 Kubernetes 리소스, 영구 볼륨 데이터 및 내부 컨테이너 이미지를 OpenShift Container Platform 4.15로 마이그레이션할 수 있습니다.

(MTC)는 다음 리소스를 마이그레이션합니다.

  • 마이그레이션 계획에 지정된 네임스페이스입니다.
  • 네임스페이스가 지정된 리소스: MTC가 네임스페이스를 마이그레이션하면 서비스 또는 포드와 같은 해당 네임스페이스와 연결된 모든 오브젝트와 리소스가 마이그레이션됩니다. 또한 네임스페이스에 존재하지만 클러스터 수준에 없는 리소스가 클러스터 수준에 존재하는 리소스에 따라 달라지는 경우 MTC가 두 개의 리소스 모두를 마이그레이션합니다.

    예를 들어 SCC(보안 컨텍스트 제약 조건)는 클러스터 수준에 존재하는 리소스이며, 서비스 계정(SA)은 네임스페이스 수준에 존재하는 리소스입니다. MTC가 마이그레이션하는 네임스페이스에 SA가 있는 경우 MTC는 SA에 연결된 모든 SCC를 자동으로 찾고 해당 SCC도 마이그레이션합니다. 마찬가지로 MTC는 네임스페이스의 영구 볼륨 클레임에 연결된 영구 볼륨을 마이그레이션합니다.

    참고

    리소스에 따라 클러스터 범위 리소스를 수동으로 마이그레이션해야 할 수 있습니다.

  • CR(사용자 정의 리소스) 및 CRD(사용자 정의 리소스 정의): MTC는 네임스페이스 수준에서 CR 및 CRD를 자동으로 마이그레이션합니다.

MTC 웹 콘솔을 사용하여 애플리케이션을 마이그레이션하는 데는 다음 단계가 포함됩니다.

  1. 모든 클러스터에 Migration Toolkit for Containers Operator를 설치합니다.

    인터넷 액세스가 제한되거나 없는 제한된 환경에서 Migration Toolkit for Containers Operator를 설치할 수 있습니다. 소스 및 대상 클러스터는 상호 액세스 권한 및 미러 레지스트리에 대한 네트워크 액세스 권한이 있어야 합니다.

  2. MTC가 데이터를 마이그레이션하는 데 사용하는 중간 오브젝트 스토리지인 복제 리포지토리를 구성합니다.

    소스 및 대상 클러스터는 마이그레이션 중에 복제 리포지토리에 대한 네트워크 액세스 권한이 있어야 합니다. 프록시 서버를 사용하는 경우 복제 리포지토리와 클러스터 간의 네트워크 트래픽을 허용하도록 해당 서버를 구성해야 합니다.

  3. MTC 웹 콘솔에 소스 클러스터를 추가합니다.
  4. MTC 웹 콘솔에 복제 리포지토리를 추가합니다.
  5. 다음 데이터 마이그레이션 옵션 중 하나를 사용하여 마이그레이션 계획을 생성합니다.

    • 복사: MTC는 소스 클러스터에서 복제 리포지토리로, 복제 리포지토리에서 대상 클러스터로 데이터를 복사합니다.

      참고

      직접 이미지 마이그레이션 또는 직접 볼륨 마이그레이션을 사용하는 경우 소스 클러스터에서 대상 클러스터로 이미지 또는 볼륨이 직접 복사됩니다.

      마이그레이션 PV 사본
    • 이동: MTC는 소스 클러스터에서 원격 볼륨(예: NFS)을 마운트 해제하고 원격 볼륨을 가리키는 대상 클러스터에 PV 리소스를 만든 다음 대상 클러스터에 원격 볼륨을 마운트합니다. 대상 클러스터에서 실행되는 애플리케이션은 소스 클러스터와 동일한 원격 볼륨을 사용합니다. 소스 및 대상 클러스터가 원격 볼륨에 액세스할 수 있어야 합니다.

      참고

      이 다이어그램에는 복제 리포지토리가 나타나지 않지만 마이그레이션에는 필수입니다.

      마이그레이션 PV 이동
  6. 다음 옵션 중 하나를 사용하여 마이그레이션 계획을 실행합니다.

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

      스테이지 마이그레이션을 마이그레이션 전에 대부분의 데이터가 대상에 복사되도록 여러 번 실행할 수 있습니다. 하나 이상의 단계적 마이그레이션을 실행하면 컷오버 마이그레이션 기간이 단축됩니다.

    • 컷오버 (Cutover)는 소스 클러스터에서 애플리케이션을 중지하고 리소스를 대상 클러스터로 이동합니다.

      선택 사항: 마이그레이션 중에 소스 클러스터에서 트랜잭션 중지 확인란의 선택을 취소할 수 있습니다.

OCP 3에서 4로의 애플리케이션 마이그레이션

1.3. 데이터 복사 방법 정보

Migration Toolkit for Containers(MTC)는 소스 클러스터에서 대상 클러스터로 데이터를 마이그레이션하기 위한 파일 시스템 및 스냅샷 데이터 복사 방법을 지원합니다. 환경에 적합하고 스토리지 공급자가 지원하는 방법을 선택할 수 있습니다.

1.3.1. 파일 시스템 복사 방법

MTC는 소스 클러스터에서 복제 리포지토리로 데이터 파일을 복사하고 다시 대상 클러스터로 복사합니다.

파일 시스템 복사 방법은 간접 마이그레이션에 Restic을 사용하거나 직접 볼륨 마이그레이션에 Rsync를 사용합니다.

표 1.2. 파일 시스템 복사 방법 요약
혜택제한
  • 클러스터는 다른 스토리지 클래스를 보유할 수 있습니다.
  • 모든 S3 스토리지 공급자에 대해 지원됨.
  • 체크섬을 통한 선택적 데이터 확인.
  • 성능이 크게 증가하는 직접 볼륨 마이그레이션을 지원합니다.
  • 스냅샷 복사 방법보다 느림.
  • 선택적 데이터 확인으로 성능이 크게 저하합니다.
참고

Restic 및 Rsync PV 마이그레이션은 지원되는 PV가 volumeMode=filesystem 인 것으로 가정합니다. 파일 시스템 마이그레이션에는 volumeMode=Block 을 사용할 수 없습니다.

1.3.2. 스냅샷 복사 방법

MTC는 소스 클러스터 데이터의 스냅샷을 클라우드 공급자의 복제 리포지토리에 복사합니다. 대상 클러스터에서 데이터가 복원됩니다.

스냅샷 복사 방법은 Amazon Web Services, Google Cloud Provider 및 Microsoft Azure와 함께 사용할 수 있습니다.

표 1.3. 스냅샷 복사 방법 요약
혜택제한
  • 파일 시스템 복사 방법보다 빠름.
  • 클라우드 공급자는 스냅샷을 지원해야 합니다.
  • 클러스터는 동일한 클라우드 공급자에 있어야 합니다.
  • 클러스터는 동일한 위치 또는 지역에 있어야 합니다.
  • 클러스터는 동일한 스토리지 클래스를 보유해야 합니다.
  • 스토리지 클래스는 스냅샷과 호환 가능해야 합니다.
  • 직접 볼륨 마이그레이션을 지원하지 않습니다.

1.4. 직접 볼륨 마이그레이션 및 직접 이미지 마이그레이션

직접 이미지 마이그레이션(DIM) 및 직접 볼륨 마이그레이션(DVM)을 사용하여 소스 클러스터에서 대상 클러스터로 직접 이미지 및 데이터를 마이그레이션할 수 있습니다.

다른 가용성 영역에 있는 노드에서 DVM을 실행하는 경우 마이그레이션된 Pod가 영구 볼륨 클레임에 액세스할 수 없기 때문에 마이그레이션이 실패할 수 있습니다.

DIM 및 DVM은 소스 클러스터에서 복제 리포지토리로 파일을 백업하고 복제 리포지토리에서 대상 클러스터로 파일을 복원하는 중간 단계를 건너뛰기 때문에 상당한 성능 이점을 지닙니다. Rsync를 사용하여 데이터를 전송합ㅌ니다.

DIM과 DVM에는 다른 사전 요구 사항이 있습니다.

2장. MTC 릴리스 노트

2.1. Migration Toolkit for Containers 1.8 릴리스 노트

MTC(Migration Toolkit for Containers) 릴리스 노트에서는 새로운 기능 및 개선 사항, 더 이상 사용되지 않는 기능 및 알려진 문제에 대해 설명합니다.

MTC를 사용하면 네임스페이스 단위로 OpenShift Container Platform 클러스터 간에 애플리케이션 워크로드를 마이그레이션할 수 있습니다.

OpenShift Container Platform 3에서 4.15로 마이그레이션하고 OpenShift Container Platform 4 클러스터 간에 마이그레이션할 수 있습니다.

MTC는 마이그레이션을 제어하고 애플리케이션 다운타임을 최소화할 수 있도록 Kubernetes 사용자 지정 리소스를 기반으로 하는 웹 콘솔 및 API를 제공합니다.

MTC 지원 정책에 대한 자세한 내용은 Red Hat OpenShift Container Platform 라이프 사이클 정책의 일부인 OpenShift 애플리케이션 및 클러스터 마이그레이션 솔루션을 참조하십시오.

2.1.1. Migration Toolkit for Containers 1.8.3 릴리스 노트

2.1.1.1. 기술 변경 사항

MTC(Migration Toolkit for Containers) 1.8.3에는 다음과 같은 기술적 변경 사항이 있습니다.

OADP 1.3 지원

MTC 1.8.3은 MTC 1.8.z의 종속성으로 OADP(OpenShift API for Data Protection)에 대한 지원을 추가합니다.

2.1.1.2. 해결된 문제

이 릴리스에는 다음과 같은 주요 해결된 문제가 있습니다.

CVE-2024-24786: Golang protobuf 모듈의 Flaw로 인해 unmarshal 함수가 무한 루프에 들어갑니다.

이전 MTC 릴리스에서는 Golang의 protobuf 모듈에서 취약점이 발견되었습니다. 여기서 unmarshal 함수가 특정 잘못된 입력을 처리하는 동안 무한 루프를 입력했습니다. 결과적으로 공격자는 잘못된 입력을 신중하게 구성하여 함수가 무한 루프에 진입했습니다.

이번 업데이트를 통해 unmarshal 기능이 예상대로 작동합니다.

자세한 내용은 CVE-2024-24786 을 참조하십시오.

CVE-2023-45857: Axios Cross-Site Request Forgery Vulnerability

이전 MTC 릴리스에서는 Axios 1.5.1에서 취약점이 발견되었으며, Axios 1.5.1에서는 공격자가 중요한 정보를 볼 수 있도록 HTTP 헤더 X- XSRF-TOKEN 을 포함하여 템플릿에 저장된 기밀 XSRF-TOKEN을 공개했습니다.

자세한 내용은 CVE-2023-45857 에서 참조하십시오.

소스 워크로드가 quiesced되지 않으면 Restic 백업이 제대로 작동하지 않습니다.

이전 MTC 릴리스에서는 경로를 사용하여 애플리케이션을 배포할 때 일부 파일이 마이그레이션되지 않았습니다. 소스 워크로드에 대해 quiesce 옵션을 선택하지 않은 경우 Restic 백업이 예상대로 작동하지 않았습니다.

이 문제는 MTC 1.8.3에서 해결되었습니다.

자세한 내용은 BZ#2242064 에서 참조하십시오.

Velero에서 지원되지 않는 값 오류로 인해 Migration Controller 를 설치하지 못했습니다

Velero에서 지원되지 않는 값 오류로 인해 MigrationController 를 설치하지 못했습니다. OADP 1.3.0을 OADP 1.3.1로 업데이트하면 이 문제가 해결됩니다. 자세한 내용은 BZ#2267018 에서 참조하십시오.

이 문제는 MTC 1.8.3에서 해결되었습니다.

해결된 모든 문제의 전체 목록은 Jira의 MTC 1.8.3 해결 문제 목록을 참조하십시오.

2.1.1.3. 확인된 문제

MTC에는 다음과 같은 알려진 문제가 있습니다.

서비스 계정에 연결된 SCC는 OpenShift Container Platform 4.12에서 마이그레이션할 수 없습니다.

OpenShift Container Platform 버전 4.12의 서비스 계정에 대한 관련 SCC(보안 컨텍스트 제약 조건)는 마이그레이션할 수 없습니다. 이 문제는 향후 MTC 릴리스에서 해결될 예정입니다. (MIG-1454).

알려진 모든 문제의 전체 목록은 Jira의 MTC 1.8.3 알려진 문제 목록을 참조하십시오.

2.1.2. Migration Toolkit for Containers 1.8.2 릴리스 노트

2.1.2.1. 해결된 문제

이 릴리스에는 다음과 같은 주요 해결된 문제가 있습니다.

사용자 정의 CA 복제 리포지토리를 설정한 후 백업 단계가 실패합니다.

이전 릴리스의 MTC(Migration Toolkit for Containers)에서는 복제 리포지토리를 편집하고, 사용자 정의 CA 인증서를 추가하고, 리포지토리를 성공적으로 연결하며, 마이그레이션을 트리거하면 백업 단계에서 오류가 발생했습니다.

CVE-2023-26136: 4.1.3 이전의 hard-cookie 패키지는 Prototype Pollution에 취약합니다.

이전 (MTC) 릴리스에서는 MTC에서 사용되는 hard-cookie 패키지의 4.1.3 이전 버전에서는 프로토타입의 오염에 취약합니다. 이 취약점은 rejectPublicSuffixes 의 값이 false 로 설정되었을 때ieJar가 쿠키를 올바르게 처리하지 않았기 때문에 발생했습니다.

자세한 내용은 (CVE-2023-26136)에서 참조하십시오.

CVE-2022-25883 openshift-migration-ui-container: nodejs-semver: 정규식 서비스 거부

이전 릴리스 (MTC)에서 MTC에서 사용되는 7.5.2 이전의 semver 패키지 버전은 신뢰할 수 없는 사용자 데이터가 범위로 제공된 경우 newRange 함수의 정규식 서비스 거부 (ReDoS)에 취약했습니다.

자세한 내용은 (CVE-2022-25883)에서 참조하십시오.

2.1.2.2. 확인된 문제

이 릴리스에는 알려진 문제가 없습니다.

2.1.3. Migration Toolkit for Containers 1.8.1 릴리스 노트

2.1.3.1. 해결된 문제

이 릴리스에는 다음과 같은 주요 해결된 문제가 있습니다.

CVE-2023-39325: golang: net/http, x/net/http2: 빠른 스트림 재설정으로 인해 과도한 작업이 발생할 수 있습니다.

MTC(Migration Toolkit for Containers)에서 사용하는 HTTP/2 프로토콜에서 멀티플렉싱된 스트림을 처리하는 데 취약점이 발견되었습니다. 클라이언트는 반복적으로 새로운 멀티플렉싱 스트림을 요청하고 이를 취소하기 위해 RST_STREAM 프레임을 즉시 보낼 수 있습니다. 이렇게 하면 스트림 설정 및 해제 측면에서 서버에 대한 추가 워크로드가 생성되는 반면 연결당 최대 활성 스트림 수에 대한 서버 측 제한을 방지하여 서버 리소스 사용량으로 인해 서비스 거부가 발생합니다. (BZ#2245079)

이 문제를 해결하려면 MTC 1.8.1 이상으로 업데이트하는 것이 좋습니다.

자세한 내용은 (CVE-2023-39325)(CVE-2023-44487)를 참조하십시오.

2.1.3.2. 확인된 문제

이 릴리스에는 알려진 문제가 없습니다.

2.1.4. Migration Toolkit for Containers 1.8.0 릴리스 노트

2.1.4.1. 해결된 문제

이 릴리스에는 다음과 같은 해결된 문제가 있습니다.

간접 마이그레이션은 백업 단계에 있습니다.

이전 릴리스에서는 InvalidImageName 오류로 인해 간접 마이그레이션이 백업 단계에서 중단되었습니다. (BZ#2233097)

PodVolumeRestore는 마이그레이션이 복원 단계에서 중단되도록 계속 진행 중 상태로 유지됩니다.

이전 릴리스에서는 간접 마이그레이션을 수행할 때 podvolumerestore가 완료될 때까지의 Stage Restore 단계에서 마이그레이션이 중단되었습니다. (BZ#2233868)

마이그레이션된 애플리케이션이 대상 클러스터의 내부 레지스트리에서 이미지를 가져올 수 없음

이전 릴리스에서는 애플리케이션을 대상 클러스터로 마이그레이션할 때 마이그레이션된 애플리케이션이 내부 이미지 레지스트리에서 이미지를 가져오는 데 실패하여 application failure가 발생했습니다. (BZ#2233103)

권한 부여 문제로 인해 Azure에서 마이그레이션 실패

이전 릴리스에서는 Azure 스토리지로 백업할 때 Backup 단계에서 마이그레이션이 실패했습니다. (BZ#2238974)

2.1.4.2. 확인된 문제

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

이전 Restic Pod는 MTC 1.7.x → 1.8.x 업그레이드에서 제거되지 않음

이번 릴리스에서는 MTC Operator를 1.7.x에서 1.8.x로 업그레이드할 때 이전 Restic Pod가 제거되지 않습니다. 따라서 업그레이드 후 Restic 및 node-agent Pod가 네임스페이스에 표시됩니다. (BZ#2236829)

마이그레이션된 빌더 Pod가 이미지 레지스트리로 푸시되지 않음

이번 릴리스에서는 소스에서 대상 클러스터로 BuildConfig 를 포함한 애플리케이션을 마이그레이션할 때 빌더 Pod가 error가 발생하여 이미지를 이미지 레지스트리로 내보내지 못합니다. (BZ#2234781)

[UI] CA 번들 파일 필드가 올바르게 지워지지 않음

이번 릴리스에서는 MigStorage의 MCG NooBaa 버킷에 대한 Require SSL verification 및 CA 번들 파일에 콘텐츠를 추가한 후 예상대로 연결이 실패합니다. 그러나 CA 번들 콘텐츠를 제거하고 Require SSL verification 를 지워 이러한 변경 사항을 되돌릴 때 여전히 연결에 실패합니다. 이 문제는 리포지토리를 삭제하고 다시 추가하여 해결할 수 있습니다. (BZ#2240052)

사용자 정의 CA 복제 리포지토리를 설정한 후 백업 단계가 실패합니다.

(MTC)에서 복제 리포지토리를 편집하고 사용자 정의 CA 인증서를 추가하고 리포지토리를 성공적으로 연결한 후 마이그레이션을 트리거하면 백업 단계에서 오류가 발생합니다.

이 문제는 MTC 1.8.2에서 해결되었습니다.

CVE-2023-26136: 4.1.3 이전의 hard-cookie 패키지는 Prototype Pollution에 취약합니다.

MTC에 사용되는 hard-cookie 패키지의 4.1.3 이전 버전은 프로토타입 문제 해결에 취약합니다. 이 취약점은 rejectPublicSuffixes 의 값이 false 로 설정된 경우 CryostatJar가 쿠키를 올바르게 처리하지 않기 때문에 발생합니다.

이 문제는 MTC 1.8.2에서 해결되었습니다.

자세한 내용은 (CVE-2023-26136)에서 참조하십시오.

CVE-2022-25883 openshift-migration-ui-container: nodejs-semver: 정규식 서비스 거부

이전 릴리스 (MTC)에서 MTC에서 사용되는 7.5.2 이전의 semver 패키지 버전은 신뢰할 수 없는 사용자 데이터가 범위로 제공되는 경우 newRange 함수의 정규식 서비스 거부 (ReDoS)에 취약합니다.

이 문제는 MTC 1.8.2에서 해결되었습니다.

자세한 내용은 (CVE-2022-25883)에서 참조하십시오.

2.1.4.3. 기술 변경 사항

이 릴리스에는 다음과 같은 기술 변경 사항이 있습니다.

  • OpenShift Container Platform 3에서 OpenShift Container Platform 4로 마이그레이션하려면 레거시 MTC(Migration Toolkit for Containers) Operator 및 MTC 1.7.x가 필요합니다.
  • MTC 1.7.x에서 MTC 1.8.x로의 마이그레이션은 지원되지 않습니다.
  • MTC 1.7.x를 사용하여 OpenShift Container Platform 4.9 이하의 소스로 모든 항목을 마이그레이션해야 합니다.

    • MTC 1.7.x는 소스 및 대상 모두에서 사용해야 합니다.
  • MTC 1.8.x는 OpenShift Container Platform 4.10 이상에서 OpenShift Container Platform 4.10 이상으로의 마이그레이션만 지원합니다. 클러스터 버전 4.10 이상과 관련된 마이그레이션의 경우 1.7.x 또는 1.8.x 중 하나를 사용할 수 있습니다. 그러나 소스와 대상 모두에서 동일한 MTC 1.Y.z여야 합니다.

    • 소스 MTC 1.7.x에서 대상 MTC 1.8.x로의 마이그레이션은 지원되지 않습니다.
    • 소스 MTC 1.8.x에서 대상 MTC 1.7.x로의 마이그레이션은 지원되지 않습니다.
    • 소스 MTC 1.7.x에서 대상 MTC 1.7.x로의 마이그레이션이 지원됩니다.
    • 소스 MTC 1.8.x에서 대상 MTC 1.8.x로의 마이그레이션이 지원됩니다.
  • MTC 1.8.x는 기본적으로 OADP 1.2.x를 설치합니다.
  • MTC 1.7.x에서 MTC 1.8.0으로 업그레이드하려면 OADP 채널을 1.2로 수동으로 변경해야 합니다. 이 작업이 완료되지 않으면 Operator 업그레이드가 실패합니다.

2.2. Migration Toolkit for Containers 1.7 릴리스 노트

MTC(Migration Toolkit for Containers) 릴리스 노트에서는 새로운 기능 및 개선 사항, 더 이상 사용되지 않는 기능 및 알려진 문제에 대해 설명합니다.

MTC를 사용하면 네임스페이스 단위로 OpenShift Container Platform 클러스터 간에 애플리케이션 워크로드를 마이그레이션할 수 있습니다.

OpenShift Container Platform 3에서 4.15로 마이그레이션하고 OpenShift Container Platform 4 클러스터 간에 마이그레이션할 수 있습니다.

MTC는 마이그레이션을 제어하고 애플리케이션 다운타임을 최소화할 수 있도록 Kubernetes 사용자 지정 리소스를 기반으로 하는 웹 콘솔 및 API를 제공합니다.

MTC 지원 정책에 대한 자세한 내용은 Red Hat OpenShift Container Platform 라이프 사이클 정책의 일부인 OpenShift 애플리케이션 및 클러스터 마이그레이션 솔루션을 참조하십시오.

2.2.1. Migration Toolkit for Containers 1.7.16 릴리스 노트

2.2.1.1. 해결된 문제

이 릴리스에는 다음과 같은 해결된 문제가 있습니다.

CVE-2023-45290: Golang: net/http: Request.ParseMultipartForm 메서드의 메모리 소진

이전 MTC 버전에 영향을 미치는 net/http Golang 표준 라이브러리 패키지에서 취약점이 발견되었습니다. Request.ParseMulti partForm 을 사용하여 명시적으로 또는 Request.FormValue,Request.PostFormValue 또는 Request.FormFile 메서드를 사용하여 명시적으로 다중 파트 양식을 구문 분석할 때 구문 분석 양식의 총 크기에 대한 제한은 단일 양식 줄을 읽는 동안 사용되는 메모리에 적용되지 않습니다. 이렇게 하면 긴 줄이 포함된 악의적인 입력으로 인해 임의로 많은 양의 메모리를 할당하여 메모리 소모가 발생할 수 있습니다.

이 문제를 해결하려면 MTC 1.7.16으로 업그레이드하십시오.

자세한 내용은 CVE-2023-45290에서 참조하십시오.

CVE-2024-24783: Golang: crypto/x509: 알 수 없는 공개 키 알고리즘이 있는 인증서의 패닉 확인

이전 MTC 버전에 영향을 미치는 crypto/x509 Golang 표준 라이브러리 패키지에서 취약점이 발견되었습니다. 알 수 없는 공개 키 알고리즘이 포함된 인증서 체인을 확인하면 Certificate.Verify 에 패닉 상태가 됩니다. 이는 Config.ClientAuthVerifyClientCertIfGiven 또는 RequireAndVerifyClientCert로 설정하는 모든 crypto/tls 클라이언트 및 서버에 영향을 미칩니다. 기본 동작은 TLS 서버가 클라이언트 인증서를 확인하지 않는 것입니다.

이 문제를 해결하려면 MTC 1.7.16으로 업그레이드하십시오.

자세한 내용은 CVE-2024-24783 에서 참조하십시오.

CVE-2024-24784: Golang: net/mail: 표시 이름의 댓글이 잘못 처리됨

net/mail Golang 표준 라이브러리 패키지에서 취약점이 발견되었으며 이전 버전의 MTC에 영향을 미칩니다. ParseAddressList 함수는 주석을 잘못 처리하고, 괄호 안의 텍스트, 이름을 표시합니다. 이는 주소 구문 분석기를 따르는 잘못된 정렬이므로 다른 구문 분석을 사용하는 프로그램에서 서로 다른 신뢰 결정을 내릴 수 있습니다.

이 문제를 해결하려면 MTC 1.7.16으로 업그레이드하십시오.

자세한 내용은 CVE-2024-24784 를 참조하십시오.

CVE-2024-24785: Golang: html/template: MarshalJSON 메서드에서 반환된 오류는 템플릿을 이스케이프할 수 있습니다.

이전 MTC 버전에 영향을 미치는 html/template Golang 표준 라이브러리 패키지에서 취약점이 발견되었습니다. MarshalJSON 메서드에서 반환된 오류에 사용자 제어 데이터가 포함된 경우 html/template 패키지의 컨텍스트 자동 이스케이프 동작을 분할하는 데 사용할 수 있으므로 후속 작업이 예기치 않은 콘텐츠를 템플릿에 삽입할 수 있습니다.

이 문제를 해결하려면 MTC 1.7.16으로 업그레이드하십시오.

자세한 내용은 CVE-2024-24785 를 참조하십시오.

CVE-2024-29180: webpack-dev-middleware: URL 유효성 검사로 인해 파일 누출이 발생할 수 있습니다.

이전 MTC 버전에 영향을 미치는 webpack-dev-middleware 패키지에서 취약점이 발견되었습니다. 이 취약점은 로컬 파일을 반환하기 전에 제공된 URL 주소를 충분히 검증하지 못하므로 공격자가 URL을 작성하여 개발자의 시스템에서 임의의 로컬 파일을 반환할 수 있습니다.

이 문제를 해결하려면 MTC 1.7.16으로 업그레이드하십시오.

자세한 내용은 CVE-2024-29180 을 참조하십시오.

CVE-2024-30255: envoy: CONTINUATION 프레임 플러드로 인한 HTTP/2 CPU 소진

envoy 프록시가 이전 MTC 버전에 영향을 미치는 HTTP/2 codec를 구현하는 방식에서 취약점이 발견되었습니다. envoy 의 헤더 맵 제한을 초과한 후에도 단일 스트림 내에서 전송할 수 있는 CONTINUATION 프레임 수에 제한이 충분하지 않습니다. 이 취약점으로 인해 인증되지 않은 원격 공격자가 패킷을 취약한 서버로 보낼 수 있습니다. 이러한 패킷은 컴퓨팅 리소스를 사용하고 서비스 거부(DoS)를 유발할 수 있습니다.

이 문제를 해결하려면 MTC 1.7.16으로 업그레이드하십시오.

자세한 내용은 CVE-2024-30255 를 참조하십시오.

2.2.1.2. 확인된 문제

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

소스 클러스터의 Rsync Pod가 Error 상태가 되면 직접 볼륨 마이그레이션이 실패합니다.

PVC(영구 볼륨 클레임)가 있는 애플리케이션을 마이그레이션할 때 단계 마이그레이션 작업은 경고와 함께 성공하지만, 직접 볼륨 마이그레이션(DVM)은 오류 상태로 전환되는 소스 네임스페이스의 rsync Pod와 함께 실패합니다. (BZ#2256141)

충돌 조건이 생성된 후 간단히 지워집니다.

충돌 오류 메시지를 반환하는 새 상태 마이그레이션 계획을 생성할 때 오류 메시지가 표시된 직후에 삭제됩니다. (BZ#2144299)

클러스터에 구성된 다양한 공급자 유형의 볼륨 스냅샷 위치가 여러 개 있는 경우 마이그레이션이 실패합니다.

다른 공급자 유형이 있는 클러스터에 VSL( Volume Snapshot Locations)이 여러 개 있지만 기본 VSL로 설정하지 않은 경우 Velero로 인해 마이그레이션 작업이 실패하는 검증 오류가 발생합니다. (BZ#2180565)

2.2.2. Migration Toolkit for Containers 1.7.15 릴리스 노트

2.2.2.1. 해결된 문제

이 릴리스에는 다음과 같은 해결된 문제가 있습니다.

CVE-2024-24786: Golang의 protobuf 모듈에서 취약점이 발견되었으며, 여기서 unmarshal 함수가 무한 루프를 입력할 수 있습니다.

protojson.Unmarshal 함수에서 특정 형식의 잘못된 JSON 메시지를 정리하지 못할 때 함수가 무한 루프가 입력될 수 있는 취약점이 발견되었습니다. 이 조건은 Google.protobuf.Any 값이 포함된 메시지 또는 UnmarshalOptions. DiscardUnknown 옵션이 JSON 형식의 메시지에 설정된 경우 발생할 수 있습니다.

이 문제를 해결하려면 MTC 1.7.15로 업그레이드하십시오.

자세한 내용은 (CVE-2024-24786) 에서 참조하십시오.

CVE-2024-28180: jose-go 로 고도의 압축 데이터를 부적절하게 처리

고도로 압축 된 데이터를 부적절하게 처리하여 Jose에서 취약점이 발견되었습니다. 공격자는 Decrypt 또는 DecryptMulti 함수에 의해 압축 해제될 때 많은 양의 메모리와 CPU를 사용하는 압축된 데이터를 포함하는 JWE(JSON Web Encryption) 암호화된 메시지를 보낼 수 있습니다. 

이 문제를 해결하려면 MTC 1.7.15로 업그레이드하십시오.

자세한 내용은 (CVE-2024-28180) 에서 참조하십시오.

2.2.2.2. 확인된 문제

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

소스 클러스터의 Rsync Pod가 Error 상태가 되면 직접 볼륨 마이그레이션이 실패합니다.

PVC(영구 볼륨 클레임)를 사용하여 애플리케이션을 마이그레이션할 때 단계 마이그레이션 작업은 경고와 함께 성공하고, 직접 볼륨 마이그레이션(DVM)은 소스 네임스페이스의 rsync Pod가 오류 상태로 전환되어 실패합니다. (BZ#2256141)

충돌 조건이 생성된 후 간단히 지워집니다.

충돌 오류 메시지가 표시되는 새 상태 마이그레이션 계획을 생성할 때 오류 메시지가 표시된 직후에 삭제됩니다. (BZ#2144299)

기본 VSL이 지정되지 않은 클러스터에 구성된 다양한 공급자 유형의 VSL(볼륨 스냅샷 위치)이 여러 개 있는 경우 마이그레이션이 실패합니다.

다른 공급자 유형이 있는 클러스터에 여러 VSL이 있고 기본 VSL로 설정하지 않으면 Velero에서 마이그레이션 작업이 실패하는 검증 오류가 발생합니다. (BZ#2180565)

2.2.3. Migration Toolkit for Containers 1.7.14 릴리스 노트

2.2.3.1. 해결된 문제

이 릴리스에는 다음과 같은 해결된 문제가 있습니다.

CVE-2023-39325 CVE-2023-44487: 다양한 취약점

MTC(Migration Toolkit for Containers)에서 사용하는 HTTP/2 프로토콜의 멀티플렉싱 스트림을 처리하는 데 취약점이 발견되었습니다. 클라이언트는 반복적으로 새로운 멀티플렉싱 스트림을 요청한 다음 즉시 해당 요청을 취소하기 위해 RST_STREAM 프레임을 보낼 수 있습니다. 이 활동을 통해 스트림 설정 및 해제 측면에서 서버에 대한 추가 워크로드가 생성되었지만 연결당 최대 활성 스트림 수에 대한 서버 측 제한을 피할 수 있었습니다. 이로 인해 서버 리소스 사용량으로 인해 서비스 거부가 발생했습니다.

이 문제를 해결하려면 MTC 1.7.14로 업그레이드하십시오.

자세한 내용은 (CVE-2023-44487)(CVE-2023-39325) 를 참조하십시오.

CVE-2023-39318 CVE-2023-39319 CVE-2023-39321: 다양한 결함

  • (CVE-2023-39318): MTC에서 사용하는 Golang에서 취약점이 발견되었습니다. html/template 패키지는 < script > 컨텍스트의 HTML-예: "" 주석 토큰 또는 hashbang "#!" 주석 토큰을 올바르게 처리하지 않았습니다. 이 취약점으로 인해 템플릿 구문 분석기가 < script > 컨텍스트의 내용을 부적절하게 해석하여 작업이 부적절하게 이스케이프될 수 있습니다.

  • (CVE-2023-39319): MTC에서 사용하는 Golang에서 취약점이 발견되었습니다. html/template 패키지는 <script> 컨텍스트의 JavaScript 리터럴 내에 "<script", "<!-", "</script" 의 발생을 처리하는 데 적절한 규칙을 적용하지 않았습니다. 이로 인해 템플릿 구문 분석기에서 스크립트 컨텍스트가 조기 종료되도록 잘못 간주하여 작업이 부적절하게 이스케이프될 수 있습니다. 

  • (CVE-2023-39321): MTC에서 사용하는 Golang에서 취약점이 발견되었습니다. QUIC 연결에 대한 불완전한 post-handshake 메시지를 처리하면 패닉이 발생할 수 있습니다.

  • (CVE-2023-3932): MTC에서 사용하는 Golang에서 취약점이 발견되었습니다. QUIC 전송 프로토콜을 사용하는 연결은 post-handshake 메시지를 읽을 때 버퍼링된 데이터 양에 상한을 설정하지 않아 악의적인 QUIC 연결이 바인딩되지 않은 메모리 증가를 초래할 수 있었습니다. 

이러한 문제를 해결하려면 MTC 1.7.14로 업그레이드하십시오.

자세한 내용은 (CVE-2023-39318), (CVE-2023-39319)(CVE-2023-39321) 를 참조하십시오.

2.2.3.2. 확인된 문제

이 릴리스에는 알려진 문제가 없습니다.

2.2.4. Migration Toolkit for Containers 1.7.13 릴리스 노트

2.2.4.1. 해결된 문제

이 릴리스에는 주요 해결된 문제가 없습니다.

2.2.4.2. 확인된 문제

이 릴리스에는 알려진 문제가 없습니다.

2.2.5. Migration Toolkit for Containers 1.7.12 릴리스 노트

2.2.5.1. 해결된 문제

이 릴리스에는 주요 해결된 문제가 없습니다.

2.2.5.2. 확인된 문제

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

마이그레이션 세부 정보 페이지에 오류 코드 504가 표시됩니다.

마이그레이션 세부 정보 페이지에서 처음에는 마이그레이션 세부 정보가 문제 없이 표시됩니다. 그러나 경우에 따라 세부 정보가 사라지고 504 오류가 반환됩니다. (BZ#2231106)

MTC 1.7.x를 MTC 1.8로 업그레이드할 때 이전 잔여 Pod가 제거되지 않습니다.

MTC Operator를 1.7.x에서 1.8.x로 업그레이드할 때 이전 잔여 Pod는 제거되지 않습니다. 업그레이드 후 잔여 Pod 및 node-agent Pod가 네임스페이스에 표시됩니다. (BZ#2236829)

2.2.6. Migration Toolkit for Containers 1.7.11 릴리스 노트

2.2.6.1. 해결된 문제

이 릴리스에는 주요 해결된 문제가 없습니다.

2.2.6.2. 확인된 문제

이 릴리스에는 알려진 문제가 없습니다.

2.2.7. Migration Toolkit for Containers 1.7.10 릴리스 노트

2.2.7.1. 해결된 문제

이 릴리스에는 다음과 같은 주요 해결된 문제가 있습니다.

DVM에서 rsync 옵션 조정

이번 릴리스에서는 직접 볼륨 마이그레이션(DVM) 과정의 Rsync에서 절대 심볼릭 링크가 조작되는 것을 방지할 수 있습니다. 권한 있는 모드에서 DVM을 실행하면 PVC(영구 볼륨 클레임) 내부의 절대 심볼릭 링크가 유지됩니다. 권한 있는 모드로 전환하려면 MigrationController CR에서 migration_rsync_privileged 사양을 true 로 설정합니다. (BZ#2204461)

2.2.7.2. 확인된 문제

이 릴리스에는 알려진 문제가 없습니다.

2.2.8. Migration Toolkit for Containers 1.7.9 릴리스 노트

2.2.8.1. 해결된 문제

이 릴리스에는 주요 해결된 문제가 없습니다.

2.2.8.2. 확인된 문제

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

DVM에서 rsync 옵션 조정

이번 릴리스에서는 사용자가 DVM(직접 볼륨 마이그레이션) 중에 rsync에 의해 절대 심볼릭 링크가 조작되지 않도록 할 수 없습니다. (BZ#2204461)

2.2.9. Migration Toolkit for Containers 1.7.8 릴리스 노트

2.2.9.1. 해결된 문제

이 릴리스에는 다음과 같은 주요 해결된 문제가 있습니다.

MTC Operator에서 Velero 이미지를 덮어쓸 수 없습니다

이전 릴리스에서는 MigrationController CR(사용자 정의 리소스)에서 velero_image_fqin 매개변수를 사용하여 velero 이미지를 재정의할 수 없었습니다. (BZ#2143389)

도메인 이름에 6자를 초과하면 UI에서 MigCluster를 추가할 수 없습니다.

이전 릴리스에서는 도메인 이름에 6자를 초과하면 UI에서 MigCluster를 추가할 수 없습니다. UI 코드에는 2~6자 사이의 도메인 이름이 예상되었습니다. (BZ#2152149)

UI가 마이그레이션 페이지를 렌더링하지 못했습니다: Cannot read properties of undefined (reading 'name')

이전 릴리스에서는 UI가 마이그레이션' 페이지를 렌더링 Cannot read properties of undefined (reading 'name') 속성을 반환하지 못했습니다. (BZ#2163485)

Red Hat OpenShift Container Platform 4.6 클러스터에서 DPA 리소스 생성 실패

이전 릴리스에서는 OpenShift Container Platform 4.6 클러스터에 MTC를 배포할 때 로그에 따라 DPA를 생성하지 않아 일부 Pod가 누락되었습니다. OCP 4.6 클러스터의 migration-controller 로그에서 예기치 않은 null 값이 전달되어 오류가 발생했습니다. (BZ#2173742)

2.2.9.2. 확인된 문제

이 릴리스에는 알려진 문제가 없습니다.

2.2.10. Migration Toolkit for Containers 1.7.7 릴리스 노트

2.2.10.1. 해결된 문제

이 릴리스에는 주요 해결된 문제가 없습니다.

2.2.10.2. 확인된 문제

이 릴리스에는 알려진 문제가 없습니다.

2.2.11. Migration Toolkit for Containers 1.7.6 릴리스 노트

2.2.11.1. 새로운 기능

Red Hat OpenShift Container Platform 4.12의 PSA를 사용하여 DVM 지원에 대해 제안된 변경 사항을 구현합니다.

OpenShift Container Platform 4.12에서 PSA(Pod Security Admission)가 적용되면 기본 Pod는 restricted 프로필로 실행됩니다. 이 restricted 프로필은 마이그레이션해야 하는 워크로드가 이 정책을 위반하여 더 이상 작동하지 않음을 의미합니다. 다음 개선 사항에서는 OCP 4.12와 계속 호환되는 데 필요한 변경 사항을 간략하게 설명합니다. (MIG-1240)

2.2.11.2. 해결된 문제

이 릴리스에는 다음과 같은 주요 해결된 문제가 있습니다.

Red Hat OpenShift Platform 4.12에서 cronjob 오류가 누락되어 스토리지 클래스 변환 계획을 생성할 수 없음

이전 릴리스에서는 영구 볼륨 페이지에서 버전 batch/v1beta1 에서 CronJob을 사용할 수 없는 오류가 발생하며 취소를 클릭하면 migplan이 Not ready 상태로 생성됩니다. (BZ#2143628)

2.2.11.3. 확인된 문제

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

충돌 조건이 생성되면 잠시 후에 이 조건이 지워짐

충돌 오류가 발생하는 새 상태 마이그레이션 계획을 생성하면 해당 오류가 표시된 후 해당 오류가 지워집니다. (BZ#2144299)

2.2.12. Migration Toolkit for Containers 1.7.5 릴리스 노트

2.2.12.1. 해결된 문제

이 릴리스에는 다음과 같은 주요 해결된 문제가 있습니다.

소스 클러스터에서 rsync Pod가 오류 상태로 전환되어 직접 볼륨 마이그레이션이 실패

이전 릴리스에서 마이그레이션은 경고와 함께 성공했지만 소스 네임스페이스의 rsync Pod에서 직접 볼륨 마이그레이션에 실패했습니다. (*BZ#2132978)

2.2.12.2. 확인된 문제

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

MTC Operator에서 Velero 이미지를 덮어쓸 수 없음

이전 릴리스에서는 MigrationController CR(사용자 정의 리소스)에서 velero_image_fqin 매개변수를 사용하여 velero 이미지를 재정의할 수 없었습니다. (BZ#2143389)

UI에서 MigHook를 편집할 때 페이지가 다시 로드되지 않을 수 있음

네트워크 연결 문제가 있는 경우 후크를 편집할 때 UI가 다시 로드되지 않을 수 있습니다. 네트워크 연결이 복원되면 캐시가 지워질 때까지 페이지가 다시 로드되지 않습니다. (BZ#2140208)

2.2.13. Migration Toolkit for Containers 1.7.4 릴리스 노트

2.2.13.1. 해결된 문제

이 릴리스에는 주요 해결된 문제가 없습니다.

2.2.13.2. 확인된 문제

대상 클러스터에서 일부 리소스 삭제 누락된 롤백

MTC UI에서 애플리케이션 롤백을 수행할 때 일부 리소스는 대상 클러스터에서 삭제되지 않고 롤백에 상태가 성공적으로 완료된 것으로 표시됩니다. (BZ#2126880)

2.2.14. Migration Toolkit for Containers 1.7.3 릴리스 노트

2.2.14.1. 해결된 문제

이 릴리스에는 다음과 같은 주요 해결된 문제가 있습니다.

대상 네임스페이스에 대한 올바른 DNS 검증

이전 릴리스에서는 대상 네임스페이스가 알파벳이 아닌 문자로 시작된 경우 MigPlan을 검증할 수 없습니다. (BZ#2102231)

UI에서 모든 PVC를 선택 해제하면 시도된 PVC 전송이 발생합니다.

이전 릴리스에서는 전체 마이그레이션을 수행하는 동안 PVC(영구 볼륨 클레임) 선택을 생략하지 않고 PVC 선택을 건너뛰지 않고 마이그레이션을 시도합니다. (BZ#2106073)

대상 네임스페이스에 대한 잘못된 DNS 검증

이전 릴리스에서는 대상 네임스페이스가 알파벳이 아닌 문자로 시작했기 때문에 MigPlan을 검증할 수 없었습니다. (BZ#2102231)

2.2.14.2. 확인된 문제

이 릴리스에는 알려진 문제가 없습니다.

2.2.15. Migration Toolkit for Containers 1.7.2 릴리스 노트

2.2.15.1. 해결된 문제

이 릴리스에는 다음과 같은 주요 해결된 문제가 있습니다.

MTC UI가 로그를 올바르게 표시하지 않음

이전 릴리스에서는 MTC UI가 로그를 올바르게 표시하지 않았습니다. (BZ#2062266)

migplan에서 migstorage 참조 추가 StorageClass 변환 계획

이전 릴리스에서는 StorageClass 변환 계획에 사용되지 않은 경우에도 migstorage 참조가 있었습니다. (BZ#2078459)

다운로드한 로그에서 Velero Pod 로그 누락

이전 릴리스에서는 모든 로그에 대해 압축(.zip) 폴더를 다운로드할 때 velero Pod가 누락되었습니다. (BZ#2076599)

UI 드롭다운에서 Velero Pod 로그 누락

이전 릴리스에서는 마이그레이션이 수행된 후 드롭다운 목록에 제공된 로그에 velero Pod 로그가 포함되지 않았습니다. (BZ#2076593)

Rsync 옵션 로그가 log-reader Pod에 표시되지 않음

이전 릴리스에서는 migrationcontroller에서 유효한 rsync 옵션을 설정하려고 할 때 log-reader에서 유효하지 않은 옵션 또는 rsync 명령에 대한 로그를 표시하지 않았습니다. (BZ#2079252)

Velero/Restic의 기본 CPU 요청은 너무 까다롭고 특정 환경에서는 실패

이전 릴리스에서는 Velero/Restic에 대한 기본 CPU 요청이 너무 부족하여 특정 환경에서 실패했습니다. Velero 및 Restic Pod에 대한 기본 CPU 요청은 500m로 설정됩니다. 이 값은 높았습니다. (BZ#2088022)

2.2.15.2. 확인된 문제

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

UI에서 복제 리포지토리를 다른 스토리지 공급자 유형으로 업데이트하는 것은 지원되지 않음

복제 리포지토리를 다른 유형으로 업데이트하고 리포지토리를 업데이트를 클릭하면 연결이 성공적으로 표시되지만 UI가 올바른 세부 정보로 업데이트되지 않습니다. 편집 버튼을 다시 클릭하면 이전 복제 리포지토리 정보가 계속 표시됩니다.

또한 복제 리포지토리를 다시 업데이트하려고 할 때 이전 복제 세부 정보가 계속 표시됩니다. 새 리포지토리를 선택할 때 이전에 입력한 모든 정보가 표시되고 업데이트 리포지토리는 제출할 변경 사항이 없는 경우와 같이 활성화되지 않습니다. (BZ#2102020)

백업을 찾을 수 없기 때문에 마이그레이션이 실패

초기 백업이 발견되지 않았기 때문에 복원 단계에서 마이그레이션이 실패합니다. (BZ#2104874)

Azure 리소스 그룹을 업데이트할 때 클러스터 업데이트 버튼이 활성화되지 않음

원격 클러스터를 업데이트할 때 Azure 리소스 그룹 확인란을 선택하고 리소스 그룹을 추가하면 클러스터 업데이트 옵션이 활성화되지 않습니다. (BZ#2098594)

migstorage 리소스를 삭제할 때 UI에서 오류 발생

OpenShift Container Platform에서 backupStorage 인증 정보 시크릿을 생성할 때 migstorage 가 UI에서 제거되면 404 오류가 반환되고 기본 보안이 제거되지 않습니다. (BZ#2100828)

UI에서 리소스 수를 0으로 표시하는 MigAnalytic 리소스

백엔드에서 migplan을 생성하면 Miganalytic 리소스에서 리소스 수를 UI에서 0 으로 표시합니다. (BZ#2102139)

이미지 레지스트리에 노출된 경로 호스트에 두 개의 후행 슬래시가 추가되면 레지스트리 검증이 실패

//를 의미하는 두 개의 후행 슬래시를 노출된 레지스트리 경로에 추가하면 MigCluster 리소스가 상태를 connected으로 표시합니다. DIM을 사용하여 백엔드에서 migplan을 생성할 때 계획이 준비되지 unready 상태로 이동합니다. (BZ#2104864)

소스 클러스터를 편집하는 동안 서비스 계정 토큰이 표시되지 않음

추가되었으며 Connected 상태인 소스 클러스터를 편집할 때 UI에서 서비스 계정 토큰이 필드에 표시되지 않습니다. 마법사를 저장하려면 토큰을 다시 가져와서 필드 내에 세부 정보를 제공해야 합니다. (BZ#2097668)

2.2.16. Migration Toolkit for Containers 1.7.1 릴리스 노트

2.2.16.1. 해결된 문제

이 릴리스에는 주요 해결된 문제가 없습니다.

2.2.16.2. 확인된 문제

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

대상 네임스페이스에 대한 잘못된 DNS 검증

대상 네임스페이스가 알파벳이 아닌 문자로 시작되므로 MigPlan을 검증할 수 없습니다. (BZ#2102231)

Velero Pod에서 라벨이 누락되어 마이그레이션 컨트롤러의 클라우드 전파 단계가 작동하지 않음

Velero Pod에서 라벨이 누락되어 마이그레이션 컨트롤러의 클라우드 전파 단계는 작동하지 않습니다. 마이그레이션 컨트롤러의 EnsureCloudSecretPropagated 단계는 복제 리포지토리 보안이 양쪽에 전파될 때까지 대기합니다. 이 레이블이 Velero Pod에서 누락되므로 단계가 예상대로 작동하지 않습니다. (BZ#2088026)

특정 환경에서 스케줄링을 실패하는 경우 Velero/Restic의 기본 CPU 요청이 너무 까다로움

특정 환경에서 스케줄링을 실패하는 경우 Velero/Restic의 기본 CPU 요청이 너무 까다롭습니다. Velero 및 Restic Pod에 대한 기본 CPU 요청은 500m로 설정됩니다. 이러한 값은 높습니다. Velero 및 Restic의 podConfig 필드를 사용하여 DPA에서 리소스를 구성할 수 있습니다. 마이그레이션 Operator는 CPU 요청을 100m과 같은 더 낮은 값으로 설정해야 MTC가 자주 작동하는 리소스 제한 환경에서 Velero 및 Restic Pod를 예약할 수 있습니다. (BZ#2088022)

스토리지 클래스 변환 계획을 편집한 후 persistentVolumes 페이지에 경고가 표시됨

스토리지 클래스 변환 계획을 편집한 후 persistentVolumes 페이지에 경고가 표시됩니다. 기존 마이그레이션 계획을 편집할 때 UI에 경고가 표시됩니다. At least one PVC must be selected for Storage Class Conversion. (BZ#2079549)

다운로드한 로그에서 Velero Pod 로그 누락

모든 로그에 대해 압축된(.zip) 폴더를 다운로드할 때 velero Pod가 누락됩니다. (BZ#2076599)

UI 드롭다운에서 Velero Pod 로그 누락

마이그레이션이 완료되면 드롭다운 목록에 제공된 로그에 velero Pod 로그가 포함되지 않습니다. (BZ#2076593)

2.2.17. Migration Toolkit for Containers 1.7.0 릴리스 노트

2.2.17.1. 새로운 기능 및 개선 사항

이 릴리스에는 다음과 같은 새로운 기능 및 개선 사항이 있습니다.

  • MTC(Migration Toolkit for Containers) Operator는 이제 OADP(OpenShift API for Data Protection) Operator에 따라 다릅니다. MTC Operator를 설치하면 OLM(Operator Lifecycle Manager)이 동일한 네임스페이스에 OADP Operator를 자동으로 설치합니다.
  • crane tunnel-api 명령을 사용하여 두 클러스터 간에 네트워크 터널을 설정하여 방화벽 뒤에 있는 소스 클러스터에서 클라우드 기반 대상 클러스터로 마이그레이션할 수 있습니다.
  • MTC 웹 콘솔에서 스토리지 클래스 변환: 동일한 클러스터 내에서 마이그레이션을 통해 PV(영구 볼륨)의 스토리지 클래스를 변환할 수 있습니다.
2.2.17.2. 확인된 문제

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

  • MigPlan 사용자 정의 리소스는 AWS gp2 PVC에 사용 가능한 공간이 없는 경우 경고를 표시하지 않습니다. (BZ#1963927)
  • 대상 스토리지가 AWS EBS(Elastic File System)에서 동적으로 프로비저닝한 PV인 경우 직접 및 간접 데이터 전송이 작동하지 않습니다. 이는 AWS EFS CSI(Container Storage Interface) 드라이버의 제한 때문입니다. (BZ#2085097)
  • IBM Cloud용 블록 스토리지는 동일한 가용 영역에 있어야 합니다. 가상 프라이빗 클라우드의 블록 스토리지에 대한 IBM FAQ를 참조하십시오.
  • MTC 1.7.6은 v1beta1 cron 작업을 지원하는 소스 클러스터에서 cron 작업을 v1beta1 cron 작업을 지원하지 않는 OpenShift Container Platform 4.12 이상 클러스터로 마이그레이션할 수 없습니다. (BZ#2149119)

2.3. Migration Toolkit for Containers 1.6 릴리스 노트

MTC(Migration Toolkit for Containers) 릴리스 노트에서는 새로운 기능 및 개선 사항, 더 이상 사용되지 않는 기능 및 알려진 문제에 대해 설명합니다.

MTC를 사용하면 네임스페이스 단위로 OpenShift Container Platform 클러스터 간에 애플리케이션 워크로드를 마이그레이션할 수 있습니다.

OpenShift Container Platform 3에서 4.15로 마이그레이션하고 OpenShift Container Platform 4 클러스터 간에 마이그레이션할 수 있습니다.

MTC는 마이그레이션을 제어하고 애플리케이션 다운타임을 최소화할 수 있도록 Kubernetes 사용자 지정 리소스를 기반으로 하는 웹 콘솔 및 API를 제공합니다.

MTC 지원 정책에 대한 자세한 내용은 Red Hat OpenShift Container Platform 라이프 사이클 정책의 일부인 OpenShift 애플리케이션 및 클러스터 마이그레이션 솔루션을 참조하십시오.

2.3.1. Migration Toolkit for Containers 1.6 릴리스 노트

2.3.1.1. 새로운 기능 및 개선 사항

이 릴리스에는 다음과 같은 새로운 기능 및 개선 사항이 있습니다.

  • 상태 마이그레이션: 특정 PVC(영구 볼륨 클레임)를 선택하여 반복 가능한 상태 전용 마이그레이션을 수행할 수 있습니다.
  • "신규 Operator 버전 사용 가능" 알림: MTC 웹 콘솔의 클러스터 페이지에 새로운 Migration Toolkit for Containers Operator가 사용 가능한 경우 알림이 표시됩니다.
2.3.1.2. 더 이상 사용되지 않는 기능

더 이상 사용되지 않는 기능은 다음과 같습니다.

  • MTC 버전 1.4는 더 이상 지원되지 않습니다.
2.3.1.3. 확인된 문제

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

  • OpenShift Container Platform 3.10에서 MigrationController Pod를 다시 시작하는 데 시간이 너무 오래 걸립니다. Bugzilla 보고서에는 해결 방법이 포함되어 있습니다. (BZ#1986796)
  • Stage Pod는 IBM Cloud의 클래식 OpenShift Container Platform 소스 클러스터에서 직접 볼륨 마이그레이션 중에 실패합니다. IBM 블록 스토리지 플러그인은 동일한 노드의 여러 Pod에 동일한 볼륨을 마운트하는 것을 허용하지 않습니다. 따라서 Rsync Pod와 애플리케이션 pod에 PVC를 동시에 마운트할 수 없습니다. 이 문제를 해결하려면 마이그레이션 전에 애플리케이션 Pod를 중지합니다. (BZ#1887526)
  • MigPlan 사용자 정의 리소스는 AWS gp2 PVC에 사용 가능한 공간이 없는 경우 경고를 표시하지 않습니다. (BZ#1963927)
  • IBM Cloud용 블록 스토리지는 동일한 가용 영역에 있어야 합니다. 가상 프라이빗 클라우드의 블록 스토리지에 대한 IBM FAQ를 참조하십시오.

2.4. Migration Toolkit for Containers 1.5 릴리스 노트

MTC(Migration Toolkit for Containers) 릴리스 노트에서는 새로운 기능 및 개선 사항, 더 이상 사용되지 않는 기능 및 알려진 문제에 대해 설명합니다.

MTC를 사용하면 네임스페이스 단위로 OpenShift Container Platform 클러스터 간에 애플리케이션 워크로드를 마이그레이션할 수 있습니다.

OpenShift Container Platform 3에서 4.15로 마이그레이션하고 OpenShift Container Platform 4 클러스터 간에 마이그레이션할 수 있습니다.

MTC는 마이그레이션을 제어하고 애플리케이션 다운타임을 최소화할 수 있도록 Kubernetes 사용자 지정 리소스를 기반으로 하는 웹 콘솔 및 API를 제공합니다.

MTC 지원 정책에 대한 자세한 내용은 Red Hat OpenShift Container Platform 라이프 사이클 정책의 일부인 OpenShift 애플리케이션 및 클러스터 마이그레이션 솔루션을 참조하십시오.

2.4.1. Migration Toolkit for Containers 1.5 릴리스 노트

2.4.1.1. 새로운 기능 및 개선 사항

이 릴리스에는 다음과 같은 새로운 기능 및 개선 사항이 있습니다.

  • 웹 콘솔의 마이그레이션 세부 정보 페이지의 마이그레이션 리소스 트리는 마이그레이션 모니터링 및 디버깅을 위한 추가 리소스, Kubernetes 이벤트 및 실시간 상태 정보로 향상되었습니다.
  • 웹 콘솔은 수백 개의 마이그레이션 계획을 지원할 수 있습니다.
  • 소스 네임스페이스는 마이그레이션 계획의 다른 대상 네임스페이스에 매핑될 수 있습니다. 이전에는 소스 네임스페이스가 동일한 이름의 대상 네임스페이스에 매핑되었습니다.
  • 상태 정보가 있는 후크 단계는 마이그레이션 중에 웹 콘솔에 표시됩니다.
  • 직접 볼륨 마이그레이션 중에 Rsync 재시도 시도 횟수가 웹 콘솔에 표시됩니다.
  • 직접 볼륨 마이그레이션에 대해 영구 볼륨(PV) 크기 조정을 활성화하여 대상 클러스터에 디스크 공간이 부족하지 않도록 할 수 있습니다.
  • PV 크기 조정을 트리거하는 임계값을 구성할 수 있습니다. 이전에는 디스크 사용량이 97%를 초과하면 PV 크기 조정이 발생했습니다.
  • Velero가 버전 1.6으로 업데이트되어 다양한 수정 사항 및 개선 사항을 제공합니다.
  • 캐시된 Kubernetes 클라이언트를 활성화하여 성능을 향상시킬 수 있습니다.
2.4.1.2. 더 이상 사용되지 않는 기능

더 이상 사용되지 않는 기능은 다음과 같습니다.

  • MTC 버전 1.2 및 1.3은 더 이상 지원되지 않습니다.
  • oc convert 명령이 더 이상 사용되지 않으므로 사용되지 않는 API를 업데이트하는 절차는 설명서의 문제 해결 섹션에서 제거되었습니다.
2.4.1.3. 확인된 문제

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

  • 400개 이상의 마이그레이션 계획을 생성하는 경우 Microsoft Azure 스토리지를 사용할 수 없습니다. MigStorage 사용자 지정 리소스에는 The request is being throttled as the limit has been reached for operation type 메시지가 표시됩니다. (BZ#1977226)
  • 마이그레이션에 실패하면 마이그레이션 계획에서 quiesced Pod에 대한 사용자 정의 PV(영구 볼륨) 설정이 유지되지 않습니다. 마이그레이션을 수동으로 롤백하고 마이그레이션 계획을 삭제하고 PV 설정으로 새 마이그레이션 계획을 생성해야 합니다. (BZ#1784899)
  • pv_resizing_threshold가 42% 이상인 경우가 아니면 PV 크기 조정은 AWS gp2 스토리지에 대해 예상대로 작동하지 않습니다. (BZ#1973148)
  • 다음 시나리오의 OpenShift Container Platform 3.7 및 3.9 소스 클러스터에서 PV 크기 조정이 작동하지 않습니다.

    • MTC를 설치한 후 애플리케이션이 설치되었습니다.
    • MTC를 설치한 후 애플리케이션 pod가 다른 노드에 다시 예약되었습니다.

      OpenShift Container Platform 3.7 및 3.9는 Velero가 Restic Pod에 자동으로 PV를 마운트할 수 있도록 하는 Mount Propagation 기능을 지원하지 않습니다. MigAnalytic CR(사용자 정의 리소스)은 Restic Pod에서 PV 데이터를 수집하지 못하고 리소스를 0으로 보고합니다. MigPlan CR에는 다음과 유사한 상태가 표시됩니다.

      출력 예

      status:
        conditions:
        - category: Warn
          lastTransitionTime: 2021-07-15T04:11:44Z
          message: Failed gathering extended PV usage information for PVs [nginx-logs nginx-html], please see MigAnalytic openshift-migration/ocp-24706-basicvolmig-migplan-1626319591-szwd6 for details
          reason: FailedRunningDf
          status: "True"
          type: ExtendedPVAnalysisFailed

      PV 크기 조정을 활성화하려면 소스 클러스터에서 Restic 데몬 세트를 수동으로 다시 시작하거나 애플리케이션과 동일한 노드에서 Restic Pod를 다시 시작할 수 있습니다. Restic을 다시 시작하지 않으면 PV 크기 조정 없이 직접 볼륨 마이그레이션을 실행할 수 있습니다. (BZ#1982729)

2.4.1.4. 기술 변경 사항

이 릴리스에는 다음과 같은 기술 변경 사항이 있습니다.

  • 기존 Migration Toolkit for Containers Operator 버전 1.5.1은 OpenShift Container Platform 버전 3.7에서 4.5로 수동으로 설치됩니다.
  • Migration Toolkit for Containers Operator 버전 1.5.1은 Operator Lifecycle Manager를 사용하여 OpenShift Container Platform 버전 4.6 이상에 설치됩니다.

3장. MTC 설치

OpenShift Container Platform 4에 MTC(Migration Toolkit for Containers)를 설치할 수 있습니다.

참고

OpenShift Container Platform 3에 MTC를 설치하려면 OpenShift Container Platform 3에 레거시 Migration Toolkit for Containers Operator 설치를 참조하십시오.

기본적으로 MTC 웹 콘솔 및 Migration Controller Pod는 대상 클러스터에서 실행됩니다. 원격 클러스터에서 MTC 웹 콘솔 및 Migration Controller Pod를 실행하도록 Migration Controller 사용자 정의 리소스 매니페스트를 구성할 수 있습니다.

MTC를 설치한 후에는 복제 리포지토리로 사용할 오브젝트 스토리지를 구성해야 합니다.

MTC를 설치 제거하려면 MTC 설치 해제 및 리소스 삭제를 참조하십시오.

3.1. 호환성 지침

OpenShift Container Platform 버전과 호환되는 MTC(Migration Toolkit for Containers) Operator를 설치해야 합니다.

정의

기존 플랫폼
OpenShift Container Platform 4.5 및 이전 버전입니다.
최신 플랫폼
OpenShift Container Platform 4.6 이상 버전입니다.
기존 Operator
레거시 플랫폼을 위해 설계된 MTC Operator입니다.
최신 Operator
최신 플랫폼을 위해 설계된 MTC Operator입니다.
클러스터 제어
MTC 컨트롤러 및 GUI를 실행하는 클러스터입니다.
원격 클러스터
Velero를 실행하는 마이그레이션의 소스 또는 대상 클러스터입니다. Control Cluster는 Velero API를 통해 원격 클러스터와 통신하여 마이그레이션을 구동합니다.

OpenShift Container Platform 클러스터를 마이그레이션하는 데 호환되는 MTC 버전을 사용해야 합니다. 마이그레이션이 소스 클러스터와 대상 클러스터 모두에 성공하려면 동일한 버전의 MTC를 사용해야 합니다.

MTC 1.7은 OpenShift Container Platform 3.11에서 4.9로의 마이그레이션을 지원합니다.

MTC 1.8은 OpenShift Container Platform 4.10 이상에서만 마이그레이션을 지원합니다.

표 3.1. MTC 호환성: 레거시 또는 최신 플랫폼에서 마이그레이션
세부 정보OpenShift Container Platform 3.11OpenShift Container Platform 4.0에서 4.5로OpenShift Container Platform 4.6에서 4.9로OpenShift Container Platform 4.10 이상

안정적인 MTC 버전

MTC v.1.7.z

MTC v.1.7.z

MTC v.1.7.z

MTC v.1.8.z

설치

 

레거시 MTC v.1.7.z operator: operator.yml 파일을 사용하여 수동으로 설치합니다.

[critical] 이 클러스터는 제어 클러스터가 될 수 없습니다.

OLM과 함께 설치, 릴리스 채널 release-v1.7

OLM과 함께 설치, 릴리스 채널 release-v1.8

현대 클러스터가 마이그레이션에 관련된 다른 클러스터에 연결하지 못하도록 하는 Edge 사례가 있습니다. 예를 들어 온프레미스의 OpenShift Container Platform 3.11 클러스터에서 클라우드의 최신 OpenShift Container Platform 클러스터로 마이그레이션할 때 최신 클러스터가 OpenShift Container Platform 3.11 클러스터에 연결할 수 없습니다.

MTC v.1.7.z 를 사용하면 네트워크 제한으로 인해 원격 클러스터 중 하나가 컨트롤 클러스터와 통신할 수 없는 경우 crane tunnel-api 명령을 사용합니다.

안정적인 MTC 릴리스에서는 항상 최신 클러스터를 제어 클러스터로 지정해야 하지만 이 특정 경우 레거시 클러스터를 제어 클러스터로 지정하고 워크로드를 원격 클러스터로 푸시할 수 있습니다.

3.2. OpenShift Container Platform 4.2에서 4.5로 레거시 Migration Toolkit for Containers Operator 설치

OpenShift Container Platform 버전 4.2에서 4.5로 레거시 Migration Toolkit for Containers Operator를 수동으로 설치할 수 있습니다.

사전 요구 사항

  • 모든 클러스터에서 cluster-admin 권한이 있는 사용자로 로그인합니다.
  • registry.redhat.io에 대한 액세스 권한이 있어야 합니다.
  • podman이 설치되어 있어야 합니다.

프로세스

  1. Red Hat Customer Portal 자격 증명을 사용하여 registry.redhat.io에 로그인합니다.

    $ podman login registry.redhat.io
  2. 다음 명령을 입력하여 operator.yml 파일을 다운로드합니다.

    podman cp $(podman create registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator:v1.7):/operator.yml ./
  3. 다음 명령을 입력하여 controller.yml 파일을 다운로드합니다.

    podman cp $(podman create registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator:v1.7):/controller.yml ./
  4. OpenShift Container Platform 소스 클러스터에 로그인합니다.
  5. 클러스터가 registry.redhat.io로 인증할 수 있는지 확인합니다.

    $ oc run test --image registry.redhat.io/ubi9 --command sleep infinity
  6. Migration Toolkit for Containers Operator 오브젝트 생성:

    $ oc create -f operator.yml

    출력 예

    namespace/openshift-migration created
    rolebinding.rbac.authorization.k8s.io/system:deployers created
    serviceaccount/migration-operator created
    customresourcedefinition.apiextensions.k8s.io/migrationcontrollers.migration.openshift.io created
    role.rbac.authorization.k8s.io/migration-operator created
    rolebinding.rbac.authorization.k8s.io/migration-operator created
    clusterrolebinding.rbac.authorization.k8s.io/migration-operator created
    deployment.apps/migration-operator created
    Error from server (AlreadyExists): error when creating "./operator.yml":
    rolebindings.rbac.authorization.k8s.io "system:image-builders" already exists 1
    Error from server (AlreadyExists): error when creating "./operator.yml":
    rolebindings.rbac.authorization.k8s.io "system:image-pullers" already exists

    1
    Error from server (AlreadyExists) 메시지를 무시할 수 있습니다. 이는 Migration Toolkit for Containers Operator가 이후 릴리스에서 제공되는 OpenShift Container Platform 4 이전 버전에 대한 리소스를 생성하기 때문에 발생합니다.
  7. MigrationController 오브젝트를 만듭니다.

    $ oc create -f controller.yml
  8. MTC pod가 실행 중인지 확인합니다.

    $ oc get pods -n openshift-migration

3.3. OpenShift Container Platform 4.15에 Migration Toolkit for Containers Operator 설치

Operator Lifecycle Manager를 사용하여 OpenShift Container Platform 4.15에 Migration Toolkit for Containers Operator를 설치합니다.

사전 요구 사항

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

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 OperatorOperatorHub를 클릭합니다.
  2. 키워드로 필터링 필드를 사용하여 Migration Toolkit for Containers Operator를 찾습니다.
  3. Migration Toolkit for Containers Operator를 선택하고 설치를 클릭합니다.
  4. 설치를 클릭합니다.

    설치된 Operators 페이지에서 Migration Toolkit for Containers Operatoropenshift-migration 프로젝트에 Succeeded 상태로 나타납니다.

  5. Migration Toolkit for Containers Operator를 클릭합니다.
  6. 제공된 API 아래에서 마이그레이션 컨트롤러 타일을 찾고 인스턴스 작성을 클릭합니다.
  7. 생성을 클릭합니다.
  8. 워크로드Pod를 클릭하여 MTC pod가 실행 중인지 확인합니다.

3.4. 프록시 설정

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)는 클러스터 전체 프록시 설정을 상속합니다. 클러스터 전체 프록시 설정을 재정의하려면 프록시 매개변수를 변경할 수 있습니다.

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

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

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

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

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

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

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

3.4.1.3. 알려진 문제

마이그레이션 실패 오류 Upgrade request required

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

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

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

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

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

3.4.2.1. NetworkPolicy 구성
3.4.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
3.4.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
3.4.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
3.4.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]
3.4.2.4. Rsync Pod에 대한 추가 그룹 구성

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

표 3.2. Rsync Pod의 보조 그룹
Variable유형Default설명

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"

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

자세한 내용은 클러스터 전체 프록시 구성을 참조하십시오.

3.4.4. Rsync를 루트 또는 루트가 아닌 사용자로 실행

OpenShift Container Platform 환경에는 기본적으로 PodSecurityAdmission 컨트롤러가 활성화되어 있습니다. 이 컨트롤러를 사용하려면 클러스터 관리자가 네임스페이스 레이블을 통해 Pod 보안 표준을 적용해야 합니다. 클러스터의 모든 워크로드는 Privileged,Baseline 또는 Restricted 의 Pod 보안 표준 수준 중 하나를 실행해야 합니다. 모든 클러스터에는 자체 기본 정책 세트가 있습니다.

모든 환경에서 데이터 전송을 성공적으로 수행하기 위해 MTC(Migration Toolkit for Containers) 1.ECDHE에서는 기본적으로 Rsync Pod를 루트가 아닌 사용자로 실행하는 등 Rsync Pod에 변경 사항을 도입했습니다. 이렇게 하면 더 높은 권한이 필요하지 않은 워크로드에도 데이터 전송이 가능합니다. 이러한 변경은 가능한 한 가장 낮은 수준의 권한으로 워크로드를 실행하는 것이 가장 좋기 때문에 이루어졌습니다.

3.4.4.1. 데이터 전송을 위해 루트가 아닌 기본 작업을 수동으로 덮어쓰기

대부분의 경우 Rsync Pod를 루트가 아닌 사용자로 실행해도 소스 측에서 워크로드를 루트 사용자로 실행할 때 데이터 전송이 실패할 수 있습니다. MTC는 데이터 전송을 위해 루트가 아닌 기본 작업을 수동으로 재정의하는 두 가지 방법을 제공합니다.

  • 모든 마이그레이션에 대해 대상 클러스터에서 Rsync Pod를 루트로 실행하도록 모든 마이그레이션을 구성합니다.
  • 마이그레이션당 대상 클러스터에서 Rsync Pod를 루트로 실행합니다.

두 경우 모두 마이그레이션 전에 더 높은 권한으로 워크로드를 실행하는 네임스페이스의 소스 측에 다음 레이블을 설정해야 합니다(실행,감사, 경고).

Pod Security Admission and setting values for labels에 대한 자세한 내용은 Pod 보안 승인 동기화 제어를 참조하십시오.

3.4.4.2. 모든 마이그레이션에 대해 MigrationController CR을 루트 또는 루트가 아닌 사용자로 구성

기본적으로 Rsync는 루트가 아닌 상태로 실행됩니다.

대상 클러스터에서 Rsync를 루트로 실행하도록 MigrationController CR을 구성할 수 있습니다.

프로세스

  • 다음과 같이 MigrationController CR을 구성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigrationController
    metadata:
      name: migration-controller
      namespace: openshift-migration
    spec:
      [...]
      migration_rsync_privileged: true

    이 구성은 향후 모든 마이그레이션에 적용됩니다.

3.4.4.3. MigMigration CR을 마이그레이션당 루트 또는 루트가 아닌 사용자로 구성

대상 클러스터에서 다음과 같은 루트가 아닌 옵션을 사용하여 Rsync를 루트 또는 루트가 아닌 사용자로 실행하도록 MigMigration CR을 구성할 수 있습니다.

  • 특정 사용자 ID(UID)
  • 특정 그룹 ID(GID)

프로세스

  1. Rsync를 루트로 실행하려면 다음 예에 따라 MigMigration CR을 구성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      name: migration-controller
      namespace: openshift-migration
    spec:
      [...]
      runAsRoot: true
  2. Rsync를 특정 UID(User ID) 또는 특정 그룹 ID(GID)로 실행하려면 다음 예에 따라 MigMigration CR을 구성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      name: migration-controller
      namespace: openshift-migration
    spec:
      [...]
      runAsUser: 10010001
      runAsGroup: 3

3.5. 복제 리포지토리 구성

복제 리포지토리로 사용할 오브젝트 스토리지를 구성해야 합니다. MTC(Migration Toolkit for Containers)는 소스 클러스터에서 복제 리포지토리로 데이터를 복사한 다음 복제 리포지토리에서 대상 클러스터로 데이터를 복사합니다.

MTC는 소스 클러스터에서 대상 클러스터로 데이터를 마이그레이션하기 위한 파일 시스템 및 스냅샷 데이터 복사 방법을 지원합니다. 환경에 적합하며 스토리지 공급자가 지원하는 방법을 선택합니다.

MTC는 다음과 같은 스토리지 제공자를 지원합니다.

3.5.1. 사전 요구 사항

  • 모든 클러스터에는 복제 리포지토리에 대한 중단없는 네트워크 액세스 권한이 있어야 합니다.
  • 내부 호스팅 복제 리포지토리와 함께 프록시 서버를 사용하는 경우 프록시가 복제 리포지토리에 액세스할 수 있는지 확인해야 합니다.

3.5.2. 멀티 클라우드 오브젝트 게이트웨이 인증 정보 검색

MCG(Multicloud Object Gateway) 인증 정보 및 S3 끝점을 검색해야 합니다. MCG를 MTC(Migration Toolkit for Containers)의 복제 리포지토리로 구성해야 합니다.

MTC에 대한 Secret CR(사용자 정의 리소스)을 생성해야 하는 MCG(Multicloud Object Gateway) 인증 정보를 검색해야 합니다.

참고

MCG Operator는 더 이상 사용되지 않지만 OpenShift Data Foundation에서 MCG 플러그인을 계속 사용할 수 있습니다. 플러그인을 다운로드하려면 Red Hat OpenShift Data Foundation 을 다운로드하여 운영 체제에 적합한 MCG 플러그인을 다운로드합니다.

프로세스

  • NooBaa 사용자 정의 리소스에서 describe 명령을 실행하여 S3 엔드포인트 AWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEY 를 가져옵니다.

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

3.5.3. Amazon Web Services 구성

AWS(Amazon Web Services) S3 오브젝트 스토리지를 MTC(Migration Toolkit for Containers)의 복제 리포지토리로 구성합니다.

사전 요구 사항

  • AWS CLI가 설치되어 있어야 합니다.
  • 소스 및 대상 클러스터에서 AWS S3 스토리지 버킷에 액세스할 수 있어야 합니다.
  • 스냅샷 복사 방법을 사용하는 경우:

    • EC2 EBS(Elastic Block Storage)에 액세스할 수 있어야 합니다.
    • 소스 및 대상 클러스터는 동일한 지역에 있어야 합니다.
    • 소스 및 대상 클러스터는 동일한 스토리지 클래스를 보유해야 합니다.
    • 스토리지 클래스는 스냅샷과 호환 가능해야 합니다.

프로세스

  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-1LocationConstraint를 지원하지 않습니다. 리전이 us-east-1인 경우 --create-bucket-configuration LocationConstraint=$REGION을 생략합니다.
  4. IAM 사용자를 생성합니다.

    $ aws iam create-user --user-name velero 1
    1
    Velero를 사용하여 여러 S3 버킷이 있는 여러 클러스터를 백업하려면 각 클러스터에 대해 고유한 사용자 이름을 생성합니다.
  5. 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",
                    "s3:GetBucketLocation",
                    "s3:ListBucketMultipartUploads"
                ],
                "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_KEYAWS_ACCESS_KEY_ID를 기록합니다. 인증 정보를 사용하여 AWS를 복제 리포지토리로 추가합니다.

3.5.4. GCP(Google Cloud Platform) 구성

GCP(Google Cloud Platform) 스토리지 버킷을 MTC(Migration Toolkit for Containers)의 복제 리포지토리로 구성합니다.

사전 요구 사항

  • gcloudgsutil CLI 툴이 설치되어 있어야 합니다. 자세한 내용은 Google 클라우드 설명서를 참조하십시오.
  • 소스 및 대상 클러스터에서 GCP 스토리지 버킷에 액세스할 수 있어야 합니다.
  • 스냅샷 복사 방법을 사용하는 경우:

    • 소스 및 대상 클러스터는 동일한 지역에 있어야 합니다.
    • 소스 및 대상 클러스터는 동일한 스토리지 클래스를 보유해야 합니다.
    • 스토리지 클래스는 스냅샷과 호환 가능해야 합니다.

프로세스

  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. email 값과 일치하도록 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
        storage.objects.create
        storage.objects.delete
        storage.objects.get
        storage.objects.list
        iam.serviceAccounts.signBlob
    )
  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를 복제 리포지토리로 추가합니다.

3.5.5. Microsoft Azure 구성

Microsoft Azure Blob 스토리지 컨테이너를 MTC(Migration Toolkit for Containers)의 복제 리포지토리로 구성합니다.

사전 요구 사항

  • Azure CLI가 설치되어 있어야 합니다.
  • Azure Blob 스토리지 컨테이너는 소스 및 대상 클러스터에 액세스할 수 있어야 합니다.
  • 스냅샷 복사 방법을 사용하는 경우:

    • 소스 및 대상 클러스터는 동일한 지역에 있어야 합니다.
    • 소스 및 대상 클러스터는 동일한 스토리지 클래스를 보유해야 합니다.
    • 스토리지 클래스는 스냅샷과 호환 가능해야 합니다.

프로세스

  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_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를 복제 리포지토리로 추가합니다.

3.5.6. 추가 리소스

3.6. MTC 설치 제거 및 리소스 삭제

MTC(Migration Toolkit for Containers)를 설치 제거하고 해당 리소스를 삭제하여 클러스터를 정리할 수 있습니다.

참고

velero CRD를 삭제하면 클러스터에서 Velero가 제거됩니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 로그인해야 합니다.

프로세스

  1. 모든 클러스터에서 MigrationController CR(사용자 정의 리소스)을 삭제합니다.

    $ oc delete migrationcontroller <migration_controller>
  2. Operator Lifecycle Manager를 사용하여 OpenShift Container Platform 4에서 Migration Toolkit for Containers Operator를 설치 제거합니다.
  3. 다음 명령을 실행하여 모든 클러스터에서 클러스터 범위 리소스를 삭제합니다.

    • migration CRD(사용자 정의 리소스 정의):

      $ oc delete $(oc get crds -o name | grep 'migration.openshift.io')
    • Velero CRD:

      $ oc delete $(oc get crds -o name | grep 'velero')
    • migration 클러스터 역할:

      $ oc delete $(oc get clusterroles -o name | grep 'migration.openshift.io')
    • migration-operator 클러스터 역할:

      $ oc delete clusterrole migration-operator
    • Velero 클러스터 역할:

      $ oc delete $(oc get clusterroles -o name | grep 'velero')
    • migration 클러스터 역할 바인딩:

      $ oc delete $(oc get clusterrolebindings -o name | grep 'migration.openshift.io')
    • migration-operator 클러스터 역할 바인딩:

      $ oc delete clusterrolebindings migration-operator
    • Velero 클러스터 역할 바인딩:

      $ oc delete $(oc get clusterrolebindings -o name | grep 'velero')

4장. 제한된 네트워크 환경에서 MTC 설치

다음 절차를 수행하여 제한된 네트워크 환경에서 OpenShift Container Platform 4에 MTC(Migration Toolkit for Containers)를 설치할 수 있습니다.

  1. 미러링된 Operator 카탈로그 를 생성합니다.

    이 프로세스에서는 registry.redhat.io 이미지와 미러 레지스트리 이미지 간의 매핑을 포함하는 mapping.txt 파일을 생성합니다. OpenShift Container Platform 4.2에서 4.5 소스 클러스터에 기존 Migration Toolkit for Containers Operator를 설치하려면 mapping.txt 파일이 필요합니다.

  2. Operator Lifecycle Manager를 사용하여 OpenShift Container Platform 4.15 대상 클러스터에 Migration Toolkit for Containers Operator를 설치합니다.

    기본적으로 MTC 웹 콘솔 및 Migration Controller Pod는 대상 클러스터에서 실행됩니다. 원격 클러스터에서 MTC 웹 콘솔 및 Migration Controller Pod를 실행하도록 Migration Controller 사용자 정의 리소스 매니페스트를 구성할 수 있습니다.

  3. 소스 클러스터에 Migration Toolkit for Containers Operator를 설치합니다.

    • OpenShift Container Platform 4.6 이상: Operator Lifecycle Manager를 사용하여 Migration Toolkit for Containers Operator를 설치합니다.
    • OpenShift Container Platform 4.2 - 4.5: 명령줄 인터페이스에서 기존 컨테이너용 마이그레이션 툴킷을 설치합니다.
  4. 복제 리포지토리로 사용할 오브젝트 스토리지를 구성합니다.
참고

OpenShift Container Platform 3에 MTC를 설치하려면 OpenShift Container Platform 3에 레거시 Migration Toolkit for Containers Operator 설치를 참조하십시오.

MTC를 설치 제거하려면 MTC 설치 제거 및 리소스 삭제를 참조하십시오.

4.1. 호환성 지침

OpenShift Container Platform 버전과 호환되는 MTC(Migration Toolkit for Containers) Operator를 설치해야 합니다.

정의

기존 플랫폼
OpenShift Container Platform 4.5 및 이전 버전입니다.
최신 플랫폼
OpenShift Container Platform 4.6 이상 버전입니다.
기존 Operator
레거시 플랫폼을 위해 설계된 MTC Operator입니다.
최신 Operator
최신 플랫폼을 위해 설계된 MTC Operator입니다.
클러스터 제어
MTC 컨트롤러 및 GUI를 실행하는 클러스터입니다.
원격 클러스터
Velero를 실행하는 마이그레이션의 소스 또는 대상 클러스터입니다. Control Cluster는 Velero API를 통해 원격 클러스터와 통신하여 마이그레이션을 구동합니다.

OpenShift Container Platform 클러스터를 마이그레이션하는 데 호환되는 MTC 버전을 사용해야 합니다. 마이그레이션이 소스 클러스터와 대상 클러스터 모두에 성공하려면 동일한 버전의 MTC를 사용해야 합니다.

MTC 1.7은 OpenShift Container Platform 3.11에서 4.9로의 마이그레이션을 지원합니다.

MTC 1.8은 OpenShift Container Platform 4.10 이상에서만 마이그레이션을 지원합니다.

표 4.1. MTC 호환성: 레거시 또는 최신 플랫폼에서 마이그레이션
세부 정보OpenShift Container Platform 3.11OpenShift Container Platform 4.0에서 4.5로OpenShift Container Platform 4.6에서 4.9로OpenShift Container Platform 4.10 이상

안정적인 MTC 버전

MTC v.1.7.z

MTC v.1.7.z

MTC v.1.7.z

MTC v.1.8.z

설치

 

레거시 MTC v.1.7.z operator: operator.yml 파일을 사용하여 수동으로 설치합니다.

[critical] 이 클러스터는 제어 클러스터가 될 수 없습니다.

OLM과 함께 설치, 릴리스 채널 release-v1.7

OLM과 함께 설치, 릴리스 채널 release-v1.8

현대 클러스터가 마이그레이션에 관련된 다른 클러스터에 연결하지 못하도록 하는 Edge 사례가 있습니다. 예를 들어 온프레미스의 OpenShift Container Platform 3.11 클러스터에서 클라우드의 최신 OpenShift Container Platform 클러스터로 마이그레이션할 때 최신 클러스터가 OpenShift Container Platform 3.11 클러스터에 연결할 수 없습니다.

MTC v.1.7.z 를 사용하면 네트워크 제한으로 인해 원격 클러스터 중 하나가 컨트롤 클러스터와 통신할 수 없는 경우 crane tunnel-api 명령을 사용합니다.

안정적인 MTC 릴리스에서는 항상 최신 클러스터를 제어 클러스터로 지정해야 하지만 이 특정 경우 레거시 클러스터를 제어 클러스터로 지정하고 워크로드를 원격 클러스터로 푸시할 수 있습니다.

4.2. OpenShift Container Platform 4.15에 Migration Toolkit for Containers Operator 설치

Operator Lifecycle Manager를 사용하여 OpenShift Container Platform 4.15에 Migration Toolkit for Containers Operator를 설치합니다.

사전 요구 사항

  • 모든 클러스터에서 cluster-admin 권한이 있는 사용자로 로그인합니다.
  • 로컬 레지스트리의 미러 이미지에서 Operator 카탈로그를 생성해야 합니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 OperatorOperatorHub를 클릭합니다.
  2. 키워드로 필터링 필드를 사용하여 Migration Toolkit for Containers Operator를 찾습니다.
  3. Migration Toolkit for Containers Operator를 선택하고 설치를 클릭합니다.
  4. 설치를 클릭합니다.

    설치된 Operators 페이지에서 Migration Toolkit for Containers Operatoropenshift-migration 프로젝트에 Succeeded 상태로 나타납니다.

  5. Migration Toolkit for Containers Operator를 클릭합니다.
  6. 제공된 API 아래에서 마이그레이션 컨트롤러 타일을 찾고 인스턴스 작성을 클릭합니다.
  7. 생성을 클릭합니다.
  8. 워크로드Pod를 클릭하여 MTC pod가 실행 중인지 확인합니다.

4.3. OpenShift Container Platform 4.2에서 4.5로 레거시 Migration Toolkit for Containers Operator 설치

OpenShift Container Platform 버전 4.2에서 4.5로 레거시 Migration Toolkit for Containers Operator를 수동으로 설치할 수 있습니다.

사전 요구 사항

  • 모든 클러스터에서 cluster-admin 권한이 있는 사용자로 로그인합니다.
  • registry.redhat.io에 대한 액세스 권한이 있어야 합니다.
  • podman이 설치되어 있어야 합니다.
  • registry.redhat.io에서 파일을 다운로드하려면 네트워크 액세스 권한이 있는 Linux 워크스테이션이 있어야 합니다.
  • Operator 카탈로그의 미러 이미지를 생성해야 합니다.
  • OpenShift Container Platform 4.15의 미러링된 Operator 카탈로그에서 Migration Toolkit for Containers Operator를 설치해야 합니다.

프로세스

  1. Red Hat Customer Portal 자격 증명을 사용하여 registry.redhat.io에 로그인합니다.

    $ podman login registry.redhat.io
  2. 다음 명령을 입력하여 operator.yml 파일을 다운로드합니다.

    podman cp $(podman create registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator:v1.7):/operator.yml ./
  3. 다음 명령을 입력하여 controller.yml 파일을 다운로드합니다.

    podman cp $(podman create registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator:v1.7):/controller.yml ./
  4. 다음 명령을 실행하여 Operator 이미지 매핑을 가져옵니다.

    $ grep openshift-migration-legacy-rhel8-operator ./mapping.txt | grep rhmtc

    Operator 카탈로그를 미러링할 때 mapping.txt 파일이 생성되었습니다. 출력은 registry.redhat.io 이미지와 미러 레지스트리 이미지 간의 매핑을 보여줍니다.

    출력 예

    registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator@sha256:468a6126f73b1ee12085ca53a312d1f96ef5a2ca03442bcb63724af5e2614e8a=<registry.apps.example.com>/rhmtc/openshift-migration-legacy-rhel8-operator

  5. operator.yml 파일에서 ansibleoperator 컨테이너의 image 값과 REGISTRY 값을 업데이트합니다.

    containers:
      - name: ansible
        image: <registry.apps.example.com>/rhmtc/openshift-migration-legacy-rhel8-operator@sha256:<468a6126f73b1ee12085ca53a312d1f96ef5a2ca03442bcb63724af5e2614e8a> 1
    ...
      - name: operator
        image: <registry.apps.example.com>/rhmtc/openshift-migration-legacy-rhel8-operator@sha256:<468a6126f73b1ee12085ca53a312d1f96ef5a2ca03442bcb63724af5e2614e8a> 2
    ...
        env:
        - name: REGISTRY
          value: <registry.apps.example.com> 3
    1 2
    미러 레지스트리와 Operator 이미지의 sha256 값을 지정합니다.
    3
    미러 레지스트리를 지정합니다.
  6. OpenShift Container Platform 소스 클러스터에 로그인합니다.
  7. Migration Toolkit for Containers Operator 오브젝트 생성:

    $ oc create -f operator.yml

    출력 예

    namespace/openshift-migration created
    rolebinding.rbac.authorization.k8s.io/system:deployers created
    serviceaccount/migration-operator created
    customresourcedefinition.apiextensions.k8s.io/migrationcontrollers.migration.openshift.io created
    role.rbac.authorization.k8s.io/migration-operator created
    rolebinding.rbac.authorization.k8s.io/migration-operator created
    clusterrolebinding.rbac.authorization.k8s.io/migration-operator created
    deployment.apps/migration-operator created
    Error from server (AlreadyExists): error when creating "./operator.yml":
    rolebindings.rbac.authorization.k8s.io "system:image-builders" already exists 1
    Error from server (AlreadyExists): error when creating "./operator.yml":
    rolebindings.rbac.authorization.k8s.io "system:image-pullers" already exists

    1
    Error from server (AlreadyExists) 메시지를 무시할 수 있습니다. 이는 Migration Toolkit for Containers Operator가 이후 릴리스에서 제공되는 OpenShift Container Platform 4 이전 버전에 대한 리소스를 생성하기 때문에 발생합니다.
  8. MigrationController 오브젝트를 만듭니다.

    $ oc create -f controller.yml
  9. MTC pod가 실행 중인지 확인합니다.

    $ oc get pods -n openshift-migration

4.4. 프록시 설정

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)는 클러스터 전체 프록시 설정을 상속합니다. 클러스터 전체 프록시 설정을 재정의하려면 프록시 매개변수를 변경할 수 있습니다.

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

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

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

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

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

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

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

4.4.1.3. 알려진 문제

마이그레이션 실패 오류 Upgrade request required

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

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

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

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

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

4.4.2.1. NetworkPolicy 구성
4.4.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
4.4.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
4.4.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
4.4.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]
4.4.2.4. Rsync Pod에 대한 추가 그룹 구성

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

표 4.2. Rsync Pod의 보조 그룹
Variable유형Default설명

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"

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

자세한 내용은 클러스터 전체 프록시 구성을 참조하십시오.

4.5. Rsync를 루트 또는 루트가 아닌 사용자로 실행

중요

이 섹션은 웹 콘솔이 아닌 OpenShift API로 작업하는 경우에만 적용됩니다.

OpenShift 환경에는 기본적으로 PodSecurityAdmission 컨트롤러가 활성화되어 있습니다. 이 컨트롤러를 사용하려면 클러스터 관리자가 네임스페이스 레이블을 통해 Pod 보안 표준을 적용해야 합니다. 클러스터의 모든 워크로드는 Privileged,Baseline 또는 Restricted 의 Pod 보안 표준 수준 중 하나를 실행해야 합니다. 모든 클러스터에는 자체 기본 정책 세트가 있습니다.

모든 환경에서 데이터 전송을 성공적으로 수행하기 위해 MTC(Migration Toolkit for Containers) 1.ECDHE에서는 기본적으로 Rsync Pod를 루트가 아닌 사용자로 실행하는 등 Rsync Pod에 변경 사항을 도입했습니다. 이렇게 하면 더 높은 권한이 필요하지 않은 워크로드에도 데이터 전송이 가능합니다. 이러한 변경은 가능한 한 가장 낮은 수준의 권한으로 워크로드를 실행하는 것이 가장 좋기 때문에 이루어졌습니다.

데이터 전송을 위해 루트가 아닌 기본 작업을 수동으로 덮어쓰기

대부분의 경우 Rsync Pod를 루트가 아닌 사용자로 실행해도 소스 측에서 워크로드를 루트 사용자로 실행할 때 데이터 전송이 실패할 수 있습니다. MTC는 데이터 전송을 위해 루트가 아닌 기본 작업을 수동으로 재정의하는 두 가지 방법을 제공합니다.

  • 모든 마이그레이션에 대해 대상 클러스터에서 Rsync Pod를 루트로 실행하도록 모든 마이그레이션을 구성합니다.
  • 마이그레이션당 대상 클러스터에서 Rsync Pod를 루트로 실행합니다.

두 경우 모두 마이그레이션하기 전에 권한이 높은 워크로드를 실행하는 네임스페이스의 소스 측에 다음 레이블을 설정해야 합니다. 즉, ,enforce, audit, warn을 적용합니다

Pod Security Admission and setting values for labels에 대한 자세한 내용은 Pod 보안 승인 동기화 제어를 참조하십시오.

4.5.1. 모든 마이그레이션에 대해 MigrationController CR을 루트 또는 루트가 아닌 사용자로 구성

기본적으로 Rsync는 루트가 아닌 상태로 실행됩니다.

대상 클러스터에서 Rsync를 루트로 실행하도록 MigrationController CR을 구성할 수 있습니다.

프로세스

  • 다음과 같이 MigrationController CR을 구성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigrationController
    metadata:
      name: migration-controller
      namespace: openshift-migration
    spec:
      [...]
      migration_rsync_privileged: true

    이 구성은 향후 모든 마이그레이션에 적용됩니다.

4.5.2. MigMigration CR을 마이그레이션당 루트 또는 루트가 아닌 사용자로 구성

대상 클러스터에서 다음과 같은 루트가 아닌 옵션을 사용하여 Rsync를 루트 또는 루트가 아닌 사용자로 실행하도록 MigMigration CR을 구성할 수 있습니다.

  • 특정 사용자 ID(UID)
  • 특정 그룹 ID(GID)

프로세스

  1. Rsync를 루트로 실행하려면 다음 예에 따라 MigMigration CR을 구성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      name: migration-controller
      namespace: openshift-migration
    spec:
      [...]
      runAsRoot: true
  2. Rsync를 특정 UID(User ID) 또는 특정 그룹 ID(GID)로 실행하려면 다음 예에 따라 MigMigration CR을 구성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      name: migration-controller
      namespace: openshift-migration
    spec:
      [...]
      runAsUser: 10010001
      runAsGroup: 3

4.6. 복제 리포지토리 구성

Multicloud Object Gateway는 제한된 네트워크 환경에 지원되는 유일한 옵션입니다.

MTC는 소스 클러스터에서 대상 클러스터로 데이터를 마이그레이션하기 위한 파일 시스템 및 스냅샷 데이터 복사 방법을 지원합니다. 환경에 적합하고 스토리지 공급자가 지원하는 방법을 선택할 수 있습니다.

4.6.1. 사전 요구 사항

  • 모든 클러스터에는 복제 리포지토리에 대한 중단없는 네트워크 액세스 권한이 있어야 합니다.
  • 내부 호스팅 복제 리포지토리와 함께 프록시 서버를 사용하는 경우 프록시가 복제 리포지토리에 액세스할 수 있는지 확인해야 합니다.

4.6.2. 멀티 클라우드 오브젝트 게이트웨이 인증 정보 검색

참고

MCG Operator는 더 이상 사용되지 않지만 OpenShift Data Foundation에서 MCG 플러그인을 계속 사용할 수 있습니다. 플러그인을 다운로드하려면 Red Hat OpenShift Data Foundation 을 다운로드하여 운영 체제에 적합한 MCG 플러그인을 다운로드합니다.

4.6.3. 추가 리소스

4.7. MTC 설치 제거 및 리소스 삭제

MTC(Migration Toolkit for Containers)를 설치 제거하고 해당 리소스를 삭제하여 클러스터를 정리할 수 있습니다.

참고

velero CRD를 삭제하면 클러스터에서 Velero가 제거됩니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 로그인해야 합니다.

프로세스

  1. 모든 클러스터에서 MigrationController CR(사용자 정의 리소스)을 삭제합니다.

    $ oc delete migrationcontroller <migration_controller>
  2. Operator Lifecycle Manager를 사용하여 OpenShift Container Platform 4에서 Migration Toolkit for Containers Operator를 설치 제거합니다.
  3. 다음 명령을 실행하여 모든 클러스터에서 클러스터 범위 리소스를 삭제합니다.

    • migration CRD(사용자 정의 리소스 정의):

      $ oc delete $(oc get crds -o name | grep 'migration.openshift.io')
    • Velero CRD:

      $ oc delete $(oc get crds -o name | grep 'velero')
    • migration 클러스터 역할:

      $ oc delete $(oc get clusterroles -o name | grep 'migration.openshift.io')
    • migration-operator 클러스터 역할:

      $ oc delete clusterrole migration-operator
    • Velero 클러스터 역할:

      $ oc delete $(oc get clusterroles -o name | grep 'velero')
    • migration 클러스터 역할 바인딩:

      $ oc delete $(oc get clusterrolebindings -o name | grep 'migration.openshift.io')
    • migration-operator 클러스터 역할 바인딩:

      $ oc delete clusterrolebindings migration-operator
    • Velero 클러스터 역할 바인딩:

      $ oc delete $(oc get clusterrolebindings -o name | grep 'velero')

5장. Migration Toolkit for Containers 업그레이드

Operator Lifecycle Manager를 사용하여 OpenShift Container Platform 4.15에서 MTC(Migration Toolkit for Containers)를 업그레이드할 수 있습니다.

기존 Migration Toolkit for Containers Operator를 다시 설치하여 OpenShift Container Platform 4.5 및 이전 버전에서 MTC를 업그레이드할 수 있습니다.

중요

MTC 버전 1.3에서 업그레이드하는 경우 MigPlan 사용자 정의 리소스(CR)를 업데이트하려면 추가 절차를 수행해야 합니다.

5.1. OpenShift Container Platform 4.15에서 Migration Toolkit for Containers 업그레이드

Operator Lifecycle Manager를 사용하여 OpenShift Container Platform 4.15에서 MTC(Migration Toolkit for Containers)를 업그레이드할 수 있습니다.

중요

Operator Lifecycle Manager를 사용하여 MTC를 업그레이드할 때 지원되는 마이그레이션 경로를 사용해야 합니다.

마이그레이션 경로

  • OpenShift Container Platform 3에서 OpenShift Container Platform 4로 마이그레이션하려면 레거시 MTC Operator 및 MTC 1.7.x가 필요합니다.
  • MTC 1.7.x에서 MTC 1.8.x로 마이그레이션하는 것은 지원되지 않습니다.
  • MTC 1.7.x를 사용하여 OpenShift Container Platform 4.9 이하의 소스로 모든 항목을 마이그레이션해야 합니다.

    • MTC 1.7.x는 소스 및 대상 모두에서 사용해야 합니다.
  • MTC 1.8.x는 OpenShift Container Platform 4.10 이상에서 OpenShift Container Platform 4.10 이상으로의 마이그레이션만 지원합니다. 클러스터 버전 4.10 이상과 관련된 마이그레이션의 경우 1.7.x 또는 1.8.x 중 하나를 사용할 수 있습니다. 그러나 소스 및 대상 모두에서 동일한 MTC 버전이어야 합니다.

    • 소스 MTC 1.7.x에서 대상 MTC 1.8.x로의 마이그레이션은 지원되지 않습니다.
    • 소스 MTC 1.8.x에서 대상 MTC 1.7.x로의 마이그레이션은 지원되지 않습니다.
    • 소스 MTC 1.7.x에서 대상 MTC 1.7.x로의 마이그레이션이 지원됩니다.
    • 소스 MTC 1.8.x에서 대상 MTC 1.8.x로의 마이그레이션이 지원됩니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 로그인해야 합니다.

프로세스

  1. OpenShift Container Platform 콘솔에서 Operators > 설치된 Operators로 이동합니다.

    보류 중인 업그레이드가 있는 Operator에 업그레이드 사용 가능 상태가 표시됩니다.

  2. Migration Toolkit for Containers Operator를 클릭합니다.
  3. 서브스크립션 탭을 클릭합니다. 승인이 필요한 업그레이드는 업그레이드 상태 옆에 표시됩니다. 예를 들어 1 승인 필요가 표시될 수 있습니다.
  4. 1 승인 필요를 클릭한 다음 설치 계획 프리뷰를 클릭합니다.
  5. 업그레이드에 사용할 수 있는 리소스를 보고 승인을 클릭합니다.
  6. Operator → 설치된 Operator 페이지로 이동하여 업그레이드 진행 상황을 모니터링합니다. 완료되면 상태가 성공최신으로 변경됩니다.
  7. 워크로드Pod를 클릭하여 MTC pod가 실행 중인지 확인합니다.

5.2. Migration Toolkit for Containers를 1.8.0으로 업그레이드

Migration Toolkit for Containers를 1.8.0으로 업그레이드하려면 다음 단계를 완료합니다.

프로세스

  1. 다음 방법 중 하나를 사용하여 업그레이드할 서브스크립션 이름과 현재 채널을 결정합니다.

    • 다음 명령을 실행하여 서브스크립션 이름과 채널을 확인합니다.

      $ oc -n openshift-migration get sub

      출력 예

      NAME                                                                         PACKAGE                SOURCE                 CHANNEL
      mtc-operator                                                                 mtc-operator           mtc-operator-catalog   release-v1.7
      redhat-oadp-operator-stable-1.0-mtc-operator-catalog-openshift-marketplace   redhat-oadp-operator   mtc-operator-catalog   stable-1.0

    • 또는 다음 명령을 실행하여 JSON에서 서브스크립션 이름과 채널을 반환합니다.

      $ oc -n openshift-migration get sub -o json | jq -r '.items[] | { name: .metadata.name, package: .spec.name, channel: .spec.channel }'

      출력 예

      {
        "name": "mtc-operator",
        "package": "mtc-operator",
        "channel": "release-v1.7"
      }
      {
        "name": "redhat-oadp-operator-stable-1.0-mtc-operator-catalog-openshift-marketplace",
        "package": "redhat-oadp-operator",
        "channel": "stable-1.0"
      }

  2. 각 서브스크립션에 대해 다음 명령을 실행하여 MTC 1.7 채널에서 MTC 1.8 채널로 이동하는 패치입니다.

    $ oc -n openshift-migration patch subscription mtc-operator --type merge --patch '{"spec": {"channel": "release-v1.8"}}'

    출력 예

    subscription.operators.coreos.com/mtc-operator patched

5.2.1. OADP 1.0을 1.2 for Containers 1.8.0으로 업그레이드

OADP 1.0을 Migration Toolkit for Containers 1.8.0의 1.2로 업그레이드하려면 다음 단계를 완료하십시오.

프로세스

  • 각 서브스크립션에 대해 다음 명령을 실행하여 OADP 1.0에서 OADP 1.2로 OADP Operator를 패치합니다.

    $ oc -n openshift-migration patch subscription redhat-oadp-operator-stable-1.0-mtc-operator-catalog-openshift-marketplace --type merge --patch '{"spec": {"channel":"stable-1.2"}}'
    참고

    MTC 및 OADP 설치에 사용되는 사용자별 반환된 NAME 값을 나타내는 섹션입니다.

    출력 예

    subscription.operators.coreos.com/redhat-oadp-operator-stable-1.0-mtc-operator-catalog-openshift-marketplace patched

    참고

    반환된 값은 이 예제에서 사용되는 redhat-oadp-operator-stable-1.0-mtc-operator-catalog-openshift-marketplace 와 유사합니다.

    • installPlanApproval 매개변수가 Automatic으로 설정된 경우 OLM(Operator Lifecycle Manager)이 업그레이드 프로세스를 시작합니다.
    • installPlanApproval 매개변수가 Manual 로 설정된 경우 OLM에서 업그레이드를 시작하기 전에 각 installPlan 을 승인해야 합니다.

검증

  1. 다음 명령을 실행하여 OLM에서 OADP 및 MTC 업그레이드를 완료했는지 확인합니다.

    $ oc -n openshift-migration get subscriptions.operators.coreos.com mtc-operator -o json | jq '.status | (."state"=="AtLatestKnown")'
  2. 값이 true 이면 다음 명령을 실행하여 각 서브스크립션에 사용되는 채널을 확인합니다.

    $ oc -n openshift-migration get sub -o json | jq -r '.items[] | {name: .metadata.name, channel: .spec.channel }'

    출력 예

    {
      "name": "mtc-operator",
      "channel": "release-v1.8"
    }
    {
      "name": "redhat-oadp-operator-stable-1.0-mtc-operator-catalog-openshift-marketplace",
      "channel": "stable-1.2"
    }

    Confirm that the `mtc-operator.v1.8.0` and `oadp-operator.v1.2.x` packages are installed by running the following command:
    $ oc -n openshift-migration get csv

    출력 예

    NAME                     DISPLAY                                     VERSION   REPLACES                 PHASE
    mtc-operator.v1.8.0      Migration Toolkit for Containers Operator   1.8.0     mtc-operator.v1.7.13     Succeeded
    oadp-operator.v1.2.2     OADP Operator                               1.2.2     oadp-operator.v1.0.13    Succeeded

5.3. OpenShift Container Platform 버전 4.2에서 4.5로 Migration Toolkit for Containers 업그레이드

레거시 MTC(Migration Toolkit for Containers Operator)를 수동으로 설치하여 OpenShift Container Platform 버전 4.2에서 MTC(Migration Toolkit for Containers)를 업그레이드할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 로그인해야 합니다.
  • registry.redhat.io에 대한 액세스 권한이 있어야 합니다.
  • podman이 설치되어 있어야 합니다.

프로세스

  1. 다음 명령을 입력하여 Red Hat Customer Portal 자격 증명을 사용하여 registry.redhat.io에 로그인합니다.

    $ podman login registry.redhat.io
  2. 다음 명령을 입력하여 operator.yml 파일을 다운로드합니다.

    $ podman cp $(podman create \
      registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator:v1.8):/operator.yml ./
  3. 다음 명령을 입력하여 Migration Toolkit for Containers Operator를 교체합니다.

    $ oc replace --force -f operator.yml
  4. 다음 명령을 입력하여 migration-operator 배포를 0 으로 확장하여 배포를 중지합니다.

    $ oc scale -n openshift-migration --replicas=0 deployment/migration-operator
  5. migration-operator 배포를 1 로 확장하여 배포를 시작하고 다음 명령을 입력하여 변경 사항을 적용합니다.

    $ oc scale -n openshift-migration --replicas=1 deployment/migration-operator
  6. 다음 명령을 입력하여 migration-operator 가 업그레이드되었는지 확인합니다.

    $ oc -o yaml -n openshift-migration get deployment/migration-operator | grep image: | awk -F ":" '{ print $NF }'
  7. 다음 명령을 입력하여 controller.yml 파일을 다운로드합니다.

    $ podman cp $(podman create \
      registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator:v1.8):/controller.yml ./
  8. 다음 명령을 입력하여 migration-controller 오브젝트를 생성합니다.

    $ oc create -f controller.yml
  9. 다음 명령을 입력하여 MTC Pod가 실행 중인지 확인합니다.

    $ oc get pods -n openshift-migration

5.4. MTC 1.3을 1.8로 업그레이드

MTC(Migration Toolkit for Containers) 버전 1.3.x를 1.8로 업그레이드하는 경우 MigrationController Pod가 실행 중인 클러스터에서 MigPlan 사용자 정의 리소스(CR) 매니페스트를 업데이트해야 합니다.

indirectImageMigrationindirectVolumeMigration 매개변수는 MTC 1.3에 존재하지 않기 때문에 버전 1.4의 기본값은 false이며 직접 이미지 마이그레이션 및 직접 볼륨 마이그레이션이 활성화됩니다. 직접 마이그레이션 요구 사항이 충족되지 않기 때문에 이러한 매개변수 값이 true로 변경되지 않는 한 마이그레이션 계획에서 Ready 상태에 도달할 수 없습니다.

중요
  • OpenShift Container Platform 3에서 OpenShift Container Platform 4로 마이그레이션하려면 레거시 MTC Operator 및 MTC 1.7.x가 필요합니다.
  • MTC 1.7.x를 1.8.x로 업그레이드하려면 1.7.x에서 1.8.x로 업그레이드를 성공적으로 완료하려면 OADP 채널을 stable-1.0 에서 stable-1.2 로 수동으로 업데이트해야 합니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 로그인해야 합니다.

프로세스

  1. MigrationController Pod를 실행하는 클러스터에 로그인합니다.
  2. MigPlan CR 매니페스트를 가져옵니다.

    $ oc get migplan <migplan> -o yaml -n openshift-migration
  3. 다음 매개변수 값을 업데이트하고 파일을 migplan.yaml로 저장합니다.

    ...
    spec:
      indirectImageMigration: true
      indirectVolumeMigration: true
  4. MigPlan CR 매니페스트를 교체하여 변경 사항을 적용합니다.

    $ oc replace -f migplan.yaml -n openshift-migration
  5. 업데이트된 MigPlan CR 매니페스트를 가져와 변경 사항을 확인합니다.

    $ oc get migplan <migplan> -o yaml -n openshift-migration

6장. 마이그레이션 전 체크리스트

MTC(Migration Toolkit for Containers)를 사용하여 애플리케이션 워크로드를 마이그레이션하기 전에 다음 체크리스트를 검토하십시오.

6.1. 클러스터 상태 체크리스트

  • 클러스터는 특정 플랫폼 및 설치 방법(예: 베어 메탈 )에 대한 최소 하드웨어 요구 사항을 충족합니다.
  • 모든 MTC 사전 요구 사항이 충족됩니다.
  • ❏ 모든 노드에는 유효한 OpenShift Container Platform 서브스크립션이 있습니다.
  • 노드 상태를 확인했습니다.
  • ID 공급자가 작동 중입니다.
  • ❏ 마이그레이션 네트워크의 최소 처리량은 10Gbps입니다.
  • ❏ 클러스터에 마이그레이션에 필요한 충분한 리소스가 있습니다.

    참고

    일반 워크로드에서 마이그레이션을 실행하려면 클러스터에 추가 메모리, CPU 및 스토리지가 필요합니다. 실제 리소스 요구 사항은 단일 마이그레이션 계획에서 마이그레이션되는 Kubernetes 리소스 수에 따라 다릅니다. 리소스 요구 사항을 추정하려면 비 프로덕션 환경에서 마이그레이션을 테스트해야 합니다.

  • fio는 클러스터의 etcd 디스크 성능을 확인하는 데 사용되었습니다.

6.2. 소스 클러스터 체크리스트

  • ❏ 다음 명령을 실행하여 종료 중 상태에서 비정상적으로 설정된 PV(영구 볼륨)가 있는지 확인했습니다.

    $ oc get pv
  • ❏ 다음 명령을 실행하여 실행 중 또는 완료 이외의 상태인 Pod를 확인했습니다.

    $ oc get pods --all-namespaces | egrep -v 'Running | Completed'
  • ❏ 다음 명령을 실행하여 재시작 횟수가 높은 Pod를 확인했습니다.

    $ oc get pods --all-namespaces --field-selector=status.phase=Running \
      -o json | jq '.items[]|select(any( .status.containerStatuses[]; \
      .restartCount > 3))|.metadata.name'

    Pod가 실행 중 상태인 경우에도 재시작 횟수가 많으면 기본적인 문제가 될 수 있습니다.

  • ❏ 클러스터 인증서는 마이그레이션 프로세스 기간 동안 유효합니다.
  • ❏ 다음 명령을 실행하여 보류 중인 인증서 서명 요청이 있는지 확인했습니다.

    $ oc get csr -A | grep pending -i
  • 레지스트리는 권장 스토리지 유형을 사용합니다.
  • ❏ 레지스트리에 이미지를 읽고 쓸 수 있습니다.
  • etcd 클러스터는 정상입니다.
  • 소스 클러스터의 평균 API 서버 응답 시간은 50ms 미만입니다.

6.3. 대상 클러스터 체크리스트

  • ❏ 클러스터에 올바른 네트워크 구성과 외부 서비스(예: 데이터베이스, 소스 코드 저장소, 컨테이너 미러 레지스트리, CI/CD 툴)에 액세스할 수 있는 권한이 있습니다.
  • ❏ 클러스터에서 제공하는 서비스를 사용하는 외부 애플리케이션과 서비스에는 클러스터에 액세스할 수 있는 올바른 네트워크 구성 및 권한이 있습니다.
  • ❏ 내부 컨테이너 이미지에 필요한 종속성을 충족합니다.
  • ❏ 대상 클러스터와 복제 리포지토리에 충분한 스토리지 공간이 있습니다.

7장. 네트워크 고려 사항

마이그레이션 후 애플리케이션 네트워크 트래픽을 리디렉션하는 전략을 검토합니다.

7.1. DNS 고려 사항

대상 클러스터의 DNS 도메인은 소스 클러스터의 도메인과 다릅니다. 기본적으로 애플리케이션은 마이그레이션 후 대상 클러스터의 FQDN을 가져옵니다.

마이그레이션된 애플리케이션의 소스 DNS 도메인을 보존하려면 아래에 설명된 두 옵션 중 하나를 선택합니다.

7.1.1. 클라이언트에서 대상 클러스터의 DNS 도메인 격리

소스 클러스터의 DNS 도메인으로 전송된 클라이언트의 요청이 대상 클러스터를 클라이언트에 노출하지 않고 대상 클러스터의 DNS 도메인에 도달할 수 있도록 허용할 수 있습니다.

프로세스

  1. 클라이언트와 대상 클러스터 간에 애플리케이션 로드 밸런서 또는 역방향 프록시와 같은 기타 네트워크 구성 요소를 배치합니다.
  2. DNS 서버의 소스 클러스터에서 애플리케이션 FQDN을 업데이트하여 가상 네트워크 구성 요소의 IP 주소를 반환합니다.
  3. 소스 도메인의 애플리케이션에 대해 수신된 요청을 대상 클러스터 도메인의 로드 밸런서에 보내도록 네트워크 구성 요소를 구성합니다.
  4. 소스 클러스터의 로드 밸런서의 IP 주소를 가리키는 *.apps.source.example.com 도메인에 대한 와일드카드 DNS 레코드를 만듭니다.
  5. 대상 클러스터 앞의 브릿지 네트워크 구성 요소의 IP 주소를 가리키는 각 애플리케이션에 대한 DNS 레코드를 만듭니다. 특정 DNS 레코드는 와일드카드 레코드보다 우선 순위가 높으므로 애플리케이션 FQDN이 확인되면 충돌이 발생하지 않습니다.
참고
  • 기존의 네트워크 구성 요소는 모든 보안 TLS 연결을 종료해야 합니다. 연결이 대상 클러스터 로드 밸런서 장치로 전달되면 대상 애플리케이션의 FQDN이 클라이언트에 노출되고 인증서 오류가 발생합니다.
  • 애플리케이션은 대상 클러스터 도메인을 클라이언트에 참조하는 링크를 반환해서는 안 됩니다. 그렇지 않으면 애플리케이션 일부가 제대로 로드되거나 작동하지 않을 수 있습니다.

7.1.2. 소스 DNS 도메인을 허용하도록 대상 클러스터 설정

소스 클러스터의 DNS 도메인에서 마이그레이션된 애플리케이션에 대한 요청을 수락하도록 대상 클러스터를 설정할 수 있습니다.

프로세스

비보안 HTTP 액세스 및 보안 HTTPS 액세스 모두에서 다음 단계를 수행합니다.

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

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

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

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

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

보안 HTTPS 액세스를 위해 다음 추가 단계를 수행합니다.

  1. 설치 프로세스 중에 생성된 기본 Ingress 컨트롤러의 x509 인증서를 사용자 지정 인증서로 교체합니다.
  2. subjectAltName 필드에 소스 및 대상 클러스터의 와일드카드 DNS 도메인을 포함하도록 이 인증서를 구성합니다.

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

추가 리소스

7.2. 네트워크 트래픽 리디렉션 전략

마이그레이션에 성공한 후 소스 클러스터에서 대상 클러스터로 상태 비저장 애플리케이션의 네트워크 트래픽을 리디렉션해야 합니다.

네트워크 트래픽을 리디렉션하는 전략은 다음과 같은 가정을 기반으로 합니다.

  • 애플리케이션 pod는 소스 클러스터와 대상 클러스터에서 모두 실행됩니다.
  • 각 애플리케이션에는 소스 클러스터 호스트 이름이 포함된 경로가 있습니다.
  • 소스 클러스터 호스트 이름이 있는 경로에는 CA 인증서가 포함되어 있습니다.
  • HTTPS의 경우 대상 라우터 CA 인증서에는 소스 클러스터의 와일드카드 DNS 레코드에 대한 주체 대체 이름(Subject Alternative Name)이 포함되어 있습니다.

다음 전략을 고려하여 목표를 충족하는 전략을 선택합니다.

  • 모든 애플리케이션에 대한 모든 네트워크 트래픽을 동시에 리디렉션

    대상 클러스터의 가상 IP 주소(VIP)를 가리키도록 소스 클러스터의 와일드카드 DNS 레코드를 변경합니다.

    이 전략은 간단한 애플리케이션 또는 소규모 마이그레이션에 적합합니다.

  • 개별 애플리케이션에 대한 네트워크 트래픽 리디렉션

    대상 클러스터 라우터의 VIP를 가리키는 소스 클러스터 호스트 이름을 사용하여 각 애플리케이션의 DNS 레코드를 만듭니다. 이 DNS 레코드는 소스 클러스터 와일드카드 DNS 레코드보다 우선합니다.

  • 개별 애플리케이션에 대해 네트워크 트래픽 점진적 리디렉션

    1. 각 애플리케이션에 대해 소스 클러스터 라우터의 VIP와 대상 클러스터 라우터의 VIP로 트래픽을 보낼 수 있는 프록시를 만듭니다.
    2. 프록시를 가리키는 소스 클러스터 호스트 이름을 사용하여 각 애플리케이션에 대한 DNS 레코드를 만듭니다.
    3. 트래픽의 백분율을 대상 클러스터 라우터의 VIP로 라우팅하고 나머지 트래픽을 소스 클러스터 라우터의 VIP로 라우팅하도록 애플리케이션의 프록시 항목을 구성합니다.
    4. 모든 네트워크 트래픽이 리디렉션될 때까지 대상 클러스터 라우터의 VIP로 라우팅하는 트래픽의 백분율을 점차 늘립니다.
  • 개별 애플리케이션에 대한 사용자 기반 트래픽 리디렉션

    이 전략을 사용하면 사용자 요청의 TCP/IP 헤더를 필터링하여 사전 정의된 사용자 그룹의 네트워크 트래픽을 리디렉션할 수 있습니다. 이를 통해 전체 네트워크 트래픽을 리디렉션하기 전에 특정 사용자 수에 대한 리디렉션 프로세스를 테스트할 수 있습니다.

    1. 각 애플리케이션에 대해 소스 클러스터 라우터의 VIP와 대상 클러스터 라우터의 VIP로 트래픽을 보낼 수 있는 프록시를 만듭니다.
    2. 프록시를 가리키는 소스 클러스터 호스트 이름을 사용하여 각 애플리케이션에 대한 DNS 레코드를 만듭니다.
    3. test customers와 같이 지정된 헤더 패턴과 일치하는 트래픽을 대상 클러스터 라우터의 VIP로 라우팅하고 나머지 트래픽을 소스 클러스터 라우터의 VIP로 라우팅하도록 애플리케이션의 프록시 항목을 구성합니다.
    4. 모든 트래픽이 대상 클러스터 라우터의 VIP에 있을 때까지 트래픽을 단계별로 대상 클러스터 라우터의 VIP로 리디렉션합니다.

8장. 직접 마이그레이션 요구 사항

직접 마이그레이션은 MTC(Migration Toolkit for Containers) 1.4.0 이상에서 사용할 수 있습니다.

직접 마이그레이션에는 다음 두 부분이 있습니다.

  • 직접 볼륨 마이그레이션
  • 직접 이미지 마이그레이션

직접 마이그레이션을 사용하면 중간 복제 리포지토리(오브젝트 스토리지) 없이 소스 클러스터에서 대상 클러스터로 직접 영구 볼륨 및 내부 이미지를 마이그레이션할 수 있습니다.

8.1. 사전 요구 사항

  • 외부 트래픽을 위해 마이그레이션에 관련된 클러스터(소스 및 대상) 모두에 대한 내부 레지스트리를 노출합니다.
  • 원격 소스 및 대상 클러스터가 포트 443의 OpenShift Container Platform 경로를 사용하여 통신할 수 있는지 확인합니다.
  • 소스 및 대상 MTC 클러스터에서 노출된 레지스트리 경로를 구성합니다. spec.exposedRegistryPath 필드 또는 MTC UI에서 지정하여 이 작업을 수행합니다.

    참고
    • 대상 클러스터가 호스트 클러스터(마이그레이션 컨트롤러)와 동일한 경우 특정 MTC 클러스터에 대해 노출된 레지스트리 경로를 구성할 필요가 없습니다.
    • spec.exposedRegistryPath 는 직접 볼륨 마이그레이션이 아닌 직접 이미지 마이그레이션에만 필요합니다.
  • 직접 마이그레이션을 수행하려면 MigPlan CR(사용자 정의 리소스) indirectImageMigrationindirectVolumeMigration 의 두 사양 플래그가 false 로 설정되어 있는지 확인합니다. 이 플래그의 기본값은 false 입니다.

MTC의 직접 마이그레이션 기능은 Rsync 유틸리티를 사용합니다.

8.2. 직접 볼륨 마이그레이션을 위한 rsync 구성

MTC의 직접 볼륨 마이그레이션(DVM)은 두 PV 간의 직접 연결을 사용하여 소스와 대상 PV(영구 볼륨) 간에 파일을 동기화하는 Rsync를 사용합니다.

rsync는 파일과 디렉터리를 로컬 및 원격 대상으로 전송할 수 있는 명령줄 도구입니다.

DVM에서 사용하는 rsync 명령은 예상대로 작동하는 클러스터에 최적화되어 있습니다.

MigrationController CR은 다음 변수를 노출하여 직접 볼륨 마이그레이션에서 rsync_options 를 구성합니다.

Variable유형기본값설명

rsync_opt_bwlimit

int

설정되지 않음

양의 정수로 설정하면 --bwlimit=<int&gt; 옵션이 Rsync 명령에 추가됩니다.

rsync_opt_archive

bool

true

Rsync 명령에서 --archive 옵션을 설정합니다.

rsync_opt_partial

bool

true

Rsync 명령에 --partial 옵션을 설정합니다.

rsync_opt_delete

bool

true

Rsync 명령에 --delete 옵션을 설정합니다.

rsync_opt_hardlinks

bool

true

--hard-links 옵션을 설정하여 Rsync 명령입니다.

rsync_opt_info

string

COPY2

DEL2

REMOVE2

SKIP2

FLIST2

PROGRESS2

STATS2

Rsync Pod에서 자세한 로깅을 활성화합니다.

rsync_opt_extras

string

임의의 다른 옵션에 대해 예약되어 있습니다.

  • 위의 변수를 통해 설정된 옵션을 설정하는 것은 모든 마이그레이션에 대해 전역 적입니다. Operator가 MigrationController CR을 성공적으로 조정하면 향후 모든 마이그레이션에 구성이 적용됩니다. 진행 중인 마이그레이션은 현재 어떤 단계에 있는지에 따라 업데이트된 설정을 사용할 수 있습니다. 따라서 마이그레이션을 실행하기 전에 설정을 적용하는 것이 좋습니다. 사용자는 필요에 따라 항상 설정을 업데이트할 수 있습니다.
  • rsync_opt_extras 변수를 주의해서 사용합니다. 이 변수를 사용하여 전달되는 모든 옵션은 rsync 명령에 추가됩니다. 두 개 이상의 옵션을 지정할 때 공백을 추가해야 합니다. 옵션을 지정할 때 오류가 발생하면 마이그레이션에 실패할 수 있습니다. 그러나 향후 마이그레이션에 필요한 만큼 MigrationController CR을 업데이트할 수 있습니다.
  • rsync_opt_info 플래그를 사용자 정의하면 MTC의 진행 상황 보고 기능에 부정적인 영향을 미칠 수 있습니다. 그러나 진행률 보고를 제거하면 성능 이점이 있을 수 있습니다. 이 옵션은 Rsync 작업의 성능이 허용되지 않는 것으로 관찰되는 경우에만 사용해야 합니다.
참고

DVM에서 사용하는 기본 구성은 다양한 환경에서 테스트됩니다. 클러스터가 정상이고 제대로 작동하는 경우 대부분의 프로덕션 사용 사례에 허용됩니다. 기본 설정이 작동하지 않고 Rsync 작업이 실패하는 경우 이러한 구성 변수를 사용해야 합니다.

8.2.1. Rsync Pod의 리소스 제한 구성

MigrationController CR은 다음 변수를 노출하여 Rsync에 대한 리소스 사용 요구 사항 및 제한을 구성합니다.

Variable유형Default설명

source_rsync_pod_cpu_limits

string

1

소스 rsync Pod의 CPU 제한

source_rsync_pod_memory_limits

string

1Gi

소스 rsync Pod의 메모리 제한

source_rsync_pod_cpu_requests

string

400m

소스 rsync Pod의 cpu 요청

source_rsync_pod_memory_requests

string

1Gi

소스 rsync Pod의 메모리 요청

target_rsync_pod_cpu_limits

string

1

대상 rsync Pod의 cpu 제한

target_rsync_pod_cpu_requests

string

400m

대상 rsync Pod의 cpu 요청

target_rsync_pod_memory_limits

string

1Gi

대상 rsync Pod의 메모리 제한

target_rsync_pod_memory_requests

string

1Gi

대상 rsync Pod의 메모리 요청

8.2.1.1. Rsync Pod에 대한 추가 그룹 구성

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

Variable유형Default설명

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"
8.2.1.2. rsync 재시도 구성

MTC 1.4.3 이상에서는 실패한 Rsync 작업을 다시 시도할 수 있는 새로운 기능이 도입되었습니다.

기본적으로 마이그레이션 컨트롤러는 모든 데이터가 소스에서 대상 볼륨으로 전송되거나 지정된 재시도 횟수가 충족될 때까지 Rsync를 다시 시도합니다. 기본 재시도 제한은 20 으로 설정됩니다.

대규모 볼륨의 경우 재시도 횟수 제한이 충분하지 않을 수 있습니다.

MigrationController CR에서 다음 변수를 사용하여 재시도 제한을 늘릴 수 있습니다.

apiVersion: migration.openshift.io/v1alpha1
kind: MigrationController
metadata:
  name: migration-controller
  namespace: openshift-migration
spec:
  [...]
  rsync_backoff_limit: 40

이 예에서는 재시도 제한이 40 으로 증가했습니다.

8.2.1.3. Rsync를 루트 또는 루트가 아닌 사용자로 실행

OpenShift Container Platform 환경에는 기본적으로 PodSecurityAdmission 컨트롤러가 활성화되어 있습니다. 이 컨트롤러를 사용하려면 클러스터 관리자가 네임스페이스 레이블을 통해 Pod 보안 표준을 적용해야 합니다. 클러스터의 모든 워크로드는 Privileged,Baseline 또는 Restricted 의 Pod 보안 표준 수준 중 하나를 실행해야 합니다. 모든 클러스터에는 자체 기본 정책 세트가 있습니다.

모든 환경에서 데이터 전송을 성공적으로 수행하기 위해 MTC(Migration Toolkit for Containers) 1.ECDHE에서는 기본적으로 Rsync Pod를 루트가 아닌 사용자로 실행하는 등 Rsync Pod에 변경 사항을 도입했습니다. 이렇게 하면 더 높은 권한이 필요하지 않은 워크로드에도 데이터 전송이 가능합니다. 이러한 변경은 가능한 한 가장 낮은 수준의 권한으로 워크로드를 실행하는 것이 가장 좋기 때문에 이루어졌습니다.

8.2.1.3.1. 데이터 전송을 위해 루트가 아닌 기본 작업을 수동으로 덮어쓰기

대부분의 경우 Rsync Pod를 루트가 아닌 사용자로 실행해도 소스 측에서 워크로드를 루트 사용자로 실행할 때 데이터 전송이 실패할 수 있습니다. MTC는 데이터 전송을 위해 루트가 아닌 기본 작업을 수동으로 재정의하는 두 가지 방법을 제공합니다.

  • 모든 마이그레이션에 대해 대상 클러스터에서 Rsync Pod를 루트로 실행하도록 모든 마이그레이션을 구성합니다.
  • 마이그레이션당 대상 클러스터에서 Rsync Pod를 루트로 실행합니다.

두 경우 모두 마이그레이션 전에 더 높은 권한으로 워크로드를 실행하는 네임스페이스의 소스 측에 다음 레이블을 설정해야 합니다(실행,감사, 경고).

Pod Security Admission and setting values for labels에 대한 자세한 내용은 Pod 보안 승인 동기화 제어를 참조하십시오.

8.2.1.3.2. 모든 마이그레이션에 대해 MigrationController CR을 루트 또는 루트가 아닌 사용자로 구성

기본적으로 Rsync는 루트가 아닌 상태로 실행됩니다.

대상 클러스터에서 Rsync를 루트로 실행하도록 MigrationController CR을 구성할 수 있습니다.

프로세스

  • 다음과 같이 MigrationController CR을 구성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigrationController
    metadata:
      name: migration-controller
      namespace: openshift-migration
    spec:
      [...]
      migration_rsync_privileged: true

    이 구성은 향후 모든 마이그레이션에 적용됩니다.

8.2.1.3.3. MigMigration CR을 마이그레이션당 루트 또는 루트가 아닌 사용자로 구성

대상 클러스터에서 다음과 같은 루트가 아닌 옵션을 사용하여 Rsync를 루트 또는 루트가 아닌 사용자로 실행하도록 MigMigration CR을 구성할 수 있습니다.

  • 특정 사용자 ID(UID)
  • 특정 그룹 ID(GID)

프로세스

  1. Rsync를 루트로 실행하려면 다음 예에 따라 MigMigration CR을 구성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      name: migration-controller
      namespace: openshift-migration
    spec:
      [...]
      runAsRoot: true
  2. Rsync를 특정 UID(User ID) 또는 특정 그룹 ID(GID)로 실행하려면 다음 예에 따라 MigMigration CR을 구성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      name: migration-controller
      namespace: openshift-migration
    spec:
      [...]
      runAsUser: 10010001
      runAsGroup: 3

8.2.2. MigCluster 설정

MTC에서 생성된 모든 MigCluster 리소스에 대해 migration-cluster-config 라는 ConfigMap 은 MigCluster 리소스가 나타내는 클러스터의 Migration Operator 네임스페이스에 생성됩니다. 

migration-cluster-config 를 사용하면 MigCluster 특정 값을 구성할 수 있습니다. Migration Operator는 migration-cluster-config 를 관리합니다. 

MigrationController CR에 노출된 변수를 사용하여 ConfigMap 의 모든 값을 구성할 수 있습니다.

Variable유형필수 항목설명

migration_stage_image_fqin

string

없음

Pod 단계에 사용할 이미지(IndirectVolumeMigration에만 적용 가능)

migration_registry_image_fqin

string

없음

마이그레이션 레지스트리에 사용할 이미지

rsync_endpoint_type

string

없음

데이터 전송을 위한 끝점 유형(경로,ClusterIP,NodePort)

rsync_transfer_image_fqin

string

없음

Rsync Pod에 사용할 이미지( DirectVolumeMigration에만 적용 가능)

migration_rsync_privileged

bool

없음

Rsync Pod를 권한 있는 것으로 실행할지 여부

migration_rsync_super_privileged

bool

없음

Rsync Pod를 슈퍼 권한 있는 컨테이너로 실행할지 여부(spc_t SELinux 컨텍스트)

cluster_subdomain

string

없음

클러스터의 하위 도메인

migration_registry_readiness_timeout

int

없음

마이그레이션 레지스트리 배포를 위한 준비 시간 제한(초)

migration_registry_liveness_timeout

int

없음

마이그레이션 레지스트리 배포를 위한 활성 제한 시간(초)

exposed_registry_validation_path

string

없음

MigCluster에서 노출된 레지스트리의 유효성을 검사하는 하위 경로(예: /v2)

8.3. 직접 마이그레이션 알려진 문제

8.3.1. OpenShift Container Platform에서 실행되는 워크로드에 자동으로 spc_t 를 사용하여 Skip SELinux 재레이블 해결 방법 적용

MTC(Migration Toolkit for Containers)와 관련된 상당한 볼륨을 사용하여 네임스페이스를 마이그레이션하려고 할 때 rsync-server 는 문제를 해결하기 위한 추가 정보 없이 rsync-server가 고정될 수 있습니다.

8.3.1.1. Skip SELinux 재레이블 해결 방법 필요 진단

Unable to attach or mount volume for pod…​timed out error of Unable to attach or mount volume for the pod…​timed out waiting for the condition in the kubelet logs where the rsync-server for the Direct Volume Migration (DVM)이 실행되는 노드에서 kubelet 로그의 조건을 대기하거나 마운트할 수 없는 오류를 검색합니다.

kubelet 로그의 예

kubenswrapper[3879]: W0326 16:30:36.749224    3879 volume_linux.go:49] Setting volume ownership for /var/lib/kubelet/pods/8905d88e-6531-4d65-9c2a-eff11dc7eb29/volumes/kubernetes.io~csi/pvc-287d1988-3fd9-4517-a0c7-22539acd31e6/mount and fsGroup set. If the volume has a lot of files then setting volume ownership could be slow, see https://github.com/kubernetes/kubernetes/issues/69699

kubenswrapper[3879]: E0326 16:32:02.706363    3879 kubelet.go:1841] "Unable to attach or mount volumes for pod; skipping pod" err="unmounted volumes=[8db9d5b032dab17d4ea9495af12e085a], unattached volumes=[crane2-rsync-server-secret 8db9d5b032dab17d4ea9495af12e085a kube-api-access-dlbd2 crane2-stunnel-server-config crane2-stunnel-server-secret crane2-rsync-server-config]: timed out waiting for the condition" pod="caboodle-preprod/rsync-server"

kubenswrapper[3879]: E0326 16:32:02.706496    3879 pod_workers.go:965] "Error syncing pod, skipping" err="unmounted volumes=[8db9d5b032dab17d4ea9495af12e085a], unattached volumes=[crane2-rsync-server-secret 8db9d5b032dab17d4ea9495af12e085a kube-api-access-dlbd2 crane2-stunnel-server-config crane2-stunnel-server-secret crane2-rsync-server-config]: timed out waiting for the condition" pod="caboodle-preprod/rsync-server" podUID=8905d88e-6531-4d65-9c2a-eff11dc7eb29

8.3.1.2. Skip SELinux 재레이블 해결 방법을 사용하여 해결

이 문제를 해결하려면 MigrationController CR(사용자 정의 리소스)을 사용하여 source 및 destination MigClusters 에서 migration_rsync_super_privileged 매개변수를 true 로 설정합니다.

MigrationController CR의 예

apiVersion: migration.openshift.io/v1alpha1
kind: MigrationController
metadata:
  name: migration-controller
  namespace: openshift-migration
spec:
  migration_rsync_super_privileged: true 1
  azure_resource_group: ""
  cluster_name: host
  mig_namespace_limit: "10"
  mig_pod_limit: "100"
  mig_pv_limit: "100"
  migration_controller: true
  migration_log_reader: true
  migration_ui: true
  migration_velero: true
  olm_managed: true
  restic_timeout: 1h
  version: 1.8.3

1
migration_rsync_super_privileged 매개변수의 값은 Rsync Pod를 슈퍼 권한이 있는 컨테이너로 실행할지 여부를 나타냅니다(spc_t selinux 컨텍스트). 유효한 설정은 true 또는 false 입니다.

9장. 애플리케이션 마이그레이션

MTC(Migration Toolkit for Containers) 웹 콘솔 또는 명령줄 을 사용하여 애플리케이션을 마이그레이션할 수 있습니다.

대부분의 클러스터 범위 리소스는 아직 MTC에서 처리되지 않습니다. 애플리케이션에 클러스터 범위의 리소스가 필요한 경우 대상 클러스터에서 수동으로 리소스를 생성해야 할 수 있습니다.

스테이지 마이그레이션과 컷오버 마이그레이션을 사용하여 클러스터 간에 애플리케이션을 마이그레이션할 수 있습니다.

  • 스테이지 마이그레이션은 애플리케이션을 중지하지 않고 소스 클러스터에서 대상 클러스터로 데이터를 복사합니다. 스테이지 마이그레이션을 여러 번 실행하여 할당 마이그레이션 기간을 줄일 수 있습니다.
  • 컷오버 마이그레이션은 소스 클러스터에서 트랜잭션을 중지하고 리소스를 대상 클러스터로 이동합니다.

상태 마이그레이션을 사용하여 애플리케이션 상태를 마이그레이션할 수 있습니다.

  • 상태 마이그레이션은 선택한 PVC(영구 볼륨 클레임)를 복사합니다.
  • 상태 마이그레이션을 사용하여 동일한 클러스터 내에서 네임스페이스를 마이그레이션할 수 있습니다.

마이그레이션 중에 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를 복제할 위험이 있습니다.

9.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는 동일한 스토리지 클래스를 보유해야 합니다.

9.2. MTC 웹 콘솔을 사용하여 애플리케이션 마이그레이션

MTC 웹 콘솔을 사용하여 클러스터와 복제 리포지토리를 구성할 수 있습니다. 그러면 마이그레이션 계획을 생성하고 실행할 수 있습니다.

9.2.1. MTC 웹 콘솔 시작

브라우저에서 MTC(Migration Toolkit for Containers) 웹 콘솔을 시작할 수 있습니다.

사전 요구 사항

  • MTC 웹 콘솔에는 OpenShift Container Platform 웹 콘솔에 대한 네트워크 액세스 권한이 있어야 합니다.
  • MTC 웹 콘솔에는 OAuth 인증 서버에 대한 네트워크 액세스 권한이 있어야 합니다.

프로세스

  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 사용자 이름암호로 로그인합니다.

9.2.2. MTC 웹 콘솔에 클러스터 추가

MTC(Migration Toolkit for Containers) 웹 콘솔에 클러스터를 추가할 수 있습니다.

사전 요구 사항

  • 소스 클러스터에서 원본 간 리소스 공유를 구성해야 합니다.
  • Azure 스냅샷을 사용하여 데이터를 복사하는 경우:

    • 클러스터의 Azure 리소스 그룹 이름을 지정해야 합니다.
    • 클러스터는 동일한 Azure 리소스 그룹에 있어야 합니다.
    • 클러스터는 동일한 지역 위치에 있어야 합니다.
  • 직접 이미지 마이그레이션을 사용하는 경우 소스 클러스터의 이미지 레지스트리에 대한 경로를 노출해야 합니다.

프로세스

  1. 클러스터에 로그인합니다.
  2. migration-controller 서비스 계정 토큰을 확보합니다.

    $ oc create token migration-controller -n openshift-migration

    출력 예

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

  3. MTC 웹 콘솔에 로그인합니다.
  4. MTC 웹 콘솔에서 클러스터를 클릭합니다.
  5. 클러스터 추가를 클릭합니다.
  6. 다음 필드를 작성합니다.

    • 클러스터 이름: 클러스터 이름은 소문자(a-z)와 숫자(0-9)를 포함할 수 있습니다. 공백이나 국제 문자를 포함해서는 안 됩니다.
    • URL: API 서버 URL을 지정합니다(예: https://<www.example.com>:8443).
    • 서비스 계정 토큰: migration-controller 서비스 계정 토큰을 붙여넣습니다.
    • 이미지 레지스트리로 노출된 경로 호스트: 직접 이미지 마이그레이션을 사용하는 경우 소스 클러스터의 이미지 레지스트리에 노출된 경로를 지정합니다.

      다음 명령을 실행하여 라우트를 생성합니다.

      • OpenShift Container Platform 3의 경우:

        $ oc create route passthrough --service=docker-registry --port=5000 -n default
      • OpenShift Container Platform 4의 경우:

        $ oc create route passthrough --service=image-registry --port=5000 -n openshift-image-registry
    • Azure 클러스터: Azure 스냅샷을 사용하여 데이터를 복사하는 경우 이 옵션을 선택해야 합니다.

      • Azure 리소스 그룹:이 필드는 Azure 클러스터가 선택된 경우에 표시됩니다. Azure 리소스 그룹을 지정합니다.

        Microsoft Azure에서 OpenShift Container Platform 클러스터가 생성되면 클러스터와 연결된 모든 리소스를 포함하도록 Azure 리소스 그룹이 생성됩니다. Azure CLI에서는 다음 명령을 실행하여 모든 리소스 그룹을 표시할 수 있습니다.

        $ az group list

        OpenShift Container Platform 클러스터와 연결된 ResourceGroups 는 태그가 지정됩니다. 여기서 sample-rg-name 은 UI를 추출하고 제공하는 값입니다.

        {
          "id": "/subscriptions/...//resourceGroups/sample-rg-name",
          "location": "centralus",
          "name": "...",
          "properties": {
            "provisioningState": "Succeeded"
          },
          "tags": {
            "kubernetes.io_cluster.sample-ld57c": "owned",
            "openshift_creationDate": "2019-10-25T23:28:57.988208+00:00"
          },
          "type": "Microsoft.Resources/resourceGroups"
        },

        이 정보는 리소스 그룹 블레이드의 Azure 포털에서 도 사용할 수 있습니다.

    • SSL 확인 필요 : 선택 사항: 클러스터에 대한 SSL(Secure Socket Layer) 연결을 확인하려면 이 옵션을 선택합니다.
    • CA 번들 파일: SSL 확인 필요가 선택되어 있으면 이 필드가 표시됩니다. 자체 서명된 인증서에 대한 사용자 정의 CA 인증서 번들 파일을 생성한 경우 찾아보기를 클릭하고 CA 번들 파일을 선택하여 업로드합니다.
  7. 클러스터 추가를 클릭합니다.

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

9.2.3. MTC 웹 콘솔에 복제 리포지토리 추가

MTC(Migration Toolkit for Containers) 웹 콘솔에 복제 리포지토리로 오브젝트 스토리지를 추가할 수 있습니다.

MTC는 다음과 같은 스토리지 제공자를 지원합니다.

  • AWS(Amazon Web Services) S3
  • MCG(Multi-Cloud Object Gateway)
  • 일반 S3 오브젝트 스토리지(예: Minio 또는 Ceph S3)
  • GCP(Google Cloud Provider)
  • Microsoft Azure Blob

사전 요구 사항

  • 복제 리포지토리로 오브젝트 스토리지를 구성해야 합니다.

프로세스

  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>). 일반 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. 닫기를 클릭합니다.

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

9.2.4. MTC 웹 콘솔에서 마이그레이션 계획 생성

MTC(Migration Toolkit for Containers) 웹 콘솔에서 마이그레이션 계획을 생성할 수 있습니다.

사전 요구 사항

  • 모든 클러스터에서 cluster-admin 권한이 있는 사용자로 로그인합니다.
  • 동일한 MTC 버전이 모든 클러스터에 설치되어 있는지 확인해야 합니다.
  • MTC 웹 콘솔에 클러스터와 복제 리포지토리를 추가해야 합니다.
  • 이동 데이터 복사 방법을 사용하여 PV(영구 볼륨)를 마이그레이션하려면 소스 및 대상 클러스터에 원격 볼륨에 대한 중단되지 않은 네트워크 액세스가 있어야 합니다.
  • 직접 이미지 마이그레이션을 사용하려면 소스 클러스터의 이미지 레지스트리에 노출된 경로를 지정해야 합니다. MTC 웹 콘솔을 사용하거나 MigCluster 사용자 정의 리소스 매니페스트를 업데이트하여 수행할 수 있습니다.

프로세스

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

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

  4. 소스 클러스터, 대상 클러스터, 리포지토리를 선택합니다.
  5. 다음을 클릭합니다.
  6. 마이그레이션할 프로젝트를 선택합니다.
  7. 선택 사항: 프로젝트 옆에 있는 편집 아이콘을 클릭하여 대상 네임스페이스를 변경합니다.
  8. 다음을 클릭합니다.
  9. 각 PV의 마이그레이션 유형을 선택합니다.

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

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

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

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

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

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

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

  16. 다음을 클릭합니다.
  17. 선택 사항: 후크 추가를 클릭하여 마이그레이션 계획에 후크를 추가합니다.

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

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

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

    5. 소스 클러스터 또는 대상 클러스터를 선택합니다.
    6. 서비스 계정 이름서비스 계정 네임스페이스를 입력합니다.
    7. 후크의 마이그레이션 단계를 선택합니다.

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

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

영구 볼륨 복사 방법에 대한 추가 리소스

9.2.5. MTC 웹 콘솔에서 마이그레이션 계획 실행

MTC(Migration Toolkit for Containers) 웹 콘솔에서 생성한 마이그레이션 계획을 사용하여 애플리케이션 및 데이터를 마이그레이션할 수 있습니다.

참고

마이그레이션 프로세스 중에 MTC는 마이그레이션된 PV(영구 볼륨)의 회수 정책을 대상 클러스터에서 Retain으로 설정합니다.

Backup 사용자 정의 리소스에는 원래 회수 정책을 나타내는 PVOriginalReclaimPolicy 주석이 포함되어 있습니다. 마이그레이션된 PV의 회수 정책을 수동으로 복원할 수 있습니다.

사전 요구 사항

MTC 웹 콘솔에는 다음이 포함되어야 합니다.

  • Ready 상태의 소스 클러스터
  • Ready 상태의 대상 클러스터
  • 복제 리포지토리
  • 유효한 마이그레이션 계획

프로세스

  1. MTC 웹 콘솔에 로그인하고 마이그레이션 계획을 클릭합니다.
  2. kebab 마이그레이션 계획 옆에 있는 옵션 메뉴를 클릭하고 마이그레이션에서 다음 옵션 중 하나를 선택합니다.

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

      선택 사항: 컷오버 마이그레이션 대화 상자에서 마이그레이션 중 소스 클러스터에서 트랜잭션 중지 확인란의 선택을 취소할 수 있습니다.

    • 상태 복사는 선택한 PVC(영구 볼륨 클레임)를 복사합니다.

      중요

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

      • 상태 마이그레이션 대화 상자에서 하나 이상의 PVC를 선택하고 마이그레이션을 클릭합니다.
  3. 마이그레이션이 완료되면 OpenShift Container Platform 웹 콘솔에서 애플리케이션이 성공적으로 마이그레이션되었는지 확인합니다.

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

10장. 고급 마이그레이션 옵션

대규모 마이그레이션을 수행하고 성능을 개선하기 위해 마이그레이션을 자동화하고 MigPlanMigrationController 사용자 정의 리소스를 수정할 수 있습니다.

10.1. 용어

표 10.1. MTC 용어
용어정의

소스 클러스터

애플리케이션이 마이그레이션되는 클러스터입니다.

대상 클러스터[1]

애플리케이션이 마이그레이션될 대상 클러스터입니다.

복제 리포지토리

간접 마이그레이션 중 또는 직접 볼륨 마이그레이션 또는 직접 이미지 마이그레이션 중에 Kubernetes 오브젝트에 대한 이미지, 볼륨 및 Kubernetes 오브젝트 복사에 사용되는 오브젝트 스토리지입니다.

복제 리포지토리는 모든 클러스터에서 액세스할 수 있어야 합니다.

호스트 클러스터

migration-controller pod 및 웹 콘솔이 실행 중인 클러스터입니다. host 클러스터는 일반적으로 대상 클러스터이지만 필수는 아닙니다.

호스트 클러스터에 직접 이미지 마이그레이션을 위해 노출된 레지스트리 경로가 필요하지 않습니다.

원격 클러스터

원격 클러스터는 일반적으로 소스 클러스터이지만 필수는 아닙니다.

원격 클러스터에는 migration-controller 서비스 계정 토큰이 포함된 Secret 사용자 정의 리소스가 필요합니다.

원격 클러스터에는 직접 이미지 마이그레이션을 위해 노출된 보안 레지스트리 경로가 필요합니다.

간접 마이그레이션

이미지, 볼륨 및 Kubernetes 오브젝트는 소스 클러스터에서 복제 리포지토리로 복사한 다음 복제 리포지토리에서 대상 클러스터로 복사됩니다.

직접 볼륨 마이그레이션

영구 볼륨은 소스 클러스터에서 대상 클러스터로 직접 복사됩니다.

직접 이미지 마이그레이션

이미지가 소스 클러스터에서 대상 클러스터로 직접 복사됩니다.

마이그레이션 단계

애플리케이션을 중지하지 않고 데이터가 대상 클러스터에 복사됩니다.

단계적 마이그레이션을 여러 번 실행하면 컷오버 마이그레이션 기간이 단축됩니다.

컷오버 마이그레이션

소스 클러스터에서 애플리케이션이 중지되고 해당 리소스가 대상 클러스터로 마이그레이션됩니다.

상태 마이그레이션

애플리케이션 상태는 특정 영구 볼륨 클레임을 대상 클러스터에 복사하여 마이그레이션됩니다.

마이그레이션 롤백

마이그레이션 롤백은 완료된 마이그레이션을 롤백합니다.

1 MTC 웹 콘솔에서 대상 클러스터를 호출합니다.

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 정의에 추가 그룹을 추가하여 해당 스토리지에 대한 액세스를 구성할 수 있습니다.

표 10.2. Rsync Pod의 보조 그룹
Variable유형Default설명

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"
10.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

10.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 오브젝트 매니페스트를 생성합니다.

    $ 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 MigCluster <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:
        - <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

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에서 유지됩니다.
  • 애플리케이션의 매니페스트는 소스 및 대상 클러스터 모두에서 액세스할 수 있는 중앙 리포지토리에서 사용할 수 있습니다.

프로세스

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

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

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

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

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

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

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

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

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

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

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

추가 리소스

10.3. 마이그레이션 후크

마이그레이션의 다른 단계에서 각 후크가 실행되고 단일 마이그레이션 계획에 최대 4개의 마이그레이션 후크를 추가할 수 있습니다. 마이그레이션 후크는 애플리케이션 정지 사용자 정의, 지원되지 않는 데이터 유형을 수동으로 마이그레이션 및 마이그레이션 후 애플리케이션 업데이트와 같은 작업을 수행합니다.

마이그레이션 후크는 다음 마이그레이션 단계 중 하나에서 소스 또는 대상 클러스터에서 실행됩니다.

  • PreBackup: 소스 클러스터에서 리소스를 백업하기 전
  • PostBackup: 소스 클러스터에서 리소스를 백업한 후
  • PreRestore: 대상 클러스터에서 리소스가 복원되기 전
  • PostRestore: 대상 클러스터에서 리소스가 복원된 후

기본 Ansible 이미지 또는 사용자 정의 후크 컨테이너로 실행되는 Ansible 플레이북을 생성하여 후크를 생성할 수 있습니다.

Ansible 플레이북

Ansible 플레이북은 후크 컨테이너에 구성 맵으로 마운트됩니다. 후크 컨테이너는 MigPlan 사용자 정의 리소스에 지정된 클러스터, 서비스 계정 및 네임스페이스를 사용하여 작업으로 실행됩니다. 작업은 기본 6번의 재시도 한도에 도달하거나 성공적으로 완료될 때까지 계속 실행됩니다. 이는 초기 포드가 제거되거나 종료된 경우에도 계속됩니다.

기본 Ansible 런타임 이미지는 registry.redhat.io/rhmtc/openshift-migration-hook-runner-rhel7:1.8 입니다. 이 이미지는 Ansible Runner 이미지를 기반으로 하며 Ansible Kubernetes 리소스에 대해 python-openshift 및 업데이트된 oc바이너리를 포함합니다.

사용자 정의 후크 컨테이너

기본 Ansible 이미지 대신 사용자 정의 후크 컨테이너를 사용할 수 있습니다.

10.3.1. 마이그레이션 후크의 Ansible 플레이북 작성

마이그레이션 후크로 사용할 Ansible 플레이북을 작성할 수 있습니다. MTC 웹 콘솔을 사용하거나 MigPlan 사용자 정의 리소스(CR) 매니페스트에서 spec.hooks 매개변수의 값을 지정하여 후크가 마이그레이션 계획에 추가됩니다.

Ansible 플레이북은 후크 컨테이너에 구성 맵으로 마운트됩니다. 후크 컨테이너는 MigPlan CR에 지정된 클러스터, 서비스 계정 및 네임스페이스를 사용하여 작업으로 실행됩니다. 후크 컨테이너는 클러스터에서 실행되기 전에 작업에 인증이 필요하지 않도록 지정된 서비스 계정 토큰을 사용합니다.

10.3.1.1. Ansible 모듈

Ansible shell 모듈을 사용하여 oc 명령을 실행할 수 있습니다.

shell 모듈 예

- hosts: localhost
  gather_facts: false
  tasks:
  - name: get pod name
    shell: oc get po --all-namespaces

k8s_info와 같은 kubernetes.core 모듈을 사용하여 Kubernetes 리소스와 상호 작용할 수 있습니다.

k8s_facts 모듈 예

- hosts: localhost
  gather_facts: false
  tasks:
  - name: Get pod
    k8s_info:
      kind: pods
      api: v1
      namespace: openshift-migration
      name: "{{ lookup( 'env', 'HOSTNAME') }}"
    register: pods

  - name: Print pod name
    debug:
      msg: "{{ pods.resources[0].metadata.name }}"

fail 모듈을 사용하여 0이 아닌 종료 상태가 정상적으로 생성되지 않는 경우 후크의 성공 또는 실패 여부를 확인할 수 있습니다. 후크는 작업으로 실행되며 후크의 성공 또는 실패 상태는 작업 컨테이너의 종료 상태를 기반으로 합니다.

fail 모듈 예

- hosts: localhost
  gather_facts: false
  tasks:
  - name: Set a boolean
    set_fact:
      do_fail: true

  - name: "fail"
    fail:
      msg: "Cause a failure"
    when: do_fail

10.3.1.2. 환경 변수

MigPlan CR 이름과 마이그레이션 네임스페이스는 환경 변수로 후크 컨테이너에 전달됩니다. 이러한 변수는 lookup 플러그인을 사용하여 액세스할 수 있습니다.

환경 변수 예

- hosts: localhost
  gather_facts: false
  tasks:
  - set_fact:
      namespaces: "{{ (lookup( 'env', 'MIGRATION_NAMESPACES')).split(',') }}"

  - debug:
      msg: "{{ item }}"
    with_items: "{{ namespaces }}"

  - debug:
      msg: "{{ lookup( 'env', 'MIGRATION_PLAN_NAME') }}"

10.4. 마이그레이션 계획 옵션

MigPlan CR(사용자 정의 리소스)에서 구성 요소를 제외, 편집 및 매핑할 수 있습니다.

10.4.1. 리소스 제외

마이그레이션하기 위해 리소스 로드를 줄이거나 다른 도구를 사용하여 이미지 또는 PV를 마이그레이션하기 위해 MTC(Migration Toolkit for Containers) 마이그레이션 계획에서 리소스(예: 이미지 스트림, 영구 볼륨(PV) 또는 서브스크립션)를 제외할 수 있습니다.

기본적으로 MTC는 서비스 카탈로그 리소스 및 OLM(Operator Lifecycle Manager) 리소스를 마이그레이션에서 제외합니다. 이러한 리소스는 현재 마이그레이션에 지원되지 않는 서비스 카탈로그 API 그룹 및 OLM API 그룹의 일부입니다.

프로세스

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

    $ oc edit migrationcontroller <migration_controller> -n openshift-migration
  2. 특정 리소스를 제외하는 매개변수를 추가하여 spec 섹션을 업데이트합니다. 자체 제외 매개 변수가 없는 리소스의 경우 additional_excluded_resources 매개 변수를 추가합니다.

    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
      additional_excluded_resources: 3
      - resource1
      - resource2
      ...
    1
    마이그레이션에서 이미지 스트림을 제외하려면 disable_image_migration: true를 추가합니다. MigrationController Pod가 다시 시작되면 imagestreamsmain.ymlexcluded_resources 목록에 추가됩니다.
    2
    마이그레이션 계획에서 PV를 제외하려면 disable_pv_migration: true를 추가합니다. MigrationController Pod가 다시 시작되면 persistentvolumespersistentvolumeclaimsmain.ymlexcluded_resources 목록에 추가됩니다. PV 마이그레이션을 비활성화하면 마이그레이션 계획을 생성할 때 PV 검색도 비활성화됩니다.
    3
    additional_excluded_resources 목록에 제외하려는 OpenShift Container Platform 리소스를 추가할 수 있습니다.
  3. 변경 사항이 적용되도록 MigrationController 포드가 다시 시작될 때까지 2분 정도 기다립니다.
  4. 리소스가 제외되었는지 확인합니다.

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

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

    출력 예

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

10.4.2. 네임스페이스 매핑

MigPlan CR(사용자 정의 리소스)에서 네임스페이스를 매핑하는 경우 마이그레이션 중에 네임스페이스의 UID 및 GID 범위가 복사되므로 소스 또는 대상 클러스터에서 네임스페이스가 복제되지 않아야 합니다.

두 개의 소스 네임스페이스가 동일한 대상 네임스페이스에 매핑됨

spec:
  namespaces:
    - namespace_2
    - namespace_1:namespace_2

소스 네임스페이스를 동일한 이름의 네임스페이스에 매핑하려면 매핑을 생성할 필요가 없습니다. 기본적으로 소스 네임스페이스와 대상 네임스페이스의 이름은 동일합니다.

잘못된 네임 스페이스 매핑

spec:
  namespaces:
    - namespace_1:namespace_1

올바른 네임 스페이스 참조

spec:
  namespaces:
    - namespace_1

10.4.3. 영구 볼륨 클레임 제외

마이그레이션할 PVC를 제외하고 상태 마이그레이션에 대해 PVC(영구 볼륨 클레임)를 선택합니다. PV(영구 볼륨)가 검색된 후 MigPlan 사용자 정의 리소스(CR)의 spec.persistentVolumes.pvc.selection.action 매개변수를 설정하여 PVC를 제외할 수 있습니다.

사전 요구 사항

  • MigPlan CR이 Ready 상태입니다.

프로세스

  • spec.persistentVolumes.pvc.selection.action 매개변수를 MigPlan CR에 추가하고 skip으로 설정합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigPlan
    metadata:
      name: <migplan>
      namespace: openshift-migration
    spec:
    ...
      persistentVolumes:
      - capacity: 10Gi
        name: <pv_name>
        pvc:
    ...
        selection:
          action: skip

10.4.4. 영구 볼륨 클레임 매핑

PVC를 매핑하여 소스 클러스터에서 PV(영구 볼륨 클레임) 데이터를 MigPlan CR의 대상 클러스터에 이미 프로비저닝한 PVC(영구 볼륨 클레임)로 마이그레이션할 수 있습니다. 이 매핑을 사용하면 마이그레이션된 애플리케이션의 대상 PVC가 소스 PVC와 동기화됩니다.

PV가 검색된 후 MigPlan CR(사용자 정의 리소스)에서 spec.persistentVolumes.pvc.name 매개변수를 업데이트하여 PVC를 매핑합니다.

사전 요구 사항

  • MigPlan CR이 Ready 상태입니다.

프로세스

  • MigPlan CR에서 spec.persistentVolumes.pvc.name 매개변수를 업데이트합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigPlan
    metadata:
      name: <migplan>
      namespace: openshift-migration
    spec:
    ...
      persistentVolumes:
      - capacity: 10Gi
        name: <pv_name>
        pvc:
          name: <source_pvc>:<destination_pvc> 1
    1
    소스 클러스터에서 PVC와 대상 클러스터에서 PVC를 지정합니다. 대상 PVC가 없으면 생성됩니다. 이 매핑을 사용하여 마이그레이션 중에 PVC 이름을 변경할 수 있습니다.

10.4.5. 영구 볼륨 속성 편집

MigPlan CR(사용자 정의 리소스)을 생성한 후 MigrationController CR은 PV(영구 볼륨)를 검색합니다. spec.persistentVolumes 블록 및 status.destStorageClasses 블록이 MigPlan CR에 추가됩니다.

spec.persistentVolumes.selection 블록에서 값을 편집할 수 있습니다. spec.persistentVolumes.selection 블록 외부의 값을 변경하는 경우 MigPlan CR이 MigrationController CR에 의해 조정될 때 값을 덮어씁니다.

참고

spec.persistentVolumes.selection.storageClass 매개변수의 기본값은 다음 논리에 따라 결정됩니다.

  1. 소스 클러스터 PV가 Gluster 또는 NFS인 경우 기본값은 accessMode: ReadWriteMany 또는 cephrbd 의 경우 accessMode: ReadWriteOnce 의 경우 cephfs 입니다.
  2. PV가 Gluster와 NFS가 아니거나 cephfs 또는 cephrbd를 사용할 수 없는 경우 기본값은 동일한 프로비저너의 스토리지 클래스입니다.
  3. 동일한 프로비저너의 스토리지 클래스를 사용할 수 없는 경우 기본값은 대상 클러스터의 기본 스토리지 클래스입니다.

storageClass 값은 MigPlan CR의 status.destStorageClasses 블록에서 name 매개변수 값으로 변경할 수 있습니다.

storageClass 값이 비어 있으면 마이그레이션 후 PV에 스토리지 클래스가 없습니다. 예를 들어 대상 클러스터의 NFS 볼륨으로 PV를 이동하려는 경우 이 옵션이 적합합니다.

사전 요구 사항

  • MigPlan CR이 Ready 상태입니다.

프로세스

  • MigPlan CR에서 spec.persistentVolumes.selection 값을 편집합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigPlan
    metadata:
      name: <migplan>
      namespace: openshift-migration
    spec:
      persistentVolumes:
      - capacity: 10Gi
        name: pvc-095a6559-b27f-11eb-b27f-021bddcaf6e4
        proposedCapacity: 10Gi
        pvc:
          accessModes:
          - ReadWriteMany
          hasReference: true
          name: mysql
          namespace: mysql-persistent
        selection:
          action: <copy> 1
          copyMethod: <filesystem> 2
          verify: true 3
          storageClass: <gp2> 4
          accessMode: <ReadWriteMany> 5
        storageClass: cephfs
    1
    허용되는 값은 move,copy, skip 입니다. 하나의 작업만 지원되는 경우 기본값은 지원되는 작업입니다. 여러 작업이 지원되는 경우 기본값은 copy 입니다.
    2
    허용되는 값은 snapshotfilesystem입니다. 기본값은 filesystem 입니다.
    3
    MTC 웹 콘솔에서 파일 시스템 복사에 대한 확인 옵션을 선택하면 verify 매개변수가 표시됩니다. false 로 설정할 수 있습니다.
    4
    MigPlan CR의 status.destStorageClasses 블록에서 name 매개변수 값으로 기본값을 변경할 수 있습니다. 값을 지정하지 않으면 마이그레이션 후 PV에 스토리지 클래스가 없습니다.
    5
    허용되는 값은 ReadWriteOnceReadWriteMany 입니다. 이 값을 지정하지 않으면 기본값은 소스 클러스터 PVC의 액세스 모드입니다. MigPlan CR에서 액세스 모드만 편집할 수 있습니다. MTC 웹 콘솔을 사용하여 편집할 수 없습니다.

10.4.6. MTC 웹 콘솔에서 스토리지 클래스 변환

동일한 클러스터 내에서 마이그레이션하여 PV(영구 볼륨)의 스토리지 클래스를 변환할 수 있습니다. 이렇게 하려면 MTC(Migration Toolkit for Containers) 웹 콘솔에서 마이그레이션 계획을 생성하고 실행해야 합니다.

사전 요구 사항

  • MTC가 실행 중인 클러스터에 cluster-admin 권한이 있는 사용자로 로그인해야 합니다.
  • MTC 웹 콘솔에 클러스터를 추가해야 합니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔의 왼쪽 탐색 창에서 프로젝트를 클릭합니다.
  2. 프로젝트 목록에서 프로젝트를 클릭합니다.

    프로젝트 세부 정보 페이지가 열립니다.

  3. DeploymentConfig 이름을 클릭합니다. 실행 중인 pod의 이름을 기록해 둡니다.
  4. 프로젝트의 YAML 탭을 엽니다. PV를 찾고 해당 PVC(영구 볼륨 클레임)의 이름을 기록해 둡니다.
  5. MTC 웹 콘솔에서 마이그레이션 계획을 클릭합니다.
  6. 마이그레이션 계획 추가를 클릭합니다.
  7. 계획 이름을 입력합니다.

    마이그레이션 계획 이름에는 3~63자의 소문자 영숫자(a-z, 0-90-9)가 포함되어야 하며 공백이나 밑줄(_)을 포함해서는 안 됩니다.

  8. 마이그레이션 유형 메뉴에서 스토리지 클래스 변환을 선택합니다.
  9. 소스 클러스터 목록에서 스토리지 클래스 변환을 위해 원하는 클러스터를 선택합니다.
  10. 다음을 클릭합니다.

    네임스페이스 페이지가 열립니다.

  11. 필요한 프로젝트를 선택합니다.
  12. 다음을 클릭합니다.

    영구 볼륨 페이지가 열립니다. 페이지에 기본적으로 선택한 모든 PV가 프로젝트에 표시됩니다.

  13. 각 PV에 대해 원하는 대상 스토리지 클래스를 선택합니다.
  14. 다음을 클릭합니다.

    마법사는 새 마이그레이션 계획을 검증하고 준비 상태임을 표시합니다.

  15. 닫기를 클릭합니다.

    새 계획이 마이그레이션 계획 페이지에 나타납니다.

  16. 변환을 시작하려면 새 계획의 옵션 메뉴를 클릭합니다.

    마이그레이션에서 단계컷오버 의 두 가지 옵션이 표시됩니다.

    참고

    축소 마이그레이션은 애플리케이션의 PVC 참조를 업데이트합니다.

    단계 마이그레이션은 애플리케이션의 PVC 참조를 업데이트하지 않습니다.

  17. 원하는 옵션을 선택합니다.

    선택한 옵션에 따라 마이그레이션 단계 또는 컷오버 마이그레이션 알림이 표시됩니다.

  18. 마이그레이션을 클릭합니다.

    선택한 옵션에 따라 시작 단계 또는 컷오버 시작 메시지가 표시됩니다.

  19. 현재 마이그레이션의 상태를 보려면 마이그레이션 열에서 번호를 클릭합니다.

    마이그레이션 페이지가 열립니다.

  20. 현재 마이그레이션에 대한 자세한 내용과 진행 상황을 모니터링하려면 유형 열에서 마이그레이션을 선택합니다.

    마이그레이션 세부 정보 페이지가 열립니다. 마이그레이션이 DirectVolume 단계로 진행되고 단계 상태가Running Rsync Pods to migrate Persistent Volume data로 되는 경우 세부 정보 보기를 클릭하고 복사본의 자세한 상태를 확인할 수 있습니다.

  21. 이동 경로 표시줄에서 단계 또는 컷오버 를 클릭하고 모든 단계가 완료될 때까지 기다립니다.
  22. OpenShift Container Platform 웹 콘솔의 영구 볼륨 클레임 탭을 엽니다.

    초기 PVC의 이름으로 새 PVC를 볼 수 있지만 대상 스토리지 클래스를 사용하는 PVC는 new PVC로 끝납니다.

  23. 왼쪽 탐색 창에서 Pod 를 클릭합니다. 프로젝트의 Pod가 다시 실행 중인지 확인합니다.
추가 리소스

10.4.7. MTC API를 사용하여 Kubernetes 오브젝트의 상태 마이그레이션 수행

모든 PV 데이터를 마이그레이션한 후 MTC(Migration Toolkit for Containers) API를 사용하여 애플리케이션을 구성하는 Kubernetes 오브젝트의 일회성 상태 마이그레이션을 수행할 수 있습니다.

MigPlan 사용자 정의 리소스(CR) 필드를 구성하여 Kubernetes 리소스 목록을 추가 라벨 선택기와 함께 제공하여 이러한 리소스를 추가로 필터링한 다음 MigMigration CR을 생성하여 마이그레이션을 수행하여 수행합니다. MigPlan 리소스는 마이그레이션 후 종료됩니다.

참고

Kubernetes 리소스를 선택하는 것은 API 전용 기능입니다. MigPlan CR을 업데이트하고 CLI를 사용하여 MigMigration CR을 생성해야 합니다. MTC 웹 콘솔은 Kubernetes 오브젝트 마이그레이션을 지원하지 않습니다.

참고

마이그레이션 후 MigPlan CR의 closed 매개변수가 true로 설정됩니다. 이 MigPlan CR에 대해 다른 MigMigration CR을 생성할 수 없습니다.

다음 옵션 중 하나를 사용하여 MigPlan CR에 Kubernetes 오브젝트를 추가합니다.

  • Kubernetes 오브젝트를 includedResources 섹션에 추가합니다. MigPlan CR에 includedResources 필드가 지정되면 계획에서 group-kind 목록을 입력으로 사용합니다. 목록에 있는 리소스만 마이그레이션에 포함됩니다.
  • 선택적 labelSelector 매개변수를 추가하여 MigPlanincludedResources를 필터링합니다. 이 필드를 지정하면 라벨 선택기와 일치하는 리소스만 마이그레이션에 포함됩니다. 예를 들어 app: frontend 레이블을 필터로 사용하여 SecretConfigMap 리소스 목록을 필터링할 수 있습니다.

프로세스

  1. Kubernetes 리소스를 포함하도록 MigPlan CR을 업데이트하고, 선택적으로 labelSelector 매개변수를 추가하여 포함된 리소스를 필터링합니다.

    1. Kubernetes 리소스를 포함하도록 MigPlan CR을 업데이트하려면 다음을 수행합니다.

      apiVersion: migration.openshift.io/v1alpha1
      kind: MigPlan
      metadata:
        name: <migplan>
        namespace: openshift-migration
      spec:
        includedResources:
        - kind: <kind> 1
          group: ""
        - kind: <kind>
          group: ""
      1
      Kubernetes 오브젝트를 지정합니다 (예: Secret 또는 ConfigMap ).
    2. 선택 사항: labelSelector 매개변수를 추가하여 포함된 리소스를 필터링하려면 다음을 수행합니다.

      apiVersion: migration.openshift.io/v1alpha1
      kind: MigPlan
      metadata:
        name: <migplan>
        namespace: openshift-migration
      spec:
        includedResources:
        - kind: <kind> 1
          group: ""
        - kind: <kind>
          group: ""
      ...
        labelSelector:
          matchLabels:
            <label> 2
      1
      Kubernetes 오브젝트를 지정합니다 (예: Secret 또는 ConfigMap ).
      2
      마이그레이션할 리소스의 레이블을 지정합니다 (예: : app: frontend ).
  2. 선택한 Kubernetes 리소스를 마이그레이션하기 위해 MigMigration CR을 생성합니다. migPlanRef:에서 올바른 MigPlan 이 참조되었는지 확인합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      generateName: <migplan>
      namespace: openshift-migration
    spec:
      migPlanRef:
        name: <migplan>
        namespace: openshift-migration
      stage: false

10.5. 마이그레이션 컨트롤러 옵션

마이그레이션 계획 제한을 편집하거나, 대규모 마이그레이션 및 성능 향상을 위해 MigrationController CR(사용자 정의 리소스)에서 캐시된 Kubernetes 클라이언트를 활성화하고, 영구 볼륨 크기 조정을 활성화할 수 있습니다.

10.5.1. 대규모 마이그레이션에 대한 제한 증가

대규모 마이그레이션을 위해 MTC(Migration Toolkit for Containers)로 마이그레이션 오브젝트 및 컨테이너 리소스에 대한 마이그레이션 컨트롤러 제한을 늘릴 수 있습니다.

중요

프로덕션 환경에서 마이그레이션을 수행하기 전에 이러한 변경 사항을 테스트해야 합니다.

프로세스

  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 콘솔은 마이그레이션 계획을 저장할 때 경고 메시지를 표시합니다.

10.5.2. 직접 볼륨 마이그레이션의 영구 볼륨 크기 조정 활성화

대상 클러스터에서 디스크 공간이 부족하지 않도록 직접 볼륨 마이그레이션의 PV(영구 볼륨) 크기 조정을 활성화할 수 있습니다.

PV의 디스크 사용량이 구성된 수준에 도달하면 MigrationController CR(사용자 정의 리소스)은 PVC(영구 볼륨 클레임)의 요청된 스토리지 용량을 실제 프로비저닝된 용량과 비교합니다. 그런 다음 대상 클러스터에 필요한 공간을 계산합니다.

pv_resizing_threshold 매개 변수는 PV 크기 조정을 사용할 시기를 결정합니다. 기본 임계값은 3% 입니다. 즉 PV의 디스크 사용량이 97%를 초과하면 PV 크기가 조정됩니다. PV 크기 조정이 디스크 사용량이 낮은 수준에서 발생하도록 이 임계값을 늘릴 수 있습니다.

PVC 용량은 다음 기준에 따라 계산됩니다.

  • PVC의 요청된 스토리지 용량(spec.resources.requests.storage)이 실제 프로비저닝된 용량(status.capacity.storage)과 같지 않으면 더 큰 값이 사용됩니다.
  • PV가 PVC를 통해 프로비저닝되고 나중에 PV 및 PVC 용량이 더 이상 일치하지 않도록 변경된 경우 더 큰 값이 사용됩니다.

사전 요구 사항

  • MigrationController CR에서 명령을 실행할 수 있도록 PVC를 실행 중인 하나 이상의 pod에 연결해야 합니다.

프로세스

  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)

10.5.3. 캐시된 Kubernetes 클라이언트 활성화

마이그레이션 중에 성능이 향상되도록 MigrationController CR (사용자 정의 리소스)에서 캐시된 Kubernetes 클라이언트를 활성화할 수 있습니다. 서로 다른 지역에 있는 클러스터 간에 마이그레이션하거나 네트워크 지연 시간이 큰 경우 가장 큰 성능 이점이 표시됩니다.

참고

예를 들어 직접 볼륨 마이그레이션에 대한 Rsync 백업이나 Velero 백업 및 복원과 같은 위임된 작업에서는 캐시된 클라이언트의 성능이 향상되지 않습니다.

MigrationController CR에서 MigCluster CR과 상호 작용하는 데 필요한 모든 API 리소스를 캐시하므로 캐시된 클라이언트에는 추가 메모리가 필요합니다. 일반적으로 API 서버로 전송되는 요청은 대신 캐시로 이동합니다. 캐시는 업데이트를 위해 API 서버를 모니터링합니다.

캐시된 클라이언트를 활성화한 후 OOMKilled 오류가 발생하면 MigrationController CR의 메모리 제한과 요청을 늘릴 수 있습니다.

프로세스

  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>}]'

11장. 문제 해결

이 섹션에서는 MTC(Migration Toolkit for Containers) 문제 해결을 위한 리소스에 대해 설명합니다.

알려진 문제는 MTC 릴리스 노트 를 참조하십시오.

11.1. MTC 워크플로

MTC(Migration Toolkit for Containers) 웹 콘솔 또는 Kubernetes API를 사용하여 Kubernetes 리소스, 영구 볼륨 데이터 및 내부 컨테이너 이미지를 OpenShift Container Platform 4.15로 마이그레이션할 수 있습니다.

(MTC)는 다음 리소스를 마이그레이션합니다.

  • 마이그레이션 계획에 지정된 네임스페이스입니다.
  • 네임스페이스가 지정된 리소스: MTC가 네임스페이스를 마이그레이션하면 서비스 또는 포드와 같은 해당 네임스페이스와 연결된 모든 오브젝트와 리소스가 마이그레이션됩니다. 또한 네임스페이스에 존재하지만 클러스터 수준에 없는 리소스가 클러스터 수준에 존재하는 리소스에 따라 달라지는 경우 MTC가 두 개의 리소스 모두를 마이그레이션합니다.

    예를 들어 SCC(보안 컨텍스트 제약 조건)는 클러스터 수준에 존재하는 리소스이며, 서비스 계정(SA)은 네임스페이스 수준에 존재하는 리소스입니다. MTC가 마이그레이션하는 네임스페이스에 SA가 있는 경우 MTC는 SA에 연결된 모든 SCC를 자동으로 찾고 해당 SCC도 마이그레이션합니다. 마찬가지로 MTC는 네임스페이스의 영구 볼륨 클레임에 연결된 영구 볼륨을 마이그레이션합니다.

    참고

    리소스에 따라 클러스터 범위 리소스를 수동으로 마이그레이션해야 할 수 있습니다.

  • CR(사용자 정의 리소스) 및 CRD(사용자 정의 리소스 정의): MTC는 네임스페이스 수준에서 CR 및 CRD를 자동으로 마이그레이션합니다.

MTC 웹 콘솔을 사용하여 애플리케이션을 마이그레이션하는 데는 다음 단계가 포함됩니다.

  1. 모든 클러스터에 Migration Toolkit for Containers Operator를 설치합니다.

    인터넷 액세스가 제한되거나 없는 제한된 환경에서 Migration Toolkit for Containers Operator를 설치할 수 있습니다. 소스 및 대상 클러스터는 상호 액세스 권한 및 미러 레지스트리에 대한 네트워크 액세스 권한이 있어야 합니다.

  2. MTC가 데이터를 마이그레이션하는 데 사용하는 중간 오브젝트 스토리지인 복제 리포지토리를 구성합니다.

    소스 및 대상 클러스터는 마이그레이션 중에 복제 리포지토리에 대한 네트워크 액세스 권한이 있어야 합니다. 프록시 서버를 사용하는 경우 복제 리포지토리와 클러스터 간의 네트워크 트래픽을 허용하도록 해당 서버를 구성해야 합니다.

  3. MTC 웹 콘솔에 소스 클러스터를 추가합니다.
  4. MTC 웹 콘솔에 복제 리포지토리를 추가합니다.
  5. 다음 데이터 마이그레이션 옵션 중 하나를 사용하여 마이그레이션 계획을 생성합니다.

    • 복사: MTC는 소스 클러스터에서 복제 리포지토리로, 복제 리포지토리에서 대상 클러스터로 데이터를 복사합니다.

      참고

      직접 이미지 마이그레이션 또는 직접 볼륨 마이그레이션을 사용하는 경우 소스 클러스터에서 대상 클러스터로 이미지 또는 볼륨이 직접 복사됩니다.

      마이그레이션 PV 사본
    • 이동: MTC는 소스 클러스터에서 원격 볼륨(예: NFS)을 마운트 해제하고 원격 볼륨을 가리키는 대상 클러스터에 PV 리소스를 만든 다음 대상 클러스터에 원격 볼륨을 마운트합니다. 대상 클러스터에서 실행되는 애플리케이션은 소스 클러스터와 동일한 원격 볼륨을 사용합니다. 소스 및 대상 클러스터가 원격 볼륨에 액세스할 수 있어야 합니다.

      참고

      이 다이어그램에는 복제 리포지토리가 나타나지 않지만 마이그레이션에는 필수입니다.

      마이그레이션 PV 이동
  6. 다음 옵션 중 하나를 사용하여 마이그레이션 계획을 실행합니다.

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

      스테이지 마이그레이션을 마이그레이션 전에 대부분의 데이터가 대상에 복사되도록 여러 번 실행할 수 있습니다. 하나 이상의 단계적 마이그레이션을 실행하면 컷오버 마이그레이션 기간이 단축됩니다.

    • 컷오버 (Cutover)는 소스 클러스터에서 애플리케이션을 중지하고 리소스를 대상 클러스터로 이동합니다.

      선택 사항: 마이그레이션 중에 소스 클러스터에서 트랜잭션 중지 확인란의 선택을 취소할 수 있습니다.

OCP 3에서 4로의 애플리케이션 마이그레이션
MTC 사용자 정의 리소스 정보

MTC(Migration Toolkit for Containers)는 다음과 같은 사용자 정의 리소스(CR)를 생성합니다.

마이그레이션 아키텍처 다이어그램

20 MigCluster (구성, MTC 클러스터): 클러스터 정의

20 MigStorage (구성, MTC 클러스터): 스토리지 정의

20 MigPlan (구성, MTC 클러스터): 마이그레이션 계획

MigPlan CR은 마이그레이션 중인 소스 및 대상 클러스터, 복제 리포지토리 및 네임스페이스를 설명합니다. 0, 1 또는 많은 MigMigration CR과 연관됩니다.

참고

MigPlan CR을 삭제하면 연결된 MigMigration CR이 삭제됩니다.

20 BackupStorageLocation (구성, MTC 클러스터): Velero 백업 오브젝트의 위치

20 VolumeSnapshotLocation (구성, MTC 클러스터): Velero 볼륨 스냅샷의 위치

20 MigMigration (작업, MTC 클러스터): 데이터를 준비하거나 마이그레이션할 때마다 마이그레이션이 생성됩니다. 각 MigMigration CR은 MigPlan CR과 연결되어 있습니다.

20 백업 (작업, 소스 클러스터): 마이그레이션 계획을 실행할 때 MigMigration CR은 각 소스 클러스터에 두 개의 Velero 백업 CR을 생성합니다.

  • Kubernetes 오브젝트의 백업 CR #1
  • PV 데이터용 백업 CR #2

20 복원 (작업, 대상 클러스터): 마이그레이션 계획을 실행할 때 MigMigration CR은 대상 클러스터에 두 개의 Velero 복원 CR을 생성합니다.

  • PV 데이터에 대한 CR #1 복원(백업 CR #2 사용)
  • Kubernetes 오브젝트에 대한 CR #2 복원(백업 CR #1 사용)

11.2. MTC 사용자 정의 리소스 매니페스트

MTC(Migration Toolkit for Containers)는 다음 사용자 정의 리소스(CR) 매니페스트를 사용하여 애플리케이션을 마이그레이션합니다.

11.2.1. DirectImageMigration

DirectImageMigration CR은 소스 클러스터에서 대상 클러스터로 이미지를 직접 복사합니다.

apiVersion: migration.openshift.io/v1alpha1
kind: DirectImageMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <direct_image_migration>
spec:
  srcMigClusterRef:
    name: <source_cluster>
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster>
    namespace: openshift-migration
  namespaces: 1
    - <source_namespace_1>
    - <source_namespace_2>:<destination_namespace_3> 2
1
마이그레이션할 이미지를 포함하는 하나 이상의 네임스페이스입니다. 기본적으로 대상 네임스페이스의 이름은 소스 네임스페이스와 동일합니다.
2
다른 이름으로 대상 네임스페이스의 소스 네임스페이스에 매핑합니다.

11.2.2. DirectImageStreamMigration

DirectImageStreamMigration CR은 소스 클러스터에서 대상 클러스터로 직접 이미지 스트림 참조를 복사합니다.

apiVersion: migration.openshift.io/v1alpha1
kind: DirectImageStreamMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <direct_image_stream_migration>
spec:
  srcMigClusterRef:
    name: <source_cluster>
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster>
    namespace: openshift-migration
  imageStreamRef:
    name: <image_stream>
    namespace: <source_image_stream_namespace>
  destNamespace: <destination_image_stream_namespace>

11.2.3. DirectVolumeMigration

DirectVolumeMigration CR은 소스 클러스터에서 대상 클러스터로 직접 PV(영구 볼륨)를 복사합니다.

apiVersion: migration.openshift.io/v1alpha1
kind: DirectVolumeMigration
metadata:
  name: <direct_volume_migration>
  namespace: openshift-migration
spec:
  createDestinationNamespaces: false 1
  deleteProgressReportingCRs: false 2
  destMigClusterRef:
    name: <host_cluster> 3
    namespace: openshift-migration
  persistentVolumeClaims:
  - name: <pvc> 4
    namespace: <pvc_namespace>
  srcMigClusterRef:
    name: <source_cluster>
    namespace: openshift-migration
1
대상 클러스터의 PV에 네임스페이스를 만들려면 true로 설정합니다.
2
마이그레이션 후 DirectVolumeMigrationProgress CR을 삭제하려면 true로 설정합니다. 문제 해결을 위해 DirectVolumeMigrationProgress CR이 유지되기 위한 기본값은 false입니다.
3
대상 클러스터가 호스트 클러스터가 아닌 경우 클러스터 이름을 업데이트합니다.
4
마이그레이션할 하나 이상의 PVC를 지정합니다.

11.2.4. DirectVolumeMigrationProgress

DirectVolumeMigrationProgress CR은 DirectVolumeMigration CR의 진행 상황을 보여줍니다.

apiVersion: migration.openshift.io/v1alpha1
kind: DirectVolumeMigrationProgress
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <direct_volume_migration_progress>
spec:
  clusterRef:
    name: <source_cluster>
    namespace: openshift-migration
  podRef:
    name: <rsync_pod>
    namespace: openshift-migration

11.2.5. MigAnalytic

MigAnalytic CR은 이미지 수, Kubernetes 리소스 및 관련 MigPlan CR에서 영구 볼륨 (PV) 용량을 수집합니다.

수집하는 데이터를 구성할 수 있습니다.

apiVersion: migration.openshift.io/v1alpha1
kind: MigAnalytic
metadata:
  annotations:
    migplan: <migplan>
  name: <miganalytic>
  namespace: openshift-migration
  labels:
    migplan: <migplan>
spec:
  analyzeImageCount: true 1
  analyzeK8SResources: true 2
  analyzePVCapacity: true 3
  listImages: false 4
  listImagesLimit: 50 5
  migPlanRef:
    name: <migplan>
    namespace: openshift-migration
1
선택 사항: 이미지 수를 반환합니다.
2
선택 사항: Kubernetes 리소스의 수, 종류 및 API 버전을 반환합니다.
3
선택 사항: PV 용량을 반환합니다.
4
이미지 이름 목록을 반환합니다. 기본값은 false이므로 출력이 과도하게 길지 않습니다.
5
선택 사항: listImagestrue인 경우 최대 이미지 이름 수를 지정합니다.

11.2.6. MigCluster

MigCluster CR은 호스트, 로컬 또는 원격 클러스터를 정의합니다.

apiVersion: migration.openshift.io/v1alpha1
kind: MigCluster
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <host_cluster> 1
  namespace: openshift-migration
spec:
  isHostCluster: true 2
# The 'azureResourceGroup' parameter is relevant only for Microsoft Azure.
  azureResourceGroup: <azure_resource_group> 3
  caBundle: <ca_bundle_base64> 4
  insecure: false 5
  refresh: false 6
# The 'restartRestic' parameter is relevant for a source cluster.
  restartRestic: true 7
# The following parameters are relevant for a remote cluster.
  exposedRegistryPath: <registry_route> 8
  url: <destination_cluster_url> 9
  serviceAccountSecretRef:
    name: <source_secret> 10
    namespace: openshift-config
1
migration-controller pod가 이 클러스터에서 실행되지 않는 경우 클러스터 이름을 업데이트합니다.
2
migration-controller pod는 true인 경우 이 클러스터에서 실행됩니다.
3
Microsoft Azure만 해당: 리소스 그룹을 지정합니다.
4
선택 사항: 자체 서명된 CA 인증서에 대한 인증서 번들을 생성하고 insecure 매개변수 값이 false인 경우 base64 인코딩 인증서 번들을 지정합니다.
5
SSL 확인을 비활성화하려면 true로 설정합니다.
6
클러스터를 확인하려면 true로 설정합니다.
7
Stage pod가 생성된 후 소스 클러스터에서 Restic pod를 다시 시작하려면 true로 설정합니다.
8
원격 클러스터 및 직접 이미지 마이그레이션만 해당: 공용 보안 레지스트리 경로를 지정합니다.
9
원격 클러스터만 해당: URL을 지정합니다.
10
원격 클러스터만 해당: Secret 오브젝트의 이름을 지정합니다.

11.2.7. MigHook

MigHook CR은 마이그레이션의 지정된 단계에서 사용자 정의 코드를 실행하는 마이그레이션 후크를 정의합니다. 최대 4개의 마이그레이션 후크를 생성할 수 있습니다. 각 후크는 마이그레이션의 다른 단계에서 실행됩니다.

후크 이름, 런타임 기간, 사용자 정의 이미지 및 후크를 실행할 클러스터를 구성할 수 있습니다.

후크의 마이그레이션 단계 및 네임스페이스는 MigPlan CR에 구성됩니다.

apiVersion: migration.openshift.io/v1alpha1
kind: MigHook
metadata:
  generateName: <hook_name_prefix> 1
  name: <mighook> 2
  namespace: openshift-migration
spec:
  activeDeadlineSeconds: 1800 3
  custom: false 4
  image: <hook_image> 5
  playbook: <ansible_playbook_base64> 6
  targetCluster: source 7
1
선택 사항: 각 마이그레이션 후크마다 고유한 이름이 있도록 이 매개변수의 값에 고유한 해시가 추가됩니다. name 매개변수의 값을 지정할 필요가 없습니다.
2
generateName 매개변수 값을 지정하지 않으면 마이그레이션 후크 이름을 지정합니다.
3
선택 사항: 후크를 실행할 수 있는 최대 초를 지정합니다. 기본값은 1800입니다.
4
true인 경우 후크는 사용자 정의 이미지입니다. 사용자 지정 이미지는 Ansible을 포함하거나 다른 프로그래밍 언어로 작성할 수 있습니다.
5
사용자 지정 이미지를 지정합니다(예: quay.io/konveyor/hook-runner:latest). customtrue인 경우 필수 항목입니다.
6
base64로 인코딩된 Ansible 플레이북입니다. customfalse인 경우 필수 항목입니다.
7
후크를 실행할 클러스터를 지정합니다. 유효한 값은 source 또는 destination입니다.

11.2.8. MigMigration

MigMigration CR은 MigPlan CR을 실행합니다.

단계 또는 증분 마이그레이션을 실행하거나 진행 중인 마이그레이션을 취소하거나 완료된 마이그레이션을 롤백하도록 Migmigration CR을 구성할 수 있습니다.

apiVersion: migration.openshift.io/v1alpha1
kind: MigMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <migmigration>
  namespace: openshift-migration
spec:
  canceled: false 1
  rollback: false 2
  stage: false 3
  quiescePods: true 4
  keepAnnotations: true 5
  verify: false 6
  migPlanRef:
    name: <migplan>
    namespace: openshift-migration
1
진행 중인 마이그레이션을 취소하려면 true로 설정합니다.
2
완료된 마이그레이션을 롤백하려면 true로 설정합니다.
3
단계적 마이그레이션을 실행하려면 true로 설정합니다. 데이터가 증분적으로 복사되고 소스 클러스터의 pod가 중지되지 않습니다.
4
마이그레이션 중에 애플리케이션을 중지하려면 true로 설정합니다. backup 단계 후에 소스 클러스터의 pod는 0으로 조정됩니다.
5
마이그레이션 프로세스 중에 적용되는 레이블 및 주석을 유지하려면 true로 설정합니다.
6
대상 클러스터에서 마이그레이션된 pod의 상태를 확인하고 Running 상태가 아닌 pod의 이름을 반환하려면 true로 설정합니다.

11.2.9. MigPlan

MigPlan CR은 마이그레이션 계획의 매개변수를 정의합니다.

대상 네임스페이스, 후크 단계, 직접 또는 간접 마이그레이션을 구성할 수 있습니다.

참고

기본적으로 대상 네임스페이스의 이름은 소스 네임스페이스와 동일합니다. 다른 대상 네임스페이스를 구성하는 경우 마이그레이션 중에 UID 및 GID 범위가 복사되므로 소스 또는 대상 클러스터에서 네임스페이스가 복제되지 않도록 해야 합니다.

apiVersion: migration.openshift.io/v1alpha1
kind: MigPlan
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <migplan>
  namespace: openshift-migration
spec:
  closed: false 1
  srcMigClusterRef:
    name: <source_cluster>
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster>
    namespace: openshift-migration
  hooks: 2
    - executionNamespace: <namespace> 3
      phase: <migration_phase> 4
      reference:
        name: <hook> 5
        namespace: <hook_namespace> 6
      serviceAccount: <service_account> 7
  indirectImageMigration: true 8
  indirectVolumeMigration: false 9
  migStorageRef:
    name: <migstorage>
    namespace: openshift-migration
  namespaces:
    - <source_namespace_1> 10
    - <source_namespace_2>
    - <source_namespace_3>:<destination_namespace_4> 11
  refresh: false  12
1
true인 경우 마이그레이션이 완료되었습니다. 이 MigPlan CR에 대해 다른 MigMigration CR을 생성할 수 없습니다.
2
선택 사항: 최대 4개의 마이그레이션 후크를 지정할 수 있습니다. 각 후크는 다른 마이그레이션 단계에서 실행되어야 합니다.
3
선택 사항: 후크를 실행할 네임스페이스를 지정합니다.
4
선택 사항: 후크가 실행되는 마이그레이션 단계를 지정합니다. 하나의 후크를 하나의 단계에 할당할 수 있습니다. 유효한 값은 PreBackup, PostBackup, PreRestorePostRestore입니다.
5
선택 사항: MigHook CR의 이름을 지정합니다.
6
선택 사항: MigHook CR의 네임스페이스를 지정합니다.
7
선택 사항: cluster-admin 권한이 있는 서비스 계정을 지정합니다.
8
true인 경우 직접 이미지 마이그레이션이 비활성화됩니다. 이미지는 소스 클러스터에서 복제 리포지토리로, 복제 리포지토리에서 대상 클러스터로 복사됩니다.
9
true인 경우 직접 볼륨 마이그레이션이 비활성화됩니다. PV는 소스 클러스터에서 복제 리포지토리로, 복제 리포지토리에서 대상 클러스터로 복사됩니다.
10
하나 이상의 소스 네임스페이스를 지정합니다. 소스 네임스페이스만 지정하는 경우 대상 네임스페이스는 동일합니다.
11
대상 네임스페이스가 소스 네임스페이스와 다른 경우 지정합니다.
12
MigPlan CR이 true인 경우 검증됩니다.

11.2.10. MigStorage

MigStorage CR은 복제 리포지토리의 오브젝트 스토리지를 설명합니다.

Amazon Web Services(AWS), Microsoft Azure, Google Cloud Storage, Multi-Cloud Object Gateway 및 일반 S3 호환 클라우드 스토리지를 지원합니다.

AWS 및 스냅샷 복사 방법에는 추가 매개 변수가 있습니다.

apiVersion: migration.openshift.io/v1alpha1
kind: MigStorage
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <migstorage>
  namespace: openshift-migration
spec:
  backupStorageProvider: <backup_storage_provider> 1
  volumeSnapshotProvider: <snapshot_storage_provider> 2
  backupStorageConfig:
    awsBucketName: <bucket> 3
    awsRegion: <region> 4
    credsSecretRef:
      namespace: openshift-config
      name: <storage_secret> 5
    awsKmsKeyId: <key_id> 6
    awsPublicUrl: <public_url> 7
    awsSignatureVersion: <signature_version> 8
  volumeSnapshotConfig:
    awsRegion: <region> 9
    credsSecretRef:
      namespace: openshift-config
      name: <storage_secret> 10
  refresh: false 11
1
스토리지 공급자를 지정합니다.
2
스냅샷 복사 방법만: 스토리지 공급자를 지정합니다.
3
AWS만 해당: 버킷 이름을 지정합니다.
4
AWS만 해당: 버킷 리전을 지정합니다(예: us-east-1).
5
스토리지를 위해 생성한 Secret 오브젝트의 이름을 지정합니다.
6
AWS만 해당: AWS 키 관리 서비스를 사용하는 경우 키의 고유 식별자를 지정합니다.
7
AWS만 해당: AWS 버킷에 대한 공용 액세스 권한이 부여된 경우 버킷 URL을 지정합니다.
8
AWS만 해당: 버킷에 대한 요청을 인증하기 위해 AWS 서명 버전을 지정합니다(예: 4).
9
스냅샷 복사 방법만 해당: 클러스터의 지역 리전을 지정합니다.
10
스냅샷 복사 방법만 해당: 스토리지를 위해 생성한 Secret 오브젝트의 이름을 지정합니다.
11
클러스터를 확인하려면 true로 설정합니다.

11.3. 로그 및 디버깅 툴

이 섹션에서는 문제 해결에 사용할 수 있는 로그 및 디버깅 툴에 대해 설명합니다.

11.3.1. 마이그레이션 계획 리소스 보기

MTC 웹 콘솔 및 CLI(명령줄 인터페이스)를 사용하여 마이그레이션 계획 리소스를 확인하여 실행 중인 마이그레이션을 모니터링하거나 실패한 마이그레이션 문제를 해결할 수 있습니다.

프로세스

  1. MTC 웹 콘솔에서 마이그레이션 계획을 클릭합니다.
  2. 마이그레이션 계획 옆에 있는 마이그레이션 번호를 클릭하면 마이그레이션 페이지가 표시됩니다.
  3. 마이그레이션을 클릭하여 마이그레이션 세부 정보를 확인합니다.
  4. 마이그레이션 리소스를 확장하여 목록 보기에서 마이그레이션 리소스 및 해당 상태를 봅니다.

    참고

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

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

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

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

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

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

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

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

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

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

11.3.2. 마이그레이션 계획 로그 보기

마이그레이션 계획에 대한 집계된 로그를 볼 수 있습니다. MTC 웹 콘솔을 사용하여 클립보드에 명령을 복사한 다음 CLI(명령줄 인터페이스)에서 명령을 실행합니다.

명령은 다음 pod의 필터링된 로그를 표시합니다.

  • Migration Controller
  • Velero
  • Restic
  • Rsync
  • Stunnel
  • Registry

프로세스

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

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

11.3.3. 마이그레이션 로그 리더 사용

마이그레이션 로그 리더를 사용하여 모든 마이그레이션 로그에 대한 필터링된 보기를 표시할 수 있습니다.

프로세스

  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 옵션은 색상 없이 로그를 표시합니다.

11.3.4. 성능 지표 액세스

MigrationController CR(사용자 정의 리소스)은 지표를 기록하고 클러스터 내부 모니터링 스토리지로 가져옵니다. PromQL(Prometheus Query Language)을 사용하여 마이그레이션 성능 문제를 진단하여 지표를 쿼리할 수 있습니다. Migration Controller Pod가 다시 시작되면 모든 메트릭이 재설정됩니다.

OpenShift Container Platform 웹 콘솔을 사용하여 성능 지표에 액세스하고 쿼리를 실행할 수 있습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 모니터링메트릭을 클릭합니다.
  2. PromQL 쿼리를 입력하고 표시할 시간 창을 선택한 다음 Run Queries(쿼리 실행 )를 클릭합니다.

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

11.3.4.1. 제공된 지표

MigrationController CR(사용자 정의 리소스)은 MigMigration CR 수 및 해당 API 요청에 대한 지표를 제공합니다.

11.3.4.1.1. cam_app_workload_migrations

이 메트릭은 시간 경과에 따른 MigMigration CR 수입니다. 마이그레이션 상태 변경과 함께 API 요청 정보를 수집하기 위해 mtc_client_request_countmtc_client_request_elapsed 지표를 확인하는 데 유용합니다. 이 지표는 Telemetry에 포함되어 있습니다.

표 11.1. cam_app_workload_migrations metric
쿼리 가능한 라벨 이름라벨 값 샘플레이블 설명

status

running, idle, failed, completed

MigMigration CR의 상태

type

단계, 최종

MigMigration CR의 유형

11.3.4.1.2. mtc_client_request_count

이 지표는 MigrationController 가 실행한 Kubernetes API 요청의 누적 수입니다. Telemetry에는 포함되어 있지 않습니다.

표 11.2. mtc_client_request_count 메트릭
쿼리 가능한 라벨 이름라벨 값 샘플레이블 설명

cluster

https://migcluster-url:443

요청이 발행된 클러스터

component

MigPlan, MigCluster

요청을 발급한 하위 컨트롤러 API

function

(*ReconcileMigPlan).Reconcile

요청이 발행된 기능

kind

SecretList, Deployment

요청이 발행된 Kubernetes 종류

11.3.4.1.3. mtc_client_request_elapsed

이 지표는 MigrationController가 발행한 Kubernetes API 요청의 누적 대기 시간(밀리초)입니다. Telemetry에는 포함되어 있지 않습니다.

표 11.3. mtc_client_request_elapsed 메트릭
쿼리 가능한 라벨 이름라벨 값 샘플레이블 설명

cluster

https://cluster-url.com:443

요청이 발행된 클러스터

component

migplan, migcluster

요청을 발급한 하위 컨트롤러 API

function

(*ReconcileMigPlan).Reconcile

요청이 발행된 기능

kind

SecretList, Deployment

요청이 발행된 Kubernetes 리소스

11.3.4.1.4. 유용한 쿼리

테이블에는 성능 모니터링에 사용할 수 있는 몇 가지 유용한 쿼리가 나열되어 있습니다.

표 11.4. 유용한 쿼리
쿼리설명

mtc_client_request_count

발급된 API 요청 수, 요청 유형별로 정렬

sum(mtc_client_request_count)

발행되는 총 API 요청 수

mtc_client_request_elapsed

API 요청 대기 시간, 요청 유형별로 정렬

sum(mtc_client_request_elapsed)

API 요청에 대한 총 대기 시간

sum(mtc_client_request_elapsed) / sum(mtc_client_request_count)

평균 API 요청 대기 시간

mtc_client_request_elapsed / mtc_client_request_count

요청 유형별로 정렬된 API 요청의 평균 대기 시간

cam_app_workload_migrations{status="running"} * 100

요청 수와 함께 더 쉽게 볼 수 있도록 실행 중인 마이그레이션 수, 100을 곱한 값

11.3.5. must-gather 툴 사용

must-gather 툴을 사용하여 MTC 사용자 정의 리소스에 대한 로그, 메트릭 및 정보를 수집할 수 있습니다.

must-gather 데이터는 모든 고객 사례에 첨부되어야 합니다.

1시간 또는 24시간 동안 데이터를 수집하고 Prometheus 콘솔을 사용하여 데이터를 볼 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인해야 합니다.
  • OpenShift CLI(oc)가 설치되어 있어야 합니다.

프로세스

  1. must-gather 데이터를 저장하려는 디렉터리로 이동합니다.
  2. 다음 데이터 수집 옵션 중 하나에 대해 oc adm must-gather 명령을 실행합니다.

    • 지난 24시간 동안 데이터를 수집하려면 다음 명령을 실행합니다.

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

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

    • 지난 24시간 동안 데이터를 수집하려면 다음 명령을 실행합니다.

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

      이 작업에는 오랜 시간이 걸릴 수 있습니다. 이 명령은 데이터를 must-gather/metrics/prom_data.tar.gz 파일로 저장합니다.

11.3.6. Velero CLI 툴을 사용하여 Velero 리소스 디버깅

BackupRestore CR(사용자 정의 리소스)을 디버그하고 Velero CLI 툴을 사용하여 로그를 검색할 수 있습니다.

Velero CLI 툴은 OpenShift CLI 툴보다 자세한 정보를 제공합니다.

구문

oc exec 명령을 사용하여 Velero CLI 명령을 실행합니다.

$ oc -n openshift-migration exec deployment/velero -c velero -- ./velero \
  <backup_restore_cr> <command> <cr_name>

예제

$ oc -n openshift-migration exec deployment/velero -c velero -- ./velero \
  backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql

도움말 옵션

velero --help 옵션을 사용하여 모든 Velero CLI 명령을 나열합니다.

$ oc -n openshift-migration exec deployment/velero -c velero -- ./velero \
  --help
Describe 명령

velero describe 명령을 사용하여 Backup 또는 Restore CR과 관련된 경고 및 오류 요약을 검색합니다.

$ oc -n openshift-migration exec deployment/velero -c velero -- ./velero \
  <backup_restore_cr> describe <cr_name>

예제

$ oc -n openshift-migration exec deployment/velero -c velero -- ./velero \
  backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql

다음 유형의 복원 오류 및 경고는 velero describe 요청 출력에 표시됩니다.

  • Velero: Velero 자체 작업과 관련된 메시지 목록(예: 클라우드 연결, 백업 파일 읽기 등)
  • 클러스터: 클러스터 범위 리소스 백업 또는 복원과 관련된 메시지 목록입니다.
  • 네임스페이스: 네임스페이스에 저장된 리소스 백업 또는 복원과 관련된 메시지 목록

이러한 카테고리 중 하나에 있는 하나 이상의 오류로 인해 복원 작업에서 PartiallyFailed 의 상태를 수신하고 완료 하지 않습니다. 경고로 인해 완료 상태가 변경되지 않습니다.

중요
  • 리소스별 오류( 클러스터네임스페이스 오류)의 경우 restore describe --details 출력에 Velero가 복원에 성공한 모든 리소스를 나열하는 리소스 목록이 포함됩니다. 이러한 오류가 있는 모든 리소스의 경우 리소스가 실제로 클러스터에 있는지 확인합니다.
  • describe 명령의 출력에서 Velero 오류가 있지만 리소스별 오류가 없는 경우 워크로드를 복원하는 실제 문제 없이 복원이 완료될 수 있지만 복원 후 애플리케이션을 신중하게 검증할 수 있습니다.

    예를 들어 출력에 PodVolumeRestore 또는 노드 에이전트 관련 오류가 포함된 경우 PodVolumeRestoresDataDownloads 의 상태를 확인합니다. 이러한 항목이 실패하거나 계속 실행되지 않은 경우 볼륨 데이터가 완전히 복원되었을 수 있습니다.

Logs 명령

velero logs 명령을 사용하여 Backup 또는 Restore CR의 로그를 검색합니다.

$ oc -n openshift-migration exec deployment/velero -c velero -- ./velero \
  <backup_restore_cr> logs <cr_name>

예제

$ oc -n openshift-migration exec deployment/velero -c velero -- ./velero \
  restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

11.3.7. 부분적인 마이그레이션 실패 디버깅

Velero CLI를 사용하여 Restore CR(사용자 정의 리소스) 로그를 검사하여 부분적인 마이그레이션 실패 경고 메시지를 디버깅할 수 있습니다.

부분적인 오류는 Velero가 마이그레이션에 실패하지 않는 문제가 발생하면 발생합니다. 예를 들어 CRD(사용자 정의 리소스 정의)가 누락되거나 소스 및 대상 클러스터에서 CRD 버전 간에 불일치가 있는 경우 마이그레이션이 완료되지만 CR은 대상 클러스터에서 생성되지 않습니다.

Velero 를 부분적인 오류로 기록한 다음 Backup CR에서 나머지 오브젝트를 처리합니다.

프로세스

  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 -n {namespace} exec deployment/velero -c velero -- ./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 -n {namespace} exec deployment/velero -c velero -- ./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은 부분적으로 실패한 마이그레이션의 원인을 나타냅니다.

11.3.8. 문제 해결을 위해 MTC 사용자 정의 리소스 사용

다음 MTC(Migration Toolkit for Containers) 사용자 정의 리소스(CR)를 확인하여 마이그레이션 실패 문제를 해결할 수 있습니다.

  • MigCluster
  • MigStorage
  • MigPlan
  • BackupStorageLocation

    BackupStorageLocation CR에는 CR을 생성한 MTC 인스턴스를 식별하는 migrationcontroller 레이블이 포함되어 있습니다.

        labels:
          migrationcontroller: ebe13bee-c803-47d0-a9e9-83f380328b93
  • VolumeSnapshotLocation

    VolumeSnapshotLocation CR에는 CR을 생성한 MTC 인스턴스를 식별하는 migrationcontroller 레이블이 포함되어 있습니다.

        labels:
          migrationcontroller: ebe13bee-c803-47d0-a9e9-83f380328b93
  • MigMigration
  • Backup

    MTC는 대상 클러스터에서 PV(영구 볼륨)를 Retain으로 마이그레이션한 PV(영구 볼륨)의 회수 정책을 변경합니다. Backup CR에는 원래 회수 정책을 나타내는 openshift.io/orig-reclaim-policy 주석이 포함되어 있습니다. 마이그레이션된 PV의 회수 정책을 수동으로 복원할 수 있습니다.

  • Restore

프로세스

  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

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

MigMigration 예제 출력

name:         88435fe0-c9f8-11e9-85e6-5d593ce65e10
namespace:    openshift-migration
labels:       <none>
annotations:  touch: 3b48b543-b53e-4e44-9d34-33563f0f8147
apiVersion:  migration.openshift.io/v1alpha1
kind:         MigMigration
metadata:
  creationTimestamp:  2019-08-29T01:01:29Z
  generation:          20
  resourceVersion:    88179
  selfLink:           /apis/migration.openshift.io/v1alpha1/namespaces/openshift-migration/migmigrations/88435fe0-c9f8-11e9-85e6-5d593ce65e10
  uid:                 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
spec:
  migPlanRef:
    name:        socks-shop-mig-plan
    namespace:   openshift-migration
  quiescePods:  true
  stage:         false
status:
  conditions:
    category:              Advisory
    durable:               True
    lastTransitionTime:  2019-08-29T01:03:40Z
    message:               The migration has completed successfully.
    reason:                Completed
    status:                True
    type:                  Succeeded
  phase:                   Completed
  startTimestamp:         2019-08-29T01:01:29Z
events:                    <none>

PV 데이터를 설명하는 Velero 백업 CR #2 예제 출력

apiVersion: velero.io/v1
kind: Backup
metadata:
  annotations:
    openshift.io/migrate-copy-phase: final
    openshift.io/migrate-quiesce-pods: "true"
    openshift.io/migration-registry: 172.30.105.179:5000
    openshift.io/migration-registry-dir: /socks-shop-mig-plan-registry-44dd3bd5-c9f8-11e9-95ad-0205fe66cbb6
    openshift.io/orig-reclaim-policy: delete
  creationTimestamp: "2019-08-29T01:03:15Z"
  generateName: 88435fe0-c9f8-11e9-85e6-5d593ce65e10-
  generation: 1
  labels:
    app.kubernetes.io/part-of: migration
    migmigration: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
    migration-stage-backup: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
    velero.io/storage-location: myrepo-vpzq9
  name: 88435fe0-c9f8-11e9-85e6-5d593ce65e10-59gb7
  namespace: openshift-migration
  resourceVersion: "87313"
  selfLink: /apis/velero.io/v1/namespaces/openshift-migration/backups/88435fe0-c9f8-11e9-85e6-5d593ce65e10-59gb7
  uid: c80dbbc0-c9f8-11e9-95ad-0205fe66cbb6
spec:
  excludedNamespaces: []
  excludedResources: []
  hooks:
    resources: []
  includeClusterResources: null
  includedNamespaces:
  - sock-shop
  includedResources:
  - persistentvolumes
  - persistentvolumeclaims
  - namespaces
  - imagestreams
  - imagestreamtags
  - secrets
  - configmaps
  - pods
  labelSelector:
    matchLabels:
      migration-included-stage-backup: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
  storageLocation: myrepo-vpzq9
  ttl: 720h0m0s
  volumeSnapshotLocations:
  - myrepo-wv6fx
status:
  completionTimestamp: "2019-08-29T01:02:36Z"
  errors: 0
  expiration: "2019-09-28T01:02:35Z"
  phase: Completed
  startTimestamp: "2019-08-29T01:02:35Z"
  validationErrors: null
  version: 1
  volumeSnapshotsAttempted: 0
  volumeSnapshotsCompleted: 0
  warnings: 0

Kubernetes 리소스를 설명하는 Velero 복원 CR #2 예제 출력

apiVersion: velero.io/v1
kind: Restore
metadata:
  annotations:
    openshift.io/migrate-copy-phase: final
    openshift.io/migrate-quiesce-pods: "true"
    openshift.io/migration-registry: 172.30.90.187:5000
    openshift.io/migration-registry-dir: /socks-shop-mig-plan-registry-36f54ca7-c925-11e9-825a-06fa9fb68c88
  creationTimestamp: "2019-08-28T00:09:49Z"
  generateName: e13a1b60-c927-11e9-9555-d129df7f3b96-
  generation: 3
  labels:
    app.kubernetes.io/part-of: migration
    migmigration: e18252c9-c927-11e9-825a-06fa9fb68c88
    migration-final-restore: e18252c9-c927-11e9-825a-06fa9fb68c88
  name: e13a1b60-c927-11e9-9555-d129df7f3b96-gb8nx
  namespace: openshift-migration
  resourceVersion: "82329"
  selfLink: /apis/velero.io/v1/namespaces/openshift-migration/restores/e13a1b60-c927-11e9-9555-d129df7f3b96-gb8nx
  uid: 26983ec0-c928-11e9-825a-06fa9fb68c88
spec:
  backupName: e13a1b60-c927-11e9-9555-d129df7f3b96-sz24f
  excludedNamespaces: null
  excludedResources:
  - nodes
  - events
  - events.events.k8s.io
  - backups.velero.io
  - restores.velero.io
  - resticrepositories.velero.io
  includedNamespaces: null
  includedResources: null
  namespaceMapping: null
  restorePVs: true
status:
  errors: 0
  failureReason: ""
  phase: Completed
  validationErrors: null
  warnings: 15

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

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

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

직접 볼륨 마이그레이션이 완료되지 않으면 대상 클러스터에 소스 클러스터와 동일한 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. 마이그레이션 계획을 다시 실행합니다.

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

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

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

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

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

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

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

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

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

  • 브라우저 웹 검사기를 사용하여 MTC 콘솔 웹 페이지를 확인합니다.
  • Migration UI pod 로그에 오류가 있는지 확인합니다.
11.4.2.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 번들 파일의 이름을 지정합니다.
11.4.2.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로 인해 마이그레이션이 실패하지는 않습니다.

11.4.2.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. 저장을 클릭합니다.
11.4.2.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>
11.4.2.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가 다시 시작될 때까지 기다립니다.

11.4.3. OpenShift Container Platform에서 실행되는 워크로드에 자동으로 spc_t 를 사용하여 Skip SELinux 재레이블 해결 방법 적용

MTC(Migration Toolkit for Containers)와 관련된 상당한 볼륨을 사용하여 네임스페이스를 마이그레이션하려고 할 때 rsync-server 는 문제를 해결하기 위한 추가 정보 없이 rsync-server가 고정될 수 있습니다.

11.4.3.1. Skip SELinux 재레이블 해결 방법 필요 진단

Unable to attach or mount volume for pod…​timed out error of Unable to attach or mount volume for the pod…​timed out waiting for the condition in the kubelet logs where the rsync-server for the Direct Volume Migration (DVM)이 실행되는 노드에서 kubelet 로그의 조건을 대기하거나 마운트할 수 없는 오류를 검색합니다.

kubelet 로그의 예

kubenswrapper[3879]: W0326 16:30:36.749224    3879 volume_linux.go:49] Setting volume ownership for /var/lib/kubelet/pods/8905d88e-6531-4d65-9c2a-eff11dc7eb29/volumes/kubernetes.io~csi/pvc-287d1988-3fd9-4517-a0c7-22539acd31e6/mount and fsGroup set. If the volume has a lot of files then setting volume ownership could be slow, see https://github.com/kubernetes/kubernetes/issues/69699

kubenswrapper[3879]: E0326 16:32:02.706363    3879 kubelet.go:1841] "Unable to attach or mount volumes for pod; skipping pod" err="unmounted volumes=[8db9d5b032dab17d4ea9495af12e085a], unattached volumes=[crane2-rsync-server-secret 8db9d5b032dab17d4ea9495af12e085a kube-api-access-dlbd2 crane2-stunnel-server-config crane2-stunnel-server-secret crane2-rsync-server-config]: timed out waiting for the condition" pod="caboodle-preprod/rsync-server"

kubenswrapper[3879]: E0326 16:32:02.706496    3879 pod_workers.go:965] "Error syncing pod, skipping" err="unmounted volumes=[8db9d5b032dab17d4ea9495af12e085a], unattached volumes=[crane2-rsync-server-secret 8db9d5b032dab17d4ea9495af12e085a kube-api-access-dlbd2 crane2-stunnel-server-config crane2-stunnel-server-secret crane2-rsync-server-config]: timed out waiting for the condition" pod="caboodle-preprod/rsync-server" podUID=8905d88e-6531-4d65-9c2a-eff11dc7eb29

11.4.3.2. Skip SELinux 재레이블 해결 방법을 사용하여 해결

이 문제를 해결하려면 MigrationController CR(사용자 정의 리소스)을 사용하여 source 및 destination MigClusters 에서 migration_rsync_super_privileged 매개변수를 true 로 설정합니다.

MigrationController CR의 예

apiVersion: migration.openshift.io/v1alpha1
kind: MigrationController
metadata:
  name: migration-controller
  namespace: openshift-migration
spec:
  migration_rsync_super_privileged: true 1
  azure_resource_group: ""
  cluster_name: host
  mig_namespace_limit: "10"
  mig_pod_limit: "100"
  mig_pv_limit: "100"
  migration_controller: true
  migration_log_reader: true
  migration_ui: true
  migration_velero: true
  olm_managed: true
  restic_timeout: 1h
  version: 1.8.3

1
migration_rsync_super_privileged 매개변수의 값은 Rsync Pod를 슈퍼 권한이 있는 컨테이너로 실행할지 여부를 나타냅니다(spc_t selinux 컨텍스트). 유효한 설정은 true 또는 false 입니다.

11.5. 마이그레이션 롤백

MTC 웹 콘솔 또는 CLI를 사용하여 마이그레이션을 롤백할 수 있습니다.

마이그레이션을 수동으로 롤백할 수도 있습니다.

11.5.1. MTC 웹 콘솔을 사용하여 마이그레이션 롤백

MTC(Migration Toolkit for Containers) 웹 콘솔을 사용하여 마이그레이션을 롤백할 수 있습니다.

참고

다음 리소스는 실패한 직접 볼륨 마이그레이션(DVM) 이후 디버깅을 위해 마이그레이션된 네임스페이스에 남아 있습니다.

  • 구성 맵 (소스 및 대상 클러스터)
  • Secret 오브젝트 (소스 및 대상 클러스터)
  • Rsync CR (소스 클러스터)

이러한 리소스는 롤백에 영향을 미치지 않습니다. 수동으로 삭제할 수 있습니다.

나중에 동일한 마이그레이션 계획을 성공적으로 실행하면 실패한 마이그레이션의 리소스가 자동으로 삭제됩니다.

마이그레이션 실패로 인해 애플리케이션이 중지된 경우 영구 볼륨의 데이터 손상을 방지하려면 마이그레이션을 롤백해야 합니다.

원래 애플리케이션이 소스 클러스터에서 계속 실행 중이므로 마이그레이션 중에 애플리케이션이 중지되지 않은 경우 롤백이 필요하지 않습니다.

프로세스

  1. MTC 웹 콘솔에서 마이그레이션 계획을 클릭합니다.
  2. 마이그레이션 계획 옆의 옵션 메뉴 kebab 를 클릭하고 마이그레이션에서 롤백을 선택합니다.
  3. 롤백을 클릭하고 롤백이 완료될 때까지 기다립니다.

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

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

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

11.5.2. 명령줄 인터페이스를 사용하여 마이그레이션 롤백

명령줄 인터페이스에서 MigMigration CR(사용자 정의 리소스)을 생성하여 마이그레이션을 롤백할 수 있습니다.

참고

다음 리소스는 실패한 직접 볼륨 마이그레이션(DVM) 이후 디버깅을 위해 마이그레이션된 네임스페이스에 남아 있습니다.

  • 구성 맵 (소스 및 대상 클러스터)
  • Secret 오브젝트 (소스 및 대상 클러스터)
  • Rsync CR (소스 클러스터)

이러한 리소스는 롤백에 영향을 미치지 않습니다. 수동으로 삭제할 수 있습니다.

나중에 동일한 마이그레이션 계획을 성공적으로 실행하면 실패한 마이그레이션의 리소스가 자동으로 삭제됩니다.

마이그레이션 실패로 인해 애플리케이션이 중지된 경우 영구 볼륨의 데이터 손상을 방지하려면 마이그레이션을 롤백해야 합니다.

원래 애플리케이션이 소스 클러스터에서 계속 실행 중이므로 마이그레이션 중에 애플리케이션이 중지되지 않은 경우 롤백이 필요하지 않습니다.

프로세스

  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. 마이그레이션된 프로젝트 리소스가 소스 클러스터에 있고 애플리케이션이 실행 중인지 확인합니다.

11.5.3. 마이그레이션 수동 롤백

stage Pod를 삭제하고 애플리케이션의 정지를 해제하여 실패한 마이그레이션을 수동으로 롤백할 수 있습니다.

동일한 마이그레이션 계획을 성공적으로 실행하면 실패한 마이그레이션의 리소스가 자동으로 삭제됩니다.

참고

다음 리소스는 실패한 직접 볼륨 마이그레이션(DVM) 후에도 마이그레이션된 네임스페이스에 남아 있습니다.

  • 구성 맵 (소스 및 대상 클러스터)
  • Secret 오브젝트 (소스 및 대상 클러스터)
  • Rsync CR (소스 클러스터)

이러한 리소스는 롤백에 영향을 미치지 않습니다. 수동으로 삭제할 수 있습니다.

프로세스

  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>
추가 리소스

법적 공지

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.