컨테이너를 Google Cloud로 마이그레이션: Kubernetes를 GKE로 마이그레이션

Last reviewed 2023-05-22 UTC

이 문서에서는 자체 관리형 Kubernete 환경에서 Google Kubernetes Engine(GKE)으로 마이그레이션을 계획, 설계, 구현하는 방법을 설명합니다. 잘못 수행할 경우 한 환경에서 다른 환경으로 앱을 이동하는 것이 어려워 질 수 있으므로 마이그레이션을 신중하게 계획하고 실행해야 합니다.

이 문서는 Google Cloud로 마이그레이션하는 방법을 다루는 시리즈의 일부입니다. 시리즈의 개요에 대해 자세히 알아보려면 Google Cloud로 마이그레이션: 마이그레이션 경로 선택을 참조하세요.

이 문서는 컨테이너를 Google Cloud로 마이그레이션하는 방법을 설명하는 시리즈의 일부입니다.

이 문서는 자체 관리형 Kubernetes 환경에서 GKE로 마이그레이션하려는 경우에 유용합니다. 개발자 환경은 온프레미스 환경, 비공개 호스팅 환경 또는 다른 클라우드 제공업체에서 실행 중일 수 있습니다. 이 문서는 마이그레이션 기회를 살펴보고 마이그레이션 과정을 미리 알아보고자 할 때 유용합니다.

GKE를 사용하면 다음과 같은 이점이 있습니다.

다음 다이어그램은 마이그레이션 과정을 보여줍니다.

4가지 단계로 구성된 마이그레이션 경로

마이그레이션 단계별로 Google Cloud로 마이그레이션: 시작하기에서 정의된 단계를 수행합니다.

  1. 워크로드 평가 및 검색
  2. 기반 계획 및 구축
  3. 워크로드 배포
  4. 환경 최적화

환경 평가

평가 단계에서는 자체 관리형 Kubernetes 환경을 GKE로 마이그레이션하기 위한 요구사항과 종속 항목을 결정합니다.

  1. 앱의 포괄적인 인벤토리를 빌드합니다.
  2. 앱의 속성과 종속 항목에 따라 앱을 분류합니다.
  3. 팀에 Google Cloud 교육을 실시합니다.
  4. Google Cloud에 대한 실험 및 개념 증명을 빌드합니다.
  5. 대상 환경의 총소유비용(TCO)을 계산합니다.
  6. 먼저 마이그레이션할 워크로드를 선택합니다.

다음 섹션에서는 Google Cloud로 마이그레이션: 워크로드 평가 및 검색을 사용합니다.

인벤토리 빌드

마이그레이션 범위를 지정하려면 현재 Kubernetes 환경을 이해해야 합니다. 먼저 클러스터에 대한 정보를 수집한 후 클러스터에 배포된 워크로드와 워크로드 종속 항목에 집중합니다. 평가 단계가 끝나면 인벤토리 두 개가 생성됩니다. 하나는 클러스터용이고 다른 하나는 클러스터에 배포된 워크로드용입니다.

클러스터의 인벤토리를 빌드하려면 각 클러스터에서 다음 사항을 고려합니다.

  • 노드 수 및 유형 현재 환경에 있는 노드 수와 각 노드의 특성을 알고 있으면 GKE로 이동할 때 클러스터 크기를 조정합니다. 새 환경의 노드가 개발자 환경에서 사용하는 노드와 다른 하드웨어 아키텍처 생성에서 실행될 수 있습니다. 각 아키텍처 생성 성능이 다르므로 새 환경에 필요한 노드 수가 환경과 다를 수 있습니다. 고성능 스토리지 기기, GPU, TPU와 같이 노드에서 사용하는 모든 유형의 하드웨어를 평가합니다.
  • 내부 또는 외부 클러스터. 각 클러스터가 노출되는 환경 내부 또는 외부의 작업 수행자를 평가합니다. 사용 사례를 지원하기 위해 이 평가에는 클러스터에서 실행되는 워크로드와 클러스터와 상호작용하는 인터페이스가 포함되어 있습니다.
  • 멀티테넌시. 환경에서 멀티 테넌트 클러스터를 관리할 경우 새 Google Cloud 환경에서 작동하는지 평가합니다. 멀티테넌시 전략이 Google Cloud에서의 기반 구축 방식에 영향을 미치므로 지금 멀티 테넌트 클러스터의 개선 방법을 평가하는 것이 좋습니다.
  • Kubernetes 버전. 클러스터의 Kubernetes 버전에 대한 정보를 수집하여 해당 버전과 GKE에서 사용 가능한 버전 간의 불일치 여부를 평가합니다. 이전 버전 또는 최근 출시된 버전을 실행할 경우 GKE에서 사용할 수 없는 기능이 사용 중일 수 있습니다. 기능이 지원 중단되었거나 이 기능을 제공하는 Kubernetes 버전을 아직 GKE에서 사용하지 못할 수 있습니다.
  • Kubernetes 업그레이드 주기. 안정적인 환경을 유지하려면 Kubernetes 업그레이드를 처리하는 방법과 업그레이드 주기가 GKE 업그레이드와 어떻게 관련되는지 이해해야 합니다.
  • 노드 풀. 형태에 관계없이 노드 그룹화를 사용하는 경우 그룹화 기준이 GKE에 적합하지 않을 수 있으므로 그룹화가 GKE의 노드 풀 개념과 어떻게 연결되는지 고려해야 합니다.
  • 노드 초기화. 워크로드를 실행할 수 있는 것으로 표시하기 전에 각 노드의 초기화 방법을 평가하여 이러한 초기화 절차를 GKE로 포팅할 수 있습니다.

