GKE로의 마이그레이션 여정

이 주제에서는 워크로드를 GKE로 마이그레이션할 때 수행해야 하는 몇 가지 단계를 설명합니다.

상위 수준의 탐색 및 평가 단계를 거쳐야 합니다. 이 단계에서 어떤 워크로드가 있는지, 워크로드 간의 종속성, 클라우드로 마이그레이션할 수 있는지 여부를 파악합니다.

그런 다음 마이그레이션 계획 단계로 들어가 워크로드 제품군을 평가 결과에 따라 관련 있고 함께 마이그레이션해야 하는 그룹으로 나누고 마이그레이션할 그룹 순서를 결정합니다.

또한 GKE로 마이그레이션해야 하는 워크로드와 GKE에 적합하지 않지만 Migrate for Compute Engine을 사용하여 Compute Engine으로 마이그레이션할 수 있는 워크로드를 결정합니다. GKE에 적합한 워크로드의 경우에도 워크로드 마이그레이션 도전과제를 두 가지 별개의 단계로 나눌지 선택할 수 있습니다.

  1. Migrate for Compute Engine을 사용하여 워크로드를 Compute Engine으로 마이그레이션합니다.
  2. Migrate for Anthos를 사용하여 Compute Engine에서 GKE로 마이그레이션합니다.

예를 들어 데이터 센터 마이그레이션을 수행하고 모든 워크로드를 Compute Engine으로 마이그레이션하려는 경우 그리고 두 번째 단계에서만 선택적으로 적절한 워크로드를 GKE로 마이그레이션하려는 경우에 이 방법이 적합합니다. 다이어그램에 표시된 대로 특정 워크로드에 대해 원하는 경로를 선택하면 시작 영역 설정 마이그레이션을 수행한 다음 마이그레이션 후 최적화 단계를 수행해야 합니다.

Migrate for Anthos를 사용하여 VM 또는 컨테이너로 마이그레이션하는 단계입니다.

검색

애플리케이션 및 애플리케이션의 종속 항목을 파악하여 마이그레이션에 필요한 정보를 수집합니다. 여기에는 다음의 인벤토리가 포함됩니다.

  • 워크로드를 마이그레이션 할 VM입니다.
  • 애플리케이션의 필수 네트워크 포트 및 연결
  • 앱 계층 간 종속 항목
  • 서비스 이름 확인 또는 DNS 구성

역할

  • 애플리케이션의 토폴로지 및 마이그레이션에 대한 지식을 갖춘 IT 분석가

마이그레이션 계획

애플리케이션을 배치로 나누고 탐색 단계에서 수집한 정보를 Kubernetes 모델로 변환합니다. 애플리케이션 환경, 토폴로지, 네임스페이스, 정책은 Kubernetes YAML 구성 파일로 중앙 집중화됩니다. 샘플 YAML 파일을 사용할 수 있습니다.

역할

  • 애플리케이션 마이그레이션 엔지니어 또는 분석가. Kubernetes 관리 객체 모델, GKE 배포, YAML 파일에 대한 기초적인 수준의 지식이 필요합니다.

시작 영역 설정

이 단계에서는 다음을 수행합니다.

  • 마이그레이션된 워크로드를 호스팅할 GKE 클러스터를 만들거나 식별합니다.
  • 애플리케이션에 대한 VPC 네트워크 규칙 및 Kubernetes 네트워크 정책을 만듭니다.
  • Kubernetes 서비스 정의를 적용합니다.
  • 부하 분산 옵션을 선택합니다.
  • DNS를 구성합니다.

역할

  • 클러스터 배포, Google Cloud Networking, 방화벽 규칙, Cloud Identity and Access Management 서비스 계정 및 역할, Google Cloud Marketplace의 배포에 익숙한 GKE 클러스터 관리자

GKE로 마이그레이션 및 유효성 검사

GKE 클러스터, VPC 네트워크, Migrate for Anthos 구성요소가 워크로드를 처리할 준비가 된 후 마이그레이션하려는 각 소스 VM에 Migrate for Anthos 마이그레이션 워크플로를 시작할 수 있습니다. 다음 가이드 라인에 따라 소스 워크로드 및 운영체제와 Migrate for Anthos의 호환성을 평가하세요. 마이그레이션 워크플로는 다음 다이어그램에 나와 있습니다.

설정 및 마이그레이션 단계의 개요를 보여주는 다이어그램

마이그레이션 워크플로에는 다음 5단계가 포함됩니다.

  1. 마이그레이션 계획 생성 및 검토 -- Linux 워크로드 Migrate for Anthos migctl CLI 또는 Windows 워크로드 마이그레이션 스크립트를 사용하여 마이그레이션 계획을 생성한 후 애플리케이션 소유자, 보안 관리자, 스토리지 관리자 등의 주요 이해 관계자의 의견을 받아 계획을 검토하고 업데이트합니다.
  2. 아티팩트 생성 -- CLI에 대한 입력으로 소스 VM을 처리하고 관련 아티팩트를 생성하도록 마이그레이션 계획을 사용합니다.
    • Linux 워크로드 -- 컨테이너 이미지, Dockerfile, 참조 배포 YAML(스테이트풀(Stateful) 워크로드로 지정된 경우 -- 데이터 볼륨)
    • Windows 워크로드 -- ZIP 아카이브에서 추출된 애플리케이션 파일과 Dockerfile 참고: 다음 단계로 진행하기 전에 Dockerfile 및 추출된 콘텐츠를 사용하여 컨테이너 이미지를 빌드해야 합니다.
  3. 테스트 -- 테스트, 스테이징 또는 프로덕션 클러스터에서 엔드 투 엔드 애플리케이션 레벨 유효성 검사를 위해 워크로드 배포를 진행하기 전에 추출된 컨테이너 이미지와 데이터 볼륨(해당하는 경우)이 올바르게 작동하는지 확인해 보는 것이 좋습니다. 처리 클러스터에서 '상태 테스트'를 실행하고 마이그레이션 계획에 필요한 문제나 수정 사항을 식별한 다음 2단계를 반복하고 다시 테스트할 수 있습니다.
  4. 데이터 동기화 -- 스테이트풀(Stateful) 워크로드가 마이그레이션되고 소스에서 실행되는 동안 워크로드가 새 데이터와 상태를 누적하면 최종 데이터 싱크를 수행하기 전에 소스 종료와 함께 하나 이상의 데이터 동기화 주기를 반복할 수 있습니다. 이렇게 하면 컷오버 다운타임을 줄일 수 있습니다. 각 데이터 동기화 실행은 마지막 데이터 동기화 주기 이후에 변경된 데이터만 전송합니다.
  5. CI/CD 배포 또는 통합 -- 이제 컨테이너 아티팩트가 준비되고 검증되었으므로 테스트, 스테이징 또는 프로덕션 클러스터에서 배포를 계속할 수 있습니다. 또는 Cloud Build와 같은 조정 도구를 사용하여 아티팩트로 빌드 및 배포 파이프라인과 통합할 수 있습니다.

역할

  • 워크로드 마이그레이션:
    • Kubernetes 관리 객체 모델, GKE 배포, YAML 편집에 대한 기초적인 수준의 지식이 있는 애플리케이션 소유자 또는 애플리케이션 마이그레이션 분석가.
  • 선택 사항: GCP PD 이외의 영구 볼륨으로 데이터 스토리지를 마이그레이션하는 경우:
    • GKE의 Kubernetes 영구 볼륨 관리에 익숙한 스토리지 관리자 또는 GKE 관리자.

운영 및 최적화

이제 Anthos와 더 큰 Kubernetes 생태계에서 제공하는 도구를 활용할 수 있습니다. 이 단계에서는 구성을 변경하고 애플리케이션은 다시 빌드하지 않고 Cloud Logging 및 Cloud Monitoring으로 Istio, 모니터링 및 로깅을 사용하여 액세스 정책, 암호화 및 인증을 추가할 수 있습니다. 또한 Cloud Build와 같은 도구를 사용하여 CI/CD 파이프라인과 통합하여 소프트웨어 패키지 및 버전 업데이트와 같은 2일차 유지보수 절차를 구현할 수 있습니다.