Google Cloud로 컨테이너 마이그레이션: OpenShift에서 GKE Enterprise로 마이그레이션

이 문서는 OpenShift에서 GKE Enterprise로 마이그레이션을 계획, 설계, 구현하는 데 도움이 됩니다. 잘못 수행할 경우 워크로드를 다른 환경으로 이동하는 작업이 어려워질 수 있으므로 마이그레이션 계획과 실행에 신중을 기하세요.

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

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

이 문서는 온프레미스 또는 비공개 호스팅 환경이나 다른 클라우드 제공업체에서 실행되는 OpenShift에서 GKE Enterprise로의 마이그레이션을 계획하고 있는 경우에 유용합니다. 이 문서는 마이그레이션 기회를 평가하고 그 결과를 살펴보고 싶은 경우에도 유용합니다. 대상 환경은 다음 중 하나일 수 있습니다.

  • Google Cloud에서 완전히 호스팅되는 환경
  • 워크로드의 일부를 온프레미스 또는 비공개 호스팅 환경에 유지하고 나머지를 Google Cloud로 마이그레이션하는 하이브리드 환경

적합한 환경을 결정하려면 요구사항을 고려하세요. 예를 들어 퍼블릭 클라우드 환경으로 마이그레이션하고 일부 책임을 Google에 아웃소싱하면 인프라에 대해 걱정하지 않고 비즈니스 가치를 높이는 데 집중할 수 있습니다. 탄력적 소비 모델을 활용하여 지출과 리소스 사용량을 최적화할 수 있습니다. Google Cloud 외부에 워크로드 일부를 유지해야 하는 등의 요구사항이 있는 경우, 하이브리드 환경을 고려할 수 있습니다(예: 데이터 위치 정책 및 규정을 준수하기 위해 현재 환경에 워크로드의 일부를 유지해야 하는 경우). 또는 먼저 현재 위치에서 워크로드를 현대화한 다음 Google Cloud로 마이그레이션하는 개선 및 이동 마이그레이션 전략을 구현할 수 있습니다.

대상 환경 유형에 관계없이 이 마이그레이션의 목표는 GKE Enterprise를 사용하여 해당 환경에서 실행 중인 워크로드를 관리하는 것입니다. GKE Enterprise를 채택하면 다음과 같은 다양한 서비스에 액세스할 수 있습니다.

  • 멀티 클러스터 관리를 통해 클라우드 및 온프레미스 환경의 클러스터, 인프라, 워크로드를 한 곳에서 관리할 수 있습니다.
  • 구성 동기화 및 정책 컨트롤러를 사용하면 모든 인프라에 공통된 구성 및 정책을 만들어 온프레미스와 클라우드 모두에 적용할 수 있습니다.
  • Anthos Service Mesh를 통해 운영 서비스, 트래픽 관리, 원격 분석, 서비스 간 통신 보안을 간소화하는 완전 관리형 서비스 메시를 채택할 수 있습니다.
  • Binary Authorization을 사용하면 환경에 배포하는 컨테이너를 신뢰할 수 있게 만들 수 있습니다.
  • Cloud Run for Anthos를 사용하여 GKE Enterprise 환경에서 서버리스 워크로드를 지원할 수 있습니다.

위에 나열한 서비스는 마이그레이션을 아직 설계 중인 마이그레이션 프로세스 초기에 평가하는 것이 좋습니다. 지금 서비스를 채택하는 것이 나중에 프로세스와 인프라를 수정하는 것보다 더 쉽습니다. 위 서비스는 즉시 또는 워크로드를 현대화할 준비가 되면 사용할 수 있습니다.

이 마이그레이션에서는 Google Cloud로 마이그레이션: 시작하기에 정의된 마이그레이션 프레임워크를 따릅니다. 프레임워크에는 다음 네 단계가 있습니다.

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

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

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

이 문서에서는 컨테이너를 Google Cloud로 마이그레이션: Kubernetes를 GKE로 마이그레이션에서 설명하는 개념이 사용되므로 적절한 경우 해당 문서로 연결되는 링크가 함께 제공됩니다.

워크로드 평가 및 검색

평가 단계에서는 OpenShift에서 GKE Enterprise로 워크로드를 마이그레이션하기 위한 요구사항과 종속 항목을 결정합니다.

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

다음 섹션은 Google Cloud로 마이그레이션: 워크로드 평가 및 검색을 사용하지만 OpenShift에서 GKE Enterprise로 마이그레이션하려는 워크로드 평가와 관련된 정보를 제공합니다.

인벤토리 빌드

환경 구성요소의 인벤토리를 빌드하려면 다음을 고려하세요.

  • 서비스 제공 및 플랫폼 관리 모델
  • OpenShift 프로젝트
  • 빌드 및 배포 프로세스
  • 워크로드, 요구사항, 종속 항목
  • OpenShift 클러스터 구성

서비스 제공 및 플랫폼 관리 모델