인벤토리에서 평가하는 다음 항목은 인프라와 Kubernetes 클러스터의 보안에 중점을 둡니다.

  • 네임스페이스. 클러스터에서 Kubernetes 네임스페이스를 사용하여 리소스를 논리적으로 구분하는 경우 각 네임스페이스에 있는 리소스를 평가하고 이렇게 구분한 이유를 파악합니다. 예를 들어 멀티테넌시 전략의 일환으로 네임스페이스를 사용할 수 있습니다. Kubernetes 시스템 구성요소용으로 예약된 네임스페이스에 워크로드를 배포할 수 있으며 GKE에 제어 권한이 많지 않을 수 있습니다.
  • 역할 기반 액세스 제어(RBAC). 클러스터에서 RBAC 승인을 사용할 경우 클러스터에서 구성한 모든 ClusterRole 및 ClusterRoleBinding에 대한 설명을 나열합니다.
  • 네트워크 정책. 클러스터에서 구성한 모든 네트워크 정책을 나열하고 GKE에서 네트워크 정책 작동 방식을 파악합니다.
  • 포드 보안 컨텍스트. 클러스터에서 구성한 포드 보안 컨텍스트에 대한 정보를 캡처하고 GKE에서 이들이 작동하는 방식을 알아봅니다.
  • 서비스 계정. 클러스터의 프로세스가 Kubernetes API 서버와 상호작용하는 경우 사용 중인 서비스 계정에 대한 정보를 캡처합니다.

Kubernetes 클러스터 인벤토리를 완료하고 환경의 보안을 평가한 후에는 클러스터에 배포된 워크로드의 인벤토리를 빌드합니다. 워크로드를 평가할 때는 다음 측면에 대한 정보를 수집합니다.

  • Pod 및 컨트롤러. 새 환경에서 클러스터 크기를 조정하려면 배포한 각 워크로드의 인스턴스 수를 평가하고 리소스 할당량 및 Compute 리소스 소비 한도를 사용할지 여부를 평가합니다. 각 클러스터의 제어 영역 노드에서 실행 중인 워크로드와 각 워크로드에서 사용하는 컨트롤러에 대한 정보를 수집합니다. 예를 들어 사용 중인 배포 수와 DamonSet 수를 살펴볼 수 있습니다.
  • 작업 및 CronJob. 클러스터 및 워크로드는 초기화 또는 작업 절차의 일부로 작업 또는 CronJob을 실행해야 할 수 있습니다. 배포한 작업 및 CronJob의 인스턴스 수와 각 인스턴스의 책임 및 완료 기준을 평가합니다.
  • Kubernetes 자동 확장 처리. 새 환경에서 자동 확장 정책을 마이그레이션하려면 GKE에서 수평형 포드 자동 확장 처리, 수직형 포드 자동 확장 처리, 다차원 포드 자동 확장 처리의 작동 방식을 알아봅니다.
  • 스테이트리스(Stateless) 워크로드와 스테이트풀(Stateful) 워크로드. 스테이트리스(Stateless) 워크로드는 클러스터 또는 영구 스토리지에 데이터 또는 상태를 저장하지 않습니다. 스테이트풀(Stateful) 애플리케이션은 나중에 사용할 수 있도록 데이터를 저장합니다. 스테이트풀(Stateful) 워크로드 마이그레이션은 일반적으로 스테이트리스(Stateless) 워크로드 마이그레이션보다 어려우므로 각 워크로드에서 구성요소가 스테이트리스(Stateless) 및 스테이트풀(Stateful)인지 평가합니다.
  • Kubernetes 특징. 클러스터 인벤토리에서 각 클러스터가 실행하는 Kubernetes 버전을 확인할 수 있습니다. 각 Kubernetes 버전의 출시 노트를 검토하여 제공되는 기능과 지원 중단되는 기능을 확인합니다. 그런 다음 필요한 Kubernetes 기능과 비교하여 워크로드를 평가합니다. 이 작업을 수행하는 이유는 지원 중단된 기능 또는 아직 GKE에서 사용할 수 없는 기능을 사용하고 있는지 확인하기 위함입니다. 사용할 수 없는 기능이 있으면 지원 중단된 기능에서 마이그레이션하고 새 기능을 GKE에서 사용할 수 있을 때 채택합니다.
  • 스토리지. 스테이트풀(Stateful) 워크로드의 경우 PersistenceVolumeClaim을 사용하는지 평가합니다. 크기 및 액세스 모드와 같은 스토리지 요구사항과 이러한 PersistenceVolumeClaim과 PersistenceVolume 간의 연결 관계를 나열합니다. 향후 성장을 고려하여 PersistenceVolumeClaim을 확장해야 하는지 평가합니다.
  • 구성 및 보안 비밀 삽입. 환경 구성이 변경될 때마다 배포 가능한 아티팩트를 다시 빌드하지 않으려면 ConfigMap과 Secret을 사용하여 구성과 보안 비밀을 Pod에 삽입합니다. 각 워크로드에서 사용하는 ConfigMap 및 Secret과 이들 객체를 채우는 방법을 평가합니다.
  • 종속 항목. 워크로드는 격리된 상태로 작동하지 않을 수 있습니다. 클러스터 내부 또는 외부 시스템의 종속 항목이 있을 수 있습니다. 각 워크로드에서 종속 항목을 캡처하고, 종속 항목을 사용할 수 없는 경우가 허용되는지 파악합니다. 예를 들어 일반적인 종속 항목에는 분산 파일 시스템, 데이터베이스, 보안 비밀 배포 플랫폼, ID 및 액세스 관리 시스템, 서비스 검색 메커니즘, 기타 외부 시스템이 있습니다.
  • Kubernetes 서비스. 내부 및 외부 클라이언트에 워크로드를 노출하려면 서비스를 사용합니다. 각 서비스의 유형을 알고 있어야 합니다. 외부에 노출된 서비스의 경우 서비스가 나머지 인프라와 상호작용하는 방식을 평가합니다. 예를 들어 인프라에서 LoadBalancer 서비스와 인그레스 객체를 어떻게 지원하나요? 클러스터에 배포한 인그레스 컨트롤러가 무엇인가요?
  • 서비스 메시. 환경에서 서비스 메시를 사용할 경우 구성 방법을 평가합니다. 또한 걸쳐 있는 클러스터 수, 메시의 일부인 서비스, 메시의 토폴로지를 수정하는 방법도 알아야 합니다. 예를 들어 자동 사이드카 삽입을 사용하여 Kubernetes 포드에 사이드카를 자동으로 추가하나요?
  • taint 및 톨러레이션(toleration)과 어피니티 및 안티-어피니티. 각 포드 및 노드에 대해 Kubernetes 클러스터에서 포드 예약을 맞춤설정하기 위해 노드 taint, 포드 톨러레이션(toleration) 또는 어피니티를 구성했는지 평가합니다. 이러한 속성은 가능한 비동질적 노드 또는 포드 구성에 대한 유용한 정보를 제공할 수 있으며 포드, 노드 또는 둘 다 특별한 집중 및 주의를 기울여 평가해야 할 수도 있음을 의미합니다. 예를 들어 특정 포드 집합이 Kubernetes 클러스터의 특정 노드에서만 예약되도록 구성한 경우 포드가 해당 노드에서만 사용할 수 있는 특수 리소스를 필요로 할 수 있습니다.

클러스터와 워크로드의 평가가 끝났으면 인프라의 나머지 지원 서비스와 측면을 평가합니다. 예를 들면 다음과 같습니다.

  • StorageClass 및 PersistentVolume. 동적 프로비저닝에 StorageClass를, 정적 프로비저닝된 PersistentVolume을 나열하여 인프라에서 PersistentVolumeClaim을 지원하는 방식을 평가합니다. 각 PersistentVolume에서 용량, 볼륨 모드, 액세스 모드, 클래스, 회수 정책, 마운트 옵션, 노드 어피니티를 고려합니다.
  • VolumeSnapshot 및 VolumeSnapshotContent. 각 PersistentVolume에서 VolumeSnapshot을 구성했는지 그리고 기존 VolumeSnapshotContent를 마이그레이션해야 하는지 평가합니다.
  • 컨테이너 스토리지 인터페이스(CSI) 드라이버. 클러스터에 배포된 경우 이 드라이버가 GKE와 호환되는지, GKE와 호환되는 CSI 드라이버와 함께 작동하도록 볼륨 구성을 조정해야 하는지 여부를 평가합니다.
  • 데이터 스토리지. 외부 시스템을 활용하여 PersistentVolume을 프로비저닝하는 경우 GKE 환경의 워크로드에 이러한 시스템을 사용할 수 있는 방법을 제공합니다. 외부 시스템과 GKE 환경 간의 지연 시간은 이들 간의 거리에 비례하므로 데이터 지역성은 스테이트풀(Stateful) 워크로드 성능에 영향을 미칩니다. 각 외부 데이터 스토리지 시스템에서 블록 볼륨, 파일 스토리지 또는 객체 스토리지와 같은 유형과 충족해야 하는 성능과 가용성 요구사항을 고려합니다.
  • 로깅, 모니터링, 추적. 모니터링, 로깅, 추적 시스템에 대한 정보를 캡처합니다. 시스템을 Google Cloud Observability와 통합하거나 Google Cloud Observability를 유일한 모니터링, 로깅, 추적 도구로 사용할 수 있습니다. 예를 들어 Google Cloud Observability를 다른 서비스와 통합하고 기본 프로그래밍 언어의 로깅 인터페이스를 설정하고, VM에서 Cloud Logging 에이전트를 사용할 수 있습니다. GKE는 Google Cloud Observability 및 Cloud 감사 로그와 통합됩니다. Fluentd로 GKE용 Cloud Logging 로그를 맞춤설정한 후 Dataflow를 사용하여 대규모 로그를 처리할 수도 있습니다.
  • 커스텀 리소스 및 Kubernetes 부가기능. GKE에서 작동하지 않거나 수정해야 할 수 있으므로 클러스터에 배포했을 수 있는 커스텀 Kubernetes 리소스 및 Kubernetes 부가기능에 대한 정보를 수집합니다. 예를 들어 커스텀 리소스가 외부 시스템과 상호작용하는 경우 Google Cloud 환경에 적용할 수 있는지 평가합니다.

평가 완료

Kubernetes 클러스터 및 워크로드와 관련된 인벤토리를 빌드한 후 Google Cloud로 마이그레이션: 워크로드 평가 및 검색에서 평가 단계의 나머지 활동을 완료합니다.

기반 계획 및 빌드

계획 및 구축 단계에서는 Google Cloud에서 워크로드를 지원하는 클라우드 인프라와 서비스를 프로비저닝하고 구성합니다.

  1. 리소스 계층 구조를 빌드합니다.
  2. ID 및 액세스 관리를 구성합니다.
  3. 결제를 설정합니다.
  4. 네트워크 연결을 설정합니다.
  5. 보안을 강화합니다.
  6. 모니터링 및 알림을 설정합니다.

Kubernetes 환경에서 워크로드를 관리하기 위해 infracode-as-code를 이미 채택한 경우 Google Cloud 환경에 동일한 프로세스를 적용할 수 있습니다. Kubernetes 라벨과 주석을 사용하여 GKE가 자동으로 프로비저닝하는 일부 Google Cloud 리소스를 구성할 수 있으므로 Kubernetes 설명자를 분석합니다. 예를 들어 LoadBalancer 서비스에 주석을 추가하여 외부 부하 분산기 대신 내부 부하 분산기를 프로비저닝할 수 있습니다.

다음 섹션에서는 Google Cloud로 마이그레이션: 기반 구축을 따릅니다.

리소스 계층 구조 빌드

효율적인 리소스 계층 구조를 설계하려면 Google Cloud로 마이그레이션: 기반 구축에 설명된 대로 비즈니스와 조직 구조를 Google Cloud에 연결하는 방법을 고려합니다.

예를 들어 GKE에 멀티 테넌트 환경이 필요한 경우 다음 옵션 중 하나를 선택할 수 있습니다.

  • 테넌트마다 Google Cloud 프로젝트 한 개를 만듭니다.
  • 여러 테넌트간에 프로젝트 하나를 공유하고 여러 GKE 클러스터를 프로비저닝합니다.
  • Kubernetes 네임스페이스를 사용합니다.

격리, 복잡성, 확장성 요구사항에 따라 선택합니다. 예를 들어 테넌트당 프로젝트 하나를 만들면 테넌트가 서로 격리되지만 프로젝트 수가 많아져 리소스 계층 구조 관리가 더 복잡해집니다. 그러나 Kubernetes 네임스페이스 관리는 복잡한 리소스 계층 구조보다 상대적으로 수월하지만 이 옵션은 높은 수준의 격리를 보장하지 않습니다. 예를 들어 테넌트간에 제어 영역이 공유될 수 있습니다.

ID 및 액세스 관리 구성

Identity and Access Management는 클라우드 리소스에 대한 세분화된 액세스 제어를 중앙에서 구성하는 도구를 제공합니다. 자세한 내용은 Identity and Access Management를 참조하세요.

Kubernetes RBAC가 Google Cloud의 ID 및 액세스 관리 기능과 상호작용하는 방식을 검토하고 평가 단계에서 수집한 요구사항에 따라 RBAC를 구성합니다.

결제 설정

Google Cloud 리소스를 프로비저닝하기 전에 Cloud Billing을 구성하고 GKE 가격 책정 모델을 이해합니다. 자세한 내용은 결제를 참고하세요.

네트워크 연결 설정

네트워크 구성은 환경의 기본 요소입니다. GKE 네트워크 모델과 워크로드의 연결 요구사항을 평가합니다. 그러면 네트워크 구성 계획을 시작할 수 있습니다. 자세한 내용은 연결 및 네트워킹을 참조하세요.

보안 강화

환경 보안 모델과 Google Cloud 모델 간의 차이점 그리고 GKE 클러스터의 보안 강화 방법을 이해해야 주요 애셋을 보호할 수 있습니다. 자세한 내용은 보안을 참조하세요.

모니터링 및 알림 설정

인프라와 워크로드의 성능을 명확하게 파악해야만 개선점도 찾을 수 있습니다. GKE는 Google Cloud Observability와 긴밀히 통합되므로 이러한 클러스터 내에서 GKE 클러스터와 워크로드에 대한 로깅 및 모니터링 정보를 얻을 수 있습니다. 자세한 내용은 모니터링 및 알림을 참조하세요.

워크로드 배포

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

  1. GKE 환경을 프로비저닝하고 구성합니다.
  2. GKE 클러스터를 구성합니다.
  3. 원본 환경에서 Google Cloud로 데이터를 마이그레이션합니다.
  4. GKE 환경에 워크로드를 배포합니다.
  5. 워크로드를 검증합니다.
  6. GKE에서 실행되는 워크로드를 노출합니다.
  7. 원본 환경에서 GKE 환경으로 트래픽을 전환합니다.
  8. 원본 환경을 사용 중단합니다.

런타임 플랫폼과 환경 프로비저닝 및 구성

워크로드를 새 Google Cloud 환경으로 이동하기 전에 GKE 클러스터를 프로비저닝합니다.

평가 단계가 끝나면 이제 새 Google Cloud 환경에서 필요에 맞게 GKE 클러스터를 프로비저닝하는 방법을 알게 됩니다. 다음을 프로비저닝할 수 있습니다.

GKE 클러스터 프로비저닝에 대한 자세한 내용은 다음을 참조하세요.

클러스터 구성

GKE 클러스터를 프로비저닝한 후 워크로드를 배포하거나 데이터를 마이그레이션하기 전에 GKE 클러스터마다 네임스페이스, RBAC, 네트워크 정책, 리소스 할당량, 기타 Kubernetes 및 GKE 객체를 구성합니다.

GKE 클러스터에서 Kubernetes 및 GKE 객체를 구성하려면 다음을 수행하는 것이 좋습니다.

  1. 원본 환경과 GKE 환경의 클러스터 모두에 액세스하는 데 필요한 사용자 인증 정보와 권한이 있는지 확인합니다.
  2. 원본 환경의 Kubernetes 클러스터에 있는 객체가 GKE와 호환되는지, 이러한 객체를 지원하는 구현이 소스 환경 및 GKE와 어떻게 다른지 평가합니다.
  3. 호환되지 않는 객체를 리팩터링하여 GKE와 호환되도록 하거나 사용 중지합니다.
  4. 이러한 객체를 GKE 클러스터로 마이그레이션합니다.
  5. GKE 클러스터에서 필요한 추가 객체를 구성합니다.

클러스터 구성 마이그레이션

Kubernetes 클러스터 구성을 원본 환경에서 GKE 클러스터로 마이그레이션하려면 다음 방법을 사용합니다.

  • 원본 환경의 Kubernetes 클러스터에서 객체를 구성하기 위해 코드형 인프라 프로세스를 채택한 경우 다음을 수행할 수 있습니다.

    1. Kubernetes 도구(kubectl) 또는 관리형 서비스(구성 동기화)를 사용하여 객체 이름, 위치, 네임스페이스 등 사소한 메타데이터 변경사항만 포함하여 GKE와 호환되는 객체를 마이그레이션합니다.
    2. GKE와 호환되지 않는 객체를 리팩터링하거나 사용 중지합니다.

  • 코드형 인프라 프로세스를 채택하지 않은 경우 다음을 수행할 수 있습니다.

    • Crane 및 Velero와 같은 타사 도구를 사용하여 원본 환경에서 GKE 환경으로 Kubernetes 객체 구성을 마이그레이션합니다.

데이터 이전

스테이트풀(Stateful) 워크로드에 필요한 데이터를 원본 환경에서 GKE 환경으로 마이그레이션하려면 Google Cloud로 마이그레이션: 대규모 데이터세트 전송의 안내에 따라 데이터 마이그레이션 계획을 설계하는 것이 좋습니다.

데이터를 이동하기 전에 필요한 모든 스토리지 인프라를 프로비저닝합니다. StorageClass 프로비저닝 도구를 사용할 경우 새 클러스터에서 이를 구성합니다.

GKE의 데이터 스토리지 옵션에 대한 자세한 내용은 스토리지 구성을 참조하세요. 예를 들어 Compute Engine 영구 디스크(영역 또는 리전 간 복제) 또는 Filestore를 사용할 수 있습니다.

StorageClass를 프로비저닝한 후 마이그레이션할 데이터를 저장하는 데 필요한 모든 PersistentVolume을 프로비저닝합니다. 그런 다음 원본 환경에서 이러한 PersistentVolume으로 데이터를 마이그레이션합니다. 이 데이터 마이그레이션의 세부 사항은 원본 환경의 특성에 따라 다릅니다. 예를 들어 다음을 수행할 수 있습니다.

  1. Compute Engine 인스턴스를 프로비저닝합니다.
  2. Compute Engine 인스턴스에 영구 디스크를 연결합니다.
  3. 원본 환경에서 영구 디스크로 데이터를 복사합니다.
  4. Compute Engine 인스턴스를 종료합니다.
  5. Compute Engine 인스턴스에서 영구 디스크를 분리합니다.
  6. 영구 디스크를 GKE PersistentVolume으로 구성합니다.
  7. Compute Engine 인스턴스를 사용 중단합니다.

Compute Engine 영구 디스크를 GKE PersistentVolume으로 사용하는 방법에 대한 자세한 내용은 기존 영구 디스크를 PersistentVolume으로 사용을 참조하세요.

워크로드 배포

워크로드를 배포하려면 다음 방법 중 하나를 사용하는 것이 좋습니다.

  • Google Cloud에 배포 프로세스를 구현합니다.
  • 기존 배포 프로세스를 리팩토링하여 GKE 환경에 워크로드를 배포합니다.

배포 단계에서 배포 프로세스 및 워크로드를 현대화할 수도 있습니다. 예를 들어 환경에서 포드를 사용할 경우 해당 워크로드를 Kubernetes 배포로 마이그레이션하는 것이 좋습니다.

배포 프로세스 리팩터링에 대한 자세한 내용은 Google Cloud로 마이그레이션: 수동 배포에서 컨테이너 및 자동화로 마이그레이션을 참조하세요. 수동 배포에서 컨테이너 조정 도구 및 자동화로 마이그레이션하는 방법이 설명되어 있습니다.

배포 프로세스가 준비되면 GKE에 워크로드를 배포할 수 있습니다.

Google Cloud에 배포 프로세스 구현

Google Cloud에 배포 프로세스를 구현하려면 Google Cloud 제품의 확장성, 관리형 작업, 보안 내재화 설계를 사용하세요.

Google Cloud에 배포 프로세스를 구현하는 방법에 대한 자세한 내용은 다음을 참조하세요.

기존 배포 프로세스 리팩토링

성공적인 결과를 얻기 위해 반드시 필요한 것은 아니지만 마이그레이션 중에 배포 프로세스를 리팩터링할 수도 있습니다. 예를 들어 기존 배포 프로세스를 현대화 및 자동화하여 Google Cloud에서 구현할 수 있습니다.

워크로드를 마이그레이션하는 동시에 배포 프로세스를 Google Cloud로 마이그레이션하는 작업은 복잡할 수 있으며 마이그레이션 실패 위험이 높아질 수 있습니다. 특히 복잡한 마이그레이션의 경우 배포 프로세스를 다시 한 번 마이그레이션하고 현재 배포를 계속 사용하여 GKE 환경에 워크로드를 배포할 수도 있습니다. 이 접근 방식은 마이그레이션의 복잡성을 줄이는 데 도움이 됩니다. 기존 배포 프로세스를 계속 사용하면 마이그레이션 프로세스를 간소화할 수 있습니다.

워크로드 검증

GKE 환경에 워크로드를 배포한 후 이러한 워크로드를 사용자에게 노출하기 전에 광범위한 검증 및 테스트를 수행하는 것이 좋습니다. 이 테스트는 워크로드가 예상대로 작동하는지 확인하는 데 도움이 될 수 있습니다. 예를 들어 다음과 같은 작업을 수행할 수 있습니다.

  • 워크로드가 예상된 매개변수 내에서 그리고 사양에 따라 작동하는지 확인하는 데 도움이 되는 통합 테스트, 부하 테스트, 규정 준수 테스트, 안정성 테스트, 기타 확인 절차를 수행합니다.
  • Google Cloud Observability의 로그, 측정항목, 오류 보고서를 조사하여 잠재적인 문제를 식별하고 추세를 파악하여 문제가 발생하기 전에 문제를 예측합니다.

워크로드 검증에 대한 자세한 내용은 안정성 테스트를 참조하세요.

워크로드 노출

GKE 환경에서 실행되는 워크로드의 유효성 검사 테스트를 완료한 후 워크로드를 연결할 수 있도록 워크로드를 노출합니다.

GKE 환경에서 실행되는 워크로드를 노출하려면 Kubernetes 서비스 및 서비스 메시를 사용하면 됩니다.

GKE가 Kubernetes 서비스를 지원하는 방법에 대한 자세한 내용은 서비스를 참조하세요.

GKE에서 실행되는 워크로드 노출에 대한 자세한 내용은 다음을 참조하세요.

Google Cloud 환경으로 트래픽 이동

워크로드가 GKE 환경에서 실행 중임을 확인한 후 클라이언트에 노출한 후 원본 환경에서 GKE 환경으로 트래픽을 전환합니다. 대규모 마이그레이션 및 모든 관련 위험을 방지하려면 원본 환경에서 GKE로 트래픽을 점진적으로 전환하는 것이 좋습니다.

GKE 환경의 설계 방식에 따라 원본 환경에서 대상 환경으로 트래픽을 점진적으로 전환하는 부하 분산 메커니즘을 구현할 수 있는 몇 가지 옵션이 있습니다. 예를 들어 일부 정책에 따라 DNS 레코드를 확인하는 DNS 변환 정책을 구현하여 GKE 환경에 속하는 IP 주소에 대한 특정 비율의 요청을 확인할 수 있습니다. 또는 가상 IP 주소와 네트워크 부하 분산기를 사용하여 부하 분산 메커니즘을 구현할 수 있습니다.

GKE 환경으로 트래픽을 점진적으로 전환하기 시작하면 부하가 증가함에 따라 워크로드가 어떻게 작동하는지 모니터링하는 것이 좋습니다.

마지막으로 컷오버를 수행합니다. 이 작업은 원본 환경에서 GKE 환경으로 모든 트래픽을 전환할 때 발생합니다.

부하 분산에 대한 자세한 내용은 프런트엔드에서 부하 분산을 참조하세요.

원본 환경 사용 중단

GKE 환경의 워크로드가 요청을 올바르게 처리하면 원본 환경을 사용 중단합니다.

원본 환경에서 리소스 사용 중단을 시작하기 전에 다음을 수행하는 것이 좋습니다.

  • 원본 환경의 리소스를 복원하는 데 도움이 되는 모든 데이터를 백업합니다.
  • 환경을 사용 중지하기 전에 사용자에게 알립니다.

원본 환경을 사용 중지하려면 다음 안내를 따르세요.

  1. 원본 환경의 클러스터에서 실행 중인 워크로드를 사용 중단합니다.
  2. 원본 환경의 클러스터를 삭제합니다.
  3. 보안 그룹, 부하 분산기, 가상 네트워크와 같이 이러한 클러스터와 연결된 리소스를 삭제합니다.

분리된 리소스가 남지 않도록 원본 환경에서 리소스를 사용 중지하는 순서가 중요합니다. 예를 들어 일부 공급업체는 부하 분산기를 만들 수 있는 Kubernetes 서비스를 사용 중단해야 해당 부하 분산기가 포함된 가상 네트워크를 사용 중단할 수 있습니다.

환경 최적화

최적화는 마이그레이션의 마지막 단계입니다. 이 단계에서는 환경을 이전보다 더 효율적으로 만들 수 있습니다. 이 단계에서는 환경이 최적화 요구사항을 충족할 때까지 반복 가능한 루프를 여러 번 반복 실행합니다. 이 반복 가능한 루프의 단계는 다음과 같습니다.

  1. 현재 환경, 팀, 최적화 루프 평가
  2. 최적화 요구사항 및 목표 설정
  3. 환경 및 팀 최적화
  4. 최적화 루프 조정

다음 섹션에서는 Google Cloud로 마이그레이션: 환경 최적화를 사용합니다.

현재 환경, 팀, 최적화 루프 평가

첫 번째 평가는 기존 환경에서 GKE로 마이그레이션에 중점을 두고 있지만 이 평가는 최적화 단계에 맞게 조정됩니다.

최적화 요구사항 설정

GKE 환경의 다음 최적화 요구사항을 검토합니다.

  • 고급 배포 프로세스 구현 카나리아 배포 또는 블루/그린 배포와 같은 프로세스를 통해 유연성을 추가하고, 환경 안정성을 높이고, 테스트를 확장하고, 문제가 사용자에게 미치는 영향을 줄일 수 있습니다.
  • 서비스 메시 구성. 환경에 서비스 메시를 도입하면 서비스의 관측 가능성, 트래픽 관리, 상호 인증과 같은 기능을 사용하고 DevOps팀에 미치는 부담을 줄일 수 있습니다. 멀티 클러스터 서비스 메시를 배포하여 워크로드를 세분화하거나 확장된 서비스 메시를 새 환경으로 마이그레이션할 수 있습니다.
  • 자동 확장 설정. GKE 환경을 자동으로 확장하는 다양한 보완 옵션이 있습니다. 클러스터와 각 클러스터 내 워크로드를 자동으로 확장할 수 있습니다. 클러스터 자동 확장 처리를 구성하면 워커 노드를 클러스터에 추가 또는 삭제하여 워크로드 요구사항에 따라 GKE 클러스터의 크기를 자동으로 조정할 수 있습니다. 워크로드를 자동으로 확장하려면 수직형 Pod 자동 확장 처리를 통해 CPU와 메모리 소비 요청 및 한도를 조정합니다. 자동 확장 처리를 사용할 때 각 컨테이너의 CPU와 메모리 요청에 지정할 값을 생각하지 않아도 됩니다. 자동 확장 처리에서 제공하는 측정항목을 규모에 맞게 GKE 워크로드 크기 조정으로 내보낼 수도 있습니다.
  • 선점형 가상 머신(VM)으로 비용 절감. 일부 워크로드가 가용성 보장 없이 런타임 환경에 허용된 경우 이 워크로드를 선점형 VM으로 구성된 노드 풀에 배포하는 것이 좋습니다. 선점형 VM 가격은 표준 Compute Engine VM보다 저렴하므로 클러스터 비용을 줄일 수 있습니다.
  • GKE를 다른 제품과 통합. 일부 Google Cloud 제품은 GKE와 통합되어 환경의 보안을 강화할 수 있습니다. 예를 들어 컨테이너 취약점을 분석하거나 Container Registry에서 관리형 기본 이미지를 사용할 수 있습니다.
  • GKE 클러스터를 대체 가능하도록 설계. 클러스터를 대체 가능한 것으로 간주하고 프로비저닝 및 구성을 자동화하면 운영 프로세스를 간소화하고 일반화하여 향후 마이그레이션 및 GKE 클러스터 업그레이드를 간소화할 수 있습니다. 예를 들어 대체 가능한 GKE 클러스터를 새 GKE 버전으로 업그레이드해야 할 경우, 업그레이드된 새 클러스터를 자동으로 프로비저닝 및 구성하고, 새 클러스터에 워크로드를 자동으로 배포하고, 이전의 오래된 GKE 클러스터를 사용 중단할 수 있습니다.

  • 멀티 클러스터 환경 설계 GKE에서 멀티 클러스터 환경을 구현하면 다음을 수행할 수 있습니다.

    • 아키텍처에서 단일 장애점이 발생할 가능성을 줄입니다.
    • GKE 클러스터의 하위 집합에서 구성 변경사항을 테스트할 수 있는 유연성이 증가합니다.
    • GKE 클러스터에 워크로드를 분산합니다.

Kubernetes 환경에서도 이러한 최적화 요구사항 중 일부를 충족할 수 있지만 클러스터가 지속적으로 실행되도록 노력을 기울일 필요가 없으므로 GKE에서 최적화 요구 사항을 더 수월하게 충족할 수 있고 최적화 자체에 집중할 수 있습니다.

최적화 완료

최적화 요구사항 목록을 채운 후 최적화 단계의 나머지 활동을 완료합니다.

다음 단계