Migration Toolkit for Containers

OpenShift Container Platform 4.8

OpenShift Container Platform 4로 마이그레이션

Red Hat OpenShift Documentation Team

초록

이 문서에서는 OpenShift Container Platform 클러스터를 버전 3에서 버전 4로 마이그레이션하고 이전 OpenShift Container Platform 4 릴리스에서 최신 버전으로 마이그레이션하는 방법을 설명합니다.

1장. OpenShift Container Platform 3에서 마이그레이션

1.1. OpenShift Container Platform 3에서 4로 마이그레이션 정보

OpenShift Container Platform 4에는 유연하며 자동화된 자체 관리 클러스터를 만드는 새로운 기술과 기능이 포함되어 있습니다. OpenShift Container Platform 4 클러스터의 배포 및 관리 방식은 OpenShift Container Platform 3과 크게 다릅니다.

OpenShift Container Platform 3에서 OpenShift Container Platform 4로 성공적으로 전환하려면 다음을 숙지해야 합니다.

전환 계획
OpenShift Container Platform 버전 3과 4의 차이점을 알아보십시오. 전환하기 전에 스토리지, 네트워킹, 로깅, 보안 및 모니터링 고려 사항을 검토하고 준비하십시오.
마이그레이션 수행
MTC(Migration Toolkit for Containers)에 대해 알아보고 사용하여 애플리케이션 워크로드를 마이그레이션합니다.

1.2. 마이그레이션 계획

OpenShift Container Platform 4.7으로 마이그레이션하기 전에 시간을 들여 전환을 적절히 계획해야 합니다. OpenShift Container Platform 4에는 아키텍처 변경 및 개선 사항이 도입되었으므로 OpenShift Container Platform 3 클러스터를 관리하는 데 사용한 절차가 OpenShift Container Platform 4에는 적용되지 않을 수 있습니다.

참고

이 계획 문서에서는 OpenShift Container Platform 3.11에서 OpenShift Container Platform 4.7으로 전환한다고 가정합니다.

이 문서에서는 OpenShift Container Platform 3과 OpenShift Container Platform 4의 가장 중요한 차이점과 가장 주목할 만한 마이그레이션 고려 사항을 자세히 설명합니다. OpenShift Container Platform 4 클러스터 구성에 대한 자세한 내용은 OpenShift Container Platform 설명서의 해당 섹션을 참조하십시오. 새로운 기능 및 기타 주목할 만한 기술적 변경 사항에 대한 자세한 정보는 OpenShift Container Platform 4.7 릴리스 노트를 참조하십시오.

기존 OpenShift Container Platform 3 클러스터를 OpenShift Container Platform 4로 업그레이드할 수 없습니다. 먼저 새로운 OpenShift Container Platform 4를 설치해야 합니다. 컨트롤 플레인 설정 및 애플리케이션 워크로드를 마이그레이션하는 데 도움이 되는 도구를 사용할 수 있습니다.

1.2.1. OpenShift Container Platform 3 및 OpenShift Container Platform 4 비교

관리자는 OpenShift Container Platform 3를 사용하여 RHEL(Red Hat Enterprise Linux) 호스트를 개별적으로 배포한 다음 이러한 호스트 위에 OpenShift Container Platform을 설치하여 클러스터를 구성했습니다. 이러한 호스트를 올바르게 구성하고 업데이트를 수행할 책임이 관리자에게 있었습니다.

OpenShift Container Platform 4에서는 OpenShift Container Platform 클러스터의 배포 및 관리 방식이 크게 변경되었습니다. OpenShift Container Platform 4에는 클러스터 운영의 핵심인 Operator, MachineSet 및 RHCOS(Red Hat Enterprise Linux CoreOS)와 같은 새로운 기술과 기능이 포함되어 있습니다. 이러한 기술 전환을 통해 이전에 관리자가 수행했던 일부 기능을 클러스터에서 자체 관리할 수 있습니다. 또한 플랫폼 안정성과 일관성을 보장하고 설치 및 확장을 단순화합니다.

자세한 내용은 OpenShift Container Platform 아키텍처를 참조하십시오.

1.2.1.1. 아키텍처 차이점

불변의 인프라

OpenShift Container Platform 4는 컨테이너화된 애플리케이션을 실행하도록 설계된 RHCOS(Red Hat Enterprise Linux CoreOS)를 사용하며 효율적인 설치, 운영자 기반 관리 및 간소화된 업그레이드를 제공합니다. RHCOS는 RHEL과 같은 사용자 정의 가능한 운영 체제가 아닌 변경 불가능한 컨테이너 호스트입니다. RHCOS를 사용하면 OpenShift Container Platform 4에서 기본 컨테이너 호스트의 배포를 관리하고 자동화할 수 있습니다. RHCOS는 OpenShift Container Platform의 일부입니다. 즉, 모든 항목이 컨테이너 내부에서 실행되며 OpenShift Container Platform을 사용하여 배포됩니다.

OpenShift Container Platform 4에서 컨트롤 플레인 노드는 RHCOS를 실행해야 컨트롤 플레인에 대한 전체 스택 자동화가 유지됩니다. 이를 통해 OpenShift Container Platform 3보다 업데이트 및 업그레이드를 훨씬 쉽게 처리할 수 있습니다.

자세한 내용은 RHCOS(Red Hat Enterprise Linux CoreOS)를 참조하십시오.

Operator

Operator는 Kubernetes 애플리케이션을 패키징, 배포 및 관리하는 방법입니다. Operator는 다른 소프트웨어를 실행하는 데 따르는 운영의 복잡성을 줄여 줍니다. 환경을 감시하고 현재 상태를 반영하여 실시간으로 결정을 내립니다. 고급 Operator는 자동으로 업그레이드하고 장애에 대응하도록 설계되었습니다.

자세한 내용은 Operator 이해를 참조하십시오.

1.2.1.2. 설치 및 업데이트 차이점

설치 과정

OpenShift Container Platform 3.11을 설치하기 위해 RHEL(Red Hat Enterprise Linux) 호스트를 준비하고 클러스터에 필요한 모든 구성 값을 설정한 다음 Ansible 플레이북을 실행하여 클러스터를 설치 및 설정했습니다.

OpenShift Container Platform 4.7에서는 OpenShift 설치 프로그램을 사용하여 클러스터에 필요한 최소한의 리소스 세트를 생성합니다. 클러스터가 실행되면 Operator를 사용하여 클러스터를 추가로 구성하고 새 서비스를 설치합니다. 처음 부팅한 후 RHCOS(Red Hat Enterprise Linux CoreOS) 시스템은 OpenShift Container Platform 클러스터에서 실행되는 MCO(Machine Config Operator)에서 관리합니다.

자세한 내용은 설치 프로세스를 참조하십시오.

OpenShift Container Platform 4.7 클러스터에 RHEL(Red Hat Enterprise Linux) 작업자 머신을 추가하려면 클러스터가 실행된 후 Ansible 플레이북을 사용하여 RHEL 작업자 머신에 결합합니다. 자세한 내용은 OpenShift Container Platform 클러스터에 RHEL 컴퓨팅 머신 추가를 참조하십시오.

인프라 옵션

OpenShift Container Platform 3.11에서는 준비 및 유지 관리한 인프라에 클러스터를 설치했습니다. OpenShift Container Platform 4에서는 자체 인프라를 제공할 뿐만 아니라 OpenShift Container Platform 설치 프로그램이 제공하고 클러스터에서 유지 관리하는 인프라에 클러스터를 배포할 수 있는 옵션도 있습니다.

자세한 내용은 OpenShift Container Platform 설치 개요를 참조하십시오.

클러스터 업그레이드

OpenShift Container Platform 3.11에서는 Ansible 플레이북을 실행하여 클러스터를 업그레이드했습니다. OpenShift Container Platform 4.7에서는 클러스터 노드의 RHCOS(Red Hat Enterprise Linux CoreOS) 업데이트를 포함하여 클러스터에서 자체 업데이트를 관리합니다. 웹 콘솔을 사용하거나 OpenShift CLI에서 oc adm upgrade 명령을 사용하여 클러스터를 쉽게 업그레이드할 수 있으며 Operator가 자동으로 업그레이드합니다. OpenShift Container Platform 4.7 클러스터에 RHEL 작업자 머신이 있는 경우에도 해당 작업자 머신을 업그레이드하려면 Ansible 플레이북을 실행해야 합니다.

자세한 내용은 클러스터 업데이트를 참조하십시오.

1.2.2. 마이그레이션 고려 사항

OpenShift Container Platform 3.11에서 OpenShift Container Platform 4로 전환하는 데 영향을 줄 수 있는 변경 사항 및 기타 고려 사항을 검토하십시오.

1.2.2.1. 스토리지 고려 사항

OpenShift Container Platform 3.11에서 OpenShift Container Platform 4.7으로 전환할 때 고려할 다음 스토리지 변경 사항을 검토하십시오.

로컬 볼륨 영구저장장치

로컬 스토리지는 OpenShift Container Platform 4.7에서 Local Storage Operator를 사용하는 경우에만 지원됩니다. OpenShift Container Platform 3.11의 로컬 프로비저닝 방법은 사용할 수 없습니다.

자세한 내용은 로컬 볼륨을 사용한 영구저장장치를 참조하십시오.

FlexVolume 영구저장장치

FlexVolume 플러그인 위치가 OpenShift Container Platform 3.11에서 변경되었습니다. OpenShift Container Platform 4.7의 새 위치는 /etc/kubernetes/kubelet-plugins/volume/exec입니다. 연결 가능한 FlexVolume 플러그인은 더 이상 지원되지 않습니다.

자세한 내용은 FlexVolume을 사용한 영구저장장치를 참조하십시오.

CSI(Container Storage Interface) 영구저장장치

CSI(Container Storage Interface)를 사용하는 영구저장장치는 OpenShift Container Platform 3.11의 기술 프리뷰였습니다. OpenShift Container Platform 4.7은 CSI 버전 1.1.0을 완전히 지원하며 여러 CSI 드라이버와 함께 제공됩니다. 자체 드라이버를 설치할 수도 있습니다.

자세한 내용은 CSI(Container Storage Interface)를 사용한 영구저장장치를 참조하십시오.

Red Hat OpenShift 컨테이너 스토리지

OpenShift Container Platform 3.11과 함께 사용할 수 있는 Red Hat OpenShift Container Storage 3에서는 백업 스토리지로 Red Hat Gluster Storage를 사용합니다.

OpenShift Container Platform 4에서 사용할 수 있는 Red Hat OpenShift Container Storage 4는 백업 스토리지로 Red Hat Ceph Storage를 사용합니다.

자세한 내용은 Red Hat OpenShift Container Storage를 사용한 영구저장장치상호 운용성 목록 문서를 참조하십시오.

영구저장장치 옵션 지원 중단

OpenShift Container Platform 3.11의 다음 영구저장장치 옵션에 대한 지원이 OpenShift Container Platform 4.7에서 변경되었습니다.

  • GlusterFS는 더 이상 지원되지 않습니다.
  • 독립 실행형 CephFS는 더 이상 지원되지 않습니다.
  • 독립 실행형 Ceph RBD는 더 이상 지원되지 않습니다.

OpenShift Container Platform 3.11에서 이 중 하나를 사용한 경우 OpenShift Container Platform 4.7에서 완벽하게 지원하려면 다른 영구저장장치 옵션을 선택해야 합니다.

자세한 내용은 영구저장장치 이해를 참조하십시오.

1.2.2.2. 네트워킹 고려 사항

OpenShift Container Platform 3.11에서 OpenShift Container Platform 4.7으로 전환할 때 고려할 다음 네트워킹 변경 사항을 검토하십시오.

네트워크 격리 모드

OpenShift Container Platform 3.11의 기본 네트워크 격리 모드는 ovs-subnet이지만 사용자는 ovn-multitenant를 사용하도록 자주 전환했습니다. OpenShift Container Platform 4.7의 기본 네트워크 격리 모드는 네트워크 정책에서 제어합니다.

OpenShift Container Platform 3.11 클러스터가 ovs-subnet 또는 ovs-multitenant 모드를 사용한 경우 OpenShift Container Platform 4.7 클러스터의 네트워크 정책으로 전환하는 것이 좋습니다. 네트워크 정책은 업스트림에서 지원되며 보다 유연하고 ovs-multitenant의 기능을 제공합니다. OpenShift Container Platform 4.7에서 NetworkPolicy를 사용하는 동안 ovs-multitenant 동작을 유지하려면 NetworkPolicy를 사용하여 다중 테넌트 격리를 구성 단계를 따르십시오.

자세한 내용은 네트워크 정책 정보를 참조하십시오.

호스트 간의 트래픽 암호화

OpenShift Container Platform 3.11에서는 IPsec을 사용하여 호스트 간의 트래픽을 암호화할 수 있습니다. OpenShift Container Platform 4.7에서는 IPsec을 지원하지 않습니다. 서비스 간에 상호 TLS를 활성화하려면 Red Hat OpenShift Service Mesh를 사용하는 것이 좋습니다.

자세한 내용은 Red Hat OpenShift 서비스 메시 이해를 참조하십시오.

1.2.2.3. 로깅 고려 사항

OpenShift Container Platform 3.11에서 OpenShift Container Platform 4.7으로 전환할 때 고려할 다음 로깅 변경 사항을 검토하십시오.

OpenShift Logging 배포

OpenShift Container Platform 4는 클러스터 로깅 사용자 정의 리소스를 사용하여 OpenShift 로깅을 위한 간단한 배포 메커니즘을 제공합니다.

자세한 내용은 OpenShift 로깅 설치를 참조하십시오.

집계된 로깅 데이터

OpenShift Container Platform 3.11에서 새로운 OpenShift Container Platform 4 클러스터로 집계 로깅 데이터를 전환할 수 없습니다.

자세한 내용은 OpenShift 로깅 정보를 참조하십시오.

지원되지 않는 로깅 구성

OpenShift Container Platform 3.11에서 사용 가능한 일부 로깅 구성은 OpenShift Container Platform 4.7에서 더 이상 지원되지 않습니다.

명시적으로 지원되지 않는 로깅 사례에 대한 자세한 내용은 유지 관리 및 지원을 참조하십시오.

1.2.2.4. 보안 고려 사항

OpenShift Container Platform 3.11에서 OpenShift Container Platform 4.7으로 전환할 때 고려할 다음 보안 변경 사항을 검토하십시오.

검색 끝점에 인증되지 않은 액세스

OpenShift Container Platform 3.11에서 인증되지 않은 사용자는 검색 끝점(예: /api/*/apis/* )에 액세스할 수 있습니다. 보안상의 이유로 검색 끝점에 대해 인증되지 않은 액세스는 더 이상 OpenShift Container Platform 4.7에서 허용되지 않습니다. 인증되지 않은 액세스를 허용해야 하는 경우 필요에 따라 RBAC 설정을 구성할 수 있습니다. 그러나 내부 클러스터 구성 요소가 외부 네트워크에 노출될 수 있으므로 보안 관련 사항을 고려해야 합니다.

ID 공급자

다음과 같이 눈에 띄는 변경 사항을 포함하여 OpenShift Container Platform 4의 ID 공급자 구성이 변경되었습니다.

  • OpenShift Container Platform 4.7의 요청 헤더 ID 공급자에는 상호 TLS가 필요하지만 OpenShift Container Platform 3.11에서는 그렇지 않습니다.
  • OpenShift Container Platform 4.7에서는 OpenID Connect ID 공급자의 구성이 간소화되었습니다. 이제 공급자의 /.well-known/openid-configuration 끝점에서 이전에 OpenShift Container Platform 3.11에 지정했던 데이터를 가져옵니다.

자세한 내용은 ID 공급자 구성 이해를 참조하십시오.

OAuth 토큰 스토리지 형식

새로 생성된 OAuth HTTP 전달자 토큰이 더 이상 OAuth 액세스 토큰 오브젝트의 이름과 일치하지 않습니다. 이제 오브젝트 이름은 전달자 토큰의 해시이며 더 이상 민감하지 않습니다. 이렇게 하면 민감한 정보가 유출될 위험이 줄어 듭니다.

1.2.2.5. 모니터링 고려 사항

OpenShift Container Platform 3.11에서 OpenShift Container Platform 4.7으로 전환할 때 고려할 다음 모니터링 변경 사항을 검토하십시오.

인프라 가용성 모니터링을 위한 경고

OpenShift Container Platform 3.11에서는 모니터링 구조의 가용성을 보장하기 위해 트리거되는 기본 경고를 DeadMansSwitch라고 합니다. OpenShift Container Platform 4에서는 이름이 Watchdog으로 변경되었습니다. OpenShift Container Platform 3.11에서 이 경고와 함께 PagerDuty 통합을 설정한 경우 OpenShift Container Platform 4에서 Watchdog 경고에 대한 PagerDuty 통합을 설정해야 합니다.

자세한 내용은 사용자 정의 Alertmanager 구성 적용을 참조하십시오.

1.3. Migration Toolkit for Containers 정보

MTC(Migration Toolkit for Containers)를 사용하여 OpenShift Container Platform 3.7, 3.9, 3.10 및 3.11에서 OpenShift Container Platform 4.7으로 애플리케이션 워크로드를 마이그레이션할 수 있습니다. MTC를 사용하면 마이그레이션을 제어하고 애플리케이션 다운 타임을 최소화할 수 있습니다.

참고

MTC는 기본적으로 대상 클러스터에 설치되어 있습니다.

OpenShift Container Platform 3 클러스터 또는 원격 클러스터에 MTC를 설치하도록 Migration Toolkit for Containers Operator를 구성할 수 있습니다.

Kubernetes 사용자 정의 리소스를 기반으로 하는 MTC 웹 콘솔 및 API를 사용하면 네임스페이스 단위로 상태 저장 애플리케이션 워크로드를 마이그레이션할 수 있습니다.

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

마이그레이션 후크를 사용하여 마이그레이션 중에 특정 시점에서 Ansible 플레이북을 실행할 수 있습니다. 마이그레이션 계획을 생성할 때 후크가 추가됩니다.

참고

서비스 카탈로그는 OpenShift Container Platform 4에 기본적으로 설치되지 않습니다. 서비스 카탈로그로 프로비저닝된 워크로드 리소스를 OpenShift Container Platform 3에서 4로 마이그레이션할 수 있지만 마이그레이션 후 이러한 워크로드에서 provision , 프로비전 해제 또는 update 와 같은 서비스 카탈로그 작업을 수행할 수 없습니다.

MTC 웹 콘솔은 서비스 카탈로그 리소스를 마이그레이션할 수 없는 경우 메시지를 표시합니다.

중요

마이그레이션을 시작하기 전에 마이그레이션 계획에 대한 정보를 검토하십시오.

1.3.1. Migration Toolkit for Containers 워크플로

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

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

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

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

  • CR(사용자 정의 리소스) 및 CRD(사용자 정의 리소스 정의): MTC는 네임스페이스 수준에서 존재하는 모든 CR과 해당 CR에 연결된 CRD를 자동으로 마이그레이션합니다.

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

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

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

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

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

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

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

      참고

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

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

      참고

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

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

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

      스테이징은 여러 번 실행될 수 있으므로 마이그레이션 전에 대부분의 데이터가 대상에 복사됩니다. 따라서 마이그레이션의 기간과 애플리케이션 다운 타임이 최소화됩니다.

    • 마이그레이션은 소스 클러스터에서 애플리케이션을 중지하고 대상 클러스터에서 해당 리소스를 다시 만듭니다. 선택적으로 애플리케이션을 중지하지 않고 워크로드를 마이그레이션할 수 있습니다.
OCP 3에서 4로의 애플리케이션 마이그레이션

1.3.2. Migration Toolkit for Containers 사용자 정의 리소스

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 사용)

1.3.3. 데이터 복사 방법 정보

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

1.3.3.1. 파일 시스템 복사 방법

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

표 1.1. 파일 시스템 복사 방법 요약

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

1.3.3.2. 스냅샷 복사 방법

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

AWS, Google Cloud Provider 및 Microsoft Azure는 스냅샷 복사 방법을 지원합니다.

표 1.2. 스냅샷 복사 방법 요약

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

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

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

직접 마이그레이션은 소스 클러스터에서 복제 리포지토리로 파일을 백업하고 복제 리포지토리에서 대상 클러스터로 파일을 복원하는 중간 단계를 뛰어넘기 때문에 상당한 성능 이점을 지닙니다.

직접 마이그레이션은 Rsync를 사용하여 파일을 전송합니다.

참고

직접 이미지 마이그레이션 및 직접 볼륨 마이그레이션에는 추가 사전 요구 사항이 있습니다.

1.3.4. 마이그레이션 후크 정보

MTC(Migration Toolkit for Containers)를 사용하여 마이그레이션하는 동안 특정 시점에서 사용자 정의 코드를 실행하도록 마이그레이션 후크를 사용할 수 있습니다. 마이그레이션의 다른 단계에서 각 후크가 실행되고 단일 마이그레이션 계획에 최대 4개의 마이그레이션 후크를 추가할 수 있습니다.

마이그레이션 후크는 애플리케이션 정지 사용자 정의, 지원되지 않는 데이터 유형을 수동으로 마이그레이션 및 마이그레이션 후 애플리케이션 업데이트와 같은 작업을 수행합니다.

마이그레이션 후크는 다음 마이그레이션 단계 중 하나에서 소스 또는 대상 클러스터에서 실행됩니다.

  • PreBackup : 소스 클러스터에서 리소스를 백업하기 전에
  • PostBackup : 소스 클러스터에서 리소스를 백업한 후
  • PreRestore : 대상 클러스터에서 리소스가 복원되기 전에
  • PostRestore : 대상 클러스터에서 리소스가 복원된 후

Ansible 플레이북 또는 사용자 정의 후크 컨테이너를 사용하여 후크를 생성할 수 있습니다.

Ansible 플레이북

Ansible 플레이북은 후크 컨테이너에 구성 맵으로 마운트됩니다. 후크 컨테이너는 MigPlan 사용자 정의 리소스(CR)에 지정된 클러스터, 서비스 계정 및 네임스페이스를 사용하여 작업으로 실행됩니다. 작업은 기본 6번의 재시도 한도에 도달하거나 성공적으로 완료될 때까지 계속 실행됩니다. 이는 초기 포드가 제거되거나 종료된 경우에도 계속됩니다.

기본 Ansible 런타임 이미지는 registry.redhat.io/rhmtc/openshift-migration-hook-runner-rhel7:1.4입니다. 이 이미지는 Ansible Runner 이미지를 기반으로 하며 Ansible Kubernetes 리소스에 대해 python-openshift 및 업데이트된 oc바이너리를 포함합니다.

선택 사항: 기본 이미지 대신 추가 Ansible 모듈 또는 도구가 포함된 사용자 정의 Ansible 런타임 이미지를 사용할 수 있습니다.

사용자 정의 후크 컨테이너

Ansible 플레이북 또는 사용자 정의 코드가 포함된 사용자 정의 후크 컨테이너를 생성할 수 있습니다.

1.4. Migration Toolkit for Containers 설치 및 업그레이드

OpenShift Container Platform 4.7 대상 클러스터 및 OpenShift Container Platform 3 소스 클러스터에 MTC(Migration Toolkit for Containers)를 설치할 수 있습니다.

Migration Controller 포드는 기본적으로 대상 클러스터에서 실행됩니다. 소스 클러스터 또는 원격 클러스터에서 실행되도록 Migration Controller Pod를 구성할 수 있습니다.

1.4.1. 연결된 환경에서 Migration Toolkit for Containers 설치

연결된 환경에서 MTC(Migration Toolkit for Containers)를 설치할 수 있습니다.

중요

모든 클러스터에 동일한 MTC 버전을 설치해야 합니다.

1.4.1.1. OpenShift Container Platform 4.7 대상 클러스터에 Migration Toolkit for Containers 설치

OpenShift Container Platform 4.7 대상 클러스터에 MTC(Migration Toolkit for Containers)를 설치할 수 있습니다.

사전 요구 사항

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

프로세스

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

    참고

    서브스크립션 승인 옵션을 자동으로 변경하지 마십시오. 소스 및 대상 클러스터에서 Migration Toolkit for Containers 버전이 동일해야 합니다.

  4. 설치를 클릭합니다.

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

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

1.4.1.2. OpenShift Container Platform 3 소스 클러스터에 Migration Toolkit for Containers 설치

OpenShift Container Platform 3 소스 클러스터에 MTC(Migration Toolkit for Containers)를 수동으로 설치할 수 있습니다.

중요

OpenShift Container Platform 3 및 4 클러스터에 동일한 MTC 버전을 설치해야 합니다.

OpenShift Container Platform 3 클러스터에 최신 버전이 있는지 확인하려면 마이그레이션 계획을 생성하고 실행할 준비가 되었을 때 operator.ymlcontroller-3.yml 파일을 다운로드합니다.

사전 요구 사항

  • 모든 클러스터에서 cluster-admin 권한이 있는 사용자로 로그인합니다.
  • registry.redhat.io에 대한 액세스 권한이 있어야 합니다.
  • podman이 설치되어 있어야 합니다.
  • 소스 클러스터는 OpenShift Container Platform 3.7, 3.9, 3.10 또는 3.11이어야 합니다.
  • registry.redhat.io에서 이미지를 가져오도록 소스 클러스터를 구성해야 합니다.

    이미지를 가져오려면 create an image stream secret을 생성하여 클러스터의 각 노드에 복사해야 합니다.

프로세스

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

    $ sudo podman login registry.redhat.io
  2. operator.yml 파일을 다운로드합니다.

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-rhel7-operator:v1.4):/operator.yml ./
  3. controller-3.yml 파일을 다운로드합니다.

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

    $ oc run test --image registry.redhat.io/ubi8 --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 3 이전 버전용 리소스를 생성하기 때문에 발생합니다.
  7. MigrationController 오브젝트를 만듭니다.

    $ oc create -f controller-3.yml
  8. VeleroRestic Pod가 실행 중인지 확인합니다.

    $ oc get pods -n openshift-migration

1.4.2. 제한된 환경에서 Migration Toolkit for Containers 설치

제한된 환경에서 MTC(Migration Toolkit for Containers)를 설치할 수 있습니다.

중요

모든 클러스터에 동일한 MTC 버전을 설치해야 합니다.

OpenShift Container Platform 4에 대한 사용자 정의 Operator 카탈로그 이미지를 빌드하고 로컬 미러 이미지 레지스트리로 푸시하고 로컬 레지스트리에서 Migration Toolkit for Containers Operator를 설치하도록 OLM(Operator Lifecycle Manager)을 구성할 수 있습니다.

1.4.2.1. 기본 OperatorHub 소스 비활성화

Red Hat 및 커뮤니티 프로젝트에서 제공하는 콘텐츠를 소싱하는 Operator 카탈로그는 OpenShift Container Platform을 설치하는 동안 기본적으로 OperatorHub용으로 구성됩니다.

프로세스

  • OperatorHub 오브젝트에 disableAllDefaultSources: true를 추가하여 기본 카탈로그의 소스를 비활성화합니다.

    $ oc patch OperatorHub cluster --type json \
        -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
작은 정보

또는 웹 콘솔을 사용하여 카탈로그 소스를 관리할 수 있습니다. 관리자클러스터 설정글로벌 구성OperatorHub 페이지에서 개별 소스를 생성, 삭제, 비활성화, 활성화할 수 있는 소스 탭을 클릭합니다.

1.4.2.2. 인덱스 이미지 정리

Operator 번들 포맷을 기반으로 하는 인덱스 이미지는 Operator 카탈로그의 컨테이너화된 스냅샷입니다. 지정된 패키지 목록을 제외한 인덱스를 모두 정리하여 원하는 Operator만 포함하는 소스 인덱스 복사본을 생성할 수 있습니다.

제한된 네트워크 OpenShift Container Platform 클러스터에서 미러링된 콘텐츠를 사용하도록 OLM(Operator Lifecycle Manager)을 구성할 때는 기본 카탈로그에서 Operator 서브 세트만 미러링하려면 이 정리 방법을 사용하십시오.

이 절차의 단계에서 대상 레지스트리는 무제한 네트워크 액세스 권한을 사용하여 워크스테이션에서 액세스할 수 있는 기존 미러 레지스트리입니다. 이 예제에서는 기본 redhat-operators 카탈로그의 인덱스 이미지를 정리하는 방법도 보여주지만 프로세스는 모든 인덱스 이미지에서 동일합니다.

사전 요구 사항

  • 무제한 네트워크 액세스가 가능한 워크스테이션
  • podman 버전 1.9.3+
  • grpcurl
  • opm 버전 1.12.3 이상
  • Docker v2-2를 지원하는 레지스트리에 액세스

프로세스

  1. registry.redhat.io로 인증합니다.

    $ podman login registry.redhat.io
  2. 대상 레지스트리로 인증합니다.

    $ podman login <target_registry>
  3. 정리된 인덱스에 포함하려는 패키지 목록을 결정합니다.

    1. 컨테이너에서 정리하려는 소스 인덱스 이미지를 실행합니다. 예를 들면 다음과 같습니다.

      $ podman run -p50051:50051 \
          -it registry.redhat.io/redhat/redhat-operator-index:v4.7

      출력 예

      Trying to pull registry.redhat.io/redhat/redhat-operator-index:v4.7...
      Getting image source signatures
      Copying blob ae8a0c23f5b1 done
      ...
      INFO[0000] serving registry                              database=/database/index.db port=50051

    2. 별도의 터미널 세션에서 grpcurl 명령을 사용하여 인덱스에서 제공하는 패키지 목록을 가져옵니다.

      $ grpcurl -plaintext localhost:50051 api.Registry/ListPackages > packages.out
    3. packages.out 파일을 검사하고 정리된 인덱스에 보관할 이 목록에 있는 패키지 이름을 확인합니다. 예를 들면 다음과 같습니다.

      패키지 목록 조각의 예

      ...
      {
        "name": "advanced-cluster-management"
      }
      ...
      {
        "name": "jaeger-product"
      }
      ...
      {
      {
        "name": "quay-operator"
      }
      ...

    4. podman run 명령을 실행한 터미널 세션에서 CtrlC를 눌러 컨테이너 프로세스를 중지합니다.
  4. 다음 명령을 실행하여 지정된 패키지를 제외한 소스 인덱스를 모두 정리합니다.

    $ opm index prune \
        -f registry.redhat.io/redhat/redhat-operator-index:v4.7 \1
        -p advanced-cluster-management,jaeger-product,quay-operator \2
        [-i registry.redhat.io/openshift4/ose-operator-registry:v4.7] \3
        -t <target_registry>:<port>/<namespace>/redhat-operator-index:v4.7 4
    1
    정리할 인덱스입니다.
    2
    쉼표로 구분된 보관할 패키지 목록입니다.
    3
    IBM Power Systems 및 IBM Z 이미지에만 필요합니다. 대상 OpenShift Container Platform 클러스터 주 버전 및 부 버전과 일치하는 태그를 사용하여 --from을 Operator 레지스트리 기본 이미지로 설정합니다.
    4
    빌드 중인 새 인덱스 이미지에 대한 사용자 정의 태그입니다.
  5. 다음 명령을 실행하여 새 인덱스 이미지를 대상 레지스트리로 내보냅니다.

    $ podman push <target_registry>:<port>/<namespace>/redhat-operator-index:v4.7

    <namespace>는 레지스트리의 기존 네임스페이스입니다. 예를 들어 미러링된 콘텐츠를 모두 내보내기 위해 olm-mirror 네임스페이스를 생성할 수 있습니다.

1.4.2.3. Operator 카탈로그 미러링

oc adm catalog mirror 명령을 사용하여 Red Hat 제공 카탈로그 또는 사용자 정의 카탈로그의 Operator 콘텐츠를 컨테이너 이미지 레지스트리에 미러링할 수 있습니다. 대상 레지스트리는 Docker v2-2를 지원해야 합니다. 제한된 네트워크에 있는 클러스터의 경우 이 레지스트리는 제한된 네트워크 클러스터 설치 중 생성된 미러 레지스트리와 같이 클러스터에 네트워크 액세스 권한이 있는 레지스트리일 수 있습니다.

oc adm catalog mirror 명령은 또한 Red Hat 제공 인덱스 이미지이든 자체 사용자 정의 빌드 인덱스 이미지이든 미러링 프로세스 중에 지정하는 인덱스 이미지를 대상 레지스트리에 자동으로 미러링합니다. 그러면 미러링된 인덱스 이미지를 사용하여 OLM(Operator Lifecycle Manager)이 OpenShift Container Platform 클러스터에 미러링된 카탈로그를 로드할 수 있는 카탈로그 소스를 생성할 수 있습니다.

사전 요구 사항

  • 워크스테이션에서 무제한 네트워크 액세스가 가능합니다.
  • podman 버전이 1.9.3 이상입니다.
  • Docker v2-2를 지원하는 미러 레지스트리에 액세스할 수 있습니다.
  • 미러 레지스트리에서 미러링된 Operator 콘텐츠를 저장하는 데 사용할 네임스페이스를 결정합니다. 예를 들어 olm-mirror 네임스페이스를 생성할 수 있습니다.
  • 미러 레지스트리가 인터넷에 액세스할 수 없는 경우 이동식 미디어를 무제한 네트워크 액세스 권한이 있는 워크스테이션에 연결합니다.
  • 프라이빗 레지스트리로 작업 중인 경우 REG_CREDS 환경 변수를 이후 단계에서 사용하기 위해 레지스트리 자격 증명의 파일 경로로 설정합니다. 예를 들어 podman CLI의 경우:

    $ REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.json

프로세스

  1. Red Hat 제공 카탈로그를 미러링하려면 무제한 네트워크 액세스 권한이 있는 워크스테이션에서 다음 명령을 실행하여 registry.redhat.io로 인증합니다.

    $ podman login registry.redhat.io
  2. oc adm catalog mirror 명령은 인덱스 이미지의 콘텐츠를 추출하여 미러링에 필요한 매니페스트를 생성합니다. 명령의 기본 동작은 매니페스트를 생성한 다음 인덱스 이미지 자체뿐만 아니라 인덱스 이미지의 모든 이미지 콘텐츠를 미러 레지스트리에 자동으로 미러링합니다. 또는 미러 레지스트리가 완전히 연결이 끊긴 호스트 또는 에어갭(Airgap) 호스트에 있는 경우 먼저 콘텐츠를 이동식 미디어로 미러링하고 미디어를 연결이 끊긴 환경으로 이동한 다음 미디어에서 레지스트리로 해당 콘텐츠를 미러링할 수 있습니다.

    • 옵션 A: 미러 레지스트리가 무제한 네트워크 액세스 권한이 있는 워크스테이션과 동일한 네트워크에 있는 경우 워크스테이션에서 다음 작업을 수행합니다.

      1. 미러 레지스트리에 인증이 필요한 경우 다음 명령을 실행하여 레지스트리에 로그인합니다.

        $ podman login <mirror_registry>
      2. 다음 명령을 실행하여 콘텐츠를 미러링합니다.

        $ oc adm catalog mirror \
            <index_image> \1
            <mirror_registry>:<port>/<namespace> \2
            [-a ${REG_CREDS}] \3
            [--insecure] \4
            [--index-filter-by-os='<platform>/<arch>'] \5
            [--manifests-only] 6
        1
        미러링할 카탈로그의 인덱스 이미지를 지정합니다. 예를 들어 이전에 생성한 정리된 인덱스 이미지 또는 registry.redhat.io/redhat/redhat-operator-index:v4.7과 같은 기본 카탈로그의 소스 인덱스 이미지 중 하나일 수 있습니다.
        2
        Operator 콘텐츠를 미러링할 대상 레지스트리와 네임스페이스를 지정합니다. 여기서 <namespace>는 레지스트리의 기존 네임스페이스입니다. 예를 들어 미러링된 콘텐츠를 모두 내보내기 위해 olm-mirror 네임스페이스를 생성할 수 있습니다.
        3
        선택 사항: 필요한 경우 레지스트리 자격 증명 파일의 위치를 지정합니다.
        4
        선택 사항: 대상 레지스트리에 대한 트러스트를 구성하지 않으려면 --insecure 플래그를 추가합니다.
        5
        선택 사항: 여러 변형이 있을 때 선택할 수 있는 인덱스 이미지의 플랫폼 및 아키텍처를 지정합니다. 이미지는 '<platform>/<arch>[/<variant>]’로 전달됩니다. 이는 인덱스에서 참조하는 이미지에는 적용되지 않습니다. 유효한 값은 linux/amd64, linux/ppc64lelinux/s390x입니다.
        6
        선택 사항: 미러링에 필요한 매니페스트만 생성하고 실제로 이미지 콘텐츠를 레지스트리에 미러링하지 않습니다. 이 선택 사항은 미러링할 항목을 검토하는 데 유용할 수 있으며 패키지의 서브 세트만 필요한 경우 매핑 목록을 변경할 수 있습니다. 그런 다음 oc image mirror 명령과 함께 mapping.txt 파일을 사용하여 이후 단계에서 수정된 이미지 목록을 미러링할 수 있습니다. 이 플래그는 카탈로그에서 콘텐츠의 고급 선택적 미러링에만 사용됩니다. 이전에 인덱스 이미지를 정리하기 위해 사용한 경우 opm index prune 명령은 대부분의 카탈로그 관리 사용 사례에 적합합니다.

        출력 예

        src image has index label for database path: /database/index.db
        using database path mapping: /database/index.db:/tmp/153048078
        wrote database to /tmp/153048078 1
        ...
        wrote mirroring manifests to manifests-redhat-operator-index-1614211642 2

        1
        명령으로 생성된 임시 index.db 데이터베이스용 디렉터리입니다.
        2
        생성된 매니페스트 디렉터리 이름을 기록합니다. 이 디렉터리 이름은 이후 단계에서 사용됩니다.
    • 옵션 B: 미러 레지스트리가 연결 해제된 호스트에 있는 경우 다음 작업을 수행합니다.

      1. 무제한 네트워크 액세스 권한이 있는 워크스테이션에서 다음 명령을 실행하여 콘텐츠를 로컬 파일에 미러링합니다.

        $ oc adm catalog mirror \
            <index_image> \1
            file:///local/index \2
            [-a ${REG_CREDS}] \
            [--insecure]
        1
        미러링할 카탈로그의 인덱스 이미지를 지정합니다. 예를 들어 이전에 생성한 정리된 인덱스 이미지 또는 registry.redhat.io/redhat/redhat-operator-index:v4.7과 같은 기본 카탈로그의 소스 인덱스 이미지 중 하나일 수 있습니다.
        2
        현재 디렉터리의 로컬 파일에 콘텐츠를 미러링합니다.

        출력 예

        ...
        info: Mirroring completed in 5.93s (5.915MB/s)
        wrote mirroring manifests to manifests-my-index-1614985528 1
        
        To upload local images to a registry, run:
        
        	oc adm catalog mirror file://local/index/myrepo/my-index:v1 REGISTRY/REPOSITORY 2

        1
        생성된 매니페스트 디렉터리 이름을 기록합니다. 이 디렉터리 이름은 이후 단계에서 사용됩니다.
        2
        제공된 인덱스 이미지를 기반으로 확장된 file:// 경로를 기록합니다. 이 경로는 이후 단계에서 사용됩니다.
      2. 현재 디렉터리에 생성된 v2/ 디렉터리를 이동식 미디어로 복사합니다.
      3. 물리적으로 미디어를 제거하고 연결이 끊긴 환경의 호스트에 연결하여 미러 레지스트리에 액세스할 수 있습니다.
      4. 미러 레지스트리에 인증이 필요한 경우 연결이 끊긴 환경의 호스트에서 다음 명령을 실행하여 레지스트리에 로그인합니다.

        $ podman login <mirror_registry>
      5. v2/ 디렉터리가 포함된 상위 디렉터리에서 다음 명령을 실행하여 로컬 파일에서 미러 레지스트리로 이미지를 업로드합니다.

        $ oc adm catalog mirror \
            file://local/index/<repo>/<index_image>:<tag> \1
            <mirror_registry>:<port>/<namespace> \2
            [-a ${REG_CREDS}] \
            [--insecure]
        1
        이전 명령 출력의 file:// 경로를 지정합니다.
        2
        Operator 콘텐츠를 미러링할 대상 레지스트리와 네임스페이스를 지정합니다. 여기서 <namespace>는 레지스트리의 기존 네임스페이스입니다. 예를 들어 미러링된 콘텐츠를 모두 내보내기 위해 olm-mirror 네임스페이스를 생성할 수 있습니다.
  3. 콘텐츠를 레지스트리에 미러링한 후 현재 디렉터리에 생성된 매니페스트 디렉터리를 검사합니다.

    참고

    매니페스트 디렉터리 이름은 이후 단계에서 사용됩니다.

    이전 단계에서 동일한 네트워크의 레지스트리에 콘텐츠를 미러링한 경우 디렉터리 이름은 다음 형식을 취합니다.

    manifests-<index_image_name>-<random_number>

    이전 단계에서 연결이 끊긴 호스트의 레지스트리에 콘텐츠를 미러링한 경우 디렉터리 이름은 다음 형식을 취합니다.

    manifests-index/<namespace>/<index_image_name>-<random_number>

    매니페스트 디렉터리에는 다음 파일이 포함되어 있으며, 이 중 일부는 추가 수정이 필요할 수 있습니다.

    • catalogSource.yaml 파일은 인덱스 이미지 태그 및 기타 관련 메타데이터로 미리 채워진 CatalogSource 오브젝트에 대한 기본 정의입니다. 이 파일은 있는 그대로 사용하거나 카탈로그 소스를 클러스터에 추가하도록 수정할 수 있습니다.

      중요

      콘텐츠를 로컬 파일에 미러링한 경우 metadata.name 필드에서 .name 필드에서 백슬래시(/) 문자를 제거하려면 catalogSource.yaml 파일을 수정해야 합니다. 그러지 않으면 오브젝트 생성을 시도할 때 "잘못된 리소스 이름" 오류로 인해 실패합니다.

    • imageContentSourcePolicy.yaml 파일은 Operator 매니페스트에 저장된 이미지 참조와 미러링된 레지스트리 간에 변환하도록 노드를 구성할 수 있는 ImageContentSourcePolicy 오브젝트를 정의합니다.

      참고

      클러스터에서 ImageContentSourcePolicy 오브젝트를 사용하여 저장소 미러링을 구성하는 경우 미러링된 레지스트리에 대한 글로벌 풀 시크릿만 사용할 수 있습니다. 프로젝트에 풀 시크릿을 추가할 수 없습니다.

    • mapping.txt 파일에는 모든 소스 이미지와 대상 레지스트리에서 매핑할 위치가 포함되어 있습니다. 이 파일은 oc image mirror 명령과 호환되며 미러링 구성을 추가로 사용자 정의하는 데 사용할 수 있습니다.

      중요

      미러링 프로세스 중 --manifests-only 플래그를 사용한 후 미러링할 패키지의 서브 세트를 추가로 트리밍하려면 mapping.txt 파일을 수정하고 oc image mirror 명령으로 파일을 사용하는 데 대한 “패키지 매니페스트 형식 카탈로그 이미지 미러링” 절차의 단계를 참조하십시오. 추가 조치를 수행한 후 이 프로세스를 계속할 수 있습니다.

  4. 연결 해제된 클러스터에 액세스할 수 있는 호스트에서 매니페스트 디렉터리에 imageContentSourcePolicy.yaml 파일을 지정하도록 다음 명령을 실행하여 ImageContentSourcePolicy 오브젝트를 생성합니다.

    $ oc create -f <path/to/manifests/dir>/imageContentSourcePolicy.yaml

    여기서 <path/to/manifests/dir>은 미러링된 콘텐츠의 매니페스트 디렉터리 경로입니다.

이제 미러링된 인덱스 이미지 및 Operator 콘텐츠를 참조하도록 CatalogSource 오브젝트를 생성할 수 있습니다.

1.4.2.4. 인덱스 이미지에서 카탈로그 생성

인덱스 이미지에서 Operator 카탈로그를 생성하고 OLM(Operator Lifecycle Manager)과 함께 사용하도록 OpenShift Container Platform 클러스터에 적용할 수 있습니다.

사전 요구 사항

  • 인덱스 이미지를 빌드하여 레지스트리로 내보냈습니다.

프로세스

  1. 인덱스 이미지를 참조하는 CatalogSource 오브젝트를 생성합니다.

    1. 다음을 사양에 맞게 수정하고 catalogsource.yaml 파일로 저장합니다.

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: my-operator-catalog
        namespace: openshift-marketplace
      spec:
        sourceType: grpc
        image: <registry>:<port>/<namespace>/redhat-operator-index:v4.7 <.>
        displayName: My Operator Catalog
        publisher: <publisher_name> <.>
        updateStrategy:
          registryPoll: <.>
            interval: 30m

      <.> 인덱스 이미지를 지정합니다. <.> 카탈로그를 게시하는 이름 또는 조직 이름을 지정합니다. <.> 카탈로그 소스는 새 버전을 자동으로 확인하여 최신 상태를 유지할 수 있습니다.

    2. 파일을 사용하여 CatalogSource 오브젝트를 생성합니다.

      $ oc apply -f catalogSource.yaml
  2. 다음 리소스가 성공적으로 생성되었는지 확인합니다.

    1. Pod를 확인합니다.

      $ oc get pods -n openshift-marketplace

      출력 예

      NAME                                    READY   STATUS    RESTARTS  AGE
      my-operator-catalog-6njx6               1/1     Running   0         28s
      marketplace-operator-d9f549946-96sgr    1/1     Running   0         26h

    2. 카탈로그 소스를 확인합니다.

      $ oc get catalogsource -n openshift-marketplace

      출력 예

      NAME                  DISPLAY               TYPE PUBLISHER  AGE
      my-operator-catalog   My Operator Catalog   grpc            5s

    3. 패키지 매니페스트 확인합니다.

      $ oc get packagemanifest -n openshift-marketplace

      출력 예

      NAME                          CATALOG               AGE
      jaeger-product                My Operator Catalog   93s

이제 OpenShift Container Platform 웹 콘솔의 OperatorHub 페이지에서 Operator를 설치할 수 있습니다.

1.4.2.5. 제한된 환경에서 OpenShift Container Platform 4.7 대상 클러스터에 Migration Toolkit for Containers 설치

OpenShift Container Platform 4.7 대상 클러스터에 MTC(Migration Toolkit for Containers)를 설치할 수 있습니다.

사전 요구 사항

  • 모든 클러스터에서 cluster-admin 권한이 있는 사용자로 로그인합니다.
  • 사용자 정의 Operator 카탈로그를 생성하여 미러 레지스트리로 푸시해야 합니다.
  • 미러 레지스트리에서 Migration Toolkit for Containers Operator를 설치하도록 Operator Lifecycle Manager를 구성해야 합니다.

프로세스

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

    참고

    서브스크립션 승인 옵션을 자동으로 변경하지 마십시오. 소스 및 대상 클러스터에서 Migration Toolkit for Containers 버전이 동일해야 합니다.

  4. 설치를 클릭합니다.

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

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

1.4.2.6. 제한된 환경에서 OpenShift Container Platform 3 소스 클러스터에 Migration Toolkit for Containers 설치

MTC(Migration Toolkit for Containers) Operator 이미지를 기반으로 매니페스트 파일을 만들고 로컬 이미지 레지스트리를 가리키도록 매니페스트를 편집할 수 있습니다. 그런 다음 로컬 이미지를 사용하여 OpenShift Container Platform 3 소스 클러스터에서 Migration Toolkit for Containers Operator를 생성할 수 있습니다.

중요

OpenShift Container Platform 3 및 4 클러스터에 동일한 MTC 버전을 설치해야 합니다.

OpenShift Container Platform 3 클러스터에 최신 버전이 있는지 확인하려면 마이그레이션 계획을 생성하고 실행할 준비가 되었을 때 operator.ymlcontroller-3.yml 파일을 다운로드합니다.

사전 요구 사항

  • 모든 클러스터에서 cluster-admin 권한이 있는 사용자로 로그인합니다.
  • registry.redhat.io에 대한 액세스 권한이 있어야 합니다.
  • podman이 설치되어 있어야 합니다.
  • 소스 클러스터는 OpenShift Container Platform 3.7, 3.9, 3.10 또는 3.11이어야 합니다.
  • 무제한 네트워크 액세스 권한이 있는 Linux 워크스테이션이 있어야 합니다.
  • Docker v2-2를지원하는 미러 레지스트리에 액세스할 수 있어야 합니다.

프로세스

  1. 무제한 네트워크 액세스가 가능한 워크스테이션에서 Red Hat Customer Portal 자격 증명을 사용하여 registry.redhat.io에 로그인합니다.

    $ sudo podman login registry.redhat.io
  2. operator.yml 파일을 다운로드합니다.

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-rhel7-operator:v1.4):/operator.yml ./
  3. controller-3.yml 파일을 다운로드합니다.

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-rhel7-operator:v1.4):/controller-3.yml ./
  4. OpenShift Container Platform 4 클러스터에서 oc adm catalog mirror 를 실행할 때 작성된 mapping.txt 파일에서 Operator 이미지 값을 확보합니다.

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

    출력은 registry.redhat.io 이미지와 미러 레지스트리 이미지 간의 매핑을 보여줍니다.

    출력 예

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

  5. Operator 구성 파일에서 image 및REGISTRY 값을 업데이트합니다.

    containers:
      - name: ansible
        image: <registry.apps.example.com>/rhmtc/openshift-migration-rhel7-operator@sha256:<468a6126f73b1ee12085ca53a312d1f96ef5a2ca03442bcb63724af5e2614e8a> 1
    ...
      - name: operator
        image: <registry.apps.example.com>/rhmtc/openshift-migration-rhel7-operator@sha256:<468a6126f73b1ee12085ca53a312d1f96ef5a2ca03442bcb63724af5e2614e8a> 2
    ...
        env:
        - name: REGISTRY
          value: <registry.apps.example.com> 3
    1
    mapping.txt 파일에 미러 레지스트리와 Operator 이미지의 sha256 값을 지정합니다.
    2
    mapping.txt 파일에 미러 레지스트리와 Operator 이미지의 sha256 값을 지정합니다.
    3
    미러 레지스트리를 지정합니다.
  6. OpenShift Container Platform 3 클러스터에 로그인합니다.
  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 3 이전 버전용 리소스를 생성하기 때문에 발생합니다.
  8. MigrationController 오브젝트를 만듭니다.

    $ oc create -f controller-3.yml
  9. VeleroRestic Pod가 실행 중인지 확인합니다.

    $ oc get pods -n openshift-migration

1.4.3. Migration Toolkit for Containers 업그레이드

OpenShift Container Platform 웹 콘솔을 사용하여 MTC를 업그레이드할 수 있습니다.

중요

동일한 MTC 버전이 모든 클러스터에 설치되어 있는지 확인해야 합니다.

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

1.4.3.1. OpenShift Container Platform 4 클러스터에서 Migration Toolkit for Containers 업그레이드

OpenShift Container Platform 웹 콘솔을 사용하여 OpenShift Container Platform 4 클러스터에서 MTC(Migration Toolkit for Containers)를 업그레이드할 수 있습니다.

사전 요구 사항

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

프로세스

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

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

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

1.4.3.2. OpenShift Container Platform 3 클러스터에서 Migration Toolkit for Containers 업그레이드

podman을 사용하여 OpenShift Container Platform 3 클러스터에서 MTC(Migration Toolkit for Containers)를 업그레이드할 수 있습니다.

사전 요구 사항

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

프로세스

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

    $ sudo podman login registry.redhat.io
  2. 최신 operator.yml 파일을 다운로드합니다.

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-rhel7-operator:v1.4):/operator.yml ./ 1
    1
    필요한 경우 z-stream 릴리스를 지정할 수 있습니다.
  3. Migration Toolkit for Containers Operator를 대체합니다.

    $ oc replace --force -f operator.yml
  4. 변경 사항을 적용합니다.

    • MTC 1.1.2 및 이전 버전의 경우 Restic pod를 삭제합니다.

      $ oc delete pod <restic_pod>
    • MTC 1.2 이상 버전의 경우:

      1. migration-operator 배포를 0으로 확장하여 배포를 중지합니다.

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

        $ oc scale -n openshift-migration --replicas=1 deployment/migration-operator
  5. migration-operator가 업그레이드되었는지 확인합니다.

    $ oc -o yaml -n openshift-migration get deployment/migration-operator | grep image: | awk -F ":" '{ print $NF }'
  6. 최신 controller-3.yml 파일을 다운로드합니다.

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-rhel7-operator:v1.4):/controller-3.yml ./
  7. migration-controller 오브젝트를 만듭니다.

    $ oc create -f controller-3.yml
  8. OpenShift Container Platform 버전이 3.10 이하인 경우 직접 이미지 마이그레이션 및 직접 볼륨 마이그레이션을 활성화하려면 migration-controller 서비스 계정의 보안 컨텍스트 제약 조건을 anyuid로 설정합니다.

    $ oc adm policy add-scc-to-user anyuid -z migration-controller -n openshift-migration
  9. MTC pod가 실행 중인지 확인합니다.

    $ oc get pods -n openshift-migration
  10. 이전에 OpenShift Container Platform 3 클러스터를 MTC 웹 콘솔에 추가한 경우 업그레드 프로세스에서 openshift-migration 네임스페이스를 삭제하고 복원하므로 웹 콘솔에서 서비스 계정 토큰을 업데이트해야 합니다.

    1. 서비스 계정 토큰을 확보합니다.

      $ oc sa get-token migration-controller -n openshift-migration
    2. MTC 웹 콘솔에서 클러스터를 클릭합니다.
    3. 클러스터 kebab 옆에 있는 옵션 메뉴를 클릭하고 편집을 선택합니다.
    4. 서비스 계정 토큰 필드에 새 서비스 계정 토큰을 입력합니다.
    5. 클러스터 업데이트를 클릭한 다음 닫기를 클릭합니다.

1.4.3.3. MTC 1.3을 1.4로 업그레이드

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

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

사전 요구 사항

  • MTC 1.3이 설치되어 있어야 합니다.
  • 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

1.5. 복제 리포지토리에 대한 오브젝트 스토리지 구성

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

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

다음과 같은 스토리지 공급자가 지원됩니다.

제한된 환경에서 내부 호스팅 복제 리포지토리를 만들 수 있습니다.

사전 요구 사항

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

1.5.1. Multi-Cloud Object Gateway 스토리지 버킷을 복제 리포지토리로 구성

OpenShift Container Storage Operator를 설치하고 MCG(Multi-Cloud Object Gateway) 스토리지 버킷을 MTC(Migration Toolkit for Containers)의 복제 리포지토리로 구성할 수 있습니다.

1.5.1.1. OpenShift Container Storage Operator 설치

OperatorHub에서 OpenShift Container Storage Operator를 설치할 수 있습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 OperatorOperatorHub를 클릭합니다.
  2. 키워드로 필터링(이 경우 OCS)을 사용하여 OpenShift Container Storage Operator를 찾습니다.
  3. OpenShift Container Storage Operator를 선택하고 설치를 클릭합니다.
  4. 업데이트 채널, 설치 모드승인 전략을 선택합니다.
  5. 설치를 클릭합니다.

    설치된 운영자 페이지에서 OpenShift Container Storage Operatoropenshift-storage 프로젝트에 Succeeded 상태로 나타납니다.

1.5.1.2. Multi-Cloud Object Gateway 스토리지 버킷 작성

MCG(Multi-Cloud Object Gateway) 스토리지 버킷의 사용자 정의 리소스(CR)를 생성할 수 있습니다.

프로세스

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

    $ oc login -u <username>
  2. 다음과 같은 내용과 함께 NooBaa CR 구성 파일, noobaa.yml을 생성합니다.

    apiVersion: noobaa.io/v1alpha1
    kind: NooBaa
    metadata:
      name: noobaa
      namespace: openshift-storage
    spec:
     dbResources:
       requests:
         cpu: 0.5 1
         memory: 1Gi
     coreResources:
       requests:
         cpu: 0.5 2
         memory: 1Gi
    1 2
    매우 작은 클러스터의 경우 cpu 값을 0.1로 변경할 수 있습니다.
  3. NooBaa 오브젝트를 생성합니다.

    $ oc create -f noobaa.yml
  4. 다음과 같은 내용과 함께 BackingStore CR 구성 파일 bs.yml을 생성합니다.

    apiVersion: noobaa.io/v1alpha1
    kind: BackingStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: mcg-pv-pool-bs
      namespace: openshift-storage
    spec:
      pvPool:
        numVolumes: 3 1
        resources:
          requests:
            storage: 50Gi 2
        storageClass: gp2 3
      type: pv-pool
    1
    영구 볼륨 풀에서 볼륨 수를 지정합니다.
    2
    볼륨의 크기를 지정합니다.
    3
    스토리지 클래스를 지정합니다.
  5. BackingStore 오브젝트를 생성합니다.

    $ oc create -f bs.yml
  6. 다음과 같은 내용으로 BucketClass CR 구성 파일, bc.yml을 생성합니다.

    apiVersion: noobaa.io/v1alpha1
    kind: BucketClass
    metadata:
      labels:
        app: noobaa
      name: mcg-pv-pool-bc
      namespace: openshift-storage
    spec:
      placementPolicy:
        tiers:
        - backingStores:
          - mcg-pv-pool-bs
          placement: Spread
  7. BucketClass 오브젝트를 생성합니다.

    $ oc create -f bc.yml
  8. 다음과 같은 내용과 함께 ObjectBucketClaim CR 구성 파일, obc.yml을 생성합니다.

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: migstorage
      namespace: openshift-storage
    spec:
      bucketName: migstorage 1
      storageClassName: openshift-storage.noobaa.io
      additionalConfig:
        bucketclass: mcg-pv-pool-bc
    1
    MTC 웹 콘솔에 복제 리포지토리를 추가하기 위한 버킷 이름을 기록합니다.
  9. ObjectBucketClaim 오브젝트를 생성합니다.

    $ oc create -f obc.yml
  10. 리소스 생성 프로세스를 보고 ObjectBucketClaim 상태가 Bound인지 확인합니다.

    $ watch -n 30 'oc get -n openshift-storage objectbucketclaim migstorage -o yaml'

    이 프로세스는 5-10분 정도 걸릴 수 있습니다.

  11. MTC 웹 콘솔에 복제 리포지토리를 추가할 때 필요한 다음 값을 확보하고 기록합니다.

    • S3 끝점:

      $ oc get route -n openshift-storage s3
    • S3 공급자 액세스 키:

      $ oc get secret -n openshift-storage migstorage -o go-template='{{ .data.AWS_ACCESS_KEY_ID }}' | base64 --decode
    • S3 공급자 보안 액세스 키:

      $ oc get secret -n openshift-storage migstorage -o go-template='{{ .data.AWS_SECRET_ACCESS_KEY }}' | base64 --decode

1.5.2. AWS S3 스토리지 버킷을 복제 리포지토리로 구성

AWS S3 스토리지 버킷을 MTC(Migration Toolkit for Containers)의 복제 리포지토리로 구성할 수 있습니다.

사전 요구 사항

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

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

프로세스

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

    $ aws s3api create-bucket \
        --bucket <bucket_name> \ 1
        --region <bucket_region> 2
    1
    S3 버킷 이름을 지정합니다.
    2
    S3 버킷 영역을 지정합니다(예: us-east-1).
  2. IAM 사용자 velero를 생성합니다.

    $ aws iam create-user --user-name velero
  3. EC2 EBS 스냅샷 정책을 생성합니다.

    $ cat > velero-ec2-snapshot-policy.json <<EOF
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "ec2:DescribeVolumes",
                    "ec2:DescribeSnapshots",
                    "ec2:CreateTags",
                    "ec2:CreateVolume",
                    "ec2:CreateSnapshot",
                    "ec2:DeleteSnapshot"
                ],
                "Resource": "*"
            }
        ]
    }
    EOF
  4. 하나 또는 모든 S3 버킷에 대한 AWS S3 액세스 정책을 생성합니다.

    $ cat > velero-s3-policy.json <<EOF
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "s3:GetObject",
                    "s3:DeleteObject",
                    "s3:PutObject",
                    "s3:AbortMultipartUpload",
                    "s3:ListMultipartUploadParts"
                ],
                "Resource": [
                    "arn:aws:s3:::<bucket_name>/*" 1
                ]
            },
            {
                "Effect": "Allow",
                "Action": [
                    "s3:ListBucket",
                    "s3:GetBucketLocation",
                    "s3:ListBucketMultipartUploads"
                ],
                "Resource": [
                    "arn:aws:s3:::<bucket_name>" 2
                ]
            }
        ]
    }
    EOF
    1 2
    단일 S3 버킷에 대한 액세스 권한을 부여하려면 버킷 이름을 지정합니다. 모든 AWS S3 버킷에 대한 액세스 권한을 부여하려면 다음 예제와 같이 버킷 이름 대신 *를 지정합니다.

    출력 예

    "Resource": [
        "arn:aws:s3:::*"

  5. EC2 EBS 정책을 velero에 연결합니다.

    $ aws iam put-user-policy \
      --user-name velero \
      --policy-name velero-ebs \
      --policy-document file://velero-ec2-snapshot-policy.json
  6. AWS S3 정책을 velero에 연결합니다.

    $ aws iam put-user-policy \
      --user-name velero \
      --policy-name velero-s3 \
      --policy-document file://velero-s3-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>, 1
            "AccessKeyId": <AWS_ACCESS_KEY_ID> 2
        }
    }
    1 2
    MTC 웹 콘솔에 AWS 리포지토리를 추가하기 위해 AWS_SECRET_ACCESS_KEYAWS_ACCESS_KEY_ID를 기록합니다.

1.5.3. Google Cloud Provider 스토리지 버킷을 복제 리포지토리로 구성

GCP(Google Cloud Provider) 스토리지 버킷을 MTC(Migration Toolkit for Containers)의 복제 리포지토리로 구성할 수 있습니다.

사전 요구 사항

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

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

프로세스

  1. gsutil에 로그인합니다.

    $ gsutil init

    출력 예

    Welcome! This command will take you through the configuration of gcloud.
    
    Your current configuration has been set to: [default]
    
    To continue, you must login. Would you like to login (Y/n)?

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

    $ BUCKET=<bucket_name> 1
    1
    버킷 이름을 지정합니다.
  3. 스토리지 버킷을 생성합니다.

    $ gsutil mb gs://$BUCKET/
  4. PROJECT_ID 변수를 활성 프로젝트로 설정합니다.

    $ PROJECT_ID=`gcloud config get-value project`
  5. Velero IAM 서비스 계정을 생성합니다.

    $ gcloud iam service-accounts create velero \
        --display-name "Velero Storage"
  6. SERVICE_ACCOUNT_EMAIL 변수를 생성합니다.

    $ SERVICE_ACCOUNT_EMAIL=`gcloud iam service-accounts list \
      --filter="displayName:Velero Storage" \
      --format 'value(email)'`
  7. ROLE_PERMISSIONS 변수를 생성합니다.

    $ 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
    )
  8. velero.server 사용자 정의 역할을 생성합니다.

    $ gcloud iam roles create velero.server \
        --project $PROJECT_ID \
        --title "Velero Server" \
        --permissions "$(IFS=","; echo "${ROLE_PERMISSIONS[*]}")"
  9. 프로젝트에 IAM 정책 바인딩을 추가합니다.

    $ gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member serviceAccount:$SERVICE_ACCOUNT_EMAIL \
        --role projects/$PROJECT_ID/roles/velero.server
  10. IAM 서비스 계정을 업데이트합니다.

    $ gsutil iam ch serviceAccount:$SERVICE_ACCOUNT_EMAIL:objectAdmin gs://${BUCKET}
  11. IAM 서비스 계정 키를 현재 디렉터리의 credentials-velero 파일에 저장합니다.

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

1.5.4. Microsoft Azure Blob 스토리지 컨테이너를 복제 리포지토리로 구성

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

사전 요구 사항

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

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

프로세스

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

    $ AZURE_RESOURCE_GROUP=Velero_Backups
  2. Azure 리소스 그룹을 생성합니다.

    $ az group create -n $AZURE_RESOURCE_GROUP --location <CentralUS> 1
    1
    위치를 지정합니다.
  3. AZURE_STORAGE_ACCOUNT_ID 변수를 설정합니다.

    $ AZURE_STORAGE_ACCOUNT_ID=velerobackups
  4. 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
  5. BLOB_CONTAINER 변수를 설정합니다.

    $ BLOB_CONTAINER=velero
  6. Azure Blob 스토리지 컨테이너를 생성합니다.

    $ az storage container create \
      -n $BLOB_CONTAINER \
      --public-access off \
      --account-name $AZURE_STORAGE_ACCOUNT_ID
  7. 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`
  8. 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

1.6. 애플리케이션 마이그레이션

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

1.6.1. 사전 요구 사항

MTC(Migration Toolkit for Containers)에는 다음과 같은 사전 요구 사항이 있습니다.

  • 모든 클러스터에서 cluster-admin 권한이 있는 사용자로 로그인합니다.
  • MTC 버전은 모든 클러스터에서 동일해야 합니다.
  • 애플리케이션이 openshift 네임스페이스의 이미지를 사용하는 경우 필요한 이미지 버전이 대상 클러스터에 있는지 확인해야 합니다.

    OpenShift Container Platform 4.7 클러스터에서 더 이상 사용되지 않는 OpenShift Container Platform 3 이미지를 사용하도록 이미지 스트림 태그를 수동으로 업데이트할 수 있습니다.

  • 클러스터:

    • 소스 클러스터를 최신 MTC z-stream 릴리스로 업그레이드해야 합니다.
    • migration-controller pod가 실행 중인 클러스터는 다른 클러스터에 대한 무제한 액세스 권한이 있어야 합니다.
    • 클러스터는 서로에 대한 무제한 네트워크 액세스 권한이 있어야 합니다.
    • 클러스터에 복제 리포지토리에 대한 무제한 네트워크 액세스 권한이 있어야 합니다.
    • 클러스터는 포트 443에서 OpenShift 경로를 사용하여 통신할 수 있어야 합니다.
    • 클러스터에는 중요한 조건이 없어야 합니다.
    • 클러스터가 준비 상태여야 합니다.
  • 볼륨 마이그레이션:

    • PV(영구 볼륨)가 유효해야 합니다.
    • PV를 영구 볼륨 클레임에 바인딩해야 합니다.
    • 이동 방법을 사용하여 PV를 복사하는 경우 클러스터에 원격 볼륨에 대한 무제한 액세스 권한이 있어야 합니다.
    • 스냅샷 복사 방법을 사용하여 PV를 복사하는 경우 다음 사전 요구 사항이 적용됩니다.

      • 클라우드 공급자는 스냅샷을 지원해야 합니다.
      • 볼륨에는 동일한 클라우드 프로바이더가 있어야 합니다.
      • 볼륨은 동일한 지리적 지역에 있어야 합니다.
      • 볼륨에는 동일한 스토리지 클래스가 있어야 합니다.
  • 프록시 환경에서 직접 볼륨 마이그레이션을 수행하는 경우 Stunnel TCP 프록시를 구성해야 합니다.
  • 직접 이미지 마이그레이션을 수행하는 경우 소스 클러스터의 내부 레지스트리를 외부 트래픽에 노출해야 합니다.

1.6.1.1. podman으로 더 이상 사용되지 않는 내부 이미지 업데이트

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

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

사전 요구 사항

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

프로세스

  1. 소스 및 대상 클러스터에 내부 레지스트리를 노출합니다.
  2. 비보안 레지스트리를 사용하는 경우 /etc/container/registries.conf[registries.insecure] 섹션에 레지스트리 호스트 값을 추가하여 Podman TLS 확인 오류가 발생하지 않도록 합니다.
  3. 소스 클러스터 레지스트리에 로그인합니다.

    $ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false <source_cluster>
  4. 대상 클러스터 레지스트리에 로그인합니다.

    $ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false <target_cluster>
  5. 더 이상 사용되지 않는 이미지를 가져옵니다.

    $ podman pull <source_cluster>/openshift/<image>
  6. 대상 클러스터 레지스트리의 이미지를 태그합니다.

    $ podman tag <source_cluster>/openshift/<image> <target_cluster>/openshift/<image>
  7. 대상 클러스터 4 레지스트리로 이미지를 푸시합니다.

    $ podman push <target_cluster>/openshift/<image>
  8. 이미지에 대상 클러스터에 유효한 이미지 스트림이 있는지 확인합니다.

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

    출력 예

    <image>    <target_cluster>/openshift/<image>     <versions>
    more...      6 seconds ago

1.6.1.2. CA 인증서 번들 파일 생성

자체 서명된 인증서를 사용하여 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 번들 파일의 이름을 지정합니다.

1.6.1.3. 직접 볼륨 마이그레이션을 위한 프록시 구성

프록시 뒤에서 소스 클러스터에서 직접 볼륨 마이그레이션을 수행하는 경우 MigrationController 사용자 정의 리소스(CR)에서 Stunnel 프록시를 구성해야 합니다. Stunnel은 인증서를 변경하지 않고 TCP 연결을 위해 소스 클러스터와 대상 클러스터 간에 투명 터널을 생성합니다.

참고

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

사전 요구 사항

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

프로세스

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

    $ oc get migrationcontroller <migration_controller> -n openshift-migration
  3. stunnel_tcp_proxy 매개변수를 추가합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigrationController
    metadata:
      name: migration-controller
      namespace: openshift-migration
    ...
    spec:
      stunnel_tcp_proxy: <stunnel_proxy> 1
    1
    Stunnel 프록시를 지정합니다. http://<user_name>:<password>@<ip_address>:<port>
  4. 매니페스트를 migration-controller.yaml로 저장합니다.
  5. 업데이트된 매니페스트를 적용합니다.

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

1.6.1.4. 마이그레이션 후크의 Ansible 플레이북 작성

마이그레이션 후크로 사용할 Ansible 플레이북을 작성할 수 있습니다. MTC 웹 콘솔을 사용하거나 MigPlan 사용자 정의 리소스(CR) 매니페스트에서 spec.hooks 매개변수의 값을 지정하여 후크가 마이그레이션 계획에 추가됩니다.

Ansible 플레이북은 후크 컨테이너에 구성 맵으로 마운트됩니다. 후크 컨테이너는 MigPlan CR에 지정된 클러스터, 서비스 계정 및 네임스페이스를 사용하여 작업으로 실행됩니다. 후크 컨테이너는 클러스터에서 실행되기 전에 작업에 인증이 필요하지 않도록 지정된 서비스 계정 토큰을 사용합니다.

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

1.6.1.4.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', 'migplan_name') }}"

1.6.1.5. 추가 리소스

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

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

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

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

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

사전 요구 사항

  • Azure 스냅샷을 사용하여 데이터를 복사하는 경우:

    • 클러스터의 Azure 리소스 그룹 이름을 지정해야 합니다.
    • 클러스터는 동일한 Azure 리소스 그룹에 있어야 합니다.
    • 클러스터는 동일한 지역 위치에 있어야 합니다.

프로세스

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

    $ oc sa get-token migration-controller -n openshift-migration
    eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJtaWciLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoibWlnLXRva2VuLWs4dDJyIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6Im1pZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImE1YjFiYWMwLWMxYmYtMTFlOS05Y2NiLTAyOWRmODYwYjMwOCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDptaWc6bWlnIn0.xqeeAINK7UXpdRqAtOj70qhBJPeMwmgLomV9iFxr5RoqUgKchZRG2J2rkqmPm6vr7K-cm7ibD1IBpdQJCcVDuoHYsFgV4mp9vgOfn9osSDp2TGikwNz4Az95e81xnjVUmzh-NjDsEpw71DH92iHV_xt2sTwtzftS49LpPW2LjrV0evtNBP_t_RfskdArt5VSv25eORl7zScqfe1CiMkcVbf2UqACQjo3LbkpfN26HAioO2oH0ECPiRzT0Xyh-KwFutJLS9Xgghyw-LD9kPKcE_xbbJ9Y4Rqajh7WdPYuB0Jd9DPVrslmzK-F6cgHHYoZEv0SvLQi-PO0rpDrcjOEQQ
  3. MTC 웹 콘솔에서 클러스터를 클릭합니다.
  4. 클러스터 추가를 클릭합니다.
  5. 다음 필드를 작성합니다.

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

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

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

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

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

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

사전 요구 사항

  • 데이터를 마이그레이션하기 위해 오브젝트 스토리지 버킷을 구성해야 합니다.

프로세스

  1. MTC 웹 콘솔에서 복제 리포지토리를 클릭합니다.
  2. 리포지토리 추가를 클릭합니다.
  3. 스토리지 공급자 유형을 선택하고 다음 필드를 작성합니다.

    • AWS S3, MCG 및 일반 S3 공급자용 AWS:

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

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

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

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

1.6.2.4. MTC 웹 콘솔에서 마이그레이션 계획 생성

MTC(Migration Toolkit for Containers) 웹 콘솔에서 마이그레이션 계획을 생성할 수 있습니다.

사전 요구 사항

  • 모든 클러스터에서 cluster-admin 권한이 있는 사용자로 로그인합니다.
  • 동일한 MTC 버전이 모든 클러스터에 설치되어 있는지 확인해야 합니다.
  • MTC 웹 콘솔에 클러스터와 복제 리포지토리를 추가해야 합니다.
  • 이동 데이터 복사 방법을 사용하여 PV(영구 볼륨)를 마이그레이션하려면 소스 및 대상 클러스터에 원격 볼륨에 대한 중단되지 않은 네트워크 액세스가 있어야 합니다.
  • 직접 이미지 마이그레이션을 사용하려면 소스 클러스터의 MigCluster 사용자 정의 리소스 매니페스트에서 내부 이미지 레지스트리의 노출된 경로를 지정해야 합니다.

프로세스

  1. MTC 웹 콘솔에서 마이그레이션 계획을 클릭합니다.
  2. 마이그레이션 계획 추가를 클릭합니다.
  3. 계획 이름을 입력하고 다음 클릭합니다.

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

  4. 소스 클러스터를 선택합니다.
  5. 대상 클러스터를 선택합니다.
  6. 복제 리포지토리를 선택합니다.
  7. 마이그레이션할 프로젝트를 선택하고 다음을 클릭합니다.
  8. 소스 클러스터, 대상 클러스터, 리포지토리를 선택하고 다음을 클릭합니다.
  9. 네임스페이스 페이지에서 마이그레이션할 프로젝트를 선택하고 다음을 클릭합니다.
  10. 영구 볼륨 페이지에서 각 PV의 마이그레이션 유형을 클릭합니다.

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

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

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

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

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

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

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

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

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

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

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

    5. 소스 클러스터 또는 대상 클러스터를 선택합니다.
    6. 서비스 계정 이름서비스 계정 네임스페이스를 입력합니다.
    7. 후크의 마이그레이션 단계를 선택합니다.

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

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

1.6.2.5. MTC 웹 콘솔에서 마이그레이션 계획 실행

MTC(Migration Toolkit for Containers) 웹 콘솔에서 생성한 마이그레이션 계획을 사용하여 애플리케이션 및 데이터를 준비하거나 마이그레이션할 수 있습니다.

참고

마이그레이션 프로세스 중에 MTC는 마이그레이션된 PV(영구 볼륨)의 회수 정책을 대상 클러스터에서 Retain으로 설정합니다.

Backup 사용자 정의 리소스에는 원래 회수 정책을 나타내는 PVOriginalReclaimPolicy 주석이 포함되어 있습니다. 마이그레이션된 PV의 회수 정책을 수동으로 복원할 수 있습니다.

사전 요구 사항

MTC 웹 콘솔에는 다음이 포함되어야 합니다.

  • Ready 상태의 소스 클러스터
  • Ready 상태의 대상 클러스터
  • 복제 리포지토리
  • 유효한 마이그레이션 계획

프로세스

  1. 소스 클러스터에 로그인합니다.
  2. 오래된 이미지 삭제:

    $ oc adm prune images
  3. MTC 웹 콘솔에 로그인하고 마이그레이션 계획을 클릭합니다.
  4. 마이그레이션 계획 옆에 있는 옵션 메뉴 kebab 를 클릭하고 단계를 선택하여 애플리케이션을 중지하지 않고 소스 클러스터에서 대상 클러스터로 데이터를 복사합니다.

    실제 마이그레이션 시간을 줄이기 위해 단계를 여러 번 실행할 수 있습니다.

  5. 애플리케이션 워크로드를 마이그레이션할 준비가 되었으면 마이그레이션 계획 이외의 옵션 메뉴 kebab마이그레이션을 선택합니다.
  6. 선택 사항: 마이그레이션 창에서 마이그레이션 중에 소스 클러스터에서 애플리케이션을 중지하지 않음을 선택할 수 있습니다.
  7. 마이그레이션을 클릭합니다.
  8. 마이그레이션이 완료되면 OpenShift Container Platform 웹 콘솔에서 애플리케이션이 성공적으로 마이그레이션되었는지 확인합니다.

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

1.6.3. 명령줄에서 애플리케이션 마이그레이션

MTC 사용자 정의 리소스(CR)를 사용하여 명령줄에서 애플리케이션을 마이그레이션할 수 있습니다.

로컬 클러스터에서 원격 클러스터, 원격 클러스터에서 로컬 클러스터, 원격 클러스터, 원격 클러스터 간에 애플리케이션을 마이그레이션할 수 있습니다.

MTC 용어

다음 용어는 클러스터 구성과 관련이 있습니다.

  • host 클러스터:

    • migration-controller 포드는 host 클러스터에서 실행됩니다.
    • host 클러스터에 직접 이미지 마이그레이션을 위해 노출된 보안 레지스트리 경로가 필요하지 않습니다.
  • 로컬 클러스터: 로컬 클러스터는 host 클러스터와 자주 동일하지만 필수 클러스터는 아닙니다.
  • 원격 클러스터:

    • 원격 클러스터에 직접 이미지 마이그레이션을 위해 노출된 보안 레지스트리 경로를 보유해야 합니다.
    • 원격 클러스터에 migration-controller 서비스 계정 토큰이 포함된 Secret CR이 있어야 합니다.

다음 용어는 마이그레이션 수행과 관련이 있습니다.

  • 소스 클러스터: 애플리케이션을 마이그레이션하는 클러스터입니다.
  • 대상 클러스터: 애플리케이션이 마이그레이션되는 클러스터입니다.

1.6.3.1. Migration Toolkit for Containers API를 사용하여 애플리케이션 마이그레이션

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

로컬 클러스터에서 원격 클러스터, 원격 클러스터에서 로컬 클러스터, 원격 클러스터, 원격 클러스터 간에 애플리케이션을 마이그레이션할 수 있습니다.

다음 프로세스에서는 간접 마이그레이션 및 직접 마이그레이션을 수행하는 방법을 설명합니다.

  • 간접 마이그레이션: 이미지, 볼륨 및 Kubernetes 오브젝트는 소스 클러스터에서 복제 리포지토리로 복사한 다음 복제 리포지토리에서 대상 클러스터로 복사됩니다.
  • 직접 마이그레이션: 소스 클러스터에서 대상 클러스터로 직접 이미지 또는 볼륨이 복사됩니다. 직접 이미지 마이그레이션 및 직접 볼륨 마이그레이션은 성능에 큰 이점이 있습니다.

다음 사용자 정의 리소스(CR)를 생성하여 마이그레이션을 수행합니다.

  • MigCluster CR: host, 로컬 또는 원격 클러스터를 정의합니다.

    migration-controller 포드는 host 클러스터에서 실행됩니다.

  • Secret CR: 원격 클러스터 또는 스토리지에 대한 인증 정보를 포함합니다.
  • MigStorage CR: 복제 리포지토리를 정의합니다.

    스토리지 공급자마다 MigStorage CR 매니페스트의 다른 매개변수가 필요합니다.

  • MigPlan CR: 마이그레이션 계획을 정의합니다.
  • MigMigration CR: 연결된 MigPlan에 정의된 마이그레이션을 수행합니다.

    다음과 같은 목적으로 단일 MigPlan CR에 대해 여러 MigMigration CR을 생성할 수 있습니다.

  • 단계 마이그레이션을 수행하려면 마이그레이션을 실행하기 전에 애플리케이션을 중지하지 않고 대부분의 데이터를 복사합니다. 단계별 마이그레이션은 마이그레이션의 성능을 향상시킵니다.
  • 진행 중인 마이그레이션을 취소하려면
  • 완료된 마이그레이션을 롤백하려면

사전 요구 사항

  • 모든 클러스터에 대한 cluster-admin 권한이 있어야 합니다.
  • OpenShift Container Platform CLI(oc)를 설치해야 합니다.
  • 모든 클러스터에 Migration Toolkit for Containers Operator를 설치해야 합니다.
  • 모든 클러스터에서 설치된 Migration Toolkit for Containers Operator 버전이 동일해야 합니다.
  • 복제 리포지토리로 오브젝트 스토리지를 구성해야 합니다.
  • 직접 이미지 마이그레이션을 사용하는 경우 모든 원격 클러스터에 보안 레지스트리 경로를 노출해야 합니다.
  • 직접 볼륨 마이그레이션을 사용하는 경우 소스 클러스터에 HTTP 프록시가 구성되어 있지 않아야 합니다.

프로세스

  1. host-cluster.yaml이라는 host 클러스터에 대한 MigCluster CR 매니페스트를 생성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigCluster
    metadata:
      name: host
      namespace: openshift-migration
    spec:
      isHostCluster: true
  2. host 클러스터에 대한 MigCluster CR을 생성합니다.

    $ oc create -f host-cluster.yaml -n openshift-migration
  3. cluster-secret.yaml이라는 각 원격 클러스터에 대한 Secret CR 매니페스트를 생성합니다.

    apiVersion: v1
    kind: Secret
    metadata:
      name: <cluster_secret>
      namespace: openshift-config
    type: Opaque
    data:
      saToken: <sa_token> 1
    1
    원격 클러스터의 base64로 인코딩된 migration-controller 서비스 계정(SA) 토큰을 지정합니다.

    다음 명령을 실행하여 SA 토큰을 확보할 수 있습니다.

    $ oc sa get-token migration-controller -n openshift-migration | base64 -w 0
  4. 각 원격 클러스터에 대한 Secret CR을 생성합니다.

    $ oc create -f cluster-secret.yaml
  5. remote-cluster.yaml이라는 각 원격 클러스터에 대해 MigCluster CR 매니페스트를 생성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigCluster
    metadata:
      name: <remote_cluster>
      namespace: openshift-migration
    spec:
      exposedRegistryPath: <exposed_registry_route> 1
      insecure: false 2
      isHostCluster: false
      serviceAccountSecretRef:
        name: <remote_cluster_secret> 3
        namespace: openshift-config
      url: <remote_cluster_url> 4
    1
    선택 사항: 직접 이미지 마이그레이션을 사용하는 경우 노출된 레지스트리 경로를 지정합니다(예: docker-registry-default.apps.example.com).
    2
    false인 경우 SSL 확인이 활성화됩니다. CA 인증서가 필요하지 않거나 true인 경우 확인되지 않습니다.
    3
    원격 클러스터의 Secret CR을 지정합니다.
    4
    원격 클러스터의 URL을 지정합니다.
  6. 각 원격 클러스터에 대해 MigCluster CR을 생성합니다.

    $ oc create -f remote-cluster.yaml -n openshift-migration
  7. 모든 클러스터가 Ready 상태에 있는지 확인합니다.

    $ oc describe cluster <cluster_name>
  8. storage-secret.yaml이라는 복제 리포지토리의 Secret CR 매니페스트를 생성합니다.

    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
    1
    base64 형식으로 키 ID를 지정합니다.
    2
    base64 형식으로 시크릿 키를 지정합니다.

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

    $ echo -n "<key>" | base64 -w 0 1
    1
    키 ID 또는 시크릿 키를 지정합니다. 두 키 모두 base64로 인코딩되어야 합니다.
  9. 복제 리포지토리에 대한 Secret CR을 생성합니다.

    $ oc create -f storage-secret.yaml
  10. migstorage.yaml이라는 복제 리포지토리에 대한 MigStorage CR 매니페스트를 생성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigStorage
    metadata:
      name: <storage_name>
      namespace: openshift-migration
    spec:
      backupStorageConfig:
        awsBucketName: <bucket_name> 1
        credsSecretRef:
          name: <storage_secret_ref> 2
          namespace: openshift-config
      backupStorageProvider: <storage_provider_name> 3
      volumeSnapshotConfig:
        credsSecretRef:
          name: <storage_secret_ref> 4
          namespace: openshift-config
      volumeSnapshotProvider: <storage_provider_name> 5
    1
    버킷 이름을 지정합니다.
    2
    오브젝트 스토리지의 Secrets CR을 지정합니다. 오브젝트 스토리지의 Secrets CR에 저장된 인증 정보가 올바른지 확인해야 합니다.
    3
    스토리지 공급자를 지정합니다.
    4
    선택 사항: 스냅샷을 사용하여 데이터를 복사하는 경우 오브젝트 스토리지의 Secrets CR을 지정합니다. 오브젝트 스토리지의 Secrets CR에 저장된 인증 정보가 올바른지 확인해야 합니다.
    5
    선택 사항: 스냅샷을 사용하여 데이터를 복사하는 경우 스토리지 공급자를 지정합니다.
  11. MigStorage CR을 생성합니다.

    $ oc create -f migstorage.yaml -n openshift-migration
  12. MigStorage CR이 Ready 상태에 있는지 확인합니다.

    $ oc describe migstorage <migstorage_name>
  13. migplan.yaml이라는 MigPlan CR 매니페스트를 생성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigPlan
    metadata:
      name: <migration_plan>
      namespace: openshift-migration
    spec:
      destMigClusterRef:
        name: host
        namespace: openshift-migration
      indirectImageMigration: true 1
      indirectVolumeMigration: true 2
      migStorageRef:
        name: <migstorage_ref> 3
        namespace: openshift-migration
      namespaces:
        - <application_namespace> 4
      srcMigClusterRef:
        name: <remote_cluster_ref> 5
        namespace: openshift-migration
    1
    false인 경우 직접 이미지 마이그레이션이 활성화됩니다.
    2
    false인 경우 직접 볼륨 마이그레이션이 활성화됩니다.
    3
    MigStorage CR 인스턴스의 이름을 지정합니다.
    4
    마이그레이션할 하나 이상의 네임스페이스를 지정합니다.
    5
    소스 클러스터 MigCluster 인스턴스의 이름을 지정합니다.
  14. MigPlan CR을 만듭니다.

    $ oc create -f migplan.yaml -n openshift-migration
  15. MigPlan 인스턴스를 보고 Ready 상태인지 확인합니다.

    $ oc describe migplan <migplan_name> -n openshift-migration
  16. migmigration.yaml이라는 MigMigration CR 매니페스트를 생성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      name: <migmigration_name>
      namespace: openshift-migration
    spec:
      migPlanRef:
        name: <migplan_name> 1
        namespace: openshift-migration
      quiescePods: true 2
      stage: false 3
      rollback: false 4
    1
    MigPlan CR 이름을 지정합니다.
    2
    true인 경우 마이그레이션 전에 소스 클러스터의 포드가 중지됩니다.
    3
    애플리케이션을 중지하지 않고 대부분의 데이터를 복사하는 단계 마이그레이션이 true인 경우 수행됩니다.
    4
    true인 경우 완료된 마이그레이션이 롤백됩니다.
  17. MigPlan CR에 정의된 마이그레이션을 시작하도록 MigMigration CR을 생성합니다.

    $ oc create -f migmigration.yaml -n openshift-migration
  18. MigMigration CR을 확인하여 마이그레이션 진행 상황을 확인합니다.

    $ oc watch migmigration <migmigration_name> -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:       my_application
        Namespace:  openshift-migration
      Stage:        false
    Status:
      Conditions:
        Category:              Advisory
        Last Transition Time:  2021-02-02T15:04:09Z
        Message:               Step: 19/47
        Reason:                InitialBackupCreated
        Status:                True
        Type:                  Running
        Category:              Required
        Last Transition Time:  2021-02-02T15:03:19Z
        Message:               The migration is ready.
        Status:                True
        Type:                  Ready
        Category:              Required
        Durable:               true
        Last Transition Time:  2021-02-02T15:04:05Z
        Message:               The migration registries are healthy.
        Status:                True
        Type:                  RegistriesHealthy
      Itinerary:               Final
      Observed Digest:         7fae9d21f15979c71ddc7dd075cb97061895caac5b936d92fae967019ab616d5
      Phase:                   InitialBackupCreated
      Pipeline:
        Completed:  2021-02-02T15:04:07Z
        Message:    Completed
        Name:       Prepare
        Started:    2021-02-02T15:03:18Z
        Message:    Waiting for initial Velero backup to complete.
        Name:       Backup
        Phase:      InitialBackupCreated
        Progress:
          Backup openshift-migration/c8b034c0-6567-11eb-9a4f-0bc004db0fbc-wpc44: 0 out of estimated total of 0 objects backed up (5s)
        Started:        2021-02-02T15:04:07Z
        Message:        Not started
        Name:           StageBackup
        Message:        Not started
        Name:           StageRestore
        Message:        Not started
        Name:           DirectImage
        Message:        Not started
        Name:           DirectVolume
        Message:        Not started
        Name:           Restore
        Message:        Not started
        Name:           Cleanup
      Start Timestamp:  2021-02-02T15:03:18Z
    Events:
      Type    Reason   Age                 From                     Message
      ----    ------   ----                ----                     -------
      Normal  Running  57s                 migmigration_controller  Step: 2/47
      Normal  Running  57s                 migmigration_controller  Step: 3/47
      Normal  Running  57s (x3 over 57s)   migmigration_controller  Step: 4/47
      Normal  Running  54s                 migmigration_controller  Step: 5/47
      Normal  Running  54s                 migmigration_controller  Step: 6/47
      Normal  Running  52s (x2 over 53s)   migmigration_controller  Step: 7/47
      Normal  Running  51s (x2 over 51s)   migmigration_controller  Step: 8/47
      Normal  Ready    50s (x12 over 57s)  migmigration_controller  The migration is ready.
      Normal  Running  50s                 migmigration_controller  Step: 9/47
      Normal  Running  50s                 migmigration_controller  Step: 10/47

1.6.3.2. MTC 사용자 정의 리소스 매니페스트

MTC(Migration Toolkit for Containers)는 다음 사용자 정의 리소스(CR) 매니페스트를 사용하여 애플리케이션 마이그레이션을 위한 CR을 생성합니다.

1.6.3.2.1. DirectImageMigration

DirectImageMigration CR은 소스 클러스터에서 대상 클러스터로 이미지를 직접 복사합니다.

apiVersion: migration.openshift.io/v1alpha1
kind: DirectImageMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <directimagemigration_name>
spec:
  srcMigClusterRef:
    name: <source_cluster_ref> 1
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster_ref> 2
    namespace: openshift-migration
  namespaces:
  - <namespace> 3
1
소스 클러스터의 MigCluster CR 이름을 지정합니다.
2
대상 클러스터의 MigCluster CR 이름을 지정합니다.
3
마이그레이션할 이미지를 포함하는 하나 이상의 네임스페이스를 지정합니다.
1.6.3.2.2. DirectImageStreamMigration

DirectImageStreamMigration CR은 소스 클러스터에서 대상 클러스터로 직접 이미지 스트림 참조를 복사합니다.

apiVersion: migration.openshift.io/v1alpha1
kind: DirectImageStreamMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: directimagestreammigration_name
spec:
  srcMigClusterRef:
    name: <source_cluster_ref> 1
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster_ref> 2
    namespace: openshift-migration
  imageStreamRef:
    name: <image_stream_name> 3
    namespace: <source_image_stream_namespace> 4
  destNamespace: <destination_image_stream_namespace> 5
1
소스 클러스터의 MigCluster CR 이름을 지정합니다.
2
대상 클러스터의 MigCluster CR 이름을 지정합니다.
3
이미지 스트림 이름을 지정합니다.
4
소스 클러스터에서 이미지 스트림 네임스페이스를 지정합니다.
5
대상 클러스터에서 이미지 스트림 네임스페이스를 지정합니다.
1.6.3.2.3. DirectVolumeMigration

DirectVolumeMigration CR은 소스 클러스터에서 대상 클러스터로 직접 PV(영구 볼륨)를 복사합니다.

apiVersion: migration.openshift.io/v1alpha1
kind: DirectVolumeMigration
metadata:
  name: <directvolumemigration_name>
  namespace: openshift-migration
spec:
  createDestinationNamespaces: false 1
  deleteProgressReportingCRs: false 2
  destMigClusterRef:
    name: host 3
    namespace: openshift-migration
  persistentVolumeClaims:
  - name: <pvc_name> 4
    namespace: <pvc_namespace> 5
  srcMigClusterRef:
    name: <source_cluster_ref> 6
    namespace: openshift-migration
1
true인 경우 대상 클러스터의 PV에 네임스페이스가 생성됩니다.
2
DirectVolumeMigrationProgress CR은 true인 경우 마이그레이션 후 삭제됩니다. 문제 해결을 위해 DirectVolumeMigrationProgress CR이 유지되기 위한 기본값은 false입니다.
3
대상 클러스터가 호스트 클러스터가 아닌 경우 클러스터 이름을 업데이트합니다.
4
직접 볼륨 마이그레이션을 사용하여 마이그레이션할 하나 이상의 PVC를 지정합니다.
5
각 PVC의 네임스페이스를 지정합니다.
6
소스 클러스터의 MigCluster CR 이름을 지정합니다.
1.6.3.2.4. DirectVolumeMigrationProgress

DirectVolumeMigrationProgress CR은 DirectVolumeMigration CR의 진행 상황을 보여줍니다.

apiVersion: migration.openshift.io/v1alpha1
kind: DirectVolumeMigrationProgress
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: directvolumemigrationprogress_name
spec:
  clusterRef:
    name: source_cluster
    namespace: openshift-migration
  podRef:
    name: rsync_pod
    namespace: openshift-migration
1.6.3.2.5. MigAnalytic

MigAnalytic CR은 이미지 수, Kubernetes 리소스 및 관련 MigPlan CR에서 PV 용량을 수집합니다.

apiVersion: migration.openshift.io/v1alpha1
kind: MigAnalytic
metadata:
  annotations:
    migplan: <migplan_name> 1
  name: miganalytic_name
  namespace: openshift-migration
  labels:
    migplan: <migplan_name> 2
spec:
  analyzeImageCount: true 3
  analyzeK8SResources: true 4
  analyzePVCapacity: true 5
  listImages: false 6
  listImagesLimit: 50 7
  migPlanRef:
    name: migplan_name 8
    namespace: openshift-migration
1
MigAnalytic CR과 연관된 MigPlan CR 이름을 지정합니다.
2
MigAnalytic CR과 연관된 MigPlan CR 이름을 지정합니다.
3
선택 사항: true인 경우 이미지 수가 반환됩니다.
4
선택 사항: true인 경우 Kubernetes 리소스의 수, 종류 및 API 버전을 반환합니다.
5
선택 사항: true인 경우 PV 용량을 반환합니다.
6
true인 경우 이미지 이름 목록을 반환합니다. 출력이 과도하게 길지 않도록 기본값은 false입니다.
7
선택 사항: listImagestrue인 경우 최대 이미지 이름 수를 지정합니다.
8
MigAnalytic CR과 연관된 MigPlan CR 이름을 지정합니다.
1.6.3.2.6. MigCluster

MigCluster CR은 호스트, 로컬 또는 원격 클러스터를 정의합니다.

apiVersion: migration.openshift.io/v1alpha1
kind: MigCluster
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: host 1
  namespace: openshift-migration
spec:
  isHostCluster: true 2
  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.
# isHostCluster: false
# exposedRegistryPath: 8
# url: <destination_cluster_url> 9
# serviceAccountSecretRef:
#   name: <source_secret_ref> 10
#   namespace: openshift-config
1
선택 사항: migration-controller 포드가 이 클러스터에서 실행되지 않는 경우 클러스터 이름을 업데이트합니다.
2
migration-controller 포드는 true인 경우 이 클러스터에서 실행됩니다.
3
선택 사항: 스토리지 공급자가 Microsoft Azure인 경우 리소스 그룹을 지정합니다.
4
선택 사항: 자체 서명된 CA 인증서에 대한 인증서 번들을 생성하고 insecure 매개변수 값이 false인 경우 base64 인코딩 인증서 번들을 지정합니다.
5
false인 경우 SSL 확인이 활성화됩니다.
6
true인 경우 클러스터가 검증됩니다.
7
restic 포드가 true인 경우 생성된 후 restic 포드가 소스 클러스터에서 다시 시작됩니다.
8
선택 사항: 직접 이미지 마이그레이션을 사용하는 경우 원격 클러스터의 노출된 레지스트리 경로를 지정합니다.
9
원격 클러스터의 URL을 지정합니다.
10
원격 클러스터에 대한 Secret CR의 이름을 지정합니다.
1.6.3.2.7. MigHook

MigHook CR은 마이그레이션의 지정된 단계에서 작업을 실행하는 Ansible 플레이북 또는 사용자 정의 이미지를 정의합니다.

apiVersion: migration.openshift.io/v1alpha1
kind: MigHook
metadata:
  generateName: <hook_name_prefix> 1
  name: <hook_name> 2
  namespace: openshift-migration
spec:
  activeDeadlineSeconds: 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 또는 대상을 지정합니다.
1.6.3.2.8. MigMigration

MigMigration CR은 연결된 MigPlan CR을 실행합니다.

다음 시나리오에 동일한 MigPlan CR과 연관된 여러 MigMigration CR을 생성할 수 있습니다.

  • 소스 클러스터에서 포드를 중지하지 않고도 여러 단계 또는 증분 마이그레이션을 실행하여 데이터를 복사할 수 있습니다. 단계별 마이그레이션을 실행하면 실제 마이그레이션의 성능이 향상됩니다.
  • 진행 중인 마이그레이션을 취소할 수 있습니다.
  • 마이그레이션을 롤백할 수 있습니다.
apiVersion: migration.openshift.io/v1alpha1
kind: MigMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: migmigration_name
  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_ref> 7
    namespace: openshift-migration
1
true인 경우 진행 중인 마이그레이션이 취소됩니다.
2
true인 경우 완료된 마이그레이션이 롤백됩니다.
3
true인 경우 데이터가 증분적으로 복사되고 소스 클러스터의 포드가 중지되지 않습니다.
4
소스 클러스터의 포드는 true인 경우 마이그레이션의 Backup 단계 이후 0으로 확장됩니다.
5
마이그레이션 중에 적용되는 레이블 및 주석은 true인 경우 유지됩니다.
6
대상 클러스터에서 마이그레이션된 포드의 상태가 확인되고 Running 상태에 없는 포드의 이름이 true인 경우 반환됩니다.
7
migPlanRef.name: 연결된 MigPlan CR의 이름을 지정합니다.
1.6.3.2.9. MigPlan

MigPlan CR은 마이그레이션 계획의 매개변수를 정의합니다. 동일한 매개변수로 마이그레이션 중인 가상 머신 그룹이 포함되어 있습니다.

apiVersion: migration.openshift.io/v1alpha1
kind: MigPlan
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: migplan_name
  namespace: openshift-migration
spec:
  closed: false 1
  srcMigClusterRef:
    name: <source_migcluster_ref> 2
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_migcluster_ref> 3
    namespace: openshift-migration
  hooks: 4
    - executionNamespace: <namespace> 5
      phase: <migration_phase> 6
      reference:
        name: <mighook_name> 7
        namespace: <hook_namespace> 8
      serviceAccount: <service_account> 9
  indirectImageMigration: true 10
  indirectVolumeMigration: false 11
  migStorageRef:
    name: <migstorage_name> 12
    namespace: openshift-migration
  namespaces:
  - <namespace>  13
  refresh: false  14
1
true인 경우 마이그레이션이 완료되었습니다. 이 MigPlan CR에 대해 다른 MigMigration CR을 생성할 수 없습니다.
2
소스 클러스터 MigCluster CR의 이름을 지정합니다.
3
대상 클러스터 MigCluster CR의 이름을 지정합니다.
4
선택 사항: 최대 4개의 마이그레이션 후크를 지정할 수 있습니다.
5
선택 사항: 후크를 실행할 네임스페이스를 지정합니다.
6
선택 사항: 후크가 실행되는 마이그레이션 단계를 지정합니다. 하나의 후크를 하나의 단계에 할당할 수 있습니다. 예상되는 값은 PreBackup, PostBackup, PreRestorePostRestore입니다.
7
선택 사항: MigHook CR의 이름을 지정합니다.
8
선택 사항: MigHook CR의 네임스페이스를 지정합니다.
9
선택 사항: cluster-admin 권한이 있는 서비스 계정을 지정합니다.
10
true인 경우 직접 이미지 마이그레이션이 비활성화됩니다. 이미지는 소스 클러스터에서 복제 리포지토리로, 복제 리포지토리에서 대상 클러스터로 복사됩니다.
11
true인 경우 직접 볼륨 마이그레이션이 비활성화됩니다. PV는 소스 클러스터에서 복제 리포지토리로, 복제 리포지토리에서 대상 클러스터로 복사됩니다.
12
MigStorage CR의 이름을 지정합니다.
13
하나 이상의 네임스페이스를 지정합니다.
14
MigPlan CR이 true인 경우 검증됩니다.
1.6.3.2.10. MigStorage

MigStorage CR은 복제 리포지토리의 오브젝트 스토리지를 설명합니다. Amazon Web Services, Microsoft Azure, Google Cloud Storage 및 일반 S3 호환 클라우드 스토리지(예: Minio 또는 NooBaa)를 구성할 수 있습니다.

다른 공급자에는 다른 매개 변수가 필요합니다.

apiVersion: migration.openshift.io/v1alpha1
kind: MigStorage
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: migstorage_name
  namespace: openshift-migration
spec:
  backupStorageProvider: <storage_provider> 1
  volumeSnapshotProvider: 2
  backupStorageConfig:
    awsBucketName: 3
    awsRegion: 4
    credsSecretRef:
      namespace: openshift-config
      name: <storage_secret> 5
    awsKmsKeyId: 6
    awsPublicUrl: 7
    awsSignatureVersion: 8
  volumeSnapshotConfig:
    awsRegion: 9
    credsSecretRef:
      namespace: openshift-config
      name: 10
  refresh: false 11
1
스토리지 공급자를 지정합니다.
2
선택 사항: 스냅샷 복사 방법을 사용하는 경우 스토리지 공급자를 지정합니다.
3
AWS를 사용하는 경우 버킷 이름을 지정합니다.
4
AWS를 사용하는 경우 버킷 리전을 지정합니다(예: us-east-1).
5
MigStorage CR용으로 생성한 Secret CR의 이름을 지정합니다.
6
선택 사항: AWS 키 관리 서비스를 사용하는 경우 키의 고유 식별자를 지정합니다.
7
선택 사항: AWS 버킷에 대한 공용 액세스 권한이 부여된 경우 버킷 URL을 지정합니다.
8
선택 사항: 버킷에 대한 요청을 인증하기 위해 AWS 서명 버전을 지정합니다(예: 4).
9
선택 사항: 스냅샷 복사 방법을 사용하는 경우 클러스터의 지역 리전을 지정합니다.
10
선택 사항: 스냅샷 복사 방법을 사용하는 경우 MigStorage CR에 대해 생성한 Secret CR의 이름을 지정합니다.
11
true인 경우 클러스터가 검증됩니다.

1.6.4. 추가 리소스

1.6.5. 마이그레이션 계획 구성

마이그레이션할 오브젝트 수를 늘리거나 마이그레이션에서 리소스를 제외할 수 있습니다.

1.6.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 콘솔은 마이그레이션 계획을 저장할 때 경고 메시지를 표시합니다.

1.6.5.2. 마이그레이션 계획에서 리소스 제외

마이그레이션하기 위해 리소스 로드를 줄이거나 다른 도구를 사용하여 이미지 또는 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. 특정 리소스를 제외하는 매개 변수를 추가하거나 자체 제외 매개 변수가 없는 경우 excluded_resources 매개 변수에 리소스를 추가하여 spec 섹션을 업데이트합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigrationController
    metadata:
      name: migration-controller
      namespace: openshift-migration
    spec:
      disable_image_migration: true 1
      disable_pv_migration: true 2
      ...
      excluded_resources: 3
      - imagetags
      - templateinstances
      - clusterserviceversions
      - packagemanifests
      - subscriptions
      - servicebrokers
      - servicebindings
      - serviceclasses
      - serviceinstances
      - serviceplans
      - operatorgroups
      - events
    1
    마이그레이션에서 이미지 스트림을 제외하려면 disable_image_migration: true를 추가합니다. excluded_resources 매개 변수를 편집하지 마십시오. MigrationController 포드가 다시 시작되면 imagestreamsexcluded_resources에 추가됩니다.
    2
    마이그레이션 계획에서 PV를 제외하려면 disable_pv_migration: true를 추가합니다. excluded_resources 매개 변수를 편집하지 마십시오. MigrationController 포드가 다시 시작되면 persistentvolumespersistentvolumeclaimsexcluded_resources에 추가됩니다. PV 마이그레이션을 비활성화하면 마이그레이션 계획을 생성할 때 PV 검색도 비활성화됩니다.
    3
    OpenShift Container Platform 리소스를 excluded_resources 목록에 추가할 수 있습니다. 기본 제외 리소스를 삭제하지 마십시오. 이러한 리소스는 마이그레이션에 문제가 있으므로 제외해야 합니다.
  3. 변경 사항이 적용되도록 MigrationController 포드가 다시 시작될 때까지 2분 정도 기다립니다.
  4. 리소스가 제외되었는지 확인합니다.

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

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

    출력 예

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

1.7. 문제 해결

MTC(Migration Toolkit for Containers) 사용자 정의 리소스를 보고 로그를 다운로드하여 마이그레이션 실패 문제를 해결할 수 있습니다.

실패한 마이그레이션 중에 애플리케이션이 중지된 경우 데이터 손상을 방지하기 위해 수동으로 롤백해야 합니다.

참고

원래 애플리케이션이 소스 클러스터에서 계속 실행 중이므로 마이그레이션 중에 애플리케이션이 중지되지 않은 경우 수동 롤백이 필요하지 않습니다.

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

1.7.2. 마이그레이션 로그 리더 사용

마이그레이션 로그 리더를 사용하여 모든 마이그레이션 로그에 대한 필터링된 보기를 표시할 수 있습니다.

프로세스

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

    $ oc -n openshift-migration get pods | grep log
  2. 단일 마이그레이션 로그를 표시하려면 다음 명령을 입력합니다.

    $ oc -n openshift-migration logs -f <mig-log-reader-pod> -c color 1
    1
    -c plain 옵션은 색상 없이 로그를 표시합니다.

1.7.3. 마이그레이션 로그 다운로드

MTC(Migration Toolkit for Containers) 웹 콘솔에서 Velero, ResticMigrationController 포드 로그를 다운로드하여 실패한 마이그레이션 문제를 해결할 수 있습니다.

프로세스

  1. MTC 콘솔에서 마이그레이션 계획을 클릭하여 마이그레이션 계획 목록을 확인합니다.
  2. 특정 마이그레이션 계획의 옵션 메뉴 kebab 를 클릭하고 로그를 선택합니다.
  3. 모든 클러스터에 대한 MigrationController, VeleroRestic 포드의 로그를 다운로드하려면 로그 다운로드를 클릭합니다.

    클러스터, 로그 소스 및 포드 소스를 선택한 다음 선택한 항목 다운로드를 클릭하여 단일 로그를 다운로드할 수 있습니다.

    oc logs 명령을 사용하여 CLI에서 포드 로그에 액세스할 수 있습니다.

    $ oc logs <pod-name> -f -n openshift-migration 1
    1
    포드 이름을 지정합니다.

1.7.4. 더 이상 사용되지 않는 API 업데이트

소스 클러스터에서 더 이상 사용되지 않는 API를 사용하는 경우 MTC(Migration Toolkit for Containers) 웹 콘솔에서 마이그레이션 계획을 생성할 때 다음 경고 메시지가 표시됩니다.

Some namespaces contain GVKs incompatible with destination cluster

세부 사항 보기를 클릭하여 네임스페이스 및 호환되지 않는 API를 볼 수 있습니다. 이 경고 메시지는 마이그레이션을 차단하지 않습니다.

MTC(Migration Toolkit for Containers)를 사용하여 마이그레이션하는 동안 더 이상 사용되지 않는 API는 Kubernetes 오브젝트의 Velero Backup #1에 저장됩니다. Velero Backup을 다운로드하고, 더 이상 사용되지 않는 API yaml 파일을 추출한 후 oc convert 명령으로 업데이트할 수 있습니다. 그런 다음 대상 클러스터에서 업데이트된 API를 생성할 수 있습니다.

프로세스

  1. 마이그레이션 계획을 실행합니다.
  2. MigPlan 사용자 정의 리소스 (CR)를 확인합니다.

    $ oc describe migplan <migplan_name> -n openshift-migration 1
    1
    MigPlan CR의 이름을 지정합니다.

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

    metadata:
      ...
      uid: 79509e05-61d6-11e9-bc55-02ce4781844a 1
    status:
      ...
      conditions:
      - category: Warn
        lastTransitionTime: 2020-04-30T17:16:23Z
        message: 'Some namespaces contain GVKs incompatible with destination cluster.
          See: `incompatibleNamespaces` for details'
        status: "True"
        type: GVKsIncompatible
      incompatibleNamespaces:
      - gvks: 2
        - group: batch
          kind: cronjobs
          version: v2alpha1
        - group: batch
          kind: scheduledjobs
          version: v2alpha1
    1
    MigPlan CR UID를 기록합니다.
    2
    gvks 섹션에 나열된 더 이상 사용되지 않는 API를 기록합니다.
  3. MigPlan UID와 관련된 MigMigration 이름을 가져옵니다.

    $ oc get migmigration -o json | jq -r '.items[] | select(.metadata.ownerReferences[].uid=="<migplan_uid>") | .metadata.name' 1
    1
    MigPlan CR UID를 지정합니다.
  4. MigMigration 이름과 연관된 MigMigration UID를 가져옵니다.

    $ oc get migmigration <migmigration_name> -o jsonpath='{.metadata.uid}' 1
    1
    MigMigration 이름을 지정합니다.
  5. MigMigration UID와 관련된 Velero Backup 이름을 가져옵니다.

    $ oc get backup.velero.io --selector migration-initial-backup="<migmigration_uid>" -o jsonpath={.items[*].metadata.name} 1
    1
    MigMigration UID를 지정합니다.
  6. 스토리지 공급자의 명령을 실행하여 Velero Backup의 콘텐츠를 로컬 머신으로 다운로드합니다.

    • AWS S3:

      $ aws s3 cp s3://<bucket_name>/velero/backups/<backup_name> <backup_local_dir> --recursive 1
      1
      버킷, 백업 이름 및 로컬 백업 디렉터리 이름을 지정합니다.
    • GCP:

      $ gsutil cp gs://<bucket_name>/velero/backups/<backup_name> <backup_local_dir> --recursive 1
      1
      버킷, 백업 이름 및 로컬 백업 디렉터리 이름을 지정합니다.
    • Azure:

      $ azcopy copy 'https://velerobackups.blob.core.windows.net/velero/backups/<backup_name>' '<backup_local_dir>' --recursive 1
      1
      백업 이름과 로컬 백업 디렉터리 이름을 지정합니다.
  7. Velero Backup 아카이브 파일을 추출합니다.

    $ tar -xfv <backup_local_dir>/<backup_name>.tar.gz -C <backup_local_dir>
  8. 더 이상 사용되지 않는 각 API의 오프라인 모드에서 oc convert를 실행합니다.

    $ oc convert -f <backup_local_dir>/resources/<gvk>.json
  9. 대상 클러스터에서 변환된 API를 생성합니다.

    $ oc create -f <gvk>.json

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

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

1.7.5.1. MTC 콘솔의 CA 인증서 오류

MTC 콘솔에 처음 액세스하려고 할 때 CA 인증서 오류 메시지가 표시되면 클러스터가 자체 서명된 CA 인증서를 사용하게 될 가능성이 큽니다.

오류 메시지에서 oauth-authorization-server URL로 이동하여 인증서를 수락합니다. 이 문제를 영구적으로 해결하려면 신뢰할 수 있도록 인증 기관을 설치합니다.

CA 인증서를 승인한 후 브라우저에 인증되지 않은 메시지가 표시되면 MTC 콘솔로 이동한 다음 웹 페이지를 새로 고칩니다.

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

MTC 콘솔에 자체 서명 인증서를 허용한 후 연결 시간이 초과된 메시지가 표시되면 원인은 다음 중 하나일 수 있습니다.

원인을 확인하려면 다음을 수행합니다.

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

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

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

BSL 오류 메시지

Error checking repository for stale locks

Error getting backup storage location: backupstoragelocation.velero.io \"my-bsl\" not found

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

1.7.5.4. 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. 저장을 클릭합니다.

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

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

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 오류가 있는 영구 볼륨을 식별합니다.

    Pod 볼륨 복원 오류로 CR 복원

    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를 식별합니다.

    Restic Pod 오류가 있는 PodVolumeRestore CR

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

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

    $ oc logs -f <restic-nr2v5>

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

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

Restic 권한 오류

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용 보조 그룹을 생성하고 그룹 ID를 MigrationController CR 매니페스트에 추가하여 이 문제를 해결할 수 있습니다.

프로세스

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

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

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

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

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

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

프로세스

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

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

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

    출력 예

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

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

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

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

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

1.7.7. Velero CLI를 사용하여 Backup 및 Restore CR을 디버깅합니다.

Velero 명령줄 인터페이스(CLI)를 사용하여 BackupRestore CR(사용자 정의 리소스) 및 부분 마이그레이션 실패를 디버깅할 수 있습니다. Velero CLI는 velero 포드에서 실행됩니다.

1.7.7.1. Velero 명령 구문

Velero CLI 명령은 다음 구문을 사용합니다.

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

$(oc get pods -n openshift-migration -o name | grep velero)를 대신해서 velero-<pod> -n openshift-migration을 지정할 수 있습니다.

1.7.7.2. 도움말 명령

Velero help 명령은 모든 Velero CLI 명령을 나열합니다.

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero --help

1.7.7.3. Describe 명령

Velero describe 명령은 Velero 리소스와 관련된 경고 및 오류 요약을 제공합니다.

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

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql

1.7.7.4. Logs 명령

Velero logs 명령은 Velero 리소스와 관련된 로그를 제공합니다.

velero <resource> logs <resource_id>

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

1.7.7.5. 부분적인 마이그레이션 실패 디버깅

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 exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore describe <restore>
    Phase:  PartiallyFailed (run 'velero restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf' for more information)
    
    Errors:
      Velero:     <none>
      Cluster:    <none>
      Namespaces:
        migration-example:  error restoring example.com/migration-example/migration-example: the server could not find the requested resource
  3. Velero logs 명령을 사용하여 Restore CR 로그를 확인합니다.

    $ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore logs <restore>
    time="2021-01-26T20:48:37Z" level=info msg="Attempting to restore migration-example: migration-example" logSource="pkg/restore/restore.go:1107" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf
    time="2021-01-26T20:48:37Z" level=info msg="error restoring migration-example: the server could not find the requested resource" logSource="pkg/restore/restore.go:1170" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

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

1.7.8. must-gather를 사용하여 데이터 수집

MTC(Migration Toolkit for Containers)의 Red Hat Customer Portal에서 고객 지원 사례를 여는 경우 must-gather 툴을 실행해야 합니다.

MTC의 openshift-migration-must-gather-rhel8 이미지는 기본 must-gather 이미지로 수집되지 않은 마이그레이션별 로그 및 데이터를 수집합니다.

프로세스

  1. must-gather 데이터를 저장하려는 디렉터리로 이동합니다.
  2. must-gather 명령을 실행합니다.

    $ oc adm must-gather --image=registry.redhat.io/rhmtc/openshift-migration-must-gather-rhel8:v1.4
  3. 인증 키 및 기타 민감한 정보를 제거합니다.
  4. must-gather 데이터 디렉터리의 콘텐츠가 포함된 아카이브 파일을 생성합니다.

    $ tar cvaf must-gather.tar.gz must-gather.local.<uid>/
  5. 압축 파일을 고객 지원 사례에 첨부 파일로 업로드합니다.

1.7.9. 마이그레이션 롤백

MTC 웹 콘솔 또는 CLI를 사용하여 마이그레이션을 롤백할 수 있습니다.

1.7.9.1. MTC 웹 콘솔에서 마이그레이션 롤백

MTC(Migration Toolkit for Containers) 웹 콘솔을 사용하여 마이그레이션을 롤백할 수 있습니다.

마이그레이션 실패로 인해 애플리케이션이 중지된 경우 영구 볼륨의 데이터 손상을 방지하려면 마이그레이션을 롤백해야 합니다.

원래 애플리케이션이 소스 클러스터에서 계속 실행 중이므로 마이그레이션 중에 애플리케이션이 중지되지 않은 경우 롤백이 필요하지 않습니다.

프로세스

  1. MTC 웹 콘솔에서 마이그레이션 계획을 클릭합니다.
  2. 마이그레이션 계획 옆의 옵션 메뉴 kebab 를 클릭하고 롤백을 선택합니다.
  3. 롤백을 클릭하고 롤백이 완료될 때까지 기다립니다.

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

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

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

CLI에서 MigMigration 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: migration-rollback
      namespace: openshift-migration
    spec:
    ...
      rollback: true
    ...
      migPlanRef:
        name: <migplan_name> 1
        namespace: openshift-migration
    EOF
    1
    연결된 MigPlan CR의 이름을 지정합니다.
  2. MTC 웹 콘솔에서 마이그레이션된 프로젝트 리소스가 대상 클러스터에서 제거되었는지 확인합니다.
  3. 마이그레이션된 프로젝트 리소스가 소스 클러스터에 있고 애플리케이션이 실행 중인지 확인합니다.

1.7.10. 확인된 문제

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

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

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

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

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

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

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

1.7.11. 추가 리소스

2장. OpenShift Container Platform 4.1에서 마이그레이션

2.1. Migration Toolkit for Containers 정보

MTC(Migration Toolkit for Containers)를 사용하여 OpenShift Container Platform 4.2에서 4.7으로 애플리케이션 워크로드를 마이그레이션할 수 있습니다. MTC를 사용하면 마이그레이션을 제어하고 애플리케이션 다운 타임을 최소화할 수 있습니다.

참고

소스 및 대상 클러스터가 올바르게 구성되어 있으면 동일한 버전의 OpenShift Container Platform 클러스터(예: 4.1에서 4.1로) 간에 마이그레이션할 수 있습니다.

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

Kubernetes 사용자 정의 리소스를 기반으로 하는 MTC 웹 콘솔 및 API를 사용하면 네임스페이스 단위로 스테이트풀(stateful) 및 스테이트리스(stateless) 애플리케이션 워크로드를 마이그레이션할 수 있습니다.

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

마이그레이션 후크를 사용하여 마이그레이션 중에 특정 시점에서 Ansible 플레이북을 실행할 수 있습니다. 마이그레이션 계획을 생성할 때 후크가 추가됩니다.

2.1.1. Migration Toolkit for Containers 워크플로

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

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

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

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

  • CR(사용자 정의 리소스) 및 CRD(사용자 정의 리소스 정의): MTC는 네임스페이스 수준에서 존재하는 모든 CR과 해당 CR에 연결된 CRD를 자동으로 마이그레이션합니다.

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

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

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

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

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

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

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

      참고

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

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

      참고

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

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

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

      스테이징은 여러 번 실행될 수 있으므로 마이그레이션 전에 대부분의 데이터가 대상에 복사됩니다. 따라서 마이그레이션의 기간과 애플리케이션 다운 타임이 최소화됩니다.

    • 마이그레이션은 소스 클러스터에서 애플리케이션을 중지하고 대상 클러스터에서 해당 리소스를 다시 만듭니다. 선택적으로 애플리케이션을 중지하지 않고 워크로드를 마이그레이션할 수 있습니다.
OCP 3에서 4로의 애플리케이션 마이그레이션

2.1.2. Migration Toolkit for Containers 사용자 정의 리소스

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 사용)

2.1.3. 데이터 복사 방법 정보

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

2.1.3.1. 파일 시스템 복사 방법

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

표 2.1. 파일 시스템 복사 방법 요약

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

2.1.3.2. 스냅샷 복사 방법

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

AWS, Google Cloud Provider 및 Microsoft Azure는 스냅샷 복사 방법을 지원합니다.

표 2.2. 스냅샷 복사 방법 요약

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

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

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

직접 마이그레이션은 소스 클러스터에서 복제 리포지토리로 파일을 백업하고 복제 리포지토리에서 대상 클러스터로 파일을 복원하는 중간 단계를 뛰어넘기 때문에 상당한 성능 이점을 지닙니다.

직접 마이그레이션은 Rsync를 사용하여 파일을 전송합니다.

참고

직접 이미지 마이그레이션 및 직접 볼륨 마이그레이션에는 추가 사전 요구 사항이 있습니다.

2.1.4. 마이그레이션 후크 정보

MTC(Migration Toolkit for Containers)를 사용하여 마이그레이션하는 동안 특정 시점에서 사용자 정의 코드를 실행하도록 마이그레이션 후크를 사용할 수 있습니다. 마이그레이션의 다른 단계에서 각 후크가 실행되고 단일 마이그레이션 계획에 최대 4개의 마이그레이션 후크를 추가할 수 있습니다.

마이그레이션 후크는 애플리케이션 정지 사용자 정의, 지원되지 않는 데이터 유형을 수동으로 마이그레이션 및 마이그레이션 후 애플리케이션 업데이트와 같은 작업을 수행합니다.

마이그레이션 후크는 다음 마이그레이션 단계 중 하나에서 소스 또는 대상 클러스터에서 실행됩니다.

  • PreBackup : 소스 클러스터에서 리소스를 백업하기 전에
  • PostBackup : 소스 클러스터에서 리소스를 백업한 후
  • PreRestore : 대상 클러스터에서 리소스가 복원되기 전에
  • PostRestore : 대상 클러스터에서 리소스가 복원된 후

Ansible 플레이북 또는 사용자 정의 후크 컨테이너를 사용하여 후크를 생성할 수 있습니다.

Ansible 플레이북

Ansible 플레이북은 후크 컨테이너에 구성 맵으로 마운트됩니다. 후크 컨테이너는 MigPlan 사용자 정의 리소스(CR)에 지정된 클러스터, 서비스 계정 및 네임스페이스를 사용하여 작업으로 실행됩니다. 작업은 기본 6번의 재시도 한도에 도달하거나 성공적으로 완료될 때까지 계속 실행됩니다. 이는 초기 포드가 제거되거나 종료된 경우에도 계속됩니다.

기본 Ansible 런타임 이미지는 registry.redhat.io/rhmtc/openshift-migration-hook-runner-rhel7:1.4입니다. 이 이미지는 Ansible Runner 이미지를 기반으로 하며 Ansible Kubernetes 리소스에 대해 python-openshift 및 업데이트된 oc바이너리를 포함합니다.

선택 사항: 기본 이미지 대신 추가 Ansible 모듈 또는 도구가 포함된 사용자 정의 Ansible 런타임 이미지를 사용할 수 있습니다.

사용자 정의 후크 컨테이너

Ansible 플레이북 또는 사용자 정의 코드가 포함된 사용자 정의 후크 컨테이너를 생성할 수 있습니다.

2.2. Migration Toolkit for Containers 설치 및 업그레이드

OpenShift Container Platform 4.7 대상 클러스터 및 4.1 소스 클러스터에 Migration Toolkit for Containers를 설치할 수 있습니다.

MTC는 기본적으로 대상 클러스터에 설치되어 있습니다. OpenShift Container Platform 3 클러스터 또는 원격 클러스터에 MTC를 설치할 수 있습니다.

2.2.1. 연결된 환경에서 Migration Toolkit for Containers 설치

연결된 환경에서 MTC(Migration Toolkit for Containers)를 설치할 수 있습니다.

중요

모든 클러스터에 동일한 MTC 버전을 설치해야 합니다.

2.2.1.1. OpenShift Container Platform 4.7 대상 클러스터에 Migration Toolkit for Containers 설치

OpenShift Container Platform 4.7 대상 클러스터에 MTC(Migration Toolkit for Containers)를 설치할 수 있습니다.

사전 요구 사항

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

프로세스

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

    참고

    서브스크립션 승인 옵션을 자동으로 변경하지 마십시오. 소스 및 대상 클러스터에서 Migration Toolkit for Containers 버전이 동일해야 합니다.

  4. 설치를 클릭합니다.

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

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

2.2.1.2. OpenShift Container Platform 4.1 소스 클러스터에 Migration Toolkit for Containers 설치

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

사전 요구 사항

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

프로세스

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

    참고

    서브스크립션 승인 옵션을 자동으로 변경하지 마십시오. 소스 및 대상 클러스터에서 Migration Toolkit for Containers 버전이 동일해야 합니다.

  4. 설치를 클릭합니다.

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

  5. Migration Toolkit for Containers Operator를 클릭합니다.
  6. 제공된 API 아래에서 마이그레이션 컨트롤러 타일을 찾고 인스턴스 작성을 클릭합니다.
  7. migration-controller 사용자 정의 리소스 매니페스트에서 다음 매개변수를 업데이트합니다.

    spec:
    ...
      migration_controller: false
      migration_ui: false
    ...
      deprecated_cors_configuration: true 1
    1
    deprecated_cors_configuration 매개 변수와 해당 값을 추가합니다.
  8. 생성을 클릭합니다.
  9. 워크로드포드를 클릭하여 MTC 포드가 실행 중인지 확인합니다.

2.2.2. 제한된 환경에서 Migration Toolkit for Containers 설치

제한된 환경에서 MTC(Migration Toolkit for Containers)를 설치할 수 있습니다.

중요

모든 클러스터에 동일한 MTC 버전을 설치해야 합니다.

OpenShift Container Platform 4에 대한 사용자 정의 Operator 카탈로그 이미지를 빌드하고 로컬 미러 이미지 레지스트리로 푸시하고 로컬 레지스트리에서 Migration Toolkit for Containers Operator를 설치하도록 OLM(Operator Lifecycle Manager)을 구성할 수 있습니다.

2.2.2.1. 기본 OperatorHub 소스 비활성화

Red Hat 및 커뮤니티 프로젝트에서 제공하는 콘텐츠를 소싱하는 Operator 카탈로그는 OpenShift Container Platform을 설치하는 동안 기본적으로 OperatorHub용으로 구성됩니다.

프로세스

  • OperatorHub 오브젝트에 disableAllDefaultSources: true를 추가하여 기본 카탈로그의 소스를 비활성화합니다.

    $ oc patch OperatorHub cluster --type json \
        -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
작은 정보

또는 웹 콘솔을 사용하여 카탈로그 소스를 관리할 수 있습니다. 관리자클러스터 설정글로벌 구성OperatorHub 페이지에서 개별 소스를 생성, 삭제, 비활성화, 활성화할 수 있는 소스 탭을 클릭합니다.

2.2.2.2. 인덱스 이미지 정리

Operator 번들 포맷을 기반으로 하는 인덱스 이미지는 Operator 카탈로그의 컨테이너화된 스냅샷입니다. 지정된 패키지 목록을 제외한 인덱스를 모두 정리하여 원하는 Operator만 포함하는 소스 인덱스 복사본을 생성할 수 있습니다.

제한된 네트워크 OpenShift Container Platform 클러스터에서 미러링된 콘텐츠를 사용하도록 OLM(Operator Lifecycle Manager)을 구성할 때는 기본 카탈로그에서 Operator 서브 세트만 미러링하려면 이 정리 방법을 사용하십시오.

이 절차의 단계에서 대상 레지스트리는 무제한 네트워크 액세스 권한을 사용하여 워크스테이션에서 액세스할 수 있는 기존 미러 레지스트리입니다. 이 예제에서는 기본 redhat-operators 카탈로그의 인덱스 이미지를 정리하는 방법도 보여주지만 프로세스는 모든 인덱스 이미지에서 동일합니다.

사전 요구 사항

  • 무제한 네트워크 액세스가 가능한 워크스테이션
  • podman 버전 1.9.3+
  • grpcurl
  • opm 버전 1.12.3 이상
  • Docker v2-2를 지원하는 레지스트리에 액세스

프로세스

  1. registry.redhat.io로 인증합니다.

    $ podman login registry.redhat.io
  2. 대상 레지스트리로 인증합니다.

    $ podman login <target_registry>
  3. 정리된 인덱스에 포함하려는 패키지 목록을 결정합니다.

    1. 컨테이너에서 정리하려는 소스 인덱스 이미지를 실행합니다. 예를 들면 다음과 같습니다.

      $ podman run -p50051:50051 \
          -it registry.redhat.io/redhat/redhat-operator-index:v4.7

      출력 예

      Trying to pull registry.redhat.io/redhat/redhat-operator-index:v4.7...
      Getting image source signatures
      Copying blob ae8a0c23f5b1 done
      ...
      INFO[0000] serving registry                              database=/database/index.db port=50051

    2. 별도의 터미널 세션에서 grpcurl 명령을 사용하여 인덱스에서 제공하는 패키지 목록을 가져옵니다.

      $ grpcurl -plaintext localhost:50051 api.Registry/ListPackages > packages.out
    3. packages.out 파일을 검사하고 정리된 인덱스에 보관할 이 목록에 있는 패키지 이름을 확인합니다. 예를 들면 다음과 같습니다.

      패키지 목록 조각의 예

      ...
      {
        "name": "advanced-cluster-management"
      }
      ...
      {
        "name": "jaeger-product"
      }
      ...
      {
      {
        "name": "quay-operator"
      }
      ...

    4. podman run 명령을 실행한 터미널 세션에서 CtrlC를 눌러 컨테이너 프로세스를 중지합니다.
  4. 다음 명령을 실행하여 지정된 패키지를 제외한 소스 인덱스를 모두 정리합니다.

    $ opm index prune \
        -f registry.redhat.io/redhat/redhat-operator-index:v4.7 \1
        -p advanced-cluster-management,jaeger-product,quay-operator \2
        [-i registry.redhat.io/openshift4/ose-operator-registry:v4.7] \3
        -t <target_registry>:<port>/<namespace>/redhat-operator-index:v4.7 4
    1
    정리할 인덱스입니다.
    2
    쉼표로 구분된 보관할 패키지 목록입니다.
    3
    IBM Power Systems 및 IBM Z 이미지에만 필요합니다. 대상 OpenShift Container Platform 클러스터 주 버전 및 부 버전과 일치하는 태그를 사용하여 --from을 Operator 레지스트리 기본 이미지로 설정합니다.
    4
    빌드 중인 새 인덱스 이미지에 대한 사용자 정의 태그입니다.
  5. 다음 명령을 실행하여 새 인덱스 이미지를 대상 레지스트리로 내보냅니다.

    $ podman push <target_registry>:<port>/<namespace>/redhat-operator-index:v4.7

    <namespace>는 레지스트리의 기존 네임스페이스입니다. 예를 들어 미러링된 콘텐츠를 모두 내보내기 위해 olm-mirror 네임스페이스를 생성할 수 있습니다.

2.2.2.3. Operator 카탈로그 미러링

oc adm catalog mirror 명령을 사용하여 Red Hat 제공 카탈로그 또는 사용자 정의 카탈로그의 Operator 콘텐츠를 컨테이너 이미지 레지스트리에 미러링할 수 있습니다. 대상 레지스트리는 Docker v2-2를 지원해야 합니다. 제한된 네트워크에 있는 클러스터의 경우 이 레지스트리는 제한된 네트워크 클러스터 설치 중 생성된 미러 레지스트리와 같이 클러스터에 네트워크 액세스 권한이 있는 레지스트리일 수 있습니다.

oc adm catalog mirror 명령은 또한 Red Hat 제공 인덱스 이미지이든 자체 사용자 정의 빌드 인덱스 이미지이든 미러링 프로세스 중에 지정하는 인덱스 이미지를 대상 레지스트리에 자동으로 미러링합니다. 그러면 미러링된 인덱스 이미지를 사용하여 OLM(Operator Lifecycle Manager)이 OpenShift Container Platform 클러스터에 미러링된 카탈로그를 로드할 수 있는 카탈로그 소스를 생성할 수 있습니다.

사전 요구 사항

  • 워크스테이션에서 무제한 네트워크 액세스가 가능합니다.
  • podman 버전이 1.9.3 이상입니다.
  • Docker v2-2를 지원하는 미러 레지스트리에 액세스할 수 있습니다.
  • 미러 레지스트리에서 미러링된 Operator 콘텐츠를 저장하는 데 사용할 네임스페이스를 결정합니다. 예를 들어 olm-mirror 네임스페이스를 생성할 수 있습니다.
  • 미러 레지스트리가 인터넷에 액세스할 수 없는 경우 이동식 미디어를 무제한 네트워크 액세스 권한이 있는 워크스테이션에 연결합니다.
  • 프라이빗 레지스트리로 작업 중인 경우 REG_CREDS 환경 변수를 이후 단계에서 사용하기 위해 레지스트리 자격 증명의 파일 경로로 설정합니다. 예를 들어 podman CLI의 경우:

    $ REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.json

프로세스

  1. Red Hat 제공 카탈로그를 미러링하려면 무제한 네트워크 액세스 권한이 있는 워크스테이션에서 다음 명령을 실행하여 registry.redhat.io로 인증합니다.

    $ podman login registry.redhat.io
  2. oc adm catalog mirror 명령은 인덱스 이미지의 콘텐츠를 추출하여 미러링에 필요한 매니페스트를 생성합니다. 명령의 기본 동작은 매니페스트를 생성한 다음 인덱스 이미지 자체뿐만 아니라 인덱스 이미지의 모든 이미지 콘텐츠를 미러 레지스트리에 자동으로 미러링합니다. 또는 미러 레지스트리가 완전히 연결이 끊긴 호스트 또는 에어갭(Airgap) 호스트에 있는 경우 먼저 콘텐츠를 이동식 미디어로 미러링하고 미디어를 연결이 끊긴 환경으로 이동한 다음 미디어에서 레지스트리로 해당 콘텐츠를 미러링할 수 있습니다.

    • 옵션 A: 미러 레지스트리가 무제한 네트워크 액세스 권한이 있는 워크스테이션과 동일한 네트워크에 있는 경우 워크스테이션에서 다음 작업을 수행합니다.

      1. 미러 레지스트리에 인증이 필요한 경우 다음 명령을 실행하여 레지스트리에 로그인합니다.

        $ podman login <mirror_registry>
      2. 다음 명령을 실행하여 콘텐츠를 미러링합니다.

        $ oc adm catalog mirror \
            <index_image> \1
            <mirror_registry>:<port>/<namespace> \2
            [-a ${REG_CREDS}] \3
            [--insecure] \4
            [--index-filter-by-os='<platform>/<arch>'] \5
            [--manifests-only] 6
        1
        미러링할 카탈로그의 인덱스 이미지를 지정합니다. 예를 들어 이전에 생성한 정리된 인덱스 이미지 또는 registry.redhat.io/redhat/redhat-operator-index:v4.7과 같은 기본 카탈로그의 소스 인덱스 이미지 중 하나일 수 있습니다.
        2
        Operator 콘텐츠를 미러링할 대상 레지스트리와 네임스페이스를 지정합니다. 여기서 <namespace>는 레지스트리의 기존 네임스페이스입니다. 예를 들어 미러링된 콘텐츠를 모두 내보내기 위해 olm-mirror 네임스페이스를 생성할 수 있습니다.
        3
        선택 사항: 필요한 경우 레지스트리 자격 증명 파일의 위치를 지정합니다.
        4
        선택 사항: 대상 레지스트리에 대한 트러스트를 구성하지 않으려면 --insecure 플래그를 추가합니다.
        5
        선택 사항: 여러 변형이 있을 때 선택할 수 있는 인덱스 이미지의 플랫폼 및 아키텍처를 지정합니다. 이미지는 '<platform>/<arch>[/<variant>]’로 전달됩니다. 이는 인덱스에서 참조하는 이미지에는 적용되지 않습니다. 유효한 값은 linux/amd64, linux/ppc64lelinux/s390x입니다.
        6
        선택 사항: 미러링에 필요한 매니페스트만 생성하고 실제로 이미지 콘텐츠를 레지스트리에 미러링하지 않습니다. 이 선택 사항은 미러링할 항목을 검토하는 데 유용할 수 있으며 패키지의 서브 세트만 필요한 경우 매핑 목록을 변경할 수 있습니다. 그런 다음 oc image mirror 명령과 함께 mapping.txt 파일을 사용하여 이후 단계에서 수정된 이미지 목록을 미러링할 수 있습니다. 이 플래그는 카탈로그에서 콘텐츠의 고급 선택적 미러링에만 사용됩니다. 이전에 인덱스 이미지를 정리하기 위해 사용한 경우 opm index prune 명령은 대부분의 카탈로그 관리 사용 사례에 적합합니다.

        출력 예

        src image has index label for database path: /database/index.db
        using database path mapping: /database/index.db:/tmp/153048078
        wrote database to /tmp/153048078 1
        ...
        wrote mirroring manifests to manifests-redhat-operator-index-1614211642 2

        1
        명령으로 생성된 임시 index.db 데이터베이스용 디렉터리입니다.
        2
        생성된 매니페스트 디렉터리 이름을 기록합니다. 이 디렉터리 이름은 이후 단계에서 사용됩니다.
    • 옵션 B: 미러 레지스트리가 연결 해제된 호스트에 있는 경우 다음 작업을 수행합니다.

      1. 무제한 네트워크 액세스 권한이 있는 워크스테이션에서 다음 명령을 실행하여 콘텐츠를 로컬 파일에 미러링합니다.

        $ oc adm catalog mirror \
            <index_image> \1
            file:///local/index \2
            [-a ${REG_CREDS}] \
            [--insecure]
        1
        미러링할 카탈로그의 인덱스 이미지를 지정합니다. 예를 들어 이전에 생성한 정리된 인덱스 이미지 또는 registry.redhat.io/redhat/redhat-operator-index:v4.7과 같은 기본 카탈로그의 소스 인덱스 이미지 중 하나일 수 있습니다.
        2
        현재 디렉터리의 로컬 파일에 콘텐츠를 미러링합니다.

        출력 예

        ...
        info: Mirroring completed in 5.93s (5.915MB/s)
        wrote mirroring manifests to manifests-my-index-1614985528 1
        
        To upload local images to a registry, run:
        
        	oc adm catalog mirror file://local/index/myrepo/my-index:v1 REGISTRY/REPOSITORY 2

        1
        생성된 매니페스트 디렉터리 이름을 기록합니다. 이 디렉터리 이름은 이후 단계에서 사용됩니다.
        2
        제공된 인덱스 이미지를 기반으로 확장된 file:// 경로를 기록합니다. 이 경로는 이후 단계에서 사용됩니다.
      2. 현재 디렉터리에 생성된 v2/ 디렉터리를 이동식 미디어로 복사합니다.
      3. 물리적으로 미디어를 제거하고 연결이 끊긴 환경의 호스트에 연결하여 미러 레지스트리에 액세스할 수 있습니다.
      4. 미러 레지스트리에 인증이 필요한 경우 연결이 끊긴 환경의 호스트에서 다음 명령을 실행하여 레지스트리에 로그인합니다.

        $ podman login <mirror_registry>
      5. v2/ 디렉터리가 포함된 상위 디렉터리에서 다음 명령을 실행하여 로컬 파일에서 미러 레지스트리로 이미지를 업로드합니다.

        $ oc adm catalog mirror \
            file://local/index/<repo>/<index_image>:<tag> \1
            <mirror_registry>:<port>/<namespace> \2
            [-a ${REG_CREDS}] \
            [--insecure]
        1
        이전 명령 출력의 file:// 경로를 지정합니다.
        2
        Operator 콘텐츠를 미러링할 대상 레지스트리와 네임스페이스를 지정합니다. 여기서 <namespace>는 레지스트리의 기존 네임스페이스입니다. 예를 들어 미러링된 콘텐츠를 모두 내보내기 위해 olm-mirror 네임스페이스를 생성할 수 있습니다.
  3. 콘텐츠를 레지스트리에 미러링한 후 현재 디렉터리에 생성된 매니페스트 디렉터리를 검사합니다.

    참고

    매니페스트 디렉터리 이름은 이후 단계에서 사용됩니다.

    이전 단계에서 동일한 네트워크의 레지스트리에 콘텐츠를 미러링한 경우 디렉터리 이름은 다음 형식을 취합니다.

    manifests-<index_image_name>-<random_number>

    이전 단계에서 연결이 끊긴 호스트의 레지스트리에 콘텐츠를 미러링한 경우 디렉터리 이름은 다음 형식을 취합니다.

    manifests-index/<namespace>/<index_image_name>-<random_number>

    매니페스트 디렉터리에는 다음 파일이 포함되어 있으며, 이 중 일부는 추가 수정이 필요할 수 있습니다.

    • catalogSource.yaml 파일은 인덱스 이미지 태그 및 기타 관련 메타데이터로 미리 채워진 CatalogSource 오브젝트에 대한 기본 정의입니다. 이 파일은 있는 그대로 사용하거나 카탈로그 소스를 클러스터에 추가하도록 수정할 수 있습니다.

      중요

      콘텐츠를 로컬 파일에 미러링한 경우 metadata.name 필드에서 .name 필드에서 백슬래시(/) 문자를 제거하려면 catalogSource.yaml 파일을 수정해야 합니다. 그러지 않으면 오브젝트 생성을 시도할 때 "잘못된 리소스 이름" 오류로 인해 실패합니다.

    • imageContentSourcePolicy.yaml 파일은 Operator 매니페스트에 저장된 이미지 참조와 미러링된 레지스트리 간에 변환하도록 노드를 구성할 수 있는 ImageContentSourcePolicy 오브젝트를 정의합니다.

      참고

      클러스터에서 ImageContentSourcePolicy 오브젝트를 사용하여 저장소 미러링을 구성하는 경우 미러링된 레지스트리에 대한 글로벌 풀 시크릿만 사용할 수 있습니다. 프로젝트에 풀 시크릿을 추가할 수 없습니다.

    • mapping.txt 파일에는 모든 소스 이미지와 대상 레지스트리에서 매핑할 위치가 포함되어 있습니다. 이 파일은 oc image mirror 명령과 호환되며 미러링 구성을 추가로 사용자 정의하는 데 사용할 수 있습니다.

      중요

      미러링 프로세스 중 --manifests-only 플래그를 사용한 후 미러링할 패키지의 서브 세트를 추가로 트리밍하려면 mapping.txt 파일을 수정하고 oc image mirror 명령으로 파일을 사용하는 데 대한 “패키지 매니페스트 형식 카탈로그 이미지 미러링” 절차의 단계를 참조하십시오. 추가 조치를 수행한 후 이 프로세스를 계속할 수 있습니다.

  4. 연결 해제된 클러스터에 액세스할 수 있는 호스트에서 매니페스트 디렉터리에 imageContentSourcePolicy.yaml 파일을 지정하도록 다음 명령을 실행하여 ImageContentSourcePolicy 오브젝트를 생성합니다.

    $ oc create -f <path/to/manifests/dir>/imageContentSourcePolicy.yaml

    여기서 <path/to/manifests/dir>은 미러링된 콘텐츠의 매니페스트 디렉터리 경로입니다.

이제 미러링된 인덱스 이미지 및 Operator 콘텐츠를 참조하도록 CatalogSource 오브젝트를 생성할 수 있습니다.

2.2.2.4. 인덱스 이미지에서 카탈로그 생성

인덱스 이미지에서 Operator 카탈로그를 생성하고 OLM(Operator Lifecycle Manager)과 함께 사용하도록 OpenShift Container Platform 클러스터에 적용할 수 있습니다.

사전 요구 사항

  • 인덱스 이미지를 빌드하여 레지스트리로 내보냈습니다.

프로세스

  1. 인덱스 이미지를 참조하는 CatalogSource 오브젝트를 생성합니다.

    1. 다음을 사양에 맞게 수정하고 catalogsource.yaml 파일로 저장합니다.

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: my-operator-catalog
        namespace: openshift-marketplace
      spec:
        sourceType: grpc
        image: <registry>:<port>/<namespace>/redhat-operator-index:v4.7 <.>
        displayName: My Operator Catalog
        publisher: <publisher_name> <.>
        updateStrategy:
          registryPoll: <.>
            interval: 30m

      <.> 인덱스 이미지를 지정합니다. <.> 카탈로그를 게시하는 이름 또는 조직 이름을 지정합니다. <.> 카탈로그 소스는 새 버전을 자동으로 확인하여 최신 상태를 유지할 수 있습니다.

    2. 파일을 사용하여 CatalogSource 오브젝트를 생성합니다.

      $ oc apply -f catalogSource.yaml
  2. 다음 리소스가 성공적으로 생성되었는지 확인합니다.

    1. Pod를 확인합니다.

      $ oc get pods -n openshift-marketplace

      출력 예

      NAME                                    READY   STATUS    RESTARTS  AGE
      my-operator-catalog-6njx6               1/1     Running   0         28s
      marketplace-operator-d9f549946-96sgr    1/1     Running   0         26h

    2. 카탈로그 소스를 확인합니다.

      $ oc get catalogsource -n openshift-marketplace

      출력 예

      NAME                  DISPLAY               TYPE PUBLISHER  AGE
      my-operator-catalog   My Operator Catalog   grpc            5s

    3. 패키지 매니페스트 확인합니다.

      $ oc get packagemanifest -n openshift-marketplace

      출력 예

      NAME                          CATALOG               AGE
      jaeger-product                My Operator Catalog   93s

이제 OpenShift Container Platform 웹 콘솔의 OperatorHub 페이지에서 Operator를 설치할 수 있습니다.

2.2.2.5. 제한된 환경에서 OpenShift Container Platform 4.7 대상 클러스터에 Migration Toolkit for Containers 설치

OpenShift Container Platform 4.7 대상 클러스터에 MTC(Migration Toolkit for Containers)를 설치할 수 있습니다.

사전 요구 사항

  • 모든 클러스터에서 cluster-admin 권한이 있는 사용자로 로그인합니다.
  • 사용자 정의 Operator 카탈로그를 생성하여 미러 레지스트리로 푸시해야 합니다.
  • 미러 레지스트리에서 Migration Toolkit for Containers Operator를 설치하도록 Operator Lifecycle Manager를 구성해야 합니다.

프로세스

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

    참고

    서브스크립션 승인 옵션을 자동으로 변경하지 마십시오. 소스 및 대상 클러스터에서 Migration Toolkit for Containers 버전이 동일해야 합니다.

  4. 설치를 클릭합니다.

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

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

2.2.2.6. 제한된 환경에서 OpenShift Container Platform 4.1 소스 클러스터에 Migration Toolkit for Containers 설치

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

사전 요구 사항

  • 모든 클러스터에서 cluster-admin 권한이 있는 사용자로 로그인합니다.
  • 사용자 정의 Operator 카탈로그를 생성하여 미러 레지스트리로 푸시해야 합니다.
  • 미러 레지스트리에서 Migration Toolkit for Containers Operator를 설치하도록 Operator Lifecycle Manager를 구성해야 합니다.

프로세스

  1. 키워드로 필터링 필드를 사용하여 Migration Toolkit for Containers Operator를 찾습니다.
  2. Migration Toolkit for Containers Operator를 선택하고 설치를 클릭합니다.

    참고

    서브스크립션 승인 옵션을 자동으로 변경하지 마십시오. 소스 및 대상 클러스터에서 Migration Toolkit for Containers 버전이 동일해야 합니다.

  3. 설치를 클릭합니다.

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

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

2.2.3. Migration Toolkit for Containers 업그레이드

OpenShift Container Platform 웹 콘솔을 사용하여 MTC를 업그레이드할 수 있습니다.

중요

동일한 MTC 버전이 모든 클러스터에 설치되어 있는지 확인해야 합니다.

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

2.2.3.1. OpenShift Container Platform 4 클러스터에서 Migration Toolkit for Containers 업그레이드

OpenShift Container Platform 웹 콘솔을 사용하여 OpenShift Container Platform 4 클러스터에서 MTC(Migration Toolkit for Containers)를 업그레이드할 수 있습니다.

사전 요구 사항

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

프로세스

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

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

  2. Migration Toolkit for Containers Operator를 클릭합니다.
  3. 서브스크립션 탭을 클릭합니다. 승인이 필요한 업그레이드는 업그레이드 상태 옆에 표시됩니다. 예를 들어 1 승인 필요가 표시될 수 있습니다.
  4. 1 승인 필요를 클릭한 다음 설치 계획 프리뷰를 클릭합니다.
  5. 업그레이드에 사용할 수 있는 리소스를 보고 승인을 클릭합니다.
  6. Operator → 설치된 Operator 페이지로 이동하여 업그레이드 진행 상황을 모니터링합니다. 완료되면 상태가 성공최신으로 변경됩니다.
  7. Migration Toolkit for Containers Operator를 클릭합니다.
  8. 제공된 API 아래에서 마이그레이션 컨트롤러 타일을 찾고 인스턴스 작성을 클릭합니다.
  9. 소스 클러스터에서 MTC를 업그레이드하는 경우 MigrationController 사용자 정의 리소스(CR) 매니페스트에서 다음 매개변수를 업데이트합니다.

    spec:
    ...
      migration_controller: false
      migration_ui: false
    ...
      deprecated_cors_configuration: true

    대상 클러스터에서 MigrationController CR 매니페스트를 업데이트할 필요가 없습니다.

  10. 생성을 클릭합니다.
  11. 워크로드포드를 클릭하여 MTC 포드가 실행 중인지 확인합니다.

2.2.3.2. MTC 1.3을 1.4로 업그레이드

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

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

사전 요구 사항

  • MTC 1.3이 설치되어 있어야 합니다.
  • 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

2.3. 복제 리포지토리에 대한 오브젝트 스토리지 구성

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

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

다음과 같은 스토리지 공급자가 지원됩니다.

제한된 환경에서 내부 호스팅 복제 리포지토리를 만들 수 있습니다.

사전 요구 사항

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

2.3.1. Multi-Cloud Object Gateway 스토리지 버킷을 복제 리포지토리로 구성

OpenShift Container Storage Operator를 설치하고 MCG(Multi-Cloud Object Gateway) 스토리지 버킷을 MTC(Migration Toolkit for Containers)의 복제 리포지토리로 구성할 수 있습니다.

2.3.1.1. OpenShift Container Storage Operator 설치

OperatorHub에서 OpenShift Container Storage Operator를 설치할 수 있습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 OperatorOperatorHub를 클릭합니다.
  2. 키워드로 필터링(이 경우 OCS)을 사용하여 OpenShift Container Storage Operator를 찾습니다.
  3. OpenShift Container Storage Operator를 선택하고 설치를 클릭합니다.
  4. 업데이트 채널, 설치 모드승인 전략을 선택합니다.
  5. 설치를 클릭합니다.

    설치된 운영자 페이지에서 OpenShift Container Storage Operatoropenshift-storage 프로젝트에 Succeeded 상태로 나타납니다.

2.3.1.2. Multi-Cloud Object Gateway 스토리지 버킷 작성

MCG(Multi-Cloud Object Gateway) 스토리지 버킷의 사용자 정의 리소스(CR)를 생성할 수 있습니다.

프로세스

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

    $ oc login -u <username>
  2. 다음과 같은 내용과 함께 NooBaa CR 구성 파일, noobaa.yml을 생성합니다.

    apiVersion: noobaa.io/v1alpha1
    kind: NooBaa
    metadata:
      name: noobaa
      namespace: openshift-storage
    spec:
     dbResources:
       requests:
         cpu: 0.5 1
         memory: 1Gi
     coreResources:
       requests:
         cpu: 0.5 2
         memory: 1Gi
    1 2
    매우 작은 클러스터의 경우 cpu 값을 0.1로 변경할 수 있습니다.
  3. NooBaa 오브젝트를 생성합니다.

    $ oc create -f noobaa.yml
  4. 다음과 같은 내용과 함께 BackingStore CR 구성 파일 bs.yml을 생성합니다.

    apiVersion: noobaa.io/v1alpha1
    kind: BackingStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: mcg-pv-pool-bs
      namespace: openshift-storage
    spec:
      pvPool:
        numVolumes: 3 1
        resources:
          requests:
            storage: 50Gi 2
        storageClass: gp2 3
      type: pv-pool
    1
    영구 볼륨 풀에서 볼륨 수를 지정합니다.
    2
    볼륨의 크기를 지정합니다.
    3
    스토리지 클래스를 지정합니다.
  5. BackingStore 오브젝트를 생성합니다.

    $ oc create -f bs.yml
  6. 다음과 같은 내용으로 BucketClass CR 구성 파일, bc.yml을 생성합니다.

    apiVersion: noobaa.io/v1alpha1
    kind: BucketClass
    metadata:
      labels:
        app: noobaa
      name: mcg-pv-pool-bc
      namespace: openshift-storage
    spec:
      placementPolicy:
        tiers:
        - backingStores:
          - mcg-pv-pool-bs
          placement: Spread
  7. BucketClass 오브젝트를 생성합니다.

    $ oc create -f bc.yml
  8. 다음과 같은 내용과 함께 ObjectBucketClaim CR 구성 파일, obc.yml을 생성합니다.

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: migstorage
      namespace: openshift-storage
    spec:
      bucketName: migstorage 1
      storageClassName: openshift-storage.noobaa.io
      additionalConfig:
        bucketclass: mcg-pv-pool-bc
    1
    MTC 웹 콘솔에 복제 리포지토리를 추가하기 위한 버킷 이름을 기록합니다.
  9. ObjectBucketClaim 오브젝트를 생성합니다.

    $ oc create -f obc.yml
  10. 리소스 생성 프로세스를 보고 ObjectBucketClaim 상태가 Bound인지 확인합니다.

    $ watch -n 30 'oc get -n openshift-storage objectbucketclaim migstorage -o yaml'

    이 프로세스는 5-10분 정도 걸릴 수 있습니다.

  11. MTC 웹 콘솔에 복제 리포지토리를 추가할 때 필요한 다음 값을 확보하고 기록합니다.

    • S3 끝점:

      $ oc get route -n openshift-storage s3
    • S3 공급자 액세스 키:

      $ oc get secret -n openshift-storage migstorage -o go-template='{{ .data.AWS_ACCESS_KEY_ID }}' | base64 --decode
    • S3 공급자 보안 액세스 키:

      $ oc get secret -n openshift-storage migstorage -o go-template='{{ .data.AWS_SECRET_ACCESS_KEY }}' | base64 --decode

2.3.2. AWS S3 스토리지 버킷을 복제 리포지토리로 구성

AWS S3 스토리지 버킷을 MTC(Migration Toolkit for Containers)의 복제 리포지토리로 구성할 수 있습니다.

사전 요구 사항

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

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

프로세스

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

    $ aws s3api create-bucket \
        --bucket <bucket_name> \ 1
        --region <bucket_region> 2
    1
    S3 버킷 이름을 지정합니다.
    2
    S3 버킷 영역을 지정합니다(예: us-east-1).
  2. IAM 사용자 velero를 생성합니다.

    $ aws iam create-user --user-name velero
  3. EC2 EBS 스냅샷 정책을 생성합니다.

    $ cat > velero-ec2-snapshot-policy.json <<EOF
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "ec2:DescribeVolumes",
                    "ec2:DescribeSnapshots",
                    "ec2:CreateTags",
                    "ec2:CreateVolume",
                    "ec2:CreateSnapshot",
                    "ec2:DeleteSnapshot"
                ],
                "Resource": "*"
            }
        ]
    }
    EOF
  4. 하나 또는 모든 S3 버킷에 대한 AWS S3 액세스 정책을 생성합니다.

    $ cat > velero-s3-policy.json <<EOF
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "s3:GetObject",
                    "s3:DeleteObject",
                    "s3:PutObject",
                    "s3:AbortMultipartUpload",
                    "s3:ListMultipartUploadParts"
                ],
                "Resource": [
                    "arn:aws:s3:::<bucket_name>/*" 1
                ]
            },
            {
                "Effect": "Allow",
                "Action": [
                    "s3:ListBucket",
                    "s3:GetBucketLocation",
                    "s3:ListBucketMultipartUploads"
                ],
                "Resource": [
                    "arn:aws:s3:::<bucket_name>" 2
                ]
            }
        ]
    }
    EOF
    1 2
    단일 S3 버킷에 대한 액세스 권한을 부여하려면 버킷 이름을 지정합니다. 모든 AWS S3 버킷에 대한 액세스 권한을 부여하려면 다음 예제와 같이 버킷 이름 대신 *를 지정합니다.

    출력 예

    "Resource": [
        "arn:aws:s3:::*"

  5. EC2 EBS 정책을 velero에 연결합니다.

    $ aws iam put-user-policy \
      --user-name velero \
      --policy-name velero-ebs \
      --policy-document file://velero-ec2-snapshot-policy.json
  6. AWS S3 정책을 velero에 연결합니다.

    $ aws iam put-user-policy \
      --user-name velero \
      --policy-name velero-s3 \
      --policy-document file://velero-s3-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>, 1
            "AccessKeyId": <AWS_ACCESS_KEY_ID> 2
        }
    }
    1 2
    MTC 웹 콘솔에 AWS 리포지토리를 추가하기 위해 AWS_SECRET_ACCESS_KEYAWS_ACCESS_KEY_ID를 기록합니다.

2.3.3. Google Cloud Provider 스토리지 버킷을 복제 리포지토리로 구성

GCP(Google Cloud Provider) 스토리지 버킷을 MTC(Migration Toolkit for Containers)의 복제 리포지토리로 구성할 수 있습니다.

사전 요구 사항

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

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

프로세스

  1. gsutil에 로그인합니다.

    $ gsutil init

    출력 예

    Welcome! This command will take you through the configuration of gcloud.
    
    Your current configuration has been set to: [default]
    
    To continue, you must login. Would you like to login (Y/n)?

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

    $ BUCKET=<bucket_name> 1
    1
    버킷 이름을 지정합니다.
  3. 스토리지 버킷을 생성합니다.

    $ gsutil mb gs://$BUCKET/
  4. PROJECT_ID 변수를 활성 프로젝트로 설정합니다.

    $ PROJECT_ID=`gcloud config get-value project`
  5. Velero IAM 서비스 계정을 생성합니다.

    $ gcloud iam service-accounts create velero \
        --display-name "Velero Storage"
  6. SERVICE_ACCOUNT_EMAIL 변수를 생성합니다.

    $ SERVICE_ACCOUNT_EMAIL=`gcloud iam service-accounts list \
      --filter="displayName:Velero Storage" \
      --format 'value(email)'`
  7. ROLE_PERMISSIONS 변수를 생성합니다.

    $ 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
    )
  8. velero.server 사용자 정의 역할을 생성합니다.

    $ gcloud iam roles create velero.server \
        --project $PROJECT_ID \
        --title "Velero Server" \
        --permissions "$(IFS=","; echo "${ROLE_PERMISSIONS[*]}")"
  9. 프로젝트에 IAM 정책 바인딩을 추가합니다.

    $ gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member serviceAccount:$SERVICE_ACCOUNT_EMAIL \
        --role projects/$PROJECT_ID/roles/velero.server
  10. IAM 서비스 계정을 업데이트합니다.

    $ gsutil iam ch serviceAccount:$SERVICE_ACCOUNT_EMAIL:objectAdmin gs://${BUCKET}
  11. IAM 서비스 계정 키를 현재 디렉터리의 credentials-velero 파일에 저장합니다.

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

2.3.4. Microsoft Azure Blob 스토리지 컨테이너를 복제 리포지토리로 구성

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

사전 요구 사항

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

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

프로세스

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

    $ AZURE_RESOURCE_GROUP=Velero_Backups
  2. Azure 리소스 그룹을 생성합니다.

    $ az group create -n $AZURE_RESOURCE_GROUP --location <CentralUS> 1
    1
    위치를 지정합니다.
  3. AZURE_STORAGE_ACCOUNT_ID 변수를 설정합니다.

    $ AZURE_STORAGE_ACCOUNT_ID=velerobackups
  4. 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
  5. BLOB_CONTAINER 변수를 설정합니다.

    $ BLOB_CONTAINER=velero
  6. Azure Blob 스토리지 컨테이너를 생성합니다.

    $ az storage container create \
      -n $BLOB_CONTAINER \
      --public-access off \
      --account-name $AZURE_STORAGE_ACCOUNT_ID
  7. 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`
  8. 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

2.4. 애플리케이션 마이그레이션

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

2.4.1. 사전 요구 사항

MTC(Migration Toolkit for Containers)에는 다음과 같은 사전 요구 사항이 있습니다.

  • 모든 클러스터에서 cluster-admin 권한이 있는 사용자로 로그인합니다.
  • MTC 버전은 모든 클러스터에서 동일해야 합니다.
  • 클러스터:

    • 소스 클러스터를 최신 MTC z-stream 릴리스로 업그레이드해야 합니다.
    • migration-controller pod가 실행 중인 클러스터는 다른 클러스터에 대한 무제한 액세스 권한이 있어야 합니다.
    • 클러스터는 서로에 대한 무제한 네트워크 액세스 권한이 있어야 합니다.
    • 클러스터에 복제 리포지토리에 대한 무제한 네트워크 액세스 권한이 있어야 합니다.
    • 클러스터는 포트 443에서 OpenShift 경로를 사용하여 통신할 수 있어야 합니다.
    • 클러스터에는 중요한 조건이 없어야 합니다.
    • 클러스터가 준비 상태여야 합니다.
  • 볼륨 마이그레이션:

    • PV(영구 볼륨)가 유효해야 합니다.
    • PV를 영구 볼륨 클레임에 바인딩해야 합니다.
    • 이동 방법을 사용하여 PV를 복사하는 경우 클러스터에 원격 볼륨에 대한 무제한 액세스 권한이 있어야 합니다.
    • 스냅샷 복사 방법을 사용하여 PV를 복사하는 경우 다음 사전 요구 사항이 적용됩니다.

      • 클라우드 공급자는 스냅샷을 지원해야 합니다.
      • 볼륨에는 동일한 클라우드 프로바이더가 있어야 합니다.
      • 볼륨은 동일한 지리적 지역에 있어야 합니다.
      • 볼륨에는 동일한 스토리지 클래스가 있어야 합니다.
  • 프록시 환경에서 직접 볼륨 마이그레이션을 수행하는 경우 Stunnel TCP 프록시를 구성해야 합니다.
  • 직접 이미지 마이그레이션을 수행하는 경우 소스 클러스터의 내부 레지스트리를 외부 트래픽에 노출해야 합니다.

2.4.1.1. CA 인증서 번들 파일 생성

자체 서명된 인증서를 사용하여 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 번들 파일의 이름을 지정합니다.

2.4.1.2. 직접 볼륨 마이그레이션을 위한 프록시 구성

프록시 뒤에서 소스 클러스터에서 직접 볼륨 마이그레이션을 수행하는 경우 MigrationController 사용자 정의 리소스(CR)에서 Stunnel 프록시를 구성해야 합니다. Stunnel은 인증서를 변경하지 않고 TCP 연결을 위해 소스 클러스터와 대상 클러스터 간에 투명 터널을 생성합니다.

참고

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

사전 요구 사항

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

프로세스

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

    $ oc get migrationcontroller <migration_controller> -n openshift-migration
  3. stunnel_tcp_proxy 매개변수를 추가합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigrationController
    metadata:
      name: migration-controller
      namespace: openshift-migration
    ...
    spec:
      stunnel_tcp_proxy: <stunnel_proxy> 1
    1
    Stunnel 프록시를 지정합니다. http://<user_name>:<password>@<ip_address>:<port>
  4. 매니페스트를 migration-controller.yaml로 저장합니다.
  5. 업데이트된 매니페스트를 적용합니다.

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

2.4.1.3. 마이그레이션 후크의 Ansible 플레이북 작성

마이그레이션 후크로 사용할 Ansible 플레이북을 작성할 수 있습니다. MTC 웹 콘솔을 사용하거나 MigPlan 사용자 정의 리소스(CR) 매니페스트에서 spec.hooks 매개변수의 값을 지정하여 후크가 마이그레이션 계획에 추가됩니다.

Ansible 플레이북은 후크 컨테이너에 구성 맵으로 마운트됩니다. 후크 컨테이너는 MigPlan CR에 지정된 클러스터, 서비스 계정 및 네임스페이스를 사용하여 작업으로 실행됩니다. 후크 컨테이너는 클러스터에서 실행되기 전에 작업에 인증이 필요하지 않도록 지정된 서비스 계정 토큰을 사용합니다.

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

2.4.1.3.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', 'migplan_name') }}"

2.4.1.4. 추가 리소스

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

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

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

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

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

사전 요구 사항

  • Azure 스냅샷을 사용하여 데이터를 복사하는 경우:

    • 클러스터의 Azure 리소스 그룹 이름을 지정해야 합니다.
    • 클러스터는 동일한 Azure 리소스 그룹에 있어야 합니다.
    • 클러스터는 동일한 지역 위치에 있어야 합니다.

프로세스

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

    $ oc sa get-token migration-controller -n openshift-migration
    eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJtaWciLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoibWlnLXRva2VuLWs4dDJyIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6Im1pZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImE1YjFiYWMwLWMxYmYtMTFlOS05Y2NiLTAyOWRmODYwYjMwOCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDptaWc6bWlnIn0.xqeeAINK7UXpdRqAtOj70qhBJPeMwmgLomV9iFxr5RoqUgKchZRG2J2rkqmPm6vr7K-cm7ibD1IBpdQJCcVDuoHYsFgV4mp9vgOfn9osSDp2TGikwNz4Az95e81xnjVUmzh-NjDsEpw71DH92iHV_xt2sTwtzftS49LpPW2LjrV0evtNBP_t_RfskdArt5VSv25eORl7zScqfe1CiMkcVbf2UqACQjo3LbkpfN26HAioO2oH0ECPiRzT0Xyh-KwFutJLS9Xgghyw-LD9kPKcE_xbbJ9Y4Rqajh7WdPYuB0Jd9DPVrslmzK-F6cgHHYoZEv0SvLQi-PO0rpDrcjOEQQ
  3. MTC 웹 콘솔에서 클러스터를 클릭합니다.
  4. 클러스터 추가를 클릭합니다.
  5. 다음 필드를 작성합니다.

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

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

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

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

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

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

사전 요구 사항

  • 데이터를 마이그레이션하기 위해 오브젝트 스토리지 버킷을 구성해야 합니다.

프로세스

  1. MTC 웹 콘솔에서 복제 리포지토리를 클릭합니다.
  2. 리포지토리 추가를 클릭합니다.
  3. 스토리지 공급자 유형을 선택하고 다음 필드를 작성합니다.

    • AWS S3, MCG 및 일반 S3 공급자용 AWS:

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

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

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

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

2.4.2.4. MTC 웹 콘솔에서 마이그레이션 계획 생성

MTC(Migration Toolkit for Containers) 웹 콘솔에서 마이그레이션 계획을 생성할 수 있습니다.

사전 요구 사항

  • 모든 클러스터에서 cluster-admin 권한이 있는 사용자로 로그인합니다.
  • 동일한 MTC 버전이 모든 클러스터에 설치되어 있는지 확인해야 합니다.
  • MTC 웹 콘솔에 클러스터와 복제 리포지토리를 추가해야 합니다.
  • 이동 데이터 복사 방법을 사용하여 PV(영구 볼륨)를 마이그레이션하려면 소스 및 대상 클러스터에 원격 볼륨에 대한 중단되지 않은 네트워크 액세스가 있어야 합니다.
  • 직접 이미지 마이그레이션을 사용하려면 소스 클러스터의 MigCluster 사용자 정의 리소스 매니페스트에서 내부 이미지 레지스트리의 노출된 경로를 지정해야 합니다.

프로세스

  1. MTC 웹 콘솔에서 마이그레이션 계획을 클릭합니다.
  2. 마이그레이션 계획 추가를 클릭합니다.
  3. 계획 이름을 입력하고 다음 클릭합니다.

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

  4. 소스 클러스터를 선택합니다.
  5. 대상 클러스터를 선택합니다.
  6. 복제 리포지토리를 선택합니다.
  7. 마이그레이션할 프로젝트를 선택하고 다음을 클릭합니다.
  8. 소스 클러스터, 대상 클러스터, 리포지토리를 선택하고 다음을 클릭합니다.
  9. 네임스페이스 페이지에서 마이그레이션할 프로젝트를 선택하고 다음을 클릭합니다.
  10. 영구 볼륨 페이지에서 각 PV의 마이그레이션 유형을 클릭합니다.

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

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

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

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

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

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

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

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

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

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

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

    5. 소스 클러스터 또는 대상 클러스터를 선택합니다.
    6. 서비스 계정 이름서비스 계정 네임스페이스를 입력합니다.
    7. 후크의 마이그레이션 단계를 선택합니다.

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

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

2.4.2.5. MTC 웹 콘솔에서 마이그레이션 계획 실행

MTC(Migration Toolkit for Containers) 웹 콘솔에서 생성한 마이그레이션 계획을 사용하여 애플리케이션 및 데이터를 준비하거나 마이그레이션할 수 있습니다.

참고

마이그레이션 프로세스 중에 MTC는 마이그레이션된 PV(영구 볼륨)의 회수 정책을 대상 클러스터에서 Retain으로 설정합니다.

Backup 사용자 정의 리소스에는 원래 회수 정책을 나타내는 PVOriginalReclaimPolicy 주석이 포함되어 있습니다. 마이그레이션된 PV의 회수 정책을 수동으로 복원할 수 있습니다.

사전 요구 사항

MTC 웹 콘솔에는 다음이 포함되어야 합니다.

  • Ready 상태의 소스 클러스터
  • Ready 상태의 대상 클러스터
  • 복제 리포지토리
  • 유효한 마이그레이션 계획

프로세스

  1. 소스 클러스터에 로그인합니다.
  2. 오래된 이미지 삭제:

    $ oc adm prune images
  3. MTC 웹 콘솔에 로그인하고 마이그레이션 계획을 클릭합니다.
  4. 마이그레이션 계획 옆에 있는 옵션 메뉴 kebab 를 클릭하고 단계를 선택하여 애플리케이션을 중지하지 않고 소스 클러스터에서 대상 클러스터로 데이터를 복사합니다.

    실제 마이그레이션 시간을 줄이기 위해 단계를 여러 번 실행할 수 있습니다.

  5. 애플리케이션 워크로드를 마이그레이션할 준비가 되었으면 마이그레이션 계획 이외의 옵션 메뉴 kebab마이그레이션을 선택합니다.
  6. 선택 사항: 마이그레이션 창에서 마이그레이션 중에 소스 클러스터에서 애플리케이션을 중지하지 않음을 선택할 수 있습니다.
  7. 마이그레이션을 클릭합니다.
  8. 마이그레이션이 완료되면 OpenShift Container Platform 웹 콘솔에서 애플리케이션이 성공적으로 마이그레이션되었는지 확인합니다.

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

2.4.3. 명령줄에서 애플리케이션 마이그레이션

MTC 사용자 정의 리소스(CR)를 사용하여 명령줄에서 애플리케이션을 마이그레이션할 수 있습니다.

로컬 클러스터에서 원격 클러스터, 원격 클러스터에서 로컬 클러스터, 원격 클러스터, 원격 클러스터 간에 애플리케이션을 마이그레이션할 수 있습니다.

MTC 용어

다음 용어는 클러스터 구성과 관련이 있습니다.

  • host 클러스터:

    • migration-controller 포드는 host 클러스터에서 실행됩니다.
    • host 클러스터에 직접 이미지 마이그레이션을 위해 노출된 보안 레지스트리 경로가 필요하지 않습니다.
  • 로컬 클러스터: 로컬 클러스터는 host 클러스터와 자주 동일하지만 필수 클러스터는 아닙니다.
  • 원격 클러스터:

    • 원격 클러스터에 직접 이미지 마이그레이션을 위해 노출된 보안 레지스트리 경로를 보유해야 합니다.
    • 원격 클러스터에 migration-controller 서비스 계정 토큰이 포함된 Secret CR이 있어야 합니다.

다음 용어는 마이그레이션 수행과 관련이 있습니다.

  • 소스 클러스터: 애플리케이션을 마이그레이션하는 클러스터입니다.
  • 대상 클러스터: 애플리케이션이 마이그레이션되는 클러스터입니다.

2.4.3.1. Migration Toolkit for Containers API를 사용하여 애플리케이션 마이그레이션

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

로컬 클러스터에서 원격 클러스터, 원격 클러스터에서 로컬 클러스터, 원격 클러스터, 원격 클러스터 간에 애플리케이션을 마이그레이션할 수 있습니다.

다음 프로세스에서는 간접 마이그레이션 및 직접 마이그레이션을 수행하는 방법을 설명합니다.

  • 간접 마이그레이션: 이미지, 볼륨 및 Kubernetes 오브젝트는 소스 클러스터에서 복제 리포지토리로 복사한 다음 복제 리포지토리에서 대상 클러스터로 복사됩니다.
  • 직접 마이그레이션: 소스 클러스터에서 대상 클러스터로 직접 이미지 또는 볼륨이 복사됩니다. 직접 이미지 마이그레이션 및 직접 볼륨 마이그레이션은 성능에 큰 이점이 있습니다.

다음 사용자 정의 리소스(CR)를 생성하여 마이그레이션을 수행합니다.

  • MigCluster CR: host, 로컬 또는 원격 클러스터를 정의합니다.

    migration-controller 포드는 host 클러스터에서 실행됩니다.

  • Secret CR: 원격 클러스터 또는 스토리지에 대한 인증 정보를 포함합니다.
  • MigStorage CR: 복제 리포지토리를 정의합니다.

    스토리지 공급자마다 MigStorage CR 매니페스트의 다른 매개변수가 필요합니다.

  • MigPlan CR: 마이그레이션 계획을 정의합니다.
  • MigMigration CR: 연결된 MigPlan에 정의된 마이그레이션을 수행합니다.

    다음과 같은 목적으로 단일 MigPlan CR에 대해 여러 MigMigration CR을 생성할 수 있습니다.

  • 단계 마이그레이션을 수행하려면 마이그레이션을 실행하기 전에 애플리케이션을 중지하지 않고 대부분의 데이터를 복사합니다. 단계별 마이그레이션은 마이그레이션의 성능을 향상시킵니다.
  • 진행 중인 마이그레이션을 취소하려면
  • 완료된 마이그레이션을 롤백하려면

사전 요구 사항

  • 모든 클러스터에 대한 cluster-admin 권한이 있어야 합니다.
  • OpenShift Container Platform CLI(oc)를 설치해야 합니다.
  • 모든 클러스터에 Migration Toolkit for Containers Operator를 설치해야 합니다.
  • 모든 클러스터에서 설치된 Migration Toolkit for Containers Operator 버전이 동일해야 합니다.
  • 복제 리포지토리로 오브젝트 스토리지를 구성해야 합니다.
  • 직접 이미지 마이그레이션을 사용하는 경우 모든 원격 클러스터에 보안 레지스트리 경로를 노출해야 합니다.
  • 직접 볼륨 마이그레이션을 사용하는 경우 소스 클러스터에 HTTP 프록시가 구성되어 있지 않아야 합니다.

프로세스

  1. host-cluster.yaml이라는 host 클러스터에 대한 MigCluster CR 매니페스트를 생성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigCluster
    metadata:
      name: host
      namespace: openshift-migration
    spec:
      isHostCluster: true
  2. host 클러스터에 대한 MigCluster CR을 생성합니다.

    $ oc create -f host-cluster.yaml -n openshift-migration
  3. cluster-secret.yaml이라는 각 원격 클러스터에 대한 Secret CR 매니페스트를 생성합니다.

    apiVersion: v1
    kind: Secret
    metadata:
      name: <cluster_secret>
      namespace: openshift-config
    type: Opaque
    data:
      saToken: <sa_token> 1
    1
    원격 클러스터의 base64로 인코딩된 migration-controller 서비스 계정(SA) 토큰을 지정합니다.

    다음 명령을 실행하여 SA 토큰을 확보할 수 있습니다.

    $ oc sa get-token migration-controller -n openshift-migration | base64 -w 0
  4. 각 원격 클러스터에 대한 Secret CR을 생성합니다.

    $ oc create -f cluster-secret.yaml
  5. remote-cluster.yaml이라는 각 원격 클러스터에 대해 MigCluster CR 매니페스트를 생성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigCluster
    metadata:
      name: <remote_cluster>
      namespace: openshift-migration
    spec:
      exposedRegistryPath: <exposed_registry_route> 1
      insecure: false 2
      isHostCluster: false
      serviceAccountSecretRef:
        name: <remote_cluster_secret> 3
        namespace: openshift-config
      url: <remote_cluster_url> 4
    1
    선택 사항: 직접 이미지 마이그레이션을 사용하는 경우 노출된 레지스트리 경로를 지정합니다(예: docker-registry-default.apps.example.com).
    2
    false인 경우 SSL 확인이 활성화됩니다. CA 인증서가 필요하지 않거나 true인 경우 확인되지 않습니다.
    3
    원격 클러스터의 Secret CR을 지정합니다.
    4
    원격 클러스터의 URL을 지정합니다.
  6. 각 원격 클러스터에 대해 MigCluster CR을 생성합니다.

    $ oc create -f remote-cluster.yaml -n openshift-migration
  7. 모든 클러스터가 Ready 상태에 있는지 확인합니다.

    $ oc describe cluster <cluster_name>
  8. storage-secret.yaml이라는 복제 리포지토리의 Secret CR 매니페스트를 생성합니다.

    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
    1
    base64 형식으로 키 ID를 지정합니다.
    2
    base64 형식으로 시크릿 키를 지정합니다.

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

    $ echo -n "<key>" | base64 -w 0 1
    1
    키 ID 또는 시크릿 키를 지정합니다. 두 키 모두 base64로 인코딩되어야 합니다.
  9. 복제 리포지토리에 대한 Secret CR을 생성합니다.

    $ oc create -f storage-secret.yaml
  10. migstorage.yaml이라는 복제 리포지토리에 대한 MigStorage CR 매니페스트를 생성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigStorage
    metadata:
      name: <storage_name>
      namespace: openshift-migration
    spec:
      backupStorageConfig:
        awsBucketName: <bucket_name> 1
        credsSecretRef:
          name: <storage_secret_ref> 2
          namespace: openshift-config
      backupStorageProvider: <storage_provider_name> 3
      volumeSnapshotConfig:
        credsSecretRef:
          name: <storage_secret_ref> 4
          namespace: openshift-config
      volumeSnapshotProvider: <storage_provider_name> 5
    1
    버킷 이름을 지정합니다.
    2
    오브젝트 스토리지의 Secrets CR을 지정합니다. 오브젝트 스토리지의 Secrets CR에 저장된 인증 정보가 올바른지 확인해야 합니다.
    3
    스토리지 공급자를 지정합니다.
    4
    선택 사항: 스냅샷을 사용하여 데이터를 복사하는 경우 오브젝트 스토리지의 Secrets CR을 지정합니다. 오브젝트 스토리지의 Secrets CR에 저장된 인증 정보가 올바른지 확인해야 합니다.
    5
    선택 사항: 스냅샷을 사용하여 데이터를 복사하는 경우 스토리지 공급자를 지정합니다.
  11. MigStorage CR을 생성합니다.

    $ oc create -f migstorage.yaml -n openshift-migration
  12. MigStorage CR이 Ready 상태에 있는지 확인합니다.

    $ oc describe migstorage <migstorage_name>
  13. migplan.yaml이라는 MigPlan CR 매니페스트를 생성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigPlan
    metadata:
      name: <migration_plan>
      namespace: openshift-migration
    spec:
      destMigClusterRef:
        name: host
        namespace: openshift-migration
      indirectImageMigration: true 1
      indirectVolumeMigration: true 2
      migStorageRef:
        name: <migstorage_ref> 3
        namespace: openshift-migration
      namespaces:
        - <application_namespace> 4
      srcMigClusterRef:
        name: <remote_cluster_ref> 5
        namespace: openshift-migration
    1
    false인 경우 직접 이미지 마이그레이션이 활성화됩니다.
    2
    false인 경우 직접 볼륨 마이그레이션이 활성화됩니다.
    3
    MigStorage CR 인스턴스의 이름을 지정합니다.
    4
    마이그레이션할 하나 이상의 네임스페이스를 지정합니다.
    5
    소스 클러스터 MigCluster 인스턴스의 이름을 지정합니다.
  14. MigPlan CR을 만듭니다.

    $ oc create -f migplan.yaml -n openshift-migration
  15. MigPlan 인스턴스를 보고 Ready 상태인지 확인합니다.

    $ oc describe migplan <migplan_name> -n openshift-migration
  16. migmigration.yaml이라는 MigMigration CR 매니페스트를 생성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      name: <migmigration_name>
      namespace: openshift-migration
    spec:
      migPlanRef:
        name: <migplan_name> 1
        namespace: openshift-migration
      quiescePods: true 2
      stage: false 3
      rollback: false 4
    1
    MigPlan CR 이름을 지정합니다.
    2
    true인 경우 마이그레이션 전에 소스 클러스터의 포드가 중지됩니다.
    3
    애플리케이션을 중지하지 않고 대부분의 데이터를 복사하는 단계 마이그레이션이 true인 경우 수행됩니다.
    4
    true인 경우 완료된 마이그레이션이 롤백됩니다.
  17. MigPlan CR에 정의된 마이그레이션을 시작하도록 MigMigration CR을 생성합니다.

    $ oc create -f migmigration.yaml -n openshift-migration
  18. MigMigration CR을 확인하여 마이그레이션 진행 상황을 확인합니다.

    $ oc watch migmigration <migmigration_name> -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:       my_application
        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

2.4.3.2. MTC 사용자 정의 리소스 매니페스트

MTC(Migration Toolkit for Containers)는 다음 사용자 정의 리소스(CR) 매니페스트를 사용하여 애플리케이션 마이그레이션을 위한 CR을 생성합니다.

2.4.3.2.1. DirectImageMigration

DirectImageMigration CR은 소스 클러스터에서 대상 클러스터로 이미지를 직접 복사합니다.

apiVersion: migration.openshift.io/v1alpha1
kind: DirectImageMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <directimagemigration_name>
spec:
  srcMigClusterRef:
    name: <source_cluster_ref> 1
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster_ref> 2
    namespace: openshift-migration
  namespaces:
  - <namespace> 3
1
소스 클러스터의 MigCluster CR 이름을 지정합니다.
2
대상 클러스터의 MigCluster CR 이름을 지정합니다.
3
마이그레이션할 이미지를 포함하는 하나 이상의 네임스페이스를 지정합니다.
2.4.3.2.2. DirectImageStreamMigration

DirectImageStreamMigration CR은 소스 클러스터에서 대상 클러스터로 직접 이미지 스트림 참조를 복사합니다.

apiVersion: migration.openshift.io/v1alpha1
kind: DirectImageStreamMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: directimagestreammigration_name
spec:
  srcMigClusterRef:
    name: <source_cluster_ref> 1
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster_ref> 2
    namespace: openshift-migration
  imageStreamRef:
    name: <image_stream_name> 3
    namespace: <source_image_stream_namespace> 4
  destNamespace: <destination_image_stream_namespace> 5
1
소스 클러스터의 MigCluster CR 이름을 지정합니다.
2
대상 클러스터의 MigCluster CR 이름을 지정합니다.
3
이미지 스트림 이름을 지정합니다.
4
소스 클러스터에서 이미지 스트림 네임스페이스를 지정합니다.
5
대상 클러스터에서 이미지 스트림 네임스페이스를 지정합니다.
2.4.3.2.3. DirectVolumeMigration

DirectVolumeMigration CR은 소스 클러스터에서 대상 클러스터로 직접 PV(영구 볼륨)를 복사합니다.

apiVersion: migration.openshift.io/v1alpha1
kind: DirectVolumeMigration
metadata:
  name: <directvolumemigration_name>
  namespace: openshift-migration
spec:
  createDestinationNamespaces: false 1
  deleteProgressReportingCRs: false 2
  destMigClusterRef:
    name: host 3
    namespace: openshift-migration
  persistentVolumeClaims:
  - name: <pvc_name> 4
    namespace: <pvc_namespace> 5
  srcMigClusterRef:
    name: <source_cluster_ref> 6
    namespace: openshift-migration
1
true인 경우 대상 클러스터의 PV에 네임스페이스가 생성됩니다.
2
DirectVolumeMigrationProgress CR은 true인 경우 마이그레이션 후 삭제됩니다. 문제 해결을 위해 DirectVolumeMigrationProgress CR이 유지되기 위한 기본값은 false입니다.
3
대상 클러스터가 호스트 클러스터가 아닌 경우 클러스터 이름을 업데이트합니다.
4
직접 볼륨 마이그레이션을 사용하여 마이그레이션할 하나 이상의 PVC를 지정합니다.
5
각 PVC의 네임스페이스를 지정합니다.
6
소스 클러스터의 MigCluster CR 이름을 지정합니다.
2.4.3.2.4. DirectVolumeMigrationProgress

DirectVolumeMigrationProgress CR은 DirectVolumeMigration CR의 진행 상황을 보여줍니다.

apiVersion: migration.openshift.io/v1alpha1
kind: DirectVolumeMigrationProgress
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: directvolumemigrationprogress_name
spec:
  clusterRef:
    name: source_cluster
    namespace: openshift-migration
  podRef:
    name: rsync_pod
    namespace: openshift-migration
2.4.3.2.5. MigAnalytic

MigAnalytic CR은 이미지 수, Kubernetes 리소스 및 관련 MigPlan CR에서 PV 용량을 수집합니다.

apiVersion: migration.openshift.io/v1alpha1
kind: MigAnalytic
metadata:
  annotations:
    migplan: <migplan_name> 1
  name: miganalytic_name
  namespace: openshift-migration
  labels:
    migplan: <migplan_name> 2
spec:
  analyzeImageCount: true 3
  analyzeK8SResources: true 4
  analyzePVCapacity: true 5
  listImages: false 6
  listImagesLimit: 50 7
  migPlanRef:
    name: migplan_name 8
    namespace: openshift-migration
1
MigAnalytic CR과 연관된 MigPlan CR 이름을 지정합니다.
2
MigAnalytic CR과 연관된 MigPlan CR 이름을 지정합니다.
3
선택 사항: true인 경우 이미지 수가 반환됩니다.
4
선택 사항: true인 경우 Kubernetes 리소스의 수, 종류 및 API 버전을 반환합니다.
5
선택 사항: true인 경우 PV 용량을 반환합니다.
6
true인 경우 이미지 이름 목록을 반환합니다. 출력이 과도하게 길지 않도록 기본값은 false입니다.
7
선택 사항: listImagestrue인 경우 최대 이미지 이름 수를 지정합니다.
8
MigAnalytic CR과 연관된 MigPlan CR 이름을 지정합니다.
2.4.3.2.6. MigCluster

MigCluster CR은 호스트, 로컬 또는 원격 클러스터를 정의합니다.

apiVersion: migration.openshift.io/v1alpha1
kind: MigCluster
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: host 1
  namespace: openshift-migration
spec:
  isHostCluster: true 2
  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.
# isHostCluster: false
# exposedRegistryPath: 8
# url: <destination_cluster_url> 9
# serviceAccountSecretRef:
#   name: <source_secret_ref> 10
#   namespace: openshift-config
1
선택 사항: migration-controller 포드가 이 클러스터에서 실행되지 않는 경우 클러스터 이름을 업데이트합니다.
2
migration-controller 포드는 true인 경우 이 클러스터에서 실행됩니다.
3
선택 사항: 스토리지 공급자가 Microsoft Azure인 경우 리소스 그룹을 지정합니다.
4
선택 사항: 자체 서명된 CA 인증서에 대한 인증서 번들을 생성하고 insecure 매개변수 값이 false인 경우 base64 인코딩 인증서 번들을 지정합니다.
5
false인 경우 SSL 확인이 활성화됩니다.
6
true인 경우 클러스터가 검증됩니다.
7
restic 포드가 true인 경우 생성된 후 restic 포드가 소스 클러스터에서 다시 시작됩니다.
8
선택 사항: 직접 이미지 마이그레이션을 사용하는 경우 원격 클러스터의 노출된 레지스트리 경로를 지정합니다.
9
원격 클러스터의 URL을 지정합니다.
10
원격 클러스터에 대한 Secret CR의 이름을 지정합니다.
2.4.3.2.7. MigHook

MigHook CR은 마이그레이션의 지정된 단계에서 작업을 실행하는 Ansible 플레이북 또는 사용자 정의 이미지를 정의합니다.

apiVersion: migration.openshift.io/v1alpha1
kind: MigHook
metadata:
  generateName: <hook_name_prefix> 1
  name: <hook_name> 2
  namespace: openshift-migration
spec:
  activeDeadlineSeconds: 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 또는 대상을 지정합니다.
2.4.3.2.8. MigMigration

MigMigration CR은 연결된 MigPlan CR을 실행합니다.

다음 시나리오에 동일한 MigPlan CR과 연관된 여러 MigMigration CR을 생성할 수 있습니다.

  • 소스 클러스터에서 포드를 중지하지 않고도 여러 단계 또는 증분 마이그레이션을 실행하여 데이터를 복사할 수 있습니다. 단계별 마이그레이션을 실행하면 실제 마이그레이션의 성능이 향상됩니다.
  • 진행 중인 마이그레이션을 취소할 수 있습니다.
  • 마이그레이션을 롤백할 수 있습니다.
apiVersion: migration.openshift.io/v1alpha1
kind: MigMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: migmigration_name
  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_ref> 7
    namespace: openshift-migration
1
true인 경우 진행 중인 마이그레이션이 취소됩니다.
2
true인 경우 완료된 마이그레이션이 롤백됩니다.
3
true인 경우 데이터가 증분적으로 복사되고 소스 클러스터의 포드가 중지되지 않습니다.
4
소스 클러스터의 포드는 true인 경우 마이그레이션의 Backup 단계 이후 0으로 확장됩니다.
5
마이그레이션 중에 적용되는 레이블 및 주석은 true인 경우 유지됩니다.
6
대상 클러스터에서 마이그레이션된 포드의 상태가 확인되고 Running 상태에 없는 포드의 이름이 true인 경우 반환됩니다.
7
migPlanRef.name: 연결된 MigPlan CR의 이름을 지정합니다.
2.4.3.2.9. MigPlan

MigPlan CR은 마이그레이션 계획의 매개변수를 정의합니다. 동일한 매개변수로 마이그레이션 중인 가상 머신 그룹이 포함되어 있습니다.

apiVersion: migration.openshift.io/v1alpha1
kind: MigPlan
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: migplan_name
  namespace: openshift-migration
spec:
  closed: false 1
  srcMigClusterRef:
    name: <source_migcluster_ref> 2
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_migcluster_ref> 3
    namespace: openshift-migration
  hooks: 4
    - executionNamespace: <namespace> 5
      phase: <migration_phase> 6
      reference:
        name: <mighook_name> 7
        namespace: <hook_namespace> 8
      serviceAccount: <service_account> 9
  indirectImageMigration: true 10
  indirectVolumeMigration: false 11
  migStorageRef:
    name: <migstorage_name> 12
    namespace: openshift-migration
  namespaces:
  - <namespace>  13
  refresh: false  14
1
true인 경우 마이그레이션이 완료되었습니다. 이 MigPlan CR에 대해 다른 MigMigration CR을 생성할 수 없습니다.
2
소스 클러스터 MigCluster CR의 이름을 지정합니다.
3
대상 클러스터 MigCluster CR의 이름을 지정합니다.
4
선택 사항: 최대 4개의 마이그레이션 후크를 지정할 수 있습니다.
5
선택 사항: 후크를 실행할 네임스페이스를 지정합니다.
6
선택 사항: 후크가 실행되는 마이그레이션 단계를 지정합니다. 하나의 후크를 하나의 단계에 할당할 수 있습니다. 예상되는 값은 PreBackup, PostBackup, PreRestorePostRestore입니다.
7
선택 사항: MigHook CR의 이름을 지정합니다.
8
선택 사항: MigHook CR의 네임스페이스를 지정합니다.
9
선택 사항: cluster-admin 권한이 있는 서비스 계정을 지정합니다.
10
true인 경우 직접 이미지 마이그레이션이 비활성화됩니다. 이미지는 소스 클러스터에서 복제 리포지토리로, 복제 리포지토리에서 대상 클러스터로 복사됩니다.
11
true인 경우 직접 볼륨 마이그레이션이 비활성화됩니다. PV는 소스 클러스터에서 복제 리포지토리로, 복제 리포지토리에서 대상 클러스터로 복사됩니다.
12
MigStorage CR의 이름을 지정합니다.
13
하나 이상의 네임스페이스를 지정합니다.
14
MigPlan CR이 true인 경우 검증됩니다.
2.4.3.2.10. MigStorage

MigStorage CR은 복제 리포지토리의 오브젝트 스토리지를 설명합니다. Amazon Web Services, Microsoft Azure, Google Cloud Storage 및 일반 S3 호환 클라우드 스토리지(예: Minio 또는 NooBaa)를 구성할 수 있습니다.

다른 공급자에는 다른 매개 변수가 필요합니다.

apiVersion: migration.openshift.io/v1alpha1
kind: MigStorage
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: migstorage_name
  namespace: openshift-migration
spec:
  backupStorageProvider: <storage_provider> 1
  volumeSnapshotProvider: 2
  backupStorageConfig:
    awsBucketName: 3
    awsRegion: 4
    credsSecretRef:
      namespace: openshift-config
      name: <storage_secret> 5
    awsKmsKeyId: 6
    awsPublicUrl: 7
    awsSignatureVersion: 8
  volumeSnapshotConfig:
    awsRegion: 9
    credsSecretRef:
      namespace: openshift-config
      name: 10
  refresh: false 11
1
스토리지 공급자를 지정합니다.
2
선택 사항: 스냅샷 복사 방법을 사용하는 경우 스토리지 공급자를 지정합니다.
3
AWS를 사용하는 경우 버킷 이름을 지정합니다.
4
AWS를 사용하는 경우 버킷 리전을 지정합니다(예: us-east-1).
5
MigStorage CR용으로 생성한 Secret CR의 이름을 지정합니다.
6
선택 사항: AWS 키 관리 서비스를 사용하는 경우 키의 고유 식별자를 지정합니다.
7
선택 사항: AWS 버킷에 대한 공용 액세스 권한이 부여된 경우 버킷 URL을 지정합니다.
8
선택 사항: 버킷에 대한 요청을 인증하기 위해 AWS 서명 버전을 지정합니다(예: 4).
9
선택 사항: 스냅샷 복사 방법을 사용하는 경우 클러스터의 지역 리전을 지정합니다.
10
선택 사항: 스냅샷 복사 방법을 사용하는 경우 MigStorage CR에 대해 생성한 Secret CR의 이름을 지정합니다.
11
true인 경우 클러스터가 검증됩니다.

2.4.4. 추가 리소스

2.4.5. 마이그레이션 계획 구성

마이그레이션할 오브젝트 수를 늘리거나 마이그레이션에서 리소스를 제외할 수 있습니다.

2.4.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 콘솔은 마이그레이션 계획을 저장할 때 경고 메시지를 표시합니다.

2.4.5.2. 마이그레이션 계획에서 리소스 제외

마이그레이션하기 위해 리소스 로드를 줄이거나 다른 도구를 사용하여 이미지 또는 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. 특정 리소스를 제외하는 매개 변수를 추가하거나 자체 제외 매개 변수가 없는 경우 excluded_resources 매개 변수에 리소스를 추가하여 spec 섹션을 업데이트합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigrationController
    metadata:
      name: migration-controller
      namespace: openshift-migration
    spec:
      disable_image_migration: true 1
      disable_pv_migration: true 2
      ...
      excluded_resources: 3
      - imagetags
      - templateinstances
      - clusterserviceversions
      - packagemanifests
      - subscriptions
      - servicebrokers
      - servicebindings
      - serviceclasses
      - serviceinstances
      - serviceplans
      - operatorgroups
      - events
    1
    마이그레이션에서 이미지 스트림을 제외하려면 disable_image_migration: true를 추가합니다. excluded_resources 매개 변수를 편집하지 마십시오. MigrationController 포드가 다시 시작되면 imagestreamsexcluded_resources에 추가됩니다.
    2
    마이그레이션 계획에서 PV를 제외하려면 disable_pv_migration: true를 추가합니다. excluded_resources 매개 변수를 편집하지 마십시오. MigrationController 포드가 다시 시작되면 persistentvolumespersistentvolumeclaimsexcluded_resources에 추가됩니다. PV 마이그레이션을 비활성화하면 마이그레이션 계획을 생성할 때 PV 검색도 비활성화됩니다.
    3
    OpenShift Container Platform 리소스를 excluded_resources 목록에 추가할 수 있습니다. 기본 제외 리소스를 삭제하지 마십시오. 이러한 리소스는 마이그레이션에 문제가 있으므로 제외해야 합니다.
  3. 변경 사항이 적용되도록 MigrationController 포드가 다시 시작될 때까지 2분 정도 기다립니다.
  4. 리소스가 제외되었는지 확인합니다.

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

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

    출력 예

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

2.5. 문제 해결

MTC(Migration Toolkit for Containers) 사용자 정의 리소스를 보고 로그를 다운로드하여 마이그레이션 실패 문제를 해결할 수 있습니다.

실패한 마이그레이션 중에 애플리케이션이 중지된 경우 데이터 손상을 방지하기 위해 마이그레이션을 롤백해야 합니다.

참고

원래 애플리케이션이 소스 클러스터에서 계속 실행 중이므로 마이그레이션 중에 애플리케이션이 중지되지 않은 경우 수동 롤백이 필요하지 않습니다.

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

2.5.2. 마이그레이션 로그 리더 사용

마이그레이션 로그 리더를 사용하여 모든 마이그레이션 로그에 대한 필터링된 보기를 표시할 수 있습니다.

프로세스

  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 옵션은 색상 없이 로그를 표시합니다.

2.5.3. 마이그레이션 로그 다운로드

MTC(Migration Toolkit for Containers) 웹 콘솔에서 Velero, ResticMigrationController 포드 로그를 다운로드하여 실패한 마이그레이션 문제를 해결할 수 있습니다.

프로세스

  1. MTC 콘솔에서 마이그레이션 계획을 클릭하여 마이그레이션 계획 목록을 확인합니다.
  2. 특정 마이그레이션 계획의 옵션 메뉴 kebab 를 클릭하고 로그를 선택합니다.
  3. 모든 클러스터에 대한 MigrationController, VeleroRestic 포드의 로그를 다운로드하려면 로그 다운로드를 클릭합니다.

    클러스터, 로그 소스 및 포드 소스를 선택한 다음 선택한 항목 다운로드를 클릭하여 단일 로그를 다운로드할 수 있습니다.

    oc logs 명령을 사용하여 CLI에서 포드 로그에 액세스할 수 있습니다.

    $ oc logs <pod-name> -f -n openshift-migration 1
    1
    포드 이름을 지정합니다.

2.5.4. 더 이상 사용되지 않는 API 업데이트

소스 클러스터에서 더 이상 사용되지 않는 API를 사용하는 경우 MTC(Migration Toolkit for Containers) 웹 콘솔에서 마이그레이션 계획을 생성할 때 다음 경고 메시지가 표시됩니다.

Some namespaces contain GVKs incompatible with destination cluster

세부 사항 보기를 클릭하여 네임스페이스 및 호환되지 않는 API를 볼 수 있습니다. 이 경고 메시지는 마이그레이션을 차단하지 않습니다.

MTC(Migration Toolkit for Containers)를 사용하여 마이그레이션하는 동안 더 이상 사용되지 않는 API는 Kubernetes 오브젝트의 Velero Backup #1에 저장됩니다. Velero Backup을 다운로드하고, 더 이상 사용되지 않는 API yaml 파일을 추출한 후 oc convert 명령으로 업데이트할 수 있습니다. 그런 다음 대상 클러스터에서 업데이트된 API를 생성할 수 있습니다.

프로세스

  1. 마이그레이션 계획을 실행합니다.
  2. MigPlan 사용자 정의 리소스 (CR)를 확인합니다.

    $ oc describe migplan <migplan_name> -n openshift-migration 1
    1
    MigPlan CR의 이름을 지정합니다.

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

    metadata:
      ...
      uid: 79509e05-61d6-11e9-bc55-02ce4781844a 1
    status:
      ...
      conditions:
      - category: Warn
        lastTransitionTime: 2020-04-30T17:16:23Z
        message: 'Some namespaces contain GVKs incompatible with destination cluster.
          See: `incompatibleNamespaces` for details'
        status: "True"
        type: GVKsIncompatible
      incompatibleNamespaces:
      - gvks: 2
        - group: batch
          kind: cronjobs
          version: v2alpha1
        - group: batch
          kind: scheduledjobs
          version: v2alpha1
    1
    MigPlan CR UID를 기록합니다.
    2
    gvks 섹션에 나열된 더 이상 사용되지 않는 API를 기록합니다.
  3. MigPlan UID와 관련된 MigMigration 이름을 가져옵니다.

    $ oc get migmigration -o json | jq -r '.items[] | select(.metadata.ownerReferences[].uid=="<migplan_uid>") | .metadata.name' 1
    1
    MigPlan CR UID를 지정합니다.
  4. MigMigration 이름과 연관된 MigMigration UID를 가져옵니다.

    $ oc get migmigration <migmigration_name> -o jsonpath='{.metadata.uid}' 1
    1
    MigMigration 이름을 지정합니다.
  5. MigMigration UID와 관련된 Velero Backup 이름을 가져옵니다.

    $ oc get backup.velero.io --selector migration-initial-backup="<migmigration_uid>" -o jsonpath={.items[*].metadata.name} 1
    1
    MigMigration UID를 지정합니다.
  6. 스토리지 공급자의 명령을 실행하여 Velero Backup의 콘텐츠를 로컬 머신으로 다운로드합니다.

    • AWS S3:

      $ aws s3 cp s3://<bucket_name>/velero/backups/<backup_name> <backup_local_dir> --recursive 1
      1
      버킷, 백업 이름 및 로컬 백업 디렉터리 이름을 지정합니다.
    • GCP:

      $ gsutil cp gs://<bucket_name>/velero/backups/<backup_name> <backup_local_dir> --recursive 1
      1
      버킷, 백업 이름 및 로컬 백업 디렉터리 이름을 지정합니다.
    • Azure:

      $ azcopy copy 'https://velerobackups.blob.core.windows.net/velero/backups/<backup_name>' '<backup_local_dir>' --recursive 1
      1
      백업 이름과 로컬 백업 디렉터리 이름을 지정합니다.
  7. Velero Backup 아카이브 파일을 추출합니다.

    $ tar -xfv <backup_local_dir>/<backup_name>.tar.gz -C <backup_local_dir>
  8. 더 이상 사용되지 않는 각 API의 오프라인 모드에서 oc convert를 실행합니다.

    $ oc convert -f <backup_local_dir>/resources/<gvk>.json
  9. 대상 클러스터에서 변환된 API를 생성합니다.

    $ oc create -f <gvk>.json

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

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

2.5.5.1. MTC 콘솔의 CA 인증서 오류

MTC 콘솔에 처음 액세스하려고 할 때 CA 인증서 오류 메시지가 표시되면 클러스터가 자체 서명된 CA 인증서를 사용하게 될 가능성이 큽니다.

오류 메시지에서 oauth-authorization-server URL로 이동하여 인증서를 수락합니다. 이 문제를 영구적으로 해결하려면 신뢰할 수 있도록 인증 기관을 설치합니다.

CA 인증서를 승인한 후 브라우저에 인증되지 않은 메시지가 표시되면 MTC 콘솔로 이동한 다음 웹 페이지를 새로 고칩니다.

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

MTC 콘솔에 자체 서명 인증서를 허용한 후 연결 시간이 초과된 메시지가 표시되면 원인은 다음 중 하나일 수 있습니다.

원인을 확인하려면 다음을 수행합니다.

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

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

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

BSL 오류 메시지

Error checking repository for stale locks

Error getting backup storage location: backupstoragelocation.velero.io \"my-bsl\" not found

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

2.5.5.4. 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. 저장을 클릭합니다.

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

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

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 오류가 있는 영구 볼륨을 식별합니다.

    Pod 볼륨 복원 오류로 CR 복원

    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를 식별합니다.

    Restic Pod 오류가 있는 PodVolumeRestore CR

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

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

    $ oc logs -f <restic-nr2v5>

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

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

Restic 권한 오류

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용 보조 그룹을 생성하고 그룹 ID를 MigrationController CR 매니페스트에 추가하여 이 문제를 해결할 수 있습니다.

프로세스

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

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

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

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

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

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

프로세스

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

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

2.5.7. Velero CLI를 사용하여 Backup 및 Restore CR을 디버깅합니다.

Velero 명령줄 인터페이스(CLI)를 사용하여 BackupRestore CR(사용자 정의 리소스) 및 부분 마이그레이션 실패를 디버깅할 수 있습니다. Velero CLI는 velero 포드에서 실행됩니다.

2.5.7.1. Velero 명령 구문

Velero CLI 명령은 다음 구문을 사용합니다.

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

$(oc get pods -n openshift-migration -o name | grep velero)를 대신해서 velero-<pod> -n openshift-migration을 지정할 수 있습니다.

2.5.7.2. 도움말 명령

Velero help 명령은 모든 Velero CLI 명령을 나열합니다.

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero --help

2.5.7.3. Describe 명령

Velero describe 명령은 Velero 리소스와 관련된 경고 및 오류 요약을 제공합니다.

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

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql

2.5.7.4. Logs 명령

Velero logs 명령은 Velero 리소스와 관련된 로그를 제공합니다.

velero <resource> logs <resource_id>

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

2.5.7.5. 부분적인 마이그레이션 실패 디버깅

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 exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore describe <restore>
    Phase:  PartiallyFailed (run 'velero restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf' for more information)
    
    Errors:
      Velero:     <none>
      Cluster:    <none>
      Namespaces:
        migration-example:  error restoring example.com/migration-example/migration-example: the server could not find the requested resource
  3. Velero logs 명령을 사용하여 Restore CR 로그를 확인합니다.

    $ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore logs <restore>
    time="2021-01-26T20:48:37Z" level=info msg="Attempting to restore migration-example: migration-example" logSource="pkg/restore/restore.go:1107" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf
    time="2021-01-26T20:48:37Z" level=info msg="error restoring migration-example: the server could not find the requested resource" logSource="pkg/restore/restore.go:1170" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

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

2.5.8. must-gather를 사용하여 데이터 수집

MTC(Migration Toolkit for Containers)의 Red Hat Customer Portal에서 고객 지원 사례를 여는 경우 must-gather 툴을 실행해야 합니다.

MTC의 openshift-migration-must-gather-rhel8 이미지는 기본 must-gather 이미지로 수집되지 않은 마이그레이션별 로그 및 데이터를 수집합니다.

프로세스

  1. must-gather 데이터를 저장하려는 디렉터리로 이동합니다.
  2. must-gather 명령을 실행합니다.

    $ oc adm must-gather --image=registry.redhat.io/rhmtc/openshift-migration-must-gather-rhel8:v1.4
  3. 인증 키 및 기타 민감한 정보를 제거합니다.
  4. must-gather 데이터 디렉터리의 콘텐츠가 포함된 아카이브 파일을 생성합니다.

    $ tar cvaf must-gather.tar.gz must-gather.local.<uid>/
  5. 압축 파일을 고객 지원 사례에 첨부 파일로 업로드합니다.

2.5.9. 마이그레이션 롤백

MTC 웹 콘솔 또는 CLI를 사용하여 마이그레이션을 롤백할 수 있습니다.

2.5.9.1. MTC 웹 콘솔에서 마이그레이션 롤백

MTC(Migration Toolkit for Containers) 웹 콘솔을 사용하여 마이그레이션을 롤백할 수 있습니다.

마이그레이션 실패로 인해 애플리케이션이 중지된 경우 영구 볼륨의 데이터 손상을 방지하려면 마이그레이션을 롤백해야 합니다.

원래 애플리케이션이 소스 클러스터에서 계속 실행 중이므로 마이그레이션 중에 애플리케이션이 중지되지 않은 경우 롤백이 필요하지 않습니다.

프로세스

  1. MTC 웹 콘솔에서 마이그레이션 계획을 클릭합니다.
  2. 마이그레이션 계획 옆의 옵션 메뉴 kebab 를 클릭하고 롤백을 선택합니다.
  3. 롤백을 클릭하고 롤백이 완료될 때까지 기다립니다.

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

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

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

CLI에서 MigMigration 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: migration-rollback
      namespace: openshift-migration
    spec:
    ...
      rollback: true
    ...
      migPlanRef:
        name: <migplan_name> 1
        namespace: openshift-migration
    EOF
    1
    연결된 MigPlan CR의 이름을 지정합니다.
  2. MTC 웹 콘솔에서 마이그레이션된 프로젝트 리소스가 대상 클러스터에서 제거되었는지 확인합니다.
  3. 마이그레이션된 프로젝트 리소스가 소스 클러스터에 있고 애플리케이션이 실행 중인지 확인합니다.

2.5.10. 확인된 문제

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

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

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

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

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

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

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

2.5.11. 추가 리소스

3장. Openshift Container Platform 4.2 이상에서 마이그레이션

3.1. Migration Toolkit for Containers 정보

MTC(Migration Toolkit for Containers)를 사용하여 OpenShift Container Platform 4.2에서 4.7으로 애플리케이션 워크로드를 마이그레이션할 수 있습니다. MTC를 사용하면 마이그레이션을 제어하고 애플리케이션 다운 타임을 최소화할 수 있습니다.

참고

소스 및 대상 클러스터가 올바르게 구성된 경우 동일한 버전의 OpenShift Container Platform 클러스터(예: 4.2에서 4.2로 또는 4.3에서 4.3로) 간에 마이그레이션할 수 있습니다.

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

Kubernetes 사용자 정의 리소스를 기반으로 하는 MTC 웹 콘솔 및 API를 사용하면 네임스페이스 단위로 스테이트풀(stateful) 및 스테이트리스(stateless) 애플리케이션 워크로드를 마이그레이션할 수 있습니다.

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

마이그레이션 후크를 사용하여 마이그레이션 중에 특정 시점에서 Ansible 플레이북을 실행할 수 있습니다. 마이그레이션 계획을 생성할 때 후크가 추가됩니다.

3.1.1. Migration Toolkit for Containers 워크플로

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

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

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

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

  • CR(사용자 정의 리소스) 및 CRD(사용자 정의 리소스 정의): MTC는 네임스페이스 수준에서 존재하는 모든 CR과 해당 CR에 연결된 CRD를 자동으로 마이그레이션합니다.

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

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

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

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

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

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

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

      참고

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

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

      참고

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

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

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

      스테이징은 여러 번 실행될 수 있으므로 마이그레이션 전에 대부분의 데이터가 대상에 복사됩니다. 따라서 마이그레이션의 기간과 애플리케이션 다운 타임이 최소화됩니다.

    • 마이그레이션은 소스 클러스터에서 애플리케이션을 중지하고 대상 클러스터에서 해당 리소스를 다시 만듭니다. 선택적으로 애플리케이션을 중지하지 않고 워크로드를 마이그레이션할 수 있습니다.
OCP 3에서 4로의 애플리케이션 마이그레이션

3.1.2. Migration Toolkit for Containers 사용자 정의 리소스

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 사용)

3.1.3. 데이터 복사 방법 정보

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

3.1.3.1. 파일 시스템 복사 방법

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

표 3.1. 파일 시스템 복사 방법 요약

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

3.1.3.2. 스냅샷 복사 방법

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

AWS, Google Cloud Provider 및 Microsoft Azure는 스냅샷 복사 방법을 지원합니다.

표 3.2. 스냅샷 복사 방법 요약

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

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

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

직접 마이그레이션은 소스 클러스터에서 복제 리포지토리로 파일을 백업하고 복제 리포지토리에서 대상 클러스터로 파일을 복원하는 중간 단계를 뛰어넘기 때문에 상당한 성능 이점을 지닙니다.

직접 마이그레이션은 Rsync를 사용하여 파일을 전송합니다.

참고

직접 이미지 마이그레이션 및 직접 볼륨 마이그레이션에는 추가 사전 요구 사항이 있습니다.

3.1.4. 마이그레이션 후크 정보

MTC(Migration Toolkit for Containers)를 사용하여 마이그레이션하는 동안 특정 시점에서 사용자 정의 코드를 실행하도록 마이그레이션 후크를 사용할 수 있습니다. 마이그레이션의 다른 단계에서 각 후크가 실행되고 단일 마이그레이션 계획에 최대 4개의 마이그레이션 후크를 추가할 수 있습니다.

마이그레이션 후크는 애플리케이션 정지 사용자 정의, 지원되지 않는 데이터 유형을 수동으로 마이그레이션 및 마이그레이션 후 애플리케이션 업데이트와 같은 작업을 수행합니다.

마이그레이션 후크는 다음 마이그레이션 단계 중 하나에서 소스 또는 대상 클러스터에서 실행됩니다.

  • PreBackup : 소스 클러스터에서 리소스를 백업하기 전에
  • PostBackup : 소스 클러스터에서 리소스를 백업한 후
  • PreRestore : 대상 클러스터에서 리소스가 복원되기 전에
  • PostRestore : 대상 클러스터에서 리소스가 복원된 후

Ansible 플레이북 또는 사용자 정의 후크 컨테이너를 사용하여 후크를 생성할 수 있습니다.

Ansible 플레이북

Ansible 플레이북은 후크 컨테이너에 구성 맵으로 마운트됩니다. 후크 컨테이너는 MigPlan 사용자 정의 리소스(CR)에 지정된 클러스터, 서비스 계정 및 네임스페이스를 사용하여 작업으로 실행됩니다. 작업은 기본 6번의 재시도 한도에 도달하거나 성공적으로 완료될 때까지 계속 실행됩니다. 이는 초기 포드가 제거되거나 종료된 경우에도 계속됩니다.

기본 Ansible 런타임 이미지는 registry.redhat.io/rhmtc/openshift-migration-hook-runner-rhel7:1.4입니다. 이 이미지는 Ansible Runner 이미지를 기반으로 하며 Ansible Kubernetes 리소스에 대해 python-openshift 및 업데이트된 oc바이너리를 포함합니다.

선택 사항: 기본 이미지 대신 추가 Ansible 모듈 또는 도구가 포함된 사용자 정의 Ansible 런타임 이미지를 사용할 수 있습니다.

사용자 정의 후크 컨테이너

Ansible 플레이북 또는 사용자 정의 코드가 포함된 사용자 정의 후크 컨테이너를 생성할 수 있습니다.

3.2. Migration Toolkit for Containers 설치 및 업그레이드

OpenShift Container Platform 4.7 대상 클러스터 및 4.2 소스 클러스터에 Migration Toolkit for Containers Operator를 설치할 수 있습니다.

MTC는 기본적으로 대상 클러스터에 설치되어 있습니다. OpenShift Container Platform 3 클러스터 또는 원격 클러스터에 MTC를 설치할 수 있습니다.

중요

모든 클러스터에 동일한 MTC 버전을 설치해야 합니다.

3.2.1. 연결된 환경에서 Migration Toolkit for Containers 설치

연결된 환경에서 MTC(Migration Toolkit for Containers)를 설치할 수 있습니다.

3.2.1.1. OpenShift Container Platform 4.7 대상 클러스터에 Migration Toolkit for Containers 설치

OpenShift Container Platform 4.7 대상 클러스터에 MTC(Migration Toolkit for Containers)를 설치할 수 있습니다.

사전 요구 사항

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

프로세스

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

    참고

    서브스크립션 승인 옵션을 자동으로 변경하지 마십시오. 소스 및 대상 클러스터에서 Migration Toolkit for Containers 버전이 동일해야 합니다.

  4. 설치를 클릭합니다.

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

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

3.2.1.2. OpenShift Container Platform 4.2 소스 클러스터에 Migration Toolkit for Containers 설치

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

사전 요구 사항

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

프로세스

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

    참고

    서브스크립션 승인 옵션을 자동으로 변경하지 마십시오. 소스 및 대상 클러스터에서 Migration Toolkit for Containers 버전이 동일해야 합니다.

  4. 설치를 클릭합니다.

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

  5. Migration Toolkit for Containers Operator를 클릭합니다.
  6. 제공된 API 아래에서 마이그레이션 컨트롤러 타일을 찾고 인스턴스 작성을 클릭합니다.
  7. migration-controller 사용자 정의 리소스 매니페스트에서 에서 다음 매개변수를 업데이트합니다.

    spec:
    ...
      migration_controller: false
      migration_ui: false
  8. 생성을 클릭합니다.
  9. 워크로드포드를 클릭하여 MTC 포드가 실행 중인지 확인합니다.

3.2.2. 제한된 환경에서 Migration Toolkit for Containers 설치

제한된 환경에서 MTC(Migration Toolkit for Containers)를 설치할 수 있습니다.

중요

모든 클러스터에 동일한 MTC 버전을 설치해야 합니다.

OpenShift Container Platform 4에 대한 사용자 정의 Operator 카탈로그 이미지를 빌드하고 로컬 미러 이미지 레지스트리로 푸시하고 로컬 레지스트리에서 Migration Toolkit for Containers Operator를 설치하도록 OLM(Operator Lifecycle Manager)을 구성할 수 있습니다.

3.2.2.1. 기본 OperatorHub 소스 비활성화

Red Hat 및 커뮤니티 프로젝트에서 제공하는 콘텐츠를 소싱하는 Operator 카탈로그는 OpenShift Container Platform을 설치하는 동안 기본적으로 OperatorHub용으로 구성됩니다.

프로세스

  • OperatorHub 오브젝트에 disableAllDefaultSources: true를 추가하여 기본 카탈로그의 소스를 비활성화합니다.

    $ oc patch OperatorHub cluster --type json \
        -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
작은 정보

또는 웹 콘솔을 사용하여 카탈로그 소스를 관리할 수 있습니다. 관리자클러스터 설정글로벌 구성OperatorHub 페이지에서 개별 소스를 생성, 삭제, 비활성화, 활성화할 수 있는 소스 탭을 클릭합니다.

3.2.2.2. 인덱스 이미지 정리

Operator 번들 포맷을 기반으로 하는 인덱스 이미지는 Operator 카탈로그의 컨테이너화된 스냅샷입니다. 지정된 패키지 목록을 제외한 인덱스를 모두 정리하여 원하는 Operator만 포함하는 소스 인덱스 복사본을 생성할 수 있습니다.

제한된 네트워크 OpenShift Container Platform 클러스터에서 미러링된 콘텐츠를 사용하도록 OLM(Operator Lifecycle Manager)을 구성할 때는 기본 카탈로그에서 Operator 서브 세트만 미러링하려면 이 정리 방법을 사용하십시오.

이 절차의 단계에서 대상 레지스트리는 무제한 네트워크 액세스 권한을 사용하여 워크스테이션에서 액세스할 수 있는 기존 미러 레지스트리입니다. 이 예제에서는 기본 redhat-operators 카탈로그의 인덱스 이미지를 정리하는 방법도 보여주지만 프로세스는 모든 인덱스 이미지에서 동일합니다.

사전 요구 사항

  • 무제한 네트워크 액세스가 가능한 워크스테이션
  • podman 버전 1.9.3+
  • grpcurl
  • opm 버전 1.12.3 이상
  • Docker v2-2를 지원하는 레지스트리에 액세스

프로세스

  1. registry.redhat.io로 인증합니다.

    $ podman login registry.redhat.io
  2. 대상 레지스트리로 인증합니다.

    $ podman login <target_registry>
  3. 정리된 인덱스에 포함하려는 패키지 목록을 결정합니다.

    1. 컨테이너에서 정리하려는 소스 인덱스 이미지를 실행합니다. 예를 들면 다음과 같습니다.

      $ podman run -p50051:50051 \
          -it registry.redhat.io/redhat/redhat-operator-index:v4.7

      출력 예

      Trying to pull registry.redhat.io/redhat/redhat-operator-index:v4.7...
      Getting image source signatures
      Copying blob ae8a0c23f5b1 done
      ...
      INFO[0000] serving registry                              database=/database/index.db port=50051

    2. 별도의 터미널 세션에서 grpcurl 명령을 사용하여 인덱스에서 제공하는 패키지 목록을 가져옵니다.

      $ grpcurl -plaintext localhost:50051 api.Registry/ListPackages > packages.out
    3. packages.out 파일을 검사하고 정리된 인덱스에 보관할 이 목록에 있는 패키지 이름을 확인합니다. 예를 들면 다음과 같습니다.

      패키지 목록 조각의 예

      ...
      {
        "name": "advanced-cluster-management"
      }
      ...
      {
        "name": "jaeger-product"
      }
      ...
      {
      {
        "name": "quay-operator"
      }
      ...

    4. podman run 명령을 실행한 터미널 세션에서 CtrlC를 눌러 컨테이너 프로세스를 중지합니다.
  4. 다음 명령을 실행하여 지정된 패키지를 제외한 소스 인덱스를 모두 정리합니다.

    $ opm index prune \
        -f registry.redhat.io/redhat/redhat-operator-index:v4.7 \1
        -p advanced-cluster-management,jaeger-product,quay-operator \2
        [-i registry.redhat.io/openshift4/ose-operator-registry:v4.7] \3
        -t <target_registry>:<port>/<namespace>/redhat-operator-index:v4.7 4
    1
    정리할 인덱스입니다.
    2
    쉼표로 구분된 보관할 패키지 목록입니다.
    3
    IBM Power Systems 및 IBM Z 이미지에만 필요합니다. 대상 OpenShift Container Platform 클러스터 주 버전 및 부 버전과 일치하는 태그를 사용하여 --from을 Operator 레지스트리 기본 이미지로 설정합니다.
    4
    빌드 중인 새 인덱스 이미지에 대한 사용자 정의 태그입니다.
  5. 다음 명령을 실행하여 새 인덱스 이미지를 대상 레지스트리로 내보냅니다.

    $ podman push <target_registry>:<port>/<namespace>/redhat-operator-index:v4.7

    <namespace>는 레지스트리의 기존 네임스페이스입니다. 예를 들어 미러링된 콘텐츠를 모두 내보내기 위해 olm-mirror 네임스페이스를 생성할 수 있습니다.

3.2.2.3. Operator 카탈로그 미러링

oc adm catalog mirror 명령을 사용하여 Red Hat 제공 카탈로그 또는 사용자 정의 카탈로그의 Operator 콘텐츠를 컨테이너 이미지 레지스트리에 미러링할 수 있습니다. 대상 레지스트리는 Docker v2-2를 지원해야 합니다. 제한된 네트워크에 있는 클러스터의 경우 이 레지스트리는 제한된 네트워크 클러스터 설치 중 생성된 미러 레지스트리와 같이 클러스터에 네트워크 액세스 권한이 있는 레지스트리일 수 있습니다.

oc adm catalog mirror 명령은 또한 Red Hat 제공 인덱스 이미지이든 자체 사용자 정의 빌드 인덱스 이미지이든 미러링 프로세스 중에 지정하는 인덱스 이미지를 대상 레지스트리에 자동으로 미러링합니다. 그러면 미러링된 인덱스 이미지를 사용하여 OLM(Operator Lifecycle Manager)이 OpenShift Container Platform 클러스터에 미러링된 카탈로그를 로드할 수 있는 카탈로그 소스를 생성할 수 있습니다.

사전 요구 사항

  • 워크스테이션에서 무제한 네트워크 액세스가 가능합니다.
  • podman 버전이 1.9.3 이상입니다.
  • Docker v2-2를 지원하는 미러 레지스트리에 액세스할 수 있습니다.
  • 미러 레지스트리에서 미러링된 Operator 콘텐츠를 저장하는 데 사용할 네임스페이스를 결정합니다. 예를 들어 olm-mirror 네임스페이스를 생성할 수 있습니다.
  • 미러 레지스트리가 인터넷에 액세스할 수 없는 경우 이동식 미디어를 무제한 네트워크 액세스 권한이 있는 워크스테이션에 연결합니다.
  • 프라이빗 레지스트리로 작업 중인 경우 REG_CREDS 환경 변수를 이후 단계에서 사용하기 위해 레지스트리 자격 증명의 파일 경로로 설정합니다. 예를 들어 podman CLI의 경우:

    $ REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.json

프로세스

  1. Red Hat 제공 카탈로그를 미러링하려면 무제한 네트워크 액세스 권한이 있는 워크스테이션에서 다음 명령을 실행하여 registry.redhat.io로 인증합니다.

    $ podman login registry.redhat.io
  2. oc adm catalog mirror 명령은 인덱스 이미지의 콘텐츠를 추출하여 미러링에 필요한 매니페스트를 생성합니다. 명령의 기본 동작은 매니페스트를 생성한 다음 인덱스 이미지 자체뿐만 아니라 인덱스 이미지의 모든 이미지 콘텐츠를 미러 레지스트리에 자동으로 미러링합니다. 또는 미러 레지스트리가 완전히 연결이 끊긴 호스트 또는 에어갭(Airgap) 호스트에 있는 경우 먼저 콘텐츠를 이동식 미디어로 미러링하고 미디어를 연결이 끊긴 환경으로 이동한 다음 미디어에서 레지스트리로 해당 콘텐츠를 미러링할 수 있습니다.

    • 옵션 A: 미러 레지스트리가 무제한 네트워크 액세스 권한이 있는 워크스테이션과 동일한 네트워크에 있는 경우 워크스테이션에서 다음 작업을 수행합니다.

      1. 미러 레지스트리에 인증이 필요한 경우 다음 명령을 실행하여 레지스트리에 로그인합니다.

        $ podman login <mirror_registry>
      2. 다음 명령을 실행하여 콘텐츠를 미러링합니다.

        $ oc adm catalog mirror \
            <index_image> \1
            <mirror_registry>:<port>/<namespace> \2
            [-a ${REG_CREDS}] \3
            [--insecure] \4
            [--index-filter-by-os='<platform>/<arch>'] \5
            [--manifests-only] 6
        1
        미러링할 카탈로그의 인덱스 이미지를 지정합니다. 예를 들어 이전에 생성한 정리된 인덱스 이미지 또는 registry.redhat.io/redhat/redhat-operator-index:v4.7과 같은 기본 카탈로그의 소스 인덱스 이미지 중 하나일 수 있습니다.
        2
        Operator 콘텐츠를 미러링할 대상 레지스트리와 네임스페이스를 지정합니다. 여기서 <namespace>는 레지스트리의 기존 네임스페이스입니다. 예를 들어 미러링된 콘텐츠를 모두 내보내기 위해 olm-mirror 네임스페이스를 생성할 수 있습니다.
        3
        선택 사항: 필요한 경우 레지스트리 자격 증명 파일의 위치를 지정합니다.
        4
        선택 사항: 대상 레지스트리에 대한 트러스트를 구성하지 않으려면 --insecure 플래그를 추가합니다.
        5
        선택 사항: 여러 변형이 있을 때 선택할 수 있는 인덱스 이미지의 플랫폼 및 아키텍처를 지정합니다. 이미지는 '<platform>/<arch>[/<variant>]’로 전달됩니다. 이는 인덱스에서 참조하는 이미지에는 적용되지 않습니다. 유효한 값은 linux/amd64, linux/ppc64lelinux/s390x입니다.
        6
        선택 사항: 미러링에 필요한 매니페스트만 생성하고 실제로 이미지 콘텐츠를 레지스트리에 미러링하지 않습니다. 이 선택 사항은 미러링할 항목을 검토하는 데 유용할 수 있으며 패키지의 서브 세트만 필요한 경우 매핑 목록을 변경할 수 있습니다. 그런 다음 oc image mirror 명령과 함께 mapping.txt 파일을 사용하여 이후 단계에서 수정된 이미지 목록을 미러링할 수 있습니다. 이 플래그는 카탈로그에서 콘텐츠의 고급 선택적 미러링에만 사용됩니다. 이전에 인덱스 이미지를 정리하기 위해 사용한 경우 opm index prune 명령은 대부분의 카탈로그 관리 사용 사례에 적합합니다.

        출력 예

        src image has index label for database path: /database/index.db
        using database path mapping: /database/index.db:/tmp/153048078
        wrote database to /tmp/153048078 1
        ...
        wrote mirroring manifests to manifests-redhat-operator-index-1614211642 2

        1
        명령으로 생성된 임시 index.db 데이터베이스용 디렉터리입니다.
        2
        생성된 매니페스트 디렉터리 이름을 기록합니다. 이 디렉터리 이름은 이후 단계에서 사용됩니다.
    • 옵션 B: 미러 레지스트리가 연결 해제된 호스트에 있는 경우 다음 작업을 수행합니다.

      1. 무제한 네트워크 액세스 권한이 있는 워크스테이션에서 다음 명령을 실행하여 콘텐츠를 로컬 파일에 미러링합니다.

        $ oc adm catalog mirror \
            <index_image> \1
            file:///local/index \2
            [-a ${REG_CREDS}] \
            [--insecure]
        1
        미러링할 카탈로그의 인덱스 이미지를 지정합니다. 예를 들어 이전에 생성한 정리된 인덱스 이미지 또는 registry.redhat.io/redhat/redhat-operator-index:v4.7과 같은 기본 카탈로그의 소스 인덱스 이미지 중 하나일 수 있습니다.
        2
        현재 디렉터리의 로컬 파일에 콘텐츠를 미러링합니다.

        출력 예

        ...
        info: Mirroring completed in 5.93s (5.915MB/s)
        wrote mirroring manifests to manifests-my-index-1614985528 1
        
        To upload local images to a registry, run:
        
        	oc adm catalog mirror file://local/index/myrepo/my-index:v1 REGISTRY/REPOSITORY 2

        1
        생성된 매니페스트 디렉터리 이름을 기록합니다. 이 디렉터리 이름은 이후 단계에서 사용됩니다.
        2
        제공된 인덱스 이미지를 기반으로 확장된 file:// 경로를 기록합니다. 이 경로는 이후 단계에서 사용됩니다.
      2. 현재 디렉터리에 생성된 v2/ 디렉터리를 이동식 미디어로 복사합니다.
      3. 물리적으로 미디어를 제거하고 연결이 끊긴 환경의 호스트에 연결하여 미러 레지스트리에 액세스할 수 있습니다.
      4. 미러 레지스트리에 인증이 필요한 경우 연결이 끊긴 환경의 호스트에서 다음 명령을 실행하여 레지스트리에 로그인합니다.

        $ podman login <mirror_registry>
      5. v2/ 디렉터리가 포함된 상위 디렉터리에서 다음 명령을 실행하여 로컬 파일에서 미러 레지스트리로 이미지를 업로드합니다.

        $ oc adm catalog mirror \
            file://local/index/<repo>/<index_image>:<tag> \1
            <mirror_registry>:<port>/<namespace> \2
            [-a ${REG_CREDS}] \
            [--insecure]
        1
        이전 명령 출력의 file:// 경로를 지정합니다.
        2
        Operator 콘텐츠를 미러링할 대상 레지스트리와 네임스페이스를 지정합니다. 여기서 <namespace>는 레지스트리의 기존 네임스페이스입니다. 예를 들어 미러링된 콘텐츠를 모두 내보내기 위해 olm-mirror 네임스페이스를 생성할 수 있습니다.
  3. 콘텐츠를 레지스트리에 미러링한 후 현재 디렉터리에 생성된 매니페스트 디렉터리를 검사합니다.

    참고

    매니페스트 디렉터리 이름은 이후 단계에서 사용됩니다.

    이전 단계에서 동일한 네트워크의 레지스트리에 콘텐츠를 미러링한 경우 디렉터리 이름은 다음 형식을 취합니다.

    manifests-<index_image_name>-<random_number>

    이전 단계에서 연결이 끊긴 호스트의 레지스트리에 콘텐츠를 미러링한 경우 디렉터리 이름은 다음 형식을 취합니다.

    manifests-index/<namespace>/<index_image_name>-<random_number>

    매니페스트 디렉터리에는 다음 파일이 포함되어 있으며, 이 중 일부는 추가 수정이 필요할 수 있습니다.

    • catalogSource.yaml 파일은 인덱스 이미지 태그 및 기타 관련 메타데이터로 미리 채워진 CatalogSource 오브젝트에 대한 기본 정의입니다. 이 파일은 있는 그대로 사용하거나 카탈로그 소스를 클러스터에 추가하도록 수정할 수 있습니다.

      중요

      콘텐츠를 로컬 파일에 미러링한 경우 metadata.name 필드에서 .name 필드에서 백슬래시(/) 문자를 제거하려면 catalogSource.yaml 파일을 수정해야 합니다. 그러지 않으면 오브젝트 생성을 시도할 때 "잘못된 리소스 이름" 오류로 인해 실패합니다.

    • imageContentSourcePolicy.yaml 파일은 Operator 매니페스트에 저장된 이미지 참조와 미러링된 레지스트리 간에 변환하도록 노드를 구성할 수 있는 ImageContentSourcePolicy 오브젝트를 정의합니다.

      참고

      클러스터에서 ImageContentSourcePolicy 오브젝트를 사용하여 저장소 미러링을 구성하는 경우 미러링된 레지스트리에 대한 글로벌 풀 시크릿만 사용할 수 있습니다. 프로젝트에 풀 시크릿을 추가할 수 없습니다.

    • mapping.txt 파일에는 모든 소스 이미지와 대상 레지스트리에서 매핑할 위치가 포함되어 있습니다. 이 파일은 oc image mirror 명령과 호환되며 미러링 구성을 추가로 사용자 정의하는 데 사용할 수 있습니다.

      중요

      미러링 프로세스 중 --manifests-only 플래그를 사용한 후 미러링할 패키지의 서브 세트를 추가로 트리밍하려면 mapping.txt 파일을 수정하고 oc image mirror 명령으로 파일을 사용하는 데 대한 “패키지 매니페스트 형식 카탈로그 이미지 미러링” 절차의 단계를 참조하십시오. 추가 조치를 수행한 후 이 프로세스를 계속할 수 있습니다.

  4. 연결 해제된 클러스터에 액세스할 수 있는 호스트에서 매니페스트 디렉터리에 imageContentSourcePolicy.yaml 파일을 지정하도록 다음 명령을 실행하여 ImageContentSourcePolicy 오브젝트를 생성합니다.

    $ oc create -f <path/to/manifests/dir>/imageContentSourcePolicy.yaml

    여기서 <path/to/manifests/dir>은 미러링된 콘텐츠의 매니페스트 디렉터리 경로입니다.

이제 미러링된 인덱스 이미지 및 Operator 콘텐츠를 참조하도록 CatalogSource 오브젝트를 생성할 수 있습니다.

3.2.2.4. 인덱스 이미지에서 카탈로그 생성

인덱스 이미지에서 Operator 카탈로그를 생성하고 OLM(Operator Lifecycle Manager)과 함께 사용하도록 OpenShift Container Platform 클러스터에 적용할 수 있습니다.

사전 요구 사항

  • 인덱스 이미지를 빌드하여 레지스트리로 내보냈습니다.

프로세스

  1. 인덱스 이미지를 참조하는 CatalogSource 오브젝트를 생성합니다.

    1. 다음을 사양에 맞게 수정하고 catalogsource.yaml 파일로 저장합니다.

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: my-operator-catalog
        namespace: openshift-marketplace
      spec:
        sourceType: grpc
        image: <registry>:<port>/<namespace>/redhat-operator-index:v4.7 <.>
        displayName: My Operator Catalog
        publisher: <publisher_name> <.>
        updateStrategy:
          registryPoll: <.>
            interval: 30m

      <.> 인덱스 이미지를 지정합니다. <.> 카탈로그를 게시하는 이름 또는 조직 이름을 지정합니다. <.> 카탈로그 소스는 새 버전을 자동으로 확인하여 최신 상태를 유지할 수 있습니다.

    2. 파일을 사용하여 CatalogSource 오브젝트를 생성합니다.

      $ oc apply -f catalogSource.yaml
  2. 다음 리소스가 성공적으로 생성되었는지 확인합니다.

    1. Pod를 확인합니다.

      $ oc get pods -n openshift-marketplace

      출력 예

      NAME                                    READY   STATUS    RESTARTS  AGE
      my-operator-catalog-6njx6               1/1     Running   0         28s
      marketplace-operator-d9f549946-96sgr    1/1     Running   0         26h

    2. 카탈로그 소스를 확인합니다.

      $ oc get catalogsource -n openshift-marketplace

      출력 예

      NAME                  DISPLAY               TYPE PUBLISHER  AGE
      my-operator-catalog   My Operator Catalog   grpc            5s

    3. 패키지 매니페스트 확인합니다.

      $ oc get packagemanifest -n openshift-marketplace

      출력 예

      NAME                          CATALOG               AGE
      jaeger-product                My Operator Catalog   93s

이제 OpenShift Container Platform 웹 콘솔의 OperatorHub 페이지에서 Operator를 설치할 수 있습니다.

3.2.2.5. 제한된 환경에서 OpenShift Container Platform 4.7 대상 클러스터에 Migration Toolkit for Containers 설치

OpenShift Container Platform 4.7 대상 클러스터에 MTC(Migration Toolkit for Containers)를 설치할 수 있습니다.

사전 요구 사항

  • 모든 클러스터에서 cluster-admin 권한이 있는 사용자로 로그인합니다.
  • 사용자 정의 Operator 카탈로그를 생성하여 미러 레지스트리로 푸시해야 합니다.
  • 미러 레지스트리에서 Migration Toolkit for Containers Operator를 설치하도록 Operator Lifecycle Manager를 구성해야 합니다.

프로세스

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

    참고

    서브스크립션 승인 옵션을 자동으로 변경하지 마십시오. 소스 및 대상 클러스터에서 Migration Toolkit for Containers 버전이 동일해야 합니다.

  4. 설치를 클릭합니다.

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

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

3.2.2.6. 제한된 환경에서 OpenShift Container Platform 4.2 소스 클러스터에 Migration Toolkit for Containers 설치

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

사전 요구 사항

  • 모든 클러스터에서 cluster-admin 권한이 있는 사용자로 로그인합니다.
  • 사용자 정의 Operator 카탈로그를 생성하여 미러 레지스트리로 푸시해야 합니다.
  • 미러 레지스트리에서 Migration Toolkit for Containers Operator를 설치하도록 Operator Lifecycle Manager를 구성해야 합니다.

프로세스

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

    참고

    서브스크립션 승인 옵션을 자동으로 변경하지 마십시오. 소스 및 대상 클러스터에서 Migration Toolkit for Containers 버전이 동일해야 합니다.

  4. 설치를 클릭합니다.

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

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

3.2.3. Migration Toolkit for Containers 업그레이드

OpenShift Container Platform 웹 콘솔을 사용하여 MTC를 업그레이드할 수 있습니다.

중요

동일한 MTC 버전이 모든 클러스터에 설치되어 있는지 확인해야 합니다.

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

3.2.3.1. OpenShift Container Platform 4 클러스터에서 Migration Toolkit for Containers 업그레이드

OpenShift Container Platform 웹 콘솔을 사용하여 OpenShift Container Platform 4 클러스터에서 MTC(Migration Toolkit for Containers)를 업그레이드할 수 있습니다.

사전 요구 사항

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

프로세스

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

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

  2. Migration Toolkit for Containers Operator를 클릭합니다.
  3. 서브스크립션 탭을 클릭합니다. 승인이 필요한 업그레이드는 업그레이드 상태 옆에 표시됩니다. 예를 들어 1 승인 필요가 표시될 수 있습니다.
  4. 1 승인 필요를 클릭한 다음 설치 계획 프리뷰를 클릭합니다.
  5. 업그레이드에 사용할 수 있는 리소스를 보고 승인을 클릭합니다.
  6. Operator → 설치된 Operator 페이지로 이동하여 업그레이드 진행 상황을 모니터링합니다. 완료되면 상태가 성공최신으로 변경됩니다.
  7. Migration Toolkit for Containers Operator를 클릭합니다.
  8. 제공된 API 아래에서 마이그레이션 컨트롤러 타일을 찾고 인스턴스 작성을 클릭합니다.
  9. 소스 클러스터에서 MTC를 업그레이드하는 경우 MigrationController 사용자 정의 리소스(CR) 매니페스트에서 다음 매개변수를 업데이트합니다.

    spec:
    ...
      migration_controller: false
      migration_ui: false

    대상 클러스터에서 MigrationController CR 매니페스트를 업데이트할 필요가 없습니다.

  10. 생성을 클릭합니다.
  11. 워크로드포드를 클릭하여 MTC 포드가 실행 중인지 확인합니다.

3.2.3.2. MTC 1.3을 1.4로 업그레이드

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

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

사전 요구 사항

  • MTC 1.3이 설치되어 있어야 합니다.
  • 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

3.3. 복제 리포지토리에 대한 오브젝트 스토리지 구성

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

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

다음과 같은 스토리지 공급자가 지원됩니다.

제한된 환경에서 내부 호스팅 복제 리포지토리를 만들 수 있습니다.

사전 요구 사항

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

3.3.1. Multi-Cloud Object Gateway 스토리지 버킷을 복제 리포지토리로 구성

OpenShift Container Storage Operator를 설치하고 MCG(Multi-Cloud Object Gateway) 스토리지 버킷을 MTC(Migration Toolkit for Containers)의 복제 리포지토리로 구성할 수 있습니다.

3.3.1.1. OpenShift Container Storage Operator 설치

OperatorHub에서 OpenShift Container Storage Operator를 설치할 수 있습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 OperatorOperatorHub를 클릭합니다.
  2. 키워드로 필터링(이 경우 OCS)을 사용하여 OpenShift Container Storage Operator를 찾습니다.
  3. OpenShift Container Storage Operator를 선택하고 설치를 클릭합니다.
  4. 업데이트 채널, 설치 모드승인 전략을 선택합니다.
  5. 설치를 클릭합니다.

    설치된 운영자 페이지에서 OpenShift Container Storage Operatoropenshift-storage 프로젝트에 Succeeded 상태로 나타납니다.

3.3.1.2. Multi-Cloud Object Gateway 스토리지 버킷 작성

MCG(Multi-Cloud Object Gateway) 스토리지 버킷의 사용자 정의 리소스(CR)를 생성할 수 있습니다.

프로세스

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

    $ oc login -u <username>
  2. 다음과 같은 내용과 함께 NooBaa CR 구성 파일, noobaa.yml을 생성합니다.

    apiVersion: noobaa.io/v1alpha1
    kind: NooBaa
    metadata:
      name: noobaa
      namespace: openshift-storage
    spec:
     dbResources:
       requests:
         cpu: 0.5 1
         memory: 1Gi
     coreResources:
       requests:
         cpu: 0.5 2
         memory: 1Gi
    1 2
    매우 작은 클러스터의 경우 cpu 값을 0.1로 변경할 수 있습니다.
  3. NooBaa 오브젝트를 생성합니다.

    $ oc create -f noobaa.yml
  4. 다음과 같은 내용과 함께 BackingStore CR 구성 파일 bs.yml을 생성합니다.

    apiVersion: noobaa.io/v1alpha1
    kind: BackingStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: mcg-pv-pool-bs
      namespace: openshift-storage
    spec:
      pvPool:
        numVolumes: 3 1
        resources:
          requests:
            storage: 50Gi 2
        storageClass: gp2 3
      type: pv-pool
    1
    영구 볼륨 풀에서 볼륨 수를 지정합니다.
    2
    볼륨의 크기를 지정합니다.
    3
    스토리지 클래스를 지정합니다.
  5. BackingStore 오브젝트를 생성합니다.

    $ oc create -f bs.yml
  6. 다음과 같은 내용으로 BucketClass CR 구성 파일, bc.yml을 생성합니다.

    apiVersion: noobaa.io/v1alpha1
    kind: BucketClass
    metadata:
      labels:
        app: noobaa
      name: mcg-pv-pool-bc
      namespace: openshift-storage
    spec:
      placementPolicy:
        tiers:
        - backingStores:
          - mcg-pv-pool-bs
          placement: Spread
  7. BucketClass 오브젝트를 생성합니다.

    $ oc create -f bc.yml
  8. 다음과 같은 내용과 함께 ObjectBucketClaim CR 구성 파일, obc.yml을 생성합니다.

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: migstorage
      namespace: openshift-storage
    spec:
      bucketName: migstorage 1
      storageClassName: openshift-storage.noobaa.io
      additionalConfig:
        bucketclass: mcg-pv-pool-bc
    1
    MTC 웹 콘솔에 복제 리포지토리를 추가하기 위한 버킷 이름을 기록합니다.
  9. ObjectBucketClaim 오브젝트를 생성합니다.

    $ oc create -f obc.yml
  10. 리소스 생성 프로세스를 보고 ObjectBucketClaim 상태가 Bound인지 확인합니다.

    $ watch -n 30 'oc get -n openshift-storage objectbucketclaim migstorage -o yaml'

    이 프로세스는 5-10분 정도 걸릴 수 있습니다.

  11. MTC 웹 콘솔에 복제 리포지토리를 추가할 때 필요한 다음 값을 확보하고 기록합니다.

    • S3 끝점:

      $ oc get route -n openshift-storage s3
    • S3 공급자 액세스 키:

      $ oc get secret -n openshift-storage migstorage -o go-template='{{ .data.AWS_ACCESS_KEY_ID }}' | base64 --decode
    • S3 공급자 보안 액세스 키:

      $ oc get secret -n openshift-storage migstorage -o go-template='{{ .data.AWS_SECRET_ACCESS_KEY }}' | base64 --decode

3.3.2. AWS S3 스토리지 버킷을 복제 리포지토리로 구성

AWS S3 스토리지 버킷을 MTC(Migration Toolkit for Containers)의 복제 리포지토리로 구성할 수 있습니다.

사전 요구 사항

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

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

프로세스

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

    $ aws s3api create-bucket \
        --bucket <bucket_name> \ 1
        --region <bucket_region> 2
    1
    S3 버킷 이름을 지정합니다.
    2
    S3 버킷 영역을 지정합니다(예: us-east-1).
  2. IAM 사용자 velero를 생성합니다.

    $ aws iam create-user --user-name velero
  3. EC2 EBS 스냅샷 정책을 생성합니다.

    $ cat > velero-ec2-snapshot-policy.json <<EOF
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "ec2:DescribeVolumes",
                    "ec2:DescribeSnapshots",
                    "ec2:CreateTags",
                    "ec2:CreateVolume",
                    "ec2:CreateSnapshot",
                    "ec2:DeleteSnapshot"
                ],
                "Resource": "*"
            }
        ]
    }
    EOF
  4. 하나 또는 모든 S3 버킷에 대한 AWS S3 액세스 정책을 생성합니다.

    $ cat > velero-s3-policy.json <<EOF
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "s3:GetObject",
                    "s3:DeleteObject",
                    "s3:PutObject",
                    "s3:AbortMultipartUpload",
                    "s3:ListMultipartUploadParts"
                ],
                "Resource": [
                    "arn:aws:s3:::<bucket_name>/*" 1
                ]
            },
            {
                "Effect": "Allow",
                "Action": [
                    "s3:ListBucket",
                    "s3:GetBucketLocation",
                    "s3:ListBucketMultipartUploads"
                ],
                "Resource": [
                    "arn:aws:s3:::<bucket_name>" 2
                ]
            }
        ]
    }
    EOF
    1 2
    단일 S3 버킷에 대한 액세스 권한을 부여하려면 버킷 이름을 지정합니다. 모든 AWS S3 버킷에 대한 액세스 권한을 부여하려면 다음 예제와 같이 버킷 이름 대신 *를 지정합니다.

    출력 예

    "Resource": [
        "arn:aws:s3:::*"

  5. EC2 EBS 정책을 velero에 연결합니다.

    $ aws iam put-user-policy \
      --user-name velero \
      --policy-name velero-ebs \
      --policy-document file://velero-ec2-snapshot-policy.json
  6. AWS S3 정책을 velero에 연결합니다.

    $ aws iam put-user-policy \
      --user-name velero \
      --policy-name velero-s3 \
      --policy-document file://velero-s3-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>, 1
            "AccessKeyId": <AWS_ACCESS_KEY_ID> 2
        }
    }
    1 2
    MTC 웹 콘솔에 AWS 리포지토리를 추가하기 위해 AWS_SECRET_ACCESS_KEYAWS_ACCESS_KEY_ID를 기록합니다.

3.3.3. Google Cloud Provider 스토리지 버킷을 복제 리포지토리로 구성

GCP(Google Cloud Provider) 스토리지 버킷을 MTC(Migration Toolkit for Containers)의 복제 리포지토리로 구성할 수 있습니다.

사전 요구 사항

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

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

프로세스

  1. gsutil에 로그인합니다.

    $ gsutil init

    출력 예

    Welcome! This command will take you through the configuration of gcloud.
    
    Your current configuration has been set to: [default]
    
    To continue, you must login. Would you like to login (Y/n)?

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

    $ BUCKET=<bucket_name> 1
    1
    버킷 이름을 지정합니다.
  3. 스토리지 버킷을 생성합니다.

    $ gsutil mb gs://$BUCKET/
  4. PROJECT_ID 변수를 활성 프로젝트로 설정합니다.

    $ PROJECT_ID=`gcloud config get-value project`
  5. Velero IAM 서비스 계정을 생성합니다.

    $ gcloud iam service-accounts create velero \
        --display-name "Velero Storage"
  6. SERVICE_ACCOUNT_EMAIL 변수를 생성합니다.

    $ SERVICE_ACCOUNT_EMAIL=`gcloud iam service-accounts list \
      --filter="displayName:Velero Storage" \
      --format 'value(email)'`
  7. ROLE_PERMISSIONS 변수를 생성합니다.

    $ 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
    )
  8. velero.server 사용자 정의 역할을 생성합니다.

    $ gcloud iam roles create velero.server \
        --project $PROJECT_ID \
        --title "Velero Server" \
        --permissions "$(IFS=","; echo "${ROLE_PERMISSIONS[*]}")"
  9. 프로젝트에 IAM 정책 바인딩을 추가합니다.

    $ gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member serviceAccount:$SERVICE_ACCOUNT_EMAIL \
        --role projects/$PROJECT_ID/roles/velero.server
  10. IAM 서비스 계정을 업데이트합니다.

    $ gsutil iam ch serviceAccount:$SERVICE_ACCOUNT_EMAIL:objectAdmin gs://${BUCKET}
  11. IAM 서비스 계정 키를 현재 디렉터리의 credentials-velero 파일에 저장합니다.

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

3.3.4. Microsoft Azure Blob 스토리지 컨테이너를 복제 리포지토리로 구성

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

사전 요구 사항

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

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

프로세스

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

    $ AZURE_RESOURCE_GROUP=Velero_Backups
  2. Azure 리소스 그룹을 생성합니다.

    $ az group create -n $AZURE_RESOURCE_GROUP --location <CentralUS> 1
    1
    위치를 지정합니다.
  3. AZURE_STORAGE_ACCOUNT_ID 변수를 설정합니다.

    $ AZURE_STORAGE_ACCOUNT_ID=velerobackups
  4. 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
  5. BLOB_CONTAINER 변수를 설정합니다.

    $ BLOB_CONTAINER=velero
  6. Azure Blob 스토리지 컨테이너를 생성합니다.

    $ az storage container create \
      -n $BLOB_CONTAINER \
      --public-access off \
      --account-name $AZURE_STORAGE_ACCOUNT_ID
  7. 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`
  8. 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

3.4. 애플리케이션 마이그레이션

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

3.4.1. 사전 요구 사항

MTC(Migration Toolkit for Containers)에는 다음과 같은 사전 요구 사항이 있습니다.

  • 모든 클러스터에서 cluster-admin 권한이 있는 사용자로 로그인합니다.
  • MTC 버전은 모든 클러스터에서 동일해야 합니다.
  • 클러스터:

    • 소스 클러스터를 최신 MTC z-stream 릴리스로 업그레이드해야 합니다.
    • migration-controller pod가 실행 중인 클러스터는 다른 클러스터에 대한 무제한 액세스 권한이 있어야 합니다.
    • 클러스터는 서로에 대한 무제한 네트워크 액세스 권한이 있어야 합니다.
    • 클러스터에 복제 리포지토리에 대한 무제한 네트워크 액세스 권한이 있어야 합니다.
    • 클러스터는 포트 443에서 OpenShift 경로를 사용하여 통신할 수 있어야 합니다.
    • 클러스터에는 중요한 조건이 없어야 합니다.
    • 클러스터가 준비 상태여야 합니다.
  • 볼륨 마이그레이션:

    • PV(영구 볼륨)가 유효해야 합니다.
    • PV를 영구 볼륨 클레임에 바인딩해야 합니다.
    • 이동 방법을 사용하여 PV를 복사하는 경우 클러스터에 원격 볼륨에 대한 무제한 액세스 권한이 있어야 합니다.
    • 스냅샷 복사 방법을 사용하여 PV를 복사하는 경우 다음 사전 요구 사항이 적용됩니다.

      • 클라우드 공급자는 스냅샷을 지원해야 합니다.
      • 볼륨에는 동일한 클라우드 프로바이더가 있어야 합니다.
      • 볼륨은 동일한 지리적 지역에 있어야 합니다.
      • 볼륨에는 동일한 스토리지 클래스가 있어야 합니다.
  • 프록시 환경에서 직접 볼륨 마이그레이션을 수행하는 경우 Stunnel TCP 프록시를 구성해야 합니다.
  • 직접 이미지 마이그레이션을 수행하는 경우 소스 클러스터의 내부 레지스트리를 외부 트래픽에 노출해야 합니다.

3.4.1.1. CA 인증서 번들 파일 생성

자체 서명된 인증서를 사용하여 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 번들 파일의 이름을 지정합니다.

3.4.1.2. 직접 볼륨 마이그레이션을 위한 프록시 구성

프록시 뒤에서 소스 클러스터에서 직접 볼륨 마이그레이션을 수행하는 경우 MigrationController 사용자 정의 리소스(CR)에서 Stunnel 프록시를 구성해야 합니다. Stunnel은 인증서를 변경하지 않고 TCP 연결을 위해 소스 클러스터와 대상 클러스터 간에 투명 터널을 생성합니다.

참고

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

사전 요구 사항

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

프로세스

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

    $ oc get migrationcontroller <migration_controller> -n openshift-migration
  3. stunnel_tcp_proxy 매개변수를 추가합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigrationController
    metadata:
      name: migration-controller
      namespace: openshift-migration
    ...
    spec:
      stunnel_tcp_proxy: <stunnel_proxy> 1
    1
    Stunnel 프록시를 지정합니다. http://<user_name>:<password>@<ip_address>:<port>
  4. 매니페스트를 migration-controller.yaml로 저장합니다.
  5. 업데이트된 매니페스트를 적용합니다.

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

3.4.1.3. 마이그레이션 후크의 Ansible 플레이북 작성

마이그레이션 후크로 사용할 Ansible 플레이북을 작성할 수 있습니다. MTC 웹 콘솔을 사용하거나 MigPlan 사용자 정의 리소스(CR) 매니페스트에서 spec.hooks 매개변수의 값을 지정하여 후크가 마이그레이션 계획에 추가됩니다.

Ansible 플레이북은 후크 컨테이너에 구성 맵으로 마운트됩니다. 후크 컨테이너는 MigPlan CR에 지정된 클러스터, 서비스 계정 및 네임스페이스를 사용하여 작업으로 실행됩니다. 후크 컨테이너는 클러스터에서 실행되기 전에 작업에 인증이 필요하지 않도록 지정된 서비스 계정 토큰을 사용합니다.

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

3.4.1.3.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', 'migplan_name') }}"

3.4.1.4. 추가 리소스

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

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

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

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

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

사전 요구 사항

  • Azure 스냅샷을 사용하여 데이터를 복사하는 경우:

    • 클러스터의 Azure 리소스 그룹 이름을 지정해야 합니다.
    • 클러스터는 동일한 Azure 리소스 그룹에 있어야 합니다.
    • 클러스터는 동일한 지역 위치에 있어야 합니다.

프로세스

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

    $ oc sa get-token migration-controller -n openshift-migration
    eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJtaWciLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoibWlnLXRva2VuLWs4dDJyIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6Im1pZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImE1YjFiYWMwLWMxYmYtMTFlOS05Y2NiLTAyOWRmODYwYjMwOCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDptaWc6bWlnIn0.xqeeAINK7UXpdRqAtOj70qhBJPeMwmgLomV9iFxr5RoqUgKchZRG2J2rkqmPm6vr7K-cm7ibD1IBpdQJCcVDuoHYsFgV4mp9vgOfn9osSDp2TGikwNz4Az95e81xnjVUmzh-NjDsEpw71DH92iHV_xt2sTwtzftS49LpPW2LjrV0evtNBP_t_RfskdArt5VSv25eORl7zScqfe1CiMkcVbf2UqACQjo3LbkpfN26HAioO2oH0ECPiRzT0Xyh-KwFutJLS9Xgghyw-LD9kPKcE_xbbJ9Y4Rqajh7WdPYuB0Jd9DPVrslmzK-F6cgHHYoZEv0SvLQi-PO0rpDrcjOEQQ
  3. MTC 웹 콘솔에서 클러스터를 클릭합니다.
  4. 클러스터 추가를 클릭합니다.
  5. 다음 필드를 작성합니다.

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

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

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

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

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

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

사전 요구 사항

  • 데이터를 마이그레이션하기 위해 오브젝트 스토리지 버킷을 구성해야 합니다.

프로세스

  1. MTC 웹 콘솔에서 복제 리포지토리를 클릭합니다.
  2. 리포지토리 추가를 클릭합니다.
  3. 스토리지 공급자 유형을 선택하고 다음 필드를 작성합니다.

    • AWS S3, MCG 및 일반 S3 공급자용 AWS:

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

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

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

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

3.4.2.4. MTC 웹 콘솔에서 마이그레이션 계획 생성

MTC(Migration Toolkit for Containers) 웹 콘솔에서 마이그레이션 계획을 생성할 수 있습니다.

사전 요구 사항

  • 모든 클러스터에서 cluster-admin 권한이 있는 사용자로 로그인합니다.
  • 동일한 MTC 버전이 모든 클러스터에 설치되어 있는지 확인해야 합니다.
  • MTC 웹 콘솔에 클러스터와 복제 리포지토리를 추가해야 합니다.
  • 이동 데이터 복사 방법을 사용하여 PV(영구 볼륨)를 마이그레이션하려면 소스 및 대상 클러스터에 원격 볼륨에 대한 중단되지 않은 네트워크 액세스가 있어야 합니다.
  • 직접 이미지 마이그레이션을 사용하려면 소스 클러스터의 MigCluster 사용자 정의 리소스 매니페스트에서 내부 이미지 레지스트리의 노출된 경로를 지정해야 합니다.

프로세스

  1. MTC 웹 콘솔에서 마이그레이션 계획을 클릭합니다.
  2. 마이그레이션 계획 추가를 클릭합니다.
  3. 계획 이름을 입력하고 다음 클릭합니다.

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

  4. 소스 클러스터를 선택합니다.
  5. 대상 클러스터를 선택합니다.
  6. 복제 리포지토리를 선택합니다.
  7. 마이그레이션할 프로젝트를 선택하고 다음을 클릭합니다.
  8. 소스 클러스터, 대상 클러스터, 리포지토리를 선택하고 다음을 클릭합니다.
  9. 네임스페이스 페이지에서 마이그레이션할 프로젝트를 선택하고 다음을 클릭합니다.
  10. 영구 볼륨 페이지에서 각 PV의 마이그레이션 유형을 클릭합니다.

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

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

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

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

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

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

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

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

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

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

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

    5. 소스 클러스터 또는 대상 클러스터를 선택합니다.
    6. 서비스 계정 이름서비스 계정 네임스페이스를 입력합니다.
    7. 후크의 마이그레이션 단계를 선택합니다.

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

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

3.4.2.5. MTC 웹 콘솔에서 마이그레이션 계획 실행

MTC(Migration Toolkit for Containers) 웹 콘솔에서 생성한 마이그레이션 계획을 사용하여 애플리케이션 및 데이터를 준비하거나 마이그레이션할 수 있습니다.

참고

마이그레이션 프로세스 중에 MTC는 마이그레이션된 PV(영구 볼륨)의 회수 정책을 대상 클러스터에서 Retain으로 설정합니다.

Backup 사용자 정의 리소스에는 원래 회수 정책을 나타내는 PVOriginalReclaimPolicy 주석이 포함되어 있습니다. 마이그레이션된 PV의 회수 정책을 수동으로 복원할 수 있습니다.

사전 요구 사항

MTC 웹 콘솔에는 다음이 포함되어야 합니다.

  • Ready 상태의 소스 클러스터
  • Ready 상태의 대상 클러스터
  • 복제 리포지토리
  • 유효한 마이그레이션 계획

프로세스

  1. 소스 클러스터에 로그인합니다.
  2. 오래된 이미지 삭제:

    $ oc adm prune images
  3. MTC 웹 콘솔에 로그인하고 마이그레이션 계획을 클릭합니다.
  4. 마이그레이션 계획 옆에 있는 옵션 메뉴 kebab 를 클릭하고 단계를 선택하여 애플리케이션을 중지하지 않고 소스 클러스터에서 대상 클러스터로 데이터를 복사합니다.

    실제 마이그레이션 시간을 줄이기 위해 단계를 여러 번 실행할 수 있습니다.

  5. 애플리케이션 워크로드를 마이그레이션할 준비가 되었으면 마이그레이션 계획 이외의 옵션 메뉴 kebab마이그레이션을 선택합니다.
  6. 선택 사항: 마이그레이션 창에서 마이그레이션 중에 소스 클러스터에서 애플리케이션을 중지하지 않음을 선택할 수 있습니다.
  7. 마이그레이션을 클릭합니다.
  8. 마이그레이션이 완료되면 OpenShift Container Platform 웹 콘솔에서 애플리케이션이 성공적으로 마이그레이션되었는지 확인합니다.

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

3.4.3. 명령줄에서 애플리케이션 마이그레이션

MTC 사용자 정의 리소스(CR)를 사용하여 명령줄에서 애플리케이션을 마이그레이션할 수 있습니다.

로컬 클러스터에서 원격 클러스터, 원격 클러스터에서 로컬 클러스터, 원격 클러스터, 원격 클러스터 간에 애플리케이션을 마이그레이션할 수 있습니다.

MTC 용어

다음 용어는 클러스터 구성과 관련이 있습니다.

  • host 클러스터:

    • migration-controller 포드는 host 클러스터에서 실행됩니다.
    • host 클러스터에 직접 이미지 마이그레이션을 위해 노출된 보안 레지스트리 경로가 필요하지 않습니다.
  • 로컬 클러스터: 로컬 클러스터는 host 클러스터와 자주 동일하지만 필수 클러스터는 아닙니다.
  • 원격 클러스터:

    • 원격 클러스터에 직접 이미지 마이그레이션을 위해 노출된 보안 레지스트리 경로를 보유해야 합니다.
    • 원격 클러스터에 migration-controller 서비스 계정 토큰이 포함된 Secret CR이 있어야 합니다.

다음 용어는 마이그레이션 수행과 관련이 있습니다.

  • 소스 클러스터: 애플리케이션을 마이그레이션하는 클러스터입니다.
  • 대상 클러스터: 애플리케이션이 마이그레이션되는 클러스터입니다.

3.4.3.1. Migration Toolkit for Containers API를 사용하여 애플리케이션 마이그레이션

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

로컬 클러스터에서 원격 클러스터, 원격 클러스터에서 로컬 클러스터, 원격 클러스터, 원격 클러스터 간에 애플리케이션을 마이그레이션할 수 있습니다.

다음 프로세스에서는 간접 마이그레이션 및 직접 마이그레이션을 수행하는 방법을 설명합니다.

  • 간접 마이그레이션: 이미지, 볼륨 및 Kubernetes 오브젝트는 소스 클러스터에서 복제 리포지토리로 복사한 다음 복제 리포지토리에서 대상 클러스터로 복사됩니다.
  • 직접 마이그레이션: 소스 클러스터에서 대상 클러스터로 직접 이미지 또는 볼륨이 복사됩니다. 직접 이미지 마이그레이션 및 직접 볼륨 마이그레이션은 성능에 큰 이점이 있습니다.

다음 사용자 정의 리소스(CR)를 생성하여 마이그레이션을 수행합니다.

  • MigCluster CR: host, 로컬 또는 원격 클러스터를 정의합니다.

    migration-controller 포드는 host 클러스터에서 실행됩니다.

  • Secret CR: 원격 클러스터 또는 스토리지에 대한 인증 정보를 포함합니다.
  • MigStorage CR: 복제 리포지토리를 정의합니다.

    스토리지 공급자마다 MigStorage CR 매니페스트의 다른 매개변수가 필요합니다.

  • MigPlan CR: 마이그레이션 계획을 정의합니다.
  • MigMigration CR: 연결된 MigPlan에 정의된 마이그레이션을 수행합니다.

    다음과 같은 목적으로 단일 MigPlan CR에 대해 여러 MigMigration CR을 생성할 수 있습니다.

  • 단계 마이그레이션을 수행하려면 마이그레이션을 실행하기 전에 애플리케이션을 중지하지 않고 대부분의 데이터를 복사합니다. 단계별 마이그레이션은 마이그레이션의 성능을 향상시킵니다.
  • 진행 중인 마이그레이션을 취소하려면
  • 완료된 마이그레이션을 롤백하려면

사전 요구 사항

  • 모든 클러스터에 대한 cluster-admin 권한이 있어야 합니다.
  • OpenShift Container Platform CLI(oc)를 설치해야 합니다.
  • 모든 클러스터에 Migration Toolkit for Containers Operator를 설치해야 합니다.
  • 모든 클러스터에서 설치된 Migration Toolkit for Containers Operator 버전이 동일해야 합니다.
  • 복제 리포지토리로 오브젝트 스토리지를 구성해야 합니다.
  • 직접 이미지 마이그레이션을 사용하는 경우 모든 원격 클러스터에 보안 레지스트리 경로를 노출해야 합니다.
  • 직접 볼륨 마이그레이션을 사용하는 경우 소스 클러스터에 HTTP 프록시가 구성되어 있지 않아야 합니다.

프로세스

  1. host-cluster.yaml이라는 host 클러스터에 대한 MigCluster CR 매니페스트를 생성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigCluster
    metadata:
      name: host
      namespace: openshift-migration
    spec:
      isHostCluster: true
  2. host 클러스터에 대한 MigCluster CR을 생성합니다.

    $ oc create -f host-cluster.yaml -n openshift-migration
  3. cluster-secret.yaml이라는 각 원격 클러스터에 대한 Secret CR 매니페스트를 생성합니다.

    apiVersion: v1
    kind: Secret
    metadata:
      name: <cluster_secret>
      namespace: openshift-config
    type: Opaque
    data:
      saToken: <sa_token> 1
    1
    원격 클러스터의 base64로 인코딩된 migration-controller 서비스 계정(SA) 토큰을 지정합니다.

    다음 명령을 실행하여 SA 토큰을 확보할 수 있습니다.

    $ oc sa get-token migration-controller -n openshift-migration | base64 -w 0
  4. 각 원격 클러스터에 대한 Secret CR을 생성합니다.

    $ oc create -f cluster-secret.yaml
  5. remote-cluster.yaml이라는 각 원격 클러스터에 대해 MigCluster CR 매니페스트를 생성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigCluster
    metadata:
      name: <remote_cluster>
      namespace: openshift-migration
    spec:
      exposedRegistryPath: <exposed_registry_route> 1
      insecure: false 2
      isHostCluster: false
      serviceAccountSecretRef:
        name: <remote_cluster_secret> 3
        namespace: openshift-config
      url: <remote_cluster_url> 4
    1
    선택 사항: 직접 이미지 마이그레이션을 사용하는 경우 노출된 레지스트리 경로를 지정합니다(예: docker-registry-default.apps.example.com).
    2
    false인 경우 SSL 확인이 활성화됩니다. CA 인증서가 필요하지 않거나 true인 경우 확인되지 않습니다.
    3
    원격 클러스터의 Secret CR을 지정합니다.
    4
    원격 클러스터의 URL을 지정합니다.
  6. 각 원격 클러스터에 대해 MigCluster CR을 생성합니다.

    $ oc create -f remote-cluster.yaml -n openshift-migration
  7. 모든 클러스터가 Ready 상태에 있는지 확인합니다.

    $ oc describe cluster <cluster_name>
  8. storage-secret.yaml이라는 복제 리포지토리의 Secret CR 매니페스트를 생성합니다.

    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
    1
    base64 형식으로 키 ID를 지정합니다.
    2
    base64 형식으로 시크릿 키를 지정합니다.

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

    $ echo -n "<key>" | base64 -w 0 1
    1
    키 ID 또는 시크릿 키를 지정합니다. 두 키 모두 base64로 인코딩되어야 합니다.
  9. 복제 리포지토리에 대한 Secret CR을 생성합니다.

    $ oc create -f storage-secret.yaml
  10. migstorage.yaml이라는 복제 리포지토리에 대한 MigStorage CR 매니페스트를 생성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigStorage
    metadata:
      name: <storage_name>
      namespace: openshift-migration
    spec:
      backupStorageConfig:
        awsBucketName: <bucket_name> 1
        credsSecretRef:
          name: <storage_secret_ref> 2
          namespace: openshift-config
      backupStorageProvider: <storage_provider_name> 3
      volumeSnapshotConfig:
        credsSecretRef:
          name: <storage_secret_ref> 4
          namespace: openshift-config
      volumeSnapshotProvider: <storage_provider_name> 5
    1
    버킷 이름을 지정합니다.
    2
    오브젝트 스토리지의 Secrets CR을 지정합니다. 오브젝트 스토리지의 Secrets CR에 저장된 인증 정보가 올바른지 확인해야 합니다.
    3
    스토리지 공급자를 지정합니다.
    4
    선택 사항: 스냅샷을 사용하여 데이터를 복사하는 경우 오브젝트 스토리지의 Secrets CR을 지정합니다. 오브젝트 스토리지의 Secrets CR에 저장된 인증 정보가 올바른지 확인해야 합니다.
    5
    선택 사항: 스냅샷을 사용하여 데이터를 복사하는 경우 스토리지 공급자를 지정합니다.
  11. MigStorage CR을 생성합니다.

    $ oc create -f migstorage.yaml -n openshift-migration
  12. MigStorage CR이 Ready 상태에 있는지 확인합니다.

    $ oc describe migstorage <migstorage_name>
  13. migplan.yaml이라는 MigPlan CR 매니페스트를 생성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigPlan
    metadata:
      name: <migration_plan>
      namespace: openshift-migration
    spec:
      destMigClusterRef:
        name: host
        namespace: openshift-migration
      indirectImageMigration: true 1
      indirectVolumeMigration: true 2
      migStorageRef:
        name: <migstorage_ref> 3
        namespace: openshift-migration
      namespaces:
        - <application_namespace> 4
      srcMigClusterRef:
        name: <remote_cluster_ref> 5
        namespace: openshift-migration
    1
    false인 경우 직접 이미지 마이그레이션이 활성화됩니다.
    2
    false인 경우 직접 볼륨 마이그레이션이 활성화됩니다.
    3
    MigStorage CR 인스턴스의 이름을 지정합니다.
    4
    마이그레이션할 하나 이상의 네임스페이스를 지정합니다.
    5
    소스 클러스터 MigCluster 인스턴스의 이름을 지정합니다.
  14. MigPlan CR을 만듭니다.

    $ oc create -f migplan.yaml -n openshift-migration
  15. MigPlan 인스턴스를 보고 Ready 상태인지 확인합니다.

    $ oc describe migplan <migplan_name> -n openshift-migration
  16. migmigration.yaml이라는 MigMigration CR 매니페스트를 생성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      name: <migmigration_name>
      namespace: openshift-migration
    spec:
      migPlanRef:
        name: <migplan_name> 1
        namespace: openshift-migration
      quiescePods: true 2
      stage: false 3
      rollback: false 4
    1
    MigPlan CR 이름을 지정합니다.
    2
    true인 경우 마이그레이션 전에 소스 클러스터의 포드가 중지됩니다.
    3
    애플리케이션을 중지하지 않고 대부분의 데이터를 복사하는 단계 마이그레이션이 true인 경우 수행됩니다.
    4
    true인 경우 완료된 마이그레이션이 롤백됩니다.
  17. MigPlan CR에 정의된 마이그레이션을 시작하도록 MigMigration CR을 생성합니다.

    $ oc create -f migmigration.yaml -n openshift-migration
  18. MigMigration CR을 확인하여 마이그레이션 진행 상황을 확인합니다.

    $ oc watch migmigration <migmigration_name> -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:       my_application
        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

3.4.3.2. MTC 사용자 정의 리소스 매니페스트

MTC(Migration Toolkit for Containers)는 다음 사용자 정의 리소스(CR) 매니페스트를 사용하여 애플리케이션 마이그레이션을 위한 CR을 생성합니다.

3.4.3.2.1. DirectImageMigration

DirectImageMigration CR은 소스 클러스터에서 대상 클러스터로 이미지를 직접 복사합니다.

apiVersion: migration.openshift.io/v1alpha1
kind: DirectImageMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <directimagemigration_name>
spec:
  srcMigClusterRef:
    name: <source_cluster_ref> 1
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster_ref> 2
    namespace: openshift-migration
  namespaces:
  - <namespace> 3
1
소스 클러스터의 MigCluster CR 이름을 지정합니다.
2
대상 클러스터의 MigCluster CR 이름을 지정합니다.
3
마이그레이션할 이미지를 포함하는 하나 이상의 네임스페이스를 지정합니다.
3.4.3.2.2. DirectImageStreamMigration

DirectImageStreamMigration CR은 소스 클러스터에서 대상 클러스터로 직접 이미지 스트림 참조를 복사합니다.

apiVersion: migration.openshift.io/v1alpha1
kind: DirectImageStreamMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: directimagestreammigration_name
spec:
  srcMigClusterRef:
    name: <source_cluster_ref> 1
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster_ref> 2
    namespace: openshift-migration
  imageStreamRef:
    name: <image_stream_name> 3
    namespace: <source_image_stream_namespace> 4
  destNamespace: <destination_image_stream_namespace> 5
1
소스 클러스터의 MigCluster CR 이름을 지정합니다.
2
대상 클러스터의 MigCluster CR 이름을 지정합니다.
3
이미지 스트림 이름을 지정합니다.
4
소스 클러스터에서 이미지 스트림 네임스페이스를 지정합니다.
5
대상 클러스터에서 이미지 스트림 네임스페이스를 지정합니다.
3.4.3.2.3. DirectVolumeMigration

DirectVolumeMigration CR은 소스 클러스터에서 대상 클러스터로 직접 PV(영구 볼륨)를 복사합니다.

apiVersion: migration.openshift.io/v1alpha1
kind: DirectVolumeMigration
metadata:
  name: <directvolumemigration_name>
  namespace: openshift-migration
spec:
  createDestinationNamespaces: false 1
  deleteProgressReportingCRs: false 2
  destMigClusterRef:
    name: host 3
    namespace: openshift-migration
  persistentVolumeClaims:
  - name: <pvc_name> 4
    namespace: <pvc_namespace> 5
  srcMigClusterRef:
    name: <source_cluster_ref> 6
    namespace: openshift-migration
1
true인 경우 대상 클러스터의 PV에 네임스페이스가 생성됩니다.
2
DirectVolumeMigrationProgress CR은 true인 경우 마이그레이션 후 삭제됩니다. 문제 해결을 위해 DirectVolumeMigrationProgress CR이 유지되기 위한 기본값은 false입니다.
3
대상 클러스터가 호스트 클러스터가 아닌 경우 클러스터 이름을 업데이트합니다.
4
직접 볼륨 마이그레이션을 사용하여 마이그레이션할 하나 이상의 PVC를 지정합니다.
5
각 PVC의 네임스페이스를 지정합니다.
6
소스 클러스터의 MigCluster CR 이름을 지정합니다.
3.4.3.2.4. DirectVolumeMigrationProgress

DirectVolumeMigrationProgress CR은 DirectVolumeMigration CR의 진행 상황을 보여줍니다.

apiVersion: migration.openshift.io/v1alpha1
kind: DirectVolumeMigrationProgress
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: directvolumemigrationprogress_name
spec:
  clusterRef:
    name: source_cluster
    namespace: openshift-migration
  podRef:
    name: rsync_pod
    namespace: openshift-migration
3.4.3.2.5. MigAnalytic

MigAnalytic CR은 이미지 수, Kubernetes 리소스 및 관련 MigPlan CR에서 PV 용량을 수집합니다.

apiVersion: migration.openshift.io/v1alpha1
kind: MigAnalytic
metadata:
  annotations:
    migplan: <migplan_name> 1
  name: miganalytic_name
  namespace: openshift-migration
  labels:
    migplan: <migplan_name> 2
spec:
  analyzeImageCount: true 3
  analyzeK8SResources: true 4
  analyzePVCapacity: true 5
  listImages: false 6
  listImagesLimit: 50 7
  migPlanRef:
    name: migplan_name 8
    namespace: openshift-migration
1
MigAnalytic CR과 연관된 MigPlan CR 이름을 지정합니다.
2
MigAnalytic CR과 연관된 MigPlan CR 이름을 지정합니다.
3
선택 사항: true인 경우 이미지 수가 반환됩니다.
4
선택 사항: true인 경우 Kubernetes 리소스의 수, 종류 및 API 버전을 반환합니다.
5
선택 사항: true인 경우 PV 용량을 반환합니다.
6
true인 경우 이미지 이름 목록을 반환합니다. 출력이 과도하게 길지 않도록 기본값은 false입니다.
7
선택 사항: listImagestrue인 경우 최대 이미지 이름 수를 지정합니다.
8
MigAnalytic CR과 연관된 MigPlan CR 이름을 지정합니다.
3.4.3.2.6. MigCluster

MigCluster CR은 호스트, 로컬 또는 원격 클러스터를 정의합니다.

apiVersion: migration.openshift.io/v1alpha1
kind: MigCluster
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: host 1
  namespace: openshift-migration
spec:
  isHostCluster: true 2
  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.
# isHostCluster: false
# exposedRegistryPath: 8
# url: <destination_cluster_url> 9
# serviceAccountSecretRef:
#   name: <source_secret_ref> 10
#   namespace: openshift-config
1
선택 사항: migration-controller 포드가 이 클러스터에서 실행되지 않는 경우 클러스터 이름을 업데이트합니다.
2
migration-controller 포드는 true인 경우 이 클러스터에서 실행됩니다.
3
선택 사항: 스토리지 공급자가 Microsoft Azure인 경우 리소스 그룹을 지정합니다.
4
선택 사항: 자체 서명된 CA 인증서에 대한 인증서 번들을 생성하고 insecure 매개변수 값이 false인 경우 base64 인코딩 인증서 번들을 지정합니다.
5
false인 경우 SSL 확인이 활성화됩니다.
6
true인 경우 클러스터가 검증됩니다.
7
restic 포드가 true인 경우 생성된 후 restic 포드가 소스 클러스터에서 다시 시작됩니다.
8
선택 사항: 직접 이미지 마이그레이션을 사용하는 경우 원격 클러스터의 노출된 레지스트리 경로를 지정합니다.
9
원격 클러스터의 URL을 지정합니다.
10
원격 클러스터에 대한 Secret CR의 이름을 지정합니다.
3.4.3.2.7. MigHook

MigHook CR은 마이그레이션의 지정된 단계에서 작업을 실행하는 Ansible 플레이북 또는 사용자 정의 이미지를 정의합니다.

apiVersion: migration.openshift.io/v1alpha1
kind: MigHook
metadata:
  generateName: <hook_name_prefix> 1
  name: <hook_name> 2
  namespace: openshift-migration
spec:
  activeDeadlineSeconds: 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 또는 대상을 지정합니다.
3.4.3.2.8. MigMigration

MigMigration CR은 연결된 MigPlan CR을 실행합니다.

다음 시나리오에 동일한 MigPlan CR과 연관된 여러 MigMigration CR을 생성할 수 있습니다.

  • 소스 클러스터에서 포드를 중지하지 않고도 여러 단계 또는 증분 마이그레이션을 실행하여 데이터를 복사할 수 있습니다. 단계별 마이그레이션을 실행하면 실제 마이그레이션의 성능이 향상됩니다.
  • 진행 중인 마이그레이션을 취소할 수 있습니다.
  • 마이그레이션을 롤백할 수 있습니다.
apiVersion: migration.openshift.io/v1alpha1
kind: MigMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: migmigration_name
  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_ref> 7
    namespace: openshift-migration
1
true인 경우 진행 중인 마이그레이션이 취소됩니다.
2
true인 경우 완료된 마이그레이션이 롤백됩니다.
3
true인 경우 데이터가 증분적으로 복사되고 소스 클러스터의 포드가 중지되지 않습니다.
4
소스 클러스터의 포드는 true인 경우 마이그레이션의 Backup 단계 이후 0으로 확장됩니다.
5
마이그레이션 중에 적용되는 레이블 및 주석은 true인 경우 유지됩니다.
6
대상 클러스터에서 마이그레이션된 포드의 상태가 확인되고 Running 상태에 없는 포드의 이름이 true인 경우 반환됩니다.
7
migPlanRef.name: 연결된 MigPlan CR의 이름을 지정합니다.
3.4.3.2.9. MigPlan

MigPlan CR은 마이그레이션 계획의 매개변수를 정의합니다. 동일한 매개변수로 마이그레이션 중인 가상 머신 그룹이 포함되어 있습니다.

apiVersion: migration.openshift.io/v1alpha1
kind: MigPlan
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: migplan_name
  namespace: openshift-migration
spec:
  closed: false 1
  srcMigClusterRef:
    name: <source_migcluster_ref> 2
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_migcluster_ref> 3
    namespace: openshift-migration
  hooks: 4
    - executionNamespace: <namespace> 5
      phase: <migration_phase> 6
      reference:
        name: <mighook_name> 7
        namespace: <hook_namespace> 8
      serviceAccount: <service_account> 9
  indirectImageMigration: true 10
  indirectVolumeMigration: false 11
  migStorageRef:
    name: <migstorage_name> 12
    namespace: openshift-migration
  namespaces:
  - <namespace>  13
  refresh: false  14
1
true인 경우 마이그레이션이 완료되었습니다. 이 MigPlan CR에 대해 다른 MigMigration CR을 생성할 수 없습니다.
2
소스 클러스터 MigCluster CR의 이름을 지정합니다.
3
대상 클러스터 MigCluster CR의 이름을 지정합니다.
4
선택 사항: 최대 4개의 마이그레이션 후크를 지정할 수 있습니다.
5
선택 사항: 후크를 실행할 네임스페이스를 지정합니다.
6
선택 사항: 후크가 실행되는 마이그레이션 단계를 지정합니다. 하나의 후크를 하나의 단계에 할당할 수 있습니다. 예상되는 값은 PreBackup, PostBackup, PreRestorePostRestore입니다.
7
선택 사항: MigHook CR의 이름을 지정합니다.
8
선택 사항: MigHook CR의 네임스페이스를 지정합니다.
9
선택 사항: cluster-admin 권한이 있는 서비스 계정을 지정합니다.
10
true인 경우 직접 이미지 마이그레이션이 비활성화됩니다. 이미지는 소스 클러스터에서 복제 리포지토리로, 복제 리포지토리에서 대상 클러스터로 복사됩니다.
11
true인 경우 직접 볼륨 마이그레이션이 비활성화됩니다. PV는 소스 클러스터에서 복제 리포지토리로, 복제 리포지토리에서 대상 클러스터로 복사됩니다.
12
MigStorage CR의 이름을 지정합니다.
13
하나 이상의 네임스페이스를 지정합니다.
14
MigPlan CR이 true인 경우 검증됩니다.
3.4.3.2.10. MigStorage

MigStorage CR은 복제 리포지토리의 오브젝트 스토리지를 설명합니다. Amazon Web Services, Microsoft Azure, Google Cloud Storage 및 일반 S3 호환 클라우드 스토리지(예: Minio 또는 NooBaa)를 구성할 수 있습니다.

다른 공급자에는 다른 매개 변수가 필요합니다.

apiVersion: migration.openshift.io/v1alpha1
kind: MigStorage
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: migstorage_name
  namespace: openshift-migration
spec:
  backupStorageProvider: <storage_provider> 1
  volumeSnapshotProvider: 2
  backupStorageConfig:
    awsBucketName: 3
    awsRegion: 4
    credsSecretRef:
      namespace: openshift-config
      name: <storage_secret> 5
    awsKmsKeyId: 6
    awsPublicUrl: 7
    awsSignatureVersion: 8
  volumeSnapshotConfig:
    awsRegion: 9
    credsSecretRef:
      namespace: openshift-config
      name: 10
  refresh: false 11
1
스토리지 공급자를 지정합니다.
2
선택 사항: 스냅샷 복사 방법을 사용하는 경우 스토리지 공급자를 지정합니다.
3
AWS를 사용하는 경우 버킷 이름을 지정합니다.
4
AWS를 사용하는 경우 버킷 리전을 지정합니다(예: us-east-1).
5
MigStorage CR용으로 생성한 Secret CR의 이름을 지정합니다.
6
선택 사항: AWS 키 관리 서비스를 사용하는 경우 키의 고유 식별자를 지정합니다.
7
선택 사항: AWS 버킷에 대한 공용 액세스 권한이 부여된 경우 버킷 URL을 지정합니다.
8
선택 사항: 버킷에 대한 요청을 인증하기 위해 AWS 서명 버전을 지정합니다(예: 4).
9
선택 사항: 스냅샷 복사 방법을 사용하는 경우 클러스터의 지역 리전을 지정합니다.
10
선택 사항: 스냅샷 복사 방법을 사용하는 경우 MigStorage CR에 대해 생성한 Secret CR의 이름을 지정합니다.
11
true인 경우 클러스터가 검증됩니다.

3.4.3.3. 추가 리소스

3.4.4. 마이그레이션 계획 구성

마이그레이션할 오브젝트 수를 늘리거나 마이그레이션에서 리소스를 제외할 수 있습니다.

3.4.4.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 콘솔은 마이그레이션 계획을 저장할 때 경고 메시지를 표시합니다.

3.4.4.2. 마이그레이션 계획에서 리소스 제외

마이그레이션하기 위해 리소스 로드를 줄이거나 다른 도구를 사용하여 이미지 또는 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. 특정 리소스를 제외하는 매개 변수를 추가하거나 자체 제외 매개 변수가 없는 경우 excluded_resources 매개 변수에 리소스를 추가하여 spec 섹션을 업데이트합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigrationController
    metadata:
      name: migration-controller
      namespace: openshift-migration
    spec:
      disable_image_migration: true 1
      disable_pv_migration: true 2
      ...
      excluded_resources: 3
      - imagetags
      - templateinstances
      - clusterserviceversions
      - packagemanifests
      - subscriptions
      - servicebrokers
      - servicebindings
      - serviceclasses
      - serviceinstances
      - serviceplans
      - operatorgroups
      - events
    1
    마이그레이션에서 이미지 스트림을 제외하려면 disable_image_migration: true를 추가합니다. excluded_resources 매개 변수를 편집하지 마십시오. MigrationController 포드가 다시 시작되면 imagestreamsexcluded_resources에 추가됩니다.
    2
    마이그레이션 계획에서 PV를 제외하려면 disable_pv_migration: true를 추가합니다. excluded_resources 매개 변수를 편집하지 마십시오. MigrationController 포드가 다시 시작되면 persistentvolumespersistentvolumeclaimsexcluded_resources에 추가됩니다. PV 마이그레이션을 비활성화하면 마이그레이션 계획을 생성할 때 PV 검색도 비활성화됩니다.
    3
    OpenShift Container Platform 리소스를 excluded_resources 목록에 추가할 수 있습니다. 기본 제외 리소스를 삭제하지 마십시오. 이러한 리소스는 마이그레이션에 문제가 있으므로 제외해야 합니다.
  3. 변경 사항이 적용되도록 MigrationController 포드가 다시 시작될 때까지 2분 정도 기다립니다.
  4. 리소스가 제외되었는지 확인합니다.

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

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

    출력 예

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

3.5. 문제 해결

MTC(Migration Toolkit for Containers) 사용자 정의 리소스를 보고 로그를 다운로드하여 마이그레이션 실패 문제를 해결할 수 있습니다.

실패한 마이그레이션 중에 애플리케이션이 중지된 경우 데이터 손상을 방지하기 위해 수동으로 롤백해야 합니다.

참고

원래 애플리케이션이 소스 클러스터에서 계속 실행 중이므로 마이그레이션 중에 애플리케이션이 중지되지 않은 경우 수동 롤백이 필요하지 않습니다.

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

3.5.2. 마이그레이션 로그 리더 사용

마이그레이션 로그 리더를 사용하여 모든 마이그레이션 로그에 대한 필터링된 보기를 표시할 수 있습니다.

프로세스

  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 옵션은 색상 없이 로그를 표시합니다.

3.5.3. 마이그레이션 로그 다운로드

MTC(Migration Toolkit for Containers) 웹 콘솔에서 Velero, ResticMigrationController 포드 로그를 다운로드하여 실패한 마이그레이션 문제를 해결할 수 있습니다.

프로세스

  1. MTC 콘솔에서 마이그레이션 계획을 클릭하여 마이그레이션 계획 목록을 확인합니다.
  2. 특정 마이그레이션 계획의 옵션 메뉴 kebab 를 클릭하고 로그를 선택합니다.
  3. 모든 클러스터에 대한 MigrationController, VeleroRestic 포드의 로그를 다운로드하려면 로그 다운로드를 클릭합니다.

    클러스터, 로그 소스 및 포드 소스를 선택한 다음 선택한 항목 다운로드를 클릭하여 단일 로그를 다운로드할 수 있습니다.

    oc logs 명령을 사용하여 CLI에서 포드 로그에 액세스할 수 있습니다.

    $ oc logs <pod-name> -f -n openshift-migration 1
    1
    포드 이름을 지정합니다.

3.5.4. 더 이상 사용되지 않는 API 업데이트

소스 클러스터에서 더 이상 사용되지 않는 API를 사용하는 경우 MTC(Migration Toolkit for Containers) 웹 콘솔에서 마이그레이션 계획을 생성할 때 다음 경고 메시지가 표시됩니다.

Some namespaces contain GVKs incompatible with destination cluster

세부 사항 보기를 클릭하여 네임스페이스 및 호환되지 않는 API를 볼 수 있습니다. 이 경고 메시지는 마이그레이션을 차단하지 않습니다.

MTC(Migration Toolkit for Containers)를 사용하여 마이그레이션하는 동안 더 이상 사용되지 않는 API는 Kubernetes 오브젝트의 Velero Backup #1에 저장됩니다. Velero Backup을 다운로드하고, 더 이상 사용되지 않는 API yaml 파일을 추출한 후 oc convert 명령으로 업데이트할 수 있습니다. 그런 다음 대상 클러스터에서 업데이트된 API를 생성할 수 있습니다.

프로세스

  1. 마이그레이션 계획을 실행합니다.
  2. MigPlan 사용자 정의 리소스 (CR)를 확인합니다.

    $ oc describe migplan <migplan_name> -n openshift-migration 1
    1
    MigPlan CR의 이름을 지정합니다.

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

    metadata:
      ...
      uid: 79509e05-61d6-11e9-bc55-02ce4781844a 1
    status:
      ...
      conditions:
      - category: Warn
        lastTransitionTime: 2020-04-30T17:16:23Z
        message: 'Some namespaces contain GVKs incompatible with destination cluster.
          See: `incompatibleNamespaces` for details'
        status: "True"
        type: GVKsIncompatible
      incompatibleNamespaces:
      - gvks: 2
        - group: batch
          kind: cronjobs
          version: v2alpha1
        - group: batch
          kind: scheduledjobs
          version: v2alpha1
    1
    MigPlan CR UID를 기록합니다.
    2
    gvks 섹션에 나열된 더 이상 사용되지 않는 API를 기록합니다.
  3. MigPlan UID와 관련된 MigMigration 이름을 가져옵니다.

    $ oc get migmigration -o json | jq -r '.items[] | select(.metadata.ownerReferences[].uid=="<migplan_uid>") | .metadata.name' 1
    1
    MigPlan CR UID를 지정합니다.
  4. MigMigration 이름과 연관된 MigMigration UID를 가져옵니다.

    $ oc get migmigration <migmigration_name> -o jsonpath='{.metadata.uid}' 1
    1
    MigMigration 이름을 지정합니다.
  5. MigMigration UID와 관련된 Velero Backup 이름을 가져옵니다.

    $ oc get backup.velero.io --selector migration-initial-backup="<migmigration_uid>" -o jsonpath={.items[*].metadata.name} 1
    1
    MigMigration UID를 지정합니다.
  6. 스토리지 공급자의 명령을 실행하여 Velero Backup의 콘텐츠를 로컬 머신으로 다운로드합니다.

    • AWS S3:

      $ aws s3 cp s3://<bucket_name>/velero/backups/<backup_name> <backup_local_dir> --recursive 1
      1
      버킷, 백업 이름 및 로컬 백업 디렉터리 이름을 지정합니다.
    • GCP:

      $ gsutil cp gs://<bucket_name>/velero/backups/<backup_name> <backup_local_dir> --recursive 1
      1
      버킷, 백업 이름 및 로컬 백업 디렉터리 이름을 지정합니다.
    • Azure:

      $ azcopy copy 'https://velerobackups.blob.core.windows.net/velero/backups/<backup_name>' '<backup_local_dir>' --recursive 1
      1
      백업 이름과 로컬 백업 디렉터리 이름을 지정합니다.
  7. Velero Backup 아카이브 파일을 추출합니다.

    $ tar -xfv <backup_local_dir>/<backup_name>.tar.gz -C <backup_local_dir>
  8. 더 이상 사용되지 않는 각 API의 오프라인 모드에서 oc convert를 실행합니다.

    $ oc convert -f <backup_local_dir>/resources/<gvk>.json
  9. 대상 클러스터에서 변환된 API를 생성합니다.

    $ oc create -f <gvk>.json

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

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

3.5.5.1. MTC 콘솔의 CA 인증서 오류

MTC 콘솔에 처음 액세스하려고 할 때 CA 인증서 오류 메시지가 표시되면 클러스터가 자체 서명된 CA 인증서를 사용하게 될 가능성이 큽니다.

오류 메시지에서 oauth-authorization-server URL로 이동하여 인증서를 수락합니다. 이 문제를 영구적으로 해결하려면 신뢰할 수 있도록 인증 기관을 설치합니다.

CA 인증서를 승인한 후 브라우저에 인증되지 않은 메시지가 표시되면 MTC 콘솔로 이동한 다음 웹 페이지를 새로 고칩니다.

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

MTC 콘솔에 자체 서명 인증서를 허용한 후 연결 시간이 초과된 메시지가 표시되면 원인은 다음 중 하나일 수 있습니다.

원인을 확인하려면 다음을 수행합니다.

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

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

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

BSL 오류 메시지

Error checking repository for stale locks

Error getting backup storage location: backupstoragelocation.velero.io \"my-bsl\" not found

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

3.5.5.4. 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. 저장을 클릭합니다.

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

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

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 오류가 있는 영구 볼륨을 식별합니다.

    Pod 볼륨 복원 오류로 CR 복원

    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를 식별합니다.

    Restic Pod 오류가 있는 PodVolumeRestore CR

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

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

    $ oc logs -f <restic-nr2v5>

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

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

Restic 권한 오류

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용 보조 그룹을 생성하고 그룹 ID를 MigrationController CR 매니페스트에 추가하여 이 문제를 해결할 수 있습니다.

프로세스

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

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

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

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

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

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

프로세스

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

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

3.5.7. Velero CLI를 사용하여 Backup 및 Restore CR을 디버깅합니다.

Velero 명령줄 인터페이스(CLI)를 사용하여 BackupRestore CR(사용자 정의 리소스) 및 부분 마이그레이션 실패를 디버깅할 수 있습니다. Velero CLI는 velero 포드에서 실행됩니다.

3.5.7.1. Velero 명령 구문

Velero CLI 명령은 다음 구문을 사용합니다.

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

$(oc get pods -n openshift-migration -o name | grep velero)를 대신해서 velero-<pod> -n openshift-migration을 지정할 수 있습니다.

3.5.7.2. 도움말 명령

Velero help 명령은 모든 Velero CLI 명령을 나열합니다.

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero --help

3.5.7.3. Describe 명령

Velero describe 명령은 Velero 리소스와 관련된 경고 및 오류 요약을 제공합니다.

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

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql

3.5.7.4. Logs 명령

Velero logs 명령은 Velero 리소스와 관련된 로그를 제공합니다.

velero <resource> logs <resource_id>

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

3.5.7.5. 부분적인 마이그레이션 실패 디버깅

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 exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore describe <restore>
    Phase:  PartiallyFailed (run 'velero restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf' for more information)
    
    Errors:
      Velero:     <none>
      Cluster:    <none>
      Namespaces:
        migration-example:  error restoring example.com/migration-example/migration-example: the server could not find the requested resource
  3. Velero logs 명령을 사용하여 Restore CR 로그를 확인합니다.

    $ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore logs <restore>
    time="2021-01-26T20:48:37Z" level=info msg="Attempting to restore migration-example: migration-example" logSource="pkg/restore/restore.go:1107" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf
    time="2021-01-26T20:48:37Z" level=info msg="error restoring migration-example: the server could not find the requested resource" logSource="pkg/restore/restore.go:1170" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

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

3.5.8. must-gather를 사용하여 데이터 수집

MTC(Migration Toolkit for Containers)의 Red Hat Customer Portal에서 고객 지원 사례를 여는 경우 must-gather 툴을 실행해야 합니다.

MTC의 openshift-migration-must-gather-rhel8 이미지는 기본 must-gather 이미지로 수집되지 않은 마이그레이션별 로그 및 데이터를 수집합니다.

프로세스

  1. must-gather 데이터를 저장하려는 디렉터리로 이동합니다.
  2. must-gather 명령을 실행합니다.

    $ oc adm must-gather --image=registry.redhat.io/rhmtc/openshift-migration-must-gather-rhel8:v1.4
  3. 인증 키 및 기타 민감한 정보를 제거합니다.
  4. must-gather 데이터 디렉터리의 콘텐츠가 포함된 아카이브 파일을 생성합니다.

    $ tar cvaf must-gather.tar.gz must-gather.local.<uid>/
  5. 압축 파일을 고객 지원 사례에 첨부 파일로 업로드합니다.

3.5.9. 마이그레이션 롤백

MTC 웹 콘솔 또는 CLI를 사용하여 마이그레이션을 롤백할 수 있습니다.

3.5.9.1. MTC 웹 콘솔에서 마이그레이션 롤백

MTC(Migration Toolkit for Containers) 웹 콘솔을 사용하여 마이그레이션을 롤백할 수 있습니다.

마이그레이션 실패로 인해 애플리케이션이 중지된 경우 영구 볼륨의 데이터 손상을 방지하려면 마이그레이션을 롤백해야 합니다.

원래 애플리케이션이 소스 클러스터에서 계속 실행 중이므로 마이그레이션 중에 애플리케이션이 중지되지 않은 경우 롤백이 필요하지 않습니다.

프로세스

  1. MTC 웹 콘솔에서 마이그레이션 계획을 클릭합니다.
  2. 마이그레이션 계획 옆의 옵션 메뉴 kebab 를 클릭하고 롤백을 선택합니다.
  3. 롤백을 클릭하고 롤백이 완료될 때까지 기다립니다.

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

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

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

CLI에서 MigMigration 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: migration-rollback
      namespace: openshift-migration
    spec:
    ...
      rollback: true
    ...
      migPlanRef:
        name: <migplan_name> 1
        namespace: openshift-migration
    EOF
    1
    연결된 MigPlan CR의 이름을 지정합니다.
  2. MTC 웹 콘솔에서 마이그레이션된 프로젝트 리소스가 대상 클러스터에서 제거되었는지 확인합니다.
  3. 마이그레이션된 프로젝트 리소스가 소스 클러스터에 있고 애플리케이션이 실행 중인지 확인합니다.

3.5.10. 확인된 문제

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

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

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

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

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

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

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

3.5.11. 추가 리소스

법적 공지

Copyright © 2021 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.