OpenShift에서 GKE Enterprise로 워크로드를 마이그레이션하려면 OpenShift 환경의 현재 서비스 제공 및 플랫폼 관리 모델을 평가합니다. 이 모델은 현재 조직 구조와 요구사항을 반영합니다. 현재 모델이 조직의 요구사항을 충족하지 않는 것을 알게 되면 이 마이그레이션을 모델을 개선할 기회로 사용할 수 있습니다.

먼저 다음 측면을 담당하는 팀에 대한 정보를 수집합니다.

  • 애플리케이션 개발 및 배포. 모든 OpenShift 사용자를 포함하며 일반적으로 개발팀이나 워크로드 출시팀입니다.
  • OpenShift 플랫폼 관리. OpenShift 프로젝트 생성, 사용자 역할 할당, 보안 컨텍스트 구성, CI/CD 파이프라인 구성 작업이 여기에 포함됩니다.
  • OpenShift 설치 및 클러스터 관리. OpenShift 설치, 업그레이드, 클러스터 확장, 용량 관리 작업이 여기에 포함됩니다.
  • 인프라 관리. 물리적 서버, 스토리지, 네트워킹, 가상화 플랫폼, 운영체제를 관리하는 팀입니다.

서비스 제공 및 플랫폼 관리 모델은 다음 팀으로 구성될 수 있습니다.

  • 개발팀. 이 팀은 워크로드를 개발하여 OpenShift에 배포합니다. 프로덕션 환경이 복잡한 경우 워크로드를 배포하는 팀과 개발팀이 다를 수 있습니다. 이 문서에서는 편의상 이 팀이 개발팀의 일부라고 간주합니다. 셀프서비스 환경에서는 개발팀이 OpenShift 프로젝트 생성도 책임집니다.
  • 플랫폼팀. 이 팀은 OpenShift 플랫폼 관리를 담당하며, 일반적으로 OpenShift 클러스터 관리자라고 합니다. 이 팀은 다양한 개발팀을 위해 OpenShift 프로젝트 템플릿을 구성하며, 더욱 관리되는 환경에서는 OpenShift 프로젝트를 만듭니다. 또한 이 팀은 역할 및 권한을 할당하고, 보안 컨텍스트 및 역할 기반 액세스 제어(RBAC)를 구성하며, 컴퓨팅 리소스 및 객체의 할당량을 정의하고, 빌드 및 배포 전략을 정의합니다. 개발자를 위해 미들웨어 및 애플리케이션 서버 구성을 관리하는 경우 DevOps팀 또는 미들웨어팀이라고도 합니다. 플랫폼팀과 인프라팀은 소프트웨어 설치 및 업그레이드, 클러스터 확장, 용량 관리와 같은 하위 수준의 OpenShift 클러스터 관리 활동에도 참여할 수 있습니다.
  • 인벤토리팀. 이 팀은 OpenShift 환경을 지원하는 기본 인프라를 관리합니다. 예를 들어 서버, 스토리지, 네트워킹, 가상화 플랫폼, 기본 운영체제를 담당합니다. 이 팀을 데이터 센터팀 또는 운영팀이라고도 합니다. OpenShift가 퍼블릭 클라우드 환경에 배포된 경우 이 팀은 퍼블릭 클라우드 제공업체가 제공하는 IaaS(Infrastructure as a Service)를 담당합니다.

다양한 환경을 위한 전용 OpenShift 클러스터가 있는지 평가하는 것도 중요합니다. 예를 들어 개발, 품질 보증, 프로덕션을 위한 다양한 환경이 있거나 내부 영역 및 완충 영역과 같은 여러 네트워크 및 보안 영역을 분리해야 할 수 있습니다.

OpenShift 프로젝트

OpenShift 프로젝트는 개발자가 다른 팀과 별도로 리소스를 관리하여 논리적으로 리소스를 격리할 수 있는 추가 주석이 포함된 Kubernetes 네임스페이스입니다. OpenShift 프로젝트의 인벤토리를 빌드하려면 각 프로젝트에 대해 다음 사항을 고려하세요.

  • 클러스터 역할 및 로컬 역할. OpenShift는 OpenShift 프로젝트에 로컬인 두 가지 역할 전부 또는 클러스터 전체 역할을 지원합니다. 대상 환경에서 효과적인 액세스 제어 메커니즘을 설계하기 위해 클러스터 및 로컬 역할을 만들었는지 평가합니다.
  • 클러스터 역할 및 로컬 역할의 역할 결합. 사용자 및 그룹에는 역할 결합 할당을 통해 OpenShift 프로젝트에서 작업을 수행할 수 있는 권한이 부여됩니다. 역할은 클러스터 수준 또는 로컬 수준일 수 있습니다. 로컬 역할 결합은 종종 사전 정의된 클러스터 역할에 결합됩니다. 예를 들어 기본 OpenShift 프로젝트 관리자 역할 결합은 기본 클러스터 관리자 역할에 결합될 수 있습니다.
  • ResourceQuotas. 총 리소스 소비를 제한하기 위해 OpenShift에서는 OpenShift 프로젝트 수준 할당량과 여러 OpenShift 프로젝트의 할당량을 모두 정의할 수 있습니다. 할당량이 Kubernetes ResourceQuota에 어떻게 매핑되는지 평가하고 OpenShift 환경에서 프로비저닝 및 구성한 모든 ResourceQuota 목록을 채웁니다.

환경 평가에서는 ServiceAccount 및 PersistentVolume과 같은 Kubernetes 리소스를 평가하는 방법을 설명합니다.

빌드 및 배포 프로세스

서비스 제공 및 플랫폼 관리 모델과 OpenShift 프로젝트에 대한 정보를 수집한 후 워크로드를 빌드하여 환경에 배포하는 방법을 평가합니다.

기존 OpenShift 환경에서는 모든 워크로드의 빌드 및 배포 프로세스가 동일할 수도 있고 평가할 다른 프로세스가 있을 수도 있습니다. 컨테이너식 워크로드를 위한 빌드 프로세스의 아티팩트가 컨테이너 이미지입니다. OpenShift 환경에서는 다양한 방법으로 컨테이너 이미지를 빌드, 저장, 배포할 수 있습니다.

각 컨테이너 이미지를 빌드한 후 나중에 배포할 수 있는 Container Registry에 저장합니다. Container Registry는 OpenShift 또는 OpenShift 환경 외부에서 호스팅할 수 있습니다. 대상 환경에 유사한 시스템이 필요할 수 있으므로 이 측면을 평가하세요.

워크로드, 요구사항, 종속 항목

각 OpenShift 애플리케이션에는 다음 구성요소가 포함됩니다.

애플리케이션의 용도에 따라 Deployment 객체나 DeploymentConfig 객체 대신 다른 객체를 사용하여 앱을 정의할 수 있습니다.

  • Job 또는 크론 작업을 사용하여 일괄 애플리케이션을 정의합니다.
  • StatefulSet를 사용하여 스테이트풀(Stateful) 애플리케이션을 정의합니다.
  • 모든 노드에서 실행되어야 하거나 특정 노드에 결합되어야 하는 작업 관련 워크로드가 있는 경우 DaemonSet를 사용하여 정의할 수 있습니다.

다음 표에는 애플리케이션을 대상 GKE Enterprise 환경으로 마이그레이션하기 위해 OpenShift 리소스에서 수집하는 가장 중요한 사양과 매개변수가 나와 있습니다.

소스 OpenShift 리소스 매니페스트 가장 중요한 사양 및 매개변수
Deployment, DeploymentConfig, StatefulSet, Job, 크론 작업 컨테이너 이미지 및 저장소, 컨테이너 포트, 포드 복제본 수, ConfigMap, 보안 비밀, PersistentVolumeClaim, 리소스 요청 및 한도, 업데이트 전략, StatefulSet 서비스 이름, 크론 작업 일정
ImageStream 컨테이너 이미지, 이미지 pull 정책, 컨테이너 이미지 저장소
수평형 포드 자동 확장 처리 자동 확장 기준
서비스 클러스터 내부에서 애플리케이션에 연결하는 데 사용되는 호스트 이름, 서비스가 노출되는 IP 주소 및 포트, 외부 리소스를 위해 생성된 엔드포인트
경로 클러스터 외부에서 애플리케이션에 연결하는 데 사용되는 호스트 이름 및 리소스 경로, 라우팅 규칙, 암호화, 인증서 체인 정보

환경 평가에서는 다음과 같은 Kubernetes 리소스를 평가하는 방법을 설명합니다.

OpenShift 4에는 오퍼레이터 프레임워크가 도입되었습니다. 이 OpenShift 버전을 사용하는 경우 설치된 오퍼레이터를 사용하여 일부 애플리케이션을 배포했을 수 있습니다. 이 경우 설치된 오퍼레이터 목록을 가져오고 오퍼레이터마다 배포된 오퍼레이터 인스턴스에 대한 정보를 수집합니다. 이 인스턴스는 이전에 나열된 일부 Kubernetes 리소스를 배포하는 오퍼레이터 정의 커스텀 리소스입니다.

이 리소스를 평가하는 것 외에도 다음을 평가합니다.

  • 애플리케이션의 네트워크 연결 요구사항. 예를 들어 서비스 또는 포드를 특정 네트워크에 노출해야 하나요? 특정 백엔드 시스템에 도달해야 하나요?
  • 특정 위치에서 워크로드를 실행하기 위한 제약조건. 예를 들어 다른 워크로드와의 통신 지연 시간, 데이터 위치 관련 정책, 사용자 근접성 등의 요구사항을 준수하기 위해 온프레미스에 유지해야 하는 워크로드나 데이터 세트가 있나요?

OpenShift 클러스터 구성

다음으로 OpenShift 클러스터를 평가합니다. 이 작업을 완료하려면 다음 정보를 수집합니다.

  • OpenShift 버전. 이 문서에서 다루는 OpenShift 주 버전은 OpenShift 3 및 OpenShift 4입니다. OpenShift 버전에 따라 기능이 다를 수 있습니다. 버전별로 다른 OpenShift 기능을 사용하고 있는지 확인하기 위해 실행 중인 OpenShift 버전을 평가합니다.
  • 인증에 사용되는 ID 공급업체. 인증을 위해 기본 제공 OAuth 서버와 하나 이상의 ID 공급업체를 사용 중일 수 있습니다.
  • 보안 컨텍스트 제약조건. 클러스터에 정의한 OpenShift 보안 컨텍스트 제약조건과 구성, 제약조건이 할당된 사용자, 그룹, 서비스 계정을 평가합니다.
  • 네트워크 정책 및 격리. NetworkPolicy, 포드 네트워크 격리를 구성한 방법, 클러스터에서 구성한 OpenShift SDN 모드를 평가합니다.

  • 모니터링. 현재 모니터링 요구사항과 현재 모니터링 시스템을 프로비저닝하고 구성한 방법을 평가하여 대상 환경에서 모니터링 솔루션을 설계하고 구현하는 방법을 결정합니다. 이 평가는 새 모니터링 솔루션을 사용할지 아니면 기존 솔루션을 계속 사용해도 되는지 결정하는 데 도움이 됩니다. 많은 OpenShift 버전에는 시스템 구성요소를 모니터링하며 애플리케이션 모니터링에도 사용할 수 있는 Prometheus를 기반으로 하는 모니터링 스택이 포함되어 있습니다. 대상 솔루션을 설계할 때 다음 사항을 고려하세요.

    • OpenShift 환경에서 현재 사용 중인 모니터링 솔루션(예: OpenShift에서 호스팅하는 Prometheus, 독립적 Prometheus-Grafana 스택, Zabbix, InfluxData 또는 Nagios)
    • pull 또는 push 메커니즘 등 측정항목이 생성되고 수집되는 방법
    • OpenShift 클러스터에 배포된 구성요소에 대한 종속 항목
    • 모니터링 시스템의 위치(예: 클라우드 환경에 배포 또는 온프레미스에 배포)
    • 현재 워크로드에 대해 수집하는 측정항목
    • 현재 모니터링 시스템에서 구성한 측정항목에 대한 알림

  • 로깅. 현재 로깅 요구사항과 현재 로깅 시스템을 프로비저닝하고 구성한 방법을 평가하여 대상 환경에서 로깅 솔루션을 설계하고 구현하는 방법을 결정합니다. 이 평가는 새 로깅 솔루션을 사용할지 아니면 기존 솔루션을 계속 사용해도 되는지 결정하는 데 도움이 됩니다. 많은 OpenShift 버전은 시스템 구성요소에서 로그를 수집하는 데 사용되는 Elasticsearch, Fluentd, Kibana(EFK) 스택을 기반으로 한 로깅 솔루션과 함께 제공됩니다. 이 솔루션은 애플리케이션 로깅에도 사용할 수 있습니다. 대상 솔루션을 설계할 때 다음 사항을 고려하세요.

    • OpenShift 환경에서 현재 사용 중인 로깅 시스템(예: OpenShift에서 호스팅하는 EFK 스택, 독립적EFK 스택 또는 Splunk)
    • OpenShift 클러스터에 배포된 구성요소에 대한 종속 항목
    • 로그 스토리지 구성요소의 아키텍처 및 용량
    • 로깅 시스템의 위치(예: 클라우드 환경에 배포 또는 온프레미스에 배포)
    • 로그 보관 정책 및 구성

환경 평가에서는 다음을 평가하는 방법을 설명합니다.

  • 클러스터 수
  • 클러스터당 노드 수 및 유형
  • 로깅, 모니터링, 추적에 대한 추가 고려사항
  • 커스텀 Kubernetes 리소스

평가 완료

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

기반 계획 및 구축

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

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

이 섹션에서는 Google Cloud로 마이그레이션: 기반 구축의 정보를 기반으로 GKE Enterprise에 기반을 구축하는 데 필요한 정보를 제공합니다.

Google Cloud에서 기반을 구축하기 전에 GKE Enterprise 기술 개요를 읽고 GKE Enterprise의 작동 방식과 필요한 GKE Enterprise 구성요소를 알아보세요. 평가 단계에서 수집한 워크로드 및 데이터 지역 요구사항에 따라 VMware용 GKE, Google Cloud의 GKE 클러스터, GKE on AWS에 워크로드를 배포합니다. 클러스터는 여러 환경에 분산될 수 있습니다. Google Cloud에서 GKE 기반을 구축하는 방법에 대한 자세한 내용은 기반 계획 및 구축을 참조하세요.

VMware용 GKE의 기반을 구축하려면 핵심 개념을 읽고 VMware용 GKE 설치 시 다음을 고려하세요.

GKE on AWS의 기반을 구축하려면 GKE on AWS 아키텍처 및 GKE on AWS 스토리지와 같은 핵심 개념을 읽어보세요. GKE on AWS를 설치할 때 다음 사항을 고려하세요.

워크로드 배포

배포 단계에서는 GKE Enterprise에 워크로드를 배포합니다.

  1. 런타임 플랫폼과 환경을 프로비저닝하고 구성합니다.
  2. 이전 환경에서 새 환경으로 데이터를 마이그레이션합니다.
  3. 워크로드 배포

다음 섹션에서는 Google Cloud로 마이그레이션: 대규모 데이터 세트 전송, Google Cloud로 마이그레이션: 워크로드 배포, Google Cloud로 마이그레이션: 수동 배포에서 컨테이너화된 자동 배포로 마이그레이션의 정보를 기반으로 GKE Enterprise에 워크로드를 배포하는 데 필요한 정보를 제공합니다.

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

워크로드를 배포하기 전에 필요한 GKE Enterprise 클러스터를 프로비저닝하고 구성합니다.

Google Cloud의 GKE 클러스터, VMware용 GKE 클러스터 또는 GKE on AWS 클러스터를 프로비저닝할 수 있습니다. 예를 들어 온프레미스에 배포해야 하는 워크로드가 있다면 하나 이상의 VMware용 GKE 클러스터를 프로비저닝합니다. 워크로드에 지역 요구사항이 없으면 Google Cloud의 GKE 클러스터를 프로비저닝합니다. 두 경우 모두 GKE Enterprise를 사용하여 클러스터를 관리하고 모니터링합니다. 멀티 클라우드 요구사항이 있으면 다른 GKE Enterprise 클러스터와 함께 GKE on AWS 클러스터를 프로비저닝합니다.

먼저 필요한 GKE Enterprise 클러스터의 수와 유형을 정의합니다. 이러한 요구사항은 대부분 구현하려는 서비스 모델, 다양한 환경 격리 방법 등 평가 단계에서 수집한 정보에 따라 달라집니다. 현재 여러 개발팀이 OpenShift 클러스터를 공유하고 있다면 GKE Enterprise에 멀티테넌시 모델을 구현해야 합니다.

  • 다른 Kubernetes 네임스페이스를 사용합니다. 플랫폼팀은 각 OpenShift 프로젝트의 Kubernetes 네임스페이스를 만들고 클러스터 멀티테넌시 모델을 구현합니다. 이 모델은 OpenShift 환경에서 채택한 모델과 매우 유사하므로 OpenShift 클러스터 수와 비슷한 수의 GKE Enterprise 클러스터가 필요할 수 있습니다. 필요한 경우 다양한 환경의 전용 클러스터를 계속 사용할 수 있습니다.
  • 다양한 GKE Enterprise 클러스터를 사용합니다. 인프라팀은 각 개발팀에 GKE Enterprise 클러스터를 제공하고, 플랫폼팀은 각 클러스터를 관리합니다. 이 모델은 개발에 더 큰 유연성과 격리를 제공하므로 OpenShift 클러스터 수보다 많은 GKE Enterprise 클러스터가 필요할 수 있습니다.
  • 다양한 Google Cloud 프로젝트를 사용합니다. 인프라팀은 각 개발팀을 위해 Google Cloud 프로젝트를 만들고 해당 Google Cloud 프로젝트 내에 GKE Enterprise 클러스터를 프로비저닝합니다. 그러면 플랫폼팀이 이 클러스터를 관리합니다. 이 모델은 개발팀에 최대의 유연성과 격리를 제공하므로 OpenShift 클러스터 수보다 많은 GKE Enterprise 클러스터가 필요할 수 있습니다.

필요한 클러스터 수와 이를 프로비저닝할 환경을 결정한 후 클러스터 크기, 구성, 노드 유형을 정의합니다. 그런 다음 평가 단계에서 수집한 워크로드 요구사항에 따라 클러스터 및 노드 풀을 프로비저닝합니다. 예를 들어 GPU 및 TPU 요구사항과 같은 기타 요구사항과 함께 특정 성능 및 확장성 보장이 워크로드에 필요할 수 있습니다.

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

클러스터를 만든 후 워크로드를 배포하기 전에 OpenShift 프로젝트 및 클러스터 평가 단계에서 수집한 요구사항을 충족하도록 다음 구성요소를 구성합니다.

  • ID 및 액세스 관리. ID 및 액세스 관리 구성에 설명된 대로 ID 및 액세스 관리를 구성할 수 있습니다. 기본 ID 공급업체로 설정해 Cloud ID로 마이그레이션하거나 Google Cloud 디렉터리 동기화를 사용하여 Cloud ID를 기존 LDAP 또는 Active Directory 서버와 동기화할 수 있습니다. VMware용 GKE는 명령줄을 사용하여 사용자 클러스터를 인증하기 위해 OpenID Connect(OIDC)를 지원합니다. OIDC 및 Google로 인증에 따라 명령줄 인증을 Cloud ID와 통합합니다.
  • 모니터링. 제약조건 및 요구사항에 따라 대상 GKE Enterprise 환경에 맞게 현재 모니터링 솔루션을 조정할 수 있습니다. 현재 솔루션이 OpenShift에서 호스팅되는 경우 기반 구축에 설명된 대로 Cloud Monitoring을 구현하거나 VMware용 GKE에서 Prometheus 및 Grafana를 구현할 수 있습니다.
  • 로깅. 제약조건 및 요구사항에 따라 대상 GKE Enterprise 환경에 맞게 현재 로깅 솔루션을 조정할 수 있습니다. 현재 솔루션이 OpenShift에서 호스팅되는 경우 기반 구축 - 모니터링 및 알림에 설명된 대로 Cloud Logging을 구현할 수 있습니다.

구성 동기화를 사용하면 공통 Git 호환 저장소에 있는 다음 리소스의 구성을 중앙에서 정의하고 온프레미스와 클라우드의 모든 클러스터에 해당 구성을 적용할 수 있습니다.

구성 동기화를 설치하려면 구성 동기화 설치를 참조하세요. 정책 컨트롤러를 설치하려면 정책 컨트롤러 설치를 참조하세요.

이전 환경에서 데이터 마이그레이션

이제 소스 환경에서 대상 환경으로 데이터를 마이그레이션할 수 있습니다.

OpenShift 스테이트풀(Stateful) 애플리케이션이 Kubernetes 영구 볼륨에서 데이터를 호스팅하는 경우 데이터를 대상 환경으로 마이그레이션하는 다양한 전략이 있습니다. 적절한 전략 선택은 소스 및 대상 백엔드 스토리지 제공업체 및 배포 위치와 같은 다양한 요소에 따라 달라집니다.

  • 스토리지 제공업체의 볼륨 클론, 내보내기, 가져오기 기능을 사용합니다. 온프레미스 환경에서 VMware vSphere 볼륨을 사용 중이고 VMware용 GKE로 마이그레이션하는 경우 PersistentVolume 기본 VMDK 가상 디스크를 클론하여 대상 환경의 볼륨으로 마운트합니다. GKE로 마이그레이션하는 경우 가상 디스크를 Compute Engine 영구 디스크로 가져와 영구 볼륨으로 사용합니다.
  • 운영체제 도구 또는 데이터베이스 도구를 사용하여 소스 환경의 데이터를 백업합니다. 두 환경 모두에서 액세스할 수 있는 임시 위치에 데이터를 호스팅한 다음 대상 환경에서 데이터를 복원합니다.
  • rsync와 같은 원격 복사 도구를 사용하여 소스 환경에서 대상 환경으로 데이터를 복사합니다.
  • restic 통합이 있는 Velero와 같은 스토리지 독립적 백업 솔루션을 사용합니다.

자세한 내용은 Google Cloud로 마이그레이션: 대규모 데이터 세트 전송을 참조하세요.

데이터 마이그레이션 및 GKE에서의 스토리지 관리 전략에 대한 자세한 내용은 이전 환경에서 새 환경으로 데이터 마이그레이션 및 스토리지 구성에 대한 GKE 문서를 참조하세요.

VMware용 GKE에서는 VMware vSphere 스토리지, Kubernetes 트리 내 볼륨 플러그인, 컨테이너 스토리지 인터페이스(CSI) 드라이버 등을 통해 외부 저장소 시스템과 통합하는 다양한 옵션 중 선택할 수 있습니다. 선택은 통합해야 하는 외부 스토리지 시스템, 지원되는 액세스 모드, 동적 볼륨 프로비저닝 필요 여부에 따라 달라집니다.

GKE on AWS는 Amazon Elastic Block Store(EBS)용 CSI 드라이버는 물론 EBS 볼륨에서 PersistentVolumeClaim을 지원하는 기본 StorageClass와 기타 EBS 볼륨 유형용 StorageClass를 배포합니다. 추가 CSI 드라이버와 커스텀 StorageClass도 설치할 수 있습니다. GKE on AWS에서 EBS 볼륨을 가져오려면 해당 볼륨에서 PersistentVolume을 생성해도 됩니다.

워크로드 배포

GKE Enterprise 클러스터를 프로비저닝하고 데이터를 마이그레이션한 후 이제 워크로드를 빌드하고 배포합니다. 수동 배포부터 완전 자동 배포까지 다양한 옵션이 있습니다.

오퍼레이터를 사용하여 이 배포 메서드를 사용하는 워크로드를 OpenShift 환경에 배포해야 하는 경우 워크로드를 배포하기 전에 오퍼레이터를 설치해야 합니다. 필요한 오퍼레이터의 사용 가능 여부는 다음 소스에서 확인할 수 있습니다.

수동 배포

OpenShift 환경에서 워크로드를 수동으로 배포하는 경우 이 수동 배포 프로세스를 새 GKE Enterprise 환경에 맞게 조정할 수 있습니다. 예를 들어 워크로드, 요구사항, 종속 항목에서 평가한 OpenShift 리소스 매니페스트를 해당 GKE Enterprise 리소스 매니페스트로 수동 변환할 수 있습니다.

다음은 이 문서의 워크로드, 요구사항, 종속 항목 섹션에 있는 표에 내용을 더하고 이를 사용할 수 있는 대상 GKE Enterprise 리소스에 대한 정보를 추가한 표입니다.

소스 OpenShift 리소스 매니페스트 가장 중요한 사양 및 매개변수 대상 GKE Enterprise 리소스 매니페스트
Deployment, DeploymentConfig, StatefulSet, Job, 크론 작업 컨테이너 이미지 및 저장소, 컨테이너 포트, 포드 복제본 수, ConfigMap, 보안 비밀, PersistentVolumeClaim, 리소스 요청 및 한도, 업데이트 전략, StatefulSet 서비스 이름, 크론 작업 일정 Deployment, StatefulSet, Job, 크론 작업
ImageStream 컨테이너 이미지, 이미지 pull 정책, 컨테이너 이미지 저장소 Deployment
수평형 포드 자동 확장 처리 자동 확장 기준 수평형 포드 자동 확장 처리
서비스 클러스터 내부에서 애플리케이션에 연결하는 데 사용되는 호스트 이름, 서비스가 노출되는 IP 주소 및 포트, 외부 리소스를 위해 생성된 엔드포인트 서비스
경로 클러스터 외부에서 애플리케이션에 연결하는 데 사용되는 호스트 이름 및 리소스 경로, 라우팅 규칙 인그레스

자동 배포 프로세스 설계 및 구현

워크로드를 자동으로 빌드하고 배포하려면 빌드 및 배포 프로세스를 설계 및 구현하거나 새 환경을 지원하도록 기존 프로세스를 조정합니다. 워크로드를 하이브리드 환경에 배포해야 하는 경우 배포 프로세스는 Google Cloud 기반 GKE와 VMware용 GKE를 모두 지원해야 합니다.

빌드 및 배포 프로세스를 구현하려면 Cloud Build를 사용하면 됩니다. 빌드 및 배포 프로세스를 자동화하려면 빌드 트리거 또는 GitHub 앱 트리거를 구성하거나 Google Cloud 콘솔에서 자동 배포를 설정하면 됩니다. 정책 컨트롤러 제약조건을 사용하는 경우 개발자에게 의견을 제공하기 위해 Cloud Build 작업의 정책과 대조하여 Kubernetes 및 GKE Enterprise 설명자를 확인할 수 있습니다.

온프레미스에서 빌드 작업을 실행하거나 소스 코드를 저장해야 하는 경우 GitLab을 사용할 수 있습니다. GitLab은 소스 코드 저장소, 공동작업 플랫폼, CI/CD 기능, 컨테이너 이미지 레지스트리를 제공합니다. Cloud Marketplace에서 직접 GKE Enterprise 클러스터에 GitLab을 배포하거나 사용 가능한 다른 설치 옵션 중 하나를 사용할 수 있습니다.

현재 OpenShift 기능 중 하나를 사용하여 워크로드를 빌드하거나 자동으로 배포하는 경우 현재 프로세스에 따라 다음 전략 중 하나를 채택할 수 있습니다.

  • Jenkins 파이프라인. Jenkins 파이프라인을 사용하여 빌드 및 배포 프로세스를 자동화하는 경우 파이프라인을 Cloud Build로 포팅하거나 기존 Jenkins 환경을 사용하거나 Google Cloud에 Jenkins를 배포할 수 있습니다.
  • Dockerfile 및 필수 아티팩트에서 빌드 및 배포. Cloud Build를 사용하여 Dockerfile이 포함된 컨테이너 이미지를 빌드하거나 구성 파일을 빌드할 수 있습니다. 온프레미스 클러스터에서 빌드를 실행하려면 GitLab을 사용하면 됩니다.
  • S2I(source-to-image) 빌드. Cloud Build에서는 결과 컨테이너 이미지에 필요한 아티팩트를 빌드하기 위한 사전 단계를 구현해야 합니다. S2I(source-to-image) 작업이 Python 앱을 빌드하고 컨테이너 이미지를 생성하는 경우 Python 앱을 빌드하도록 커스텀 빌드 단계를 구성한 다음 컨테이너 이미지를 빌드해야 합니다. 또한 이 방법을 사용하려면 Dockerfile을 제공해야 합니다. Dockerfile을 제공하지 않으려면 Google Cloud의 Buildpack 또는 Java 애플리케이션용 Jib를 사용할 수 있습니다.
  • 커스텀 빌드. 이제 OpenShift에서처럼 커스텀 Cloud Build 빌더를 만들 수 있습니다. 커스텀 빌더가 OpenShift 관련 기능을 사용하지 않는 경우 Cloud Build에서 사용할 수 있습니다.

컨테이너 이미지를 빌드하기 위해 선택하는 방법에 관계없이 컨테이너 이미지 저장소에 컨테이너 이미지를 저장해야 합니다. 다음과 같은 다양한 옵션이 있습니다.

  • 기존 컨테이너 이미지 저장소를 유지. OpenShift에서 실행되지 않는 외부 컨테이너 이미지 저장소를 사용 중이고 아직 마이그레이션할 준비가 되지 않았다면 해당 저장소를 계속 사용하여 컨테이너 이미지를 저장할 수 있습니다.
  • Container Registry. 완전 관리형 서비스를 선호하는 경우 Container Registry를 사용하여 컨테이너 이미지를 저장할 수 있습니다. 추가 보안 레이어가 필요한 경우 Container Registry 암호화 키를 직접 관리하고, Container Registry에 액세스하기 위한 보안 경계를 구성하고, 소프트웨어 공급망의 보안을 강화하고, Artifact Analysis를 사용하여 컨테이너 이미지에서 알려진 취약점을 검색할 수 있습니다. Container Registry는 Google에서 유지관리하는 관리형 기본 이미지도 컨테이너 이미지의 기반으로 지원합니다.
  • 온프레미스 저장소. 현재 저장소가 OpenShift에서 호스팅되기 때문에 현재 저장소에서 마이그레이션해야 하고 컨테이너 이미지를 온프레미스에 저장해야 하는 경우 GitLab과 함께 제공된 레지스트리를 선택할 수 있습니다.
  • 하이브리드 방식. 이전 옵션들을 조합하여 각 옵션의 장점을 활용할 수 있습니다. 예를 들어 Container Registry를 기본 저장소로 사용하고 이를 온프레미스 저장소에 미러링할 수 있습니다. 이 경우 Container Registry 기능을 사용하면서 온프레미스 저장소도 계속 활용할 수 있습니다.

컨테이너 이미지를 저장하기 위해 어느 것을 선택하건 컨테이너 이미지 저장소에 액세스하려면 클러스터의 사용자 인증 정보를 프로비저닝하고 구성해야 합니다.

빌드 상태 및 컨테이너 이미지에 대한 알림을 사용자 또는 타사 서비스에 보내야 하는 경우 Cloud Functions를 사용하여 Cloud Build 및 Container Registry에 의해 생성된 이벤트에 응답할 수 있습니다.

OpenShift에서 GKE Enterprise로 기능 매핑 요약

다음 표는 GKE Enterprise 기능을 OpenShift에서 사용한 기능으로 매핑하는 방법을 요약한 것입니다.

OpenShift GKE Enterprise
OpenShift 프로젝트
  • 구성 동기화가 중앙에서 관리하는 Kubernetes 네임스페이스
  • 구성 동기화가 중앙에서 관리하는 Kubernetes RBAC 승인
  • 구성 동기화가 중앙에서 관리하는 Kubernetes 리소스 할당량
OpenShift SDN 및 네트워크 격리
  • 구성 동기화가 중앙에서 관리하는 Calico 네트워크 보안 정책
OpenShift 보안 컨텍스트 제약조건
  • 정책 컨트롤러 제약조건
OpenShift 파이프라인
  • Cloud Build
  • Google Cloud Jenkins 플러그인을 사용한 Jenkins 통합
  • GitLab
OpenShift S2I(Source-to-Image)
  • Cloud Native Buildpack
  • Jib
ID 통합
  • Cloud ID
  • Google Cloud 디렉터리 동기화
  • VMware용 GKE OIDC 통합

환경 최적화

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

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

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

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

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

최적화 요구사항 설정

GKE on Google Cloud 최적화 요구사항은 환경 최적화에 설정된 최적화 요구사항을 검토하세요.

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

최적화 완료

최적화 요구사항 목록을 채운 후 Google Cloud로 마이그레이션: 환경 최적화에 나와 있는 최적화 단계의 나머지 활동을 완료합니다.

도움 받기

Google Cloud는 Google Cloud 서비스를 최적으로 활용하는 데 필요한 도움과 지원을 받을 수 있는 다양한 옵션과 리소스를 제공합니다.

  • 셀프서비스 리소스. 전담 지원이 필요하지 않은 경우 자신의 속도에 맞게 다양한 옵션을 사용할 수 있습니다.
  • 기술 파트너. Google Cloud는 여러 회사와 협력 관계를 맺어 Google 제품 및 서비스를 사용할 수 있도록 지원합니다.
  • Google Cloud 전문 서비스. Google 전문 서비스를 통해 Google Cloud 투자 효과를 극대화할 수 있습니다.

Google Cloud Migration Center에는 워크로드를 Google Cloud로 마이그레이션하는 데 유용한 추가 리소스가 있습니다.

이러한 리소스에 대한 자세한 내용은 Google Cloud로 마이그레이션: 시작하기의 도움말 찾기 섹션을 참조하세요.

다음 단계