계획 권장사항

이 주제에서는 Migrate to Containers를 사용하여 수행한 실제 애플리케이션 마이그레이션을 기반으로 Google Kubernetes Engine(GKE) 또는 GKE Enterprise로의 애플리케이션 마이그레이션에 대한 조언을 제공합니다.

마이그레이션 센터 검색 클라이언트 CLI 또는 mcdc CLI는 컨테이너로의 마이그레이션에 대한 VM 워크로드의 적합성을 판단하는 데 사용하는 도구입니다.

Migrate to Containers는 다음에 설명된 특정 유형의 Linux 및 Windows 워크로드에 권장됩니다.

적합

Linux

Migrate to Containers를 사용한 마이그레이션에 적합한 Linux 애플리케이션에는 다음과 같은 애플리케이션 아키텍처가 포함됩니다.

  • 웹/애플리케이션 서버
  • 비즈니스 로직 미들웨어(예: Tomcat)
  • 멀티 VM, 다중 계층 스택(예: LAMP)
  • 중소 규모 데이터베이스(예: MySQL 및 PostgreSQL)

또한 Migrate to Containers를 사용한 마이그레이션에 가장 적합한 애플리케이션의 작동 특성은 다음과 같습니다.

  • 낮은 가동 주기, 간헐적으로 집중되는 워크로드
  • 개발, 테스트 및 학습 환경
  • 상시 가동되는 저부하 서비스

일반적으로 대부분의 Linux 워크로드는 적합하지 않음에 명시적으로 나열된 워크로드를 제외하면 마이그레이션과 호환됩니다.

Windows

Migrate to Containers를 사용한 마이그레이션에 적합한 Windows 애플리케이션에는 다음 특성을 모두 충족하는 워크로드가 포함됩니다.

  • IIS 7 이상, .NET Framework 3.5 이상이 포함된 ASP.NET
  • 웹 및 로직 등급
  • WS2008 R2 이상

운영체제 지원

Migrate to Containers는 이러한 VM 운영체제와 호환됩니다.

비적합

Linux

Linux의 경우 Migrate to Containers에 적합하지 않은 애플리케이션 및 서버는 다음과 같습니다.

  • 고성능 및 대용량 메모리 내 데이터베이스
  • 특수 커널 드라이버가 있는 VM(예: kernel-mode NFS)
  • 특정 하드웨어에 대한 종속 항목
  • 특정 하드웨어 ID 등록에 묶인 라이선스가 있는 소프트웨어

Windows

Windows의 경우 IIS 7 이상이 설치되어 있지 않은 워크로드는 마이그레이션에 적합하지 않습니다. 마이그레이션에 적합하지 않은 기타 유형의 애플리케이션은 다음과 같습니다.

  • GPU 또는 TPU에 종속 항목이 있는 애플리케이션
  • 하위 수준 네트워킹 애플리케이션
  • 데스크톱, RDP, VDI 애플리케이션
  • BYOL을 사용하는 애플리케이션

DNS 및 네트워크 액세스 규칙

GKE로 마이그레이션하기 전에 마이그레이션 된 워크로드에 사용되는 네트워크 리소스와 서비스에 대해 파악하고 Virtual Private Cloud에서 이러한 리소스와 서비스에 액세스하고 연결할 수 있는지 확인하세요.

Kubernetes 서비스 이름 계획

워크로드가 서비스에 액세스하기 위해 DNS에 의존하는 경우 Kubernetes 네임스페이스 스키마, 네트워크 정책, 서비스 이름을 계획해야 합니다.

마이그레이션 프로세스로 생성된 배포 사양에는 'ClusterIP' 유형의 제안된 헤드리스 Service 객체가 포함됩니다. 'ClusterIP'는 부하 분산이 없고 클러스터 내부에서만 연결할 수 있는 단일 클러스터 내부 IP를 의미합니다. Kubernetes 엔드포인트 컨트롤러는 deployment_spec.yaml에서 "app": "app-name"으로 라벨이 표시되고, 포드로 연결되는 레코드(주소)를 반환하도록 DNS 구성을 수정합니다.

포드와 컨테이너 연결을 위한 서비스 만들기 및 적용

워크로드를 마이그레이션한 후에는 호스트 이름을 더 이상 적용할 수 없습니다. 워크로드에 연결할 수 있도록 하려면 서비스를 만들어 적용합니다.

마이그레이션된 이름과 IP 식별 및 구성

GKE는 /etc/hosts 파일을 관리합니다. Migrate to Containers에서는 소스 VM에서 GKE로 호스트 파일을 조정이 아직 자동화되지 않았습니다. 마이그레이션된 VM의 호스트 파일에 있는 이름과 IP를 식별하여 hostAliases로 구성해야 합니다.

종속 서비스를 동일한 네임스페이스에 배치

서로 종속된 서비스는 동일한 Kubernetes 네임스페이스에 같이 위치하고 짧은 DNS 이름(예: app 및 db)을 사용하여 통신해야 합니다. 이 구성은 프로덕션, 스테이징, 테스트와 같은 여러 애플리케이션 환경을 복제하는 데도 유용합니다.

GKE 네트워킹으로 액세스 표면 제어

GKE에는 정교한 네트워킹 제어 기능이 있습니다. 포드는 공용 인터넷, VPC 네트워크, 내부 클러스터 네트워크와 같은 다른 네트워크에서 액세스가 가능합니다. 이는 VLAN, 필터, 라우팅 규칙 관리의 복잡성을 추가하지 않고도 워크로드에 대한 액세스 표면을 추가로 제어하고 제한할 수 있는 기회를 제공합니다.

예를 들어 일반적인 3계층 애플리케이션에는 프런트엔드, 애플리케이션, 데이터베이스 계층이 있습니다. Google Cloud로 마이그레이션될 때 프런트엔드 서비스는 VPC 네트워크에서 LoadBalancer로 구성됩니다. 다른 계층은 GKE 클러스터에서 직접 액세스할 수 없습니다. 네트워크 액세스 정책은 내부 클러스터 네트워크 내의 프런트엔드 포드에서만 애플리케이션 서비스에 액세스할 수 있도록 합니다. 또 다른 정책은 애플리케이션 포드에서만 데이터베이스 포드에 액세스할 수 있도록 합니다.

NFS

NFS 마운트를 영구 볼륨으로 정의

마이그레이션 계획을 만들 때 소스 VM의 NFS 클라이언트 마운트를 자동으로 검색하고 생성된 계획에 추가합니다.

마운트는 계획에 추가될 때 기본적으로 사용 중지됩니다. 즉, 마이그레이션 아티팩트를 생성할 때 PersistentVolume 및 PersistentVolumeClaim 정의가 deployment_spec.yaml 파일에 포함되지 않습니다. Migrate to Containers에서 PersistentVolume 및 PersistentVolumeClaim 정의를 생성하려면 먼저 마이그레이션 계획을 수정하여 NFS 클라이언트 마운트를 사용 설정해야 합니다.

자세한 내용은 NFS 마운트 맞춤설정을 참조하세요.

kernel-mode NFS 서버

NFS 서버가 kernel-mode로 실행되는 VM은 Migrate to Containers를 사용하여 GKE로 마이그레이션할 수 없습니다. 이러한 VM은 Compute Engine에서 VM으로 마이그레이션해야 합니다. 또는 클라우드 기반 NFS 솔루션에 Filestore를 사용할 수 있습니다.

소스 NFS 공유에서 데이터 마이그레이션

소스 VM이 NFS 공유 마운트를 사용하는 경우 이 데이터를 자동으로 마이그레이션되지 않습니다. NFS 영구 볼륨을 사용하여 마이그레이션된 워크로드에 공유를 마운트하거나, 소스 NFS 공유가 원격이라면 클러스터에 대해 낮은 지연 시간 액세스를 제공하는 다른 파일 공유에 데이터를 복사합니다.

데이터 복사 옵션은 다음을 참조하세요.

  1. Storage Transfer Service 또는 Transfer Appliance

  2. gsutil rsync로 데이터 복사(소스 파일 공유에서 버킷으로, 이후 버킷에서 클라우드의 파일 공유로)

  3. NetApp Cloud Volumes에 대한 NetApp SnapMirror와 같은 서드 파티 솔루션

  4. Rsync와 같은 OSS 유틸리티

데이터베이스 액세스 가능성 확인

애플리케이션에 VM에서 로컬로 실행되거나 외부 머신에서 실행되는 데이터베이스가 사용되는 경우 새로 마이그레이션된 포드에서 데이터베이스에 액세스할 수 있는지 확인해야 합니다. 네트워크 방화벽 정책에 따라 클러스터에서 데이터베이스로의 액세스가 허용되는지 검사해야 합니다.

데이터베이스를 Google Cloud로 마이그레이션하려면 Database Migration Service를 사용하는 것이 좋습니다.

또는 클러스터 내에서 데이터베이스를 실행할 수 있습니다. 자세한 내용은 GKE에서 데이터베이스 배포 계획을 참조하세요.

삽입된 메타데이터를 사용할 수 있도록 하기

애플리케이션이 삽입된 메타데이터(예를 들어 환경 변수)에 의존하는 경우 GKE에서 이 메타데이터를 사용할 수 있도록 해야 합니다. 동일한 메타데이터 삽입 방법을 사용할 수 없는 경우 GKE는 ConfigMaps 및 Secrets를 제공합니다.

runlevel 3에서 시작하도록 필요한 서비스 구성

Migrate to Containers 워크로드는 실행 수준 3에만 연결됩니다. Migrate to Containers를 사용하여 GKE로 마이그레이션된 VM은 Linux runlevel 3의 컨테이너에서 부팅됩니다. 특정 서비스(예를 들어 VNC를 사용한 원격 GUI 액세스를 위한 X11 또는 XDM)는 기본적으로 runlevel 5에서만 시작되도록 구성됩니다. 필요한 모든 서비스는 runlevel 3에서 시작하도록 구성되어야 합니다.

불필요한 서비스 사용 중지

Migrate to Containers는 하드웨어 또는 환경 관련 서비스와 VM에서 실행되는 사전 정의된 추가 서비스 집합을 자동으로 중지합니다. 이러한 서비스는 워크로드를 컨테이너로 마이그레이션한 후 필요하지 않습니다.

예를 들어 Migrate to Containers는 iptable, ip6tables, firewalld를 자동으로 사용 중지합니다. Migrate to Containers에 의해 사용 중지되는 서비스의 전체 목록을 보려면 blocklist.yaml 파일을 다운로드합니다.

사용 중지된 서비스 맞춤설정

기본적으로 Migrate to Containers는 위에 나열된 불필요한 서비스를 사용 중지합니다. 또한 마이그레이션 계획을 맞춤설정하여 차단 목록을 정의하여 마이그레이션된 컨테이너에서 사용 중지할 고유한 커스텀 서비스 목록을 정의할 수도 있습니다. 차단 목록에서는 마이그레이션된 컨테이너에서 사용 중지할 서비스를 하나 이상 지정합니다.

마이그레이션된 VM 유지보수 및 업데이트

마이그레이션 중 생성하는 아티팩트를 사용하여 애플리케이션 및 사용자 모드 OS 소프트웨어 업데이트 적용, 보안 패치 적용, 삽입된 구성 수정, 파일 추가 또는 교체, Migrate to Containers 런타임 소프트웨어 업데이트를 수행할 수 있습니다.

자세한 내용은 마이그레이션 후 이미지 업데이트를 참조하세요.

다음 단계