컨테이너를 Google Cloud로 마이그레이션: 멀티 클러스터 GKE 환경으로 마이그레이션

Last reviewed 2023-05-08 UTC

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

이 문서는 Google Cloud로 마이그레이션하는 방법을 다루는 시리즈의 일부입니다. 시리즈 개요는 Google Cloud로 마이그레이션: 마이그레이션 경로 선택을 참조하세요.

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

이 문서는 GKE 환경에서 다른 GKE 환경으로 마이그레이션을 계획하는 경우에도 유용합니다. 이 문서는 마이그레이션 기회를 평가하고 그 결과를 살펴보고 싶은 경우에도 유용합니다.

GKE 환경에서 다른 GKE 환경으로 마이그레이션하는 이유는 다음과 같습니다.

  • 클러스터를 만들 때만 사용할 수 있는 GKE 기능 사용 설정. GKE는 새로운 기능 및 보안 수정사항에 따라 지속적으로 진화하고 있습니다. 대부분의 새로운 기능 및 수정사항을 활용하기 위해서는 자동 업그레이드 또는 수동 방식을 통해 GKE 클러스터 및 노드 풀을 새 GKE 버전으로 업그레이드해야 할 수 있습니다.

    일부 새로운 GKE 기능은 기존 클러스터에서 사용 설정할 수 없으며, 해당 새로운 기능을 사용 설정하여 새 GKE 클러스터를 만들어야 합니다. 예를 들어 GKE의 VPC 네이티브 네트워킹, Dataplane V2, 메타데이터 숨김은 새 클러스터를 만들 때만 사용 설정할 수 있습니다. 만든 후에는 이러한 기능을 사용 설정하도록 기존 클러스터의 구성을 업데이트할 수 없습니다.

  • 인프라에 대한 자동화된 프로비저닝 및 구성 프로세스 구현. 인프라를 수동으로 프로비저닝하고 구성하는 경우 수동적이고 오류 발생이 많은 방법을 사용하는 대신 GKE 클러스터를 프로비저닝하고 구성하기 위한 자동화된 프로세스를 설계하고 구현할 수 있습니다.

새 환경의 아키텍처를 설계할 때는 멀티 클러스터 GKE 환경을 고려하는 것이 좋습니다. 환경에 다중 GKE 클러스터를 프로비저닝하고 구성하여 다음을 수행할 수 있습니다.

  • 아키텍처에 단일 장애점이 도입될 가능성을 줄여줍니다. 예를 들어 클러스터에 중단이 발생하면 다른 클러스터가 대신할 수 있습니다.
  • 멀티 클러스터 환경이 제공하는 더 큰 유연성을 얻을 수 있습니다. 예를 들어 클러스터 하위 집합에 변경사항을 적용하여 잘못된 구성 변경으로 인한 문제의 영향을 제한할 수 있습니다. 그리고 변경사항을 검증한 후에 이를 남은 클러스터에 적용할 수 있습니다.
  • 워크로드가 클러스터 간에 통신하도록 허용합니다. 예를 들어 한 클러스터에 배포된 워크로드가 다른 클러스터에 배포된 워크로드와 통신할 수 있습니다.

이 문서의 안내는 단일 클러스터 GKE 환경에도 적용될 수 있습니다. 단일 클러스터 GKE 환경으로 마이그레이션할 때 환경은 멀티 클러스터 환경에 비해 관리하기에 덜 복잡합니다. 하지만 단일 클러스터 환경은 멀티 클러스터 GKE 환경의 늘어난 유연성, 안정성, 복원력 이점을 얻지 못합니다.

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

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

앞의 다이어그램에 설명된 프레임워크에는 다음 단계가 포함됩니다. 이에 대한 정의는 Google Cloud로 마이그레이션: 시작하기를 참조하세요.

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

각 마이그레이션 단계를 수행할 때 앞의 단계를 따릅니다. 이 문서에서는 또한 컨테이너를 Google Cloud로 마이그레이션: Kubernetes를 GKE로 마이그레이션에 설명된 개념이 사용됩니다. 필요한 경우 링크를 눌러 참조하세요.

환경 평가

평가 단계에서는 원본 환경 및 마이그레이션할 워크로드에 대한 정보를 수집합니다. 이러한 평가는 마이그레이션에 중요하며 마이그레이션 및 대상 환경에 필요한 리소스 크기를 알맞게 결정하기 위한 것입니다. 평가 단계에서 다음을 수행합니다.

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

다음 섹션에서는 Google Cloud로 마이그레이션: 워크로드 평가 및 검색을 따릅니다. 하지만 새 GKE 클러스터로 마이그레이션하려는 워크로드를 평가하는 것과 관련된 정보를 제공합니다.

Kubernetes를 GKE로 마이그레이션할 때 환경 평가에서는 ServiceAccounts 및 PersistentVolumes와 같은 Kubernetes 클러스터 및 리소스를 평가하는 방법을 설명합니다. 이 정보는 GKE 환경 평가에도 적용됩니다.

인벤토리 빌드

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

Kubernetes를 GKE로 마이그레이션할 때 인벤토리 빌드에서는 Kubernetes 클러스터 및 워크로드의 인벤토리를 빌드하는 방법을 설명합니다. GKE 환경의 인벤토리 빌드에도 적용될 수 있습니다. 이 문서를 계속 진행하기 전에 해당 안내에 따라 Kubernetes 클러스터의 인벤토리를 빌드합니다.

Kubernetes를 GKE로 마이그레이션 안내에 따라 인벤토리를 빌드했으면 이제 인벤토리를 미세 조정합니다. GKE 클러스터 및 노드 풀 인벤토리를 완료하려면 다음을 포함하여 각 클러스터 및 노드 풀에 대해 GKE 관련 요소 및 기능을 고려합니다.

인벤토리를 빌드할 때 마이그레이션 중에 사용 중단되어야 하는 일부 GKE 클러스터가 발견될 수 있습니다. 일부 Google Cloud 리소스는 이를 만든 GKE 클러스터를 삭제해도 삭제되지 않습니다. 마이그레이션 계획에 이러한 리소스 중단이 포함되는지 확인합니다.

다른 잠재적인 GKE 관련 요소 및 기능에 대한 자세한 내용은 GKE 문서를 참조하세요.

평가 완료

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

기반 계획 및 구축

계획 단계에서는 Google Cloud에서 워크로드를 지원하는 기초, 클라우드 인프라, 서비스를 프로비저닝하고 구성합니다. 계획 단계에서 다음을 수행합니다.

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

네트워크 연결을 설정할 때 노드, 포드, 서비스에 할당할 수 있도록 서브넷의 IP 주소가 충분한지 확인합니다. 클러스터에 대해 네트워킹을 설정할 때 IP 주소 할당을 신중하게 계획합니다. 예를 들어 GKE에 대해 비공개로 사용되는 공개 IP를 구성할 수 있습니다. 클러스터에서 포드 및 서비스에 대해 설정하는 두 번째 IP 주소 범위는 할당 후 변경할 수 없습니다. /22(1,024개 주소) 이하의 포드 또는 서비스 범위를 할당하는 경우 특별히 주의해야 합니다. 그렇지 않으면 클러스터가 성장할 때 포드 및 서비스의 IP 주소가 부족해질 수 있습니다. 자세한 내용은 IP 주소 범위 계획을 참조하세요.

GKE 환경에 만드는 내부 부합 분산기에 대해 개별 공유 서브넷을 사용하는 것이 좋습니다. type: LoadBalancer의 Kubernetes 서비스를 사용할 때는 부하 분산기 서브넷을 지정할 수 있습니다. 내부 HTTP(S) 내부 부하 분산기를 구성할 때는 프록시 전용 서브넷을 구성해야 합니다.

GKE 환경의 기초를 빌드하려면 컨테이너를 Google Cloud로 마이그레이션: Kubernetes를 GKE로 마이그레이션에 있는 계획 및 빌드 단계의 활동을 완료합니다.

워크로드 배포

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

  1. 테스트 환경을 프로비저닝하고 구성합니다.
  2. 원본 환경에서 대상 환경으로 데이터를 마이그레이션합니다.
  3. 대상 환경에 워크로드를 배포합니다.

이 섹션에서는 GKE에 워크로드 배포와 관련된 정보를 제공합니다. 이 내용은 Kubernetes를 GKE로 마이그레이션: 워크로드 배포의 정보를 기반으로 합니다.

런타임 플랫폼 및 환경 평가

유연성, 안정성, 유지보수 가능성이 더 높은 인프라를 얻기 위해서는 멀티 클러스터 아키텍처를 설계하고 구현하는 것이 좋습니다. 멀티 클러스터 아키텍처에서 환경에 다중 프로덕션 GKE 클러스터를 사용합니다. 예를 들어 환경에 다중 GKE 클러스터를 프로비저닝하는 경우 연속 업그레이드 또는 블루/그린 업그레이드와 같은 고급 클러스터 수명 주기 전략을 구현할 수 있습니다. 멀티 클러스터 GKE 아키텍처 설계 및 그 이점에 대한 자세한 내용은 멀티 클러스터 인그레스를 사용하는 멀티 클러스터 GKE 업그레이드를 참조하세요.

다중 클러스터 간에 환경을 실행할 때는 다음과 같이 고려해야 할 추가 문제가 있습니다.

  • 구성 관리, 서비스 검색 및 통신, 애플리케이션 출시, 수신 트래픽의 부하 분산을 조정해야 합니다.
  • 클러스터에서 추가 소프트웨어를 실행하고, 추가 자동화 및 인프라를 실행해야 할 수 있습니다.

이러한 문제 해결을 위해서는 실수로 인한 영향을 최소화하기 위해 클러스터 구성을 순차적으로 업데이트할 수 있도록 지속적 통합/지속적 배포(CI/CD) 파이프라인이 필요할 수 있습니다. 또한 한 클러스터에서 다른 클러스터로 트래픽을 분배하기 위해 부하 분산기가 필요할 수 있습니다.

수동적인 인프라 관리는 오류가 발생하기 쉬우며 잘못된 구성, 현재 인프라 상태에 대한 내부 문서화 부족으로 인해 문제에 노출될 수 있습니다. 이러한 문제로 인한 위험을 완화하기 위해서는 인프라를 코드 패턴으로 적용하는 것이 좋습니다. 이 패턴을 적용할 때는 워크로드의 소스 코드를 처리할 때와 동일한 방법으로 인프라 프로비저닝을 처리합니다.

멀티 클러스터 GKE 환경에는 여러 아키텍처 옵션이 있습니다. 이에 대해서는 이 섹션의 뒷 부분을 참조하세요. 다양한 요소에 따라 선택하는 옵션이 달라질 수 있으며, 어떤 옵션도 다른 옵션보다 본질적으로 우월하지는 않습니다. 각 유형마다 나름의 장단점이 있습니다. 아키텍처 유형을 선택하려면 다음을 수행합니다.

  1. 멀티 클러스터 GKE 환경의 아키텍처 유형을 평가할 수 있도록 기준 집합을 설정합니다.
  2. 평가 기준에 따라 각 옵션을 평가합니다.
  3. 요구사항에 가장 적합한 옵션을 선택합니다.

멀티 클러스터 GKE 환경의 아키텍처 유형을 평가하도록 기준을 설정하려면 완료한 환경 평가를 사용하여 필요한 기능을 식별합니다. 중요도에 따라 기능 순서를 지정합니다. 예를 들어 워크로드 및 환경을 평가한 후 중요도 순서에 따라 나열된 다음 평가 기준을 고려할 수 있습니다.

  1. Google 관리형 솔루션. Google 관리형 또는 자체 관리형 서비스 및 제품 중 선호 대상을 선택합니다.
  2. 아키텍처와 상호작용하기 위한 인터페이스. 상호작용할 수 있는 머신이 읽을 수 있는 인터페이스가 있나요? 인터페이스가 개방형 표준으로 정의되어 있나요? 인터페이스가 선언적 지시문이나 명령적 지시문 또는 둘 다를 지원하나요?
  3. GKE 환경 외부에 서비스 노출. 아키텍처에서 배포된 GKE 클러스터 외부에서의 워크로드 노출이 허용되나요?
  4. 클러스터 간 통신. 아키텍처에서 클러스터 간 통신 채널이 지원되나요? 워크로드가 분산 아키텍처를 지원하나요? 이 기준은 Jenkins와 같은 분산 설계로 워크로드를 지원하는 데 중요합니다.
  5. 트래픽 관리. 아키텍처에서 결함 주입, 트래픽 이동, 요청 제한 시간 및 재시도, 회로 차단기, 트래픽 모니터링과 같은 고급 트래픽 관리 기능이 지원되나요? 이러한 기능이 사용하도록 준비되어 있나요? 아니면 직접 구현해야 하나요?
  6. 추가 도구 프로비저닝 및 구성. 추가 하드웨어 또는 소프트웨어 구성요소를 프로비저닝하고 구성해야 하나요?

Google Cloud는 멀티 클러스터 GKE 환경의 아키텍처를 설계하기 위한 다음 옵션을 제공합니다. 워크로드에 가장 적합한 옵션을 선택하려면 먼저 앞에서 설정한 평가 기준과 비교하여 평가해야 합니다. 임의의 정렬된 비율을 사용하여 각 설계 옵션에 각 평가 기준에 대한 점수를 할당합니다. 예를 들어 각 평가 기준에 대해 1~10 사이의 점수를 각 환경에 할당할 수 있습니다. 다음 옵션은 새로운 멀티 클러스터 GKE 환경의 관리를 위해 필요한 노력의 정도에 따라 오름차순으로 표시되어 있습니다.

  1. 멀티 클러스터 인그레스 및 멀티 클러스터 서비스 검색
  2. 멀티 클러스터 인그레스 및 Anthos Service Mesh
  3. Traffic Director
  4. Kubernetes 및 자체 관리형 DNS 레코드 업데이트

다음 섹션은 이러한 옵션을 자세히 설명하고 각 옵션을 평가하기 위한 기준 목록을 포함합니다. 제품 문서를 읽어 특정 기준에 대한 점수를 할당할 수 있습니다. 예를 들어 문서를 읽고 이전에 설정한 평가 기준 중 일부에 따라 Anthos Service Mesh를 평가할 수 있습니다. 그러나 다른 기준에 점수를 할당하려면 보다 깊이 있는 벤치마크와 시뮬레이션을 설계하고 실행해야 할 수 있습니다. 예를 들어 워크로드에 적합한지 평가하기 위해서는 여러 멀티 클러스터 GKE 아키텍처의 성능을 벤치마크해야 할 수 있습니다.

멀티 클러스터 인그레스 및 멀티 클러스터 서비스 검색

멀티 클러스터 인그레스는 배포된 GKE 클러스터에 관계없이 워크로드를 노출할 수 있게 해주는 Google 관리형 서비스입니다. 또한 GKE 클러스터 및 리전 간에 공유 부하 분산기를 구성할 수 있게 해줍니다. 멀티 클러스터 GKE 환경에서 멀티 클러스터 인그레스를 사용하는 방법에 대한 자세한 내용은 멀티 클러스터 인그레스를 사용한 멀티 클러스터 GKE 업그레이드 및 Istio 메시 확장으로 마이그레이션 지원을 참조하세요.

멀티 클러스터 서비스 검색은 Kubernetes 기반의 클러스터간 서비스 검색 및 GKE용 연결 메커니즘입니다. 멀티 클러스터 서비스 검색은 Kubernetes 서비스 리소스를 기반으로 앱이 클러스터 경계 간에 서로를 검색하고 연결할 수 있게 해줍니다. 이전에 설정한 기준에 따라 멀티 클러스터 인그레스 및 멀티 클러스터 서비스 검색을 평가하려면 다음 목록을 사용하세요. 이 목록은 상대적인 중요도 순서로 나열되어 있습니다.

  1. Google 관리형 솔루션. 멀티 클러스터 서비스 검색은 GKE의 완전 관리형 기능입니다. Cloud DNS 영역 및 레코드, 방화벽 규칙, Traffic Director와 같은 리소스를 구성하므로, 이를 관리할 필요가 없습니다.
  2. 아키텍처와 상호작용하기 위한 인터페이스. 서비스는 ServiceExport라는 선언적 Kubernetes 리소스를 사용하여 다른 클러스터로 내보내집니다.
  3. GKE 환경 외부에 서비스 노출. 멀티 클러스터 인그레스 및 멀티 클러스터 서비스 검색을 사용할 때는 배포한 위치에 관계없이 GKE 클러스터 외부에 워크로드를 노출할 수 있습니다.
  4. 클러스터 간 통신. ServiceExport 객체를 선언하여 다른 GKE 클러스터로 기존 서비스를 내보냅니다. 동일한 Fleet의 GKE 클러스터는 ServiceExport 객체를 사용하여 내보내는 서비스를 자동으로 가져옵니다. 멀티 클러스터 서비스 검색은 내보낸 각 서비스에 대해 가상 IP 주소를 설정합니다. 멀티 클러스터 서비스 검색은 Kubernetes DNS 규칙의 단순 변형을 사용하여 서비스를 검색하고 연결하도록 Traffic Director 리소스, Cloud DNS, 방화벽 규칙을 자동으로 구성합니다. 예를 들어 my-svc 서비스에 연결하려면 my-svc.my-ns.svc.clusterset.local 이름을 사용할 수 있습니다.
  5. 트래픽 관리. 멀티 클러스터 서비스 검색은 단순 레이어 3/4 연결을 구성하고 서비스 검색을 위해 DNS를 사용합니다. 트래픽 관리 기능은 제공하지 않습니다.
  6. 추가 도구 프로비저닝 및 구성. Google API를 사용 설정하여 멀티 클러스터 서비스 검색을 설정할 수 있습니다. 추가 도구는 설치할 필요가 없습니다. 자세한 내용은 컨테이너를 Google Cloud로 마이그레이션: 멀티 클러스터 서비스 검색 및 멀티 클러스터 인그레스를 사용하여 멀티 클러스터 GKE 환경으로 마이그레이션을 참조하세요.

멀티 클러스터 인그레스 및 Anthos Service Mesh

서비스 메시는 분산 앱의 네트워크 문제를 도와주는 아키텍처 패턴입니다. 이러한 문제에는 서비스 검색, 부하 분산, 내결함성, 트래픽 제어, 관측 가능성, 인증, 승인, 전송 중 암호화가 포함됩니다. 일반적인 서비스 메시 구현은 데이터 영역 및 제어 영역으로 구성됩니다. 데이터 영역은 일반적으로 사이드카 프록시를 사용하여 직접적인 트래픽 처리 및 대상 워크로드로의 전달을 처리합니다. 제어 영역은 데이터 영역을 구성하는 구성요소를 나타냅니다.

인프라에서 서비스 메시 패턴을 구현할 때는 Anthos Service Mesh 및 Traffic Director의 두 가지 Google Cloud 제품 중 하나를 선택합니다. 두 제품 모두 다중 GKE 클러스터 간의 애플리케이션 레이어(L7) 네트워킹을 구성하기 위한 제어 영역을 제공합니다. Anthos Service Mesh는 Istio를 기반으로 하며 선언적 오픈소스 API를 제공합니다. Traffic Director는 Google 부하 분산 기능, 오픈소스 기술의 조합을 기반으로 하며, 명령적 Google API를 제공합니다.

Anthos Service Mesh는 배포된 GKE 클러스터에 관계없이 그리고 앱 모드를 수정하지 않고 워크로드를 연결, 관리, 보호, 모니터링할 수 있게 해주는 Google 관리형 도구 모음입니다. Anthos Service Mesh를 사용하여 여러 GKE 클러스터를 포함하는 메시지를 설정하는 방법은 Anthos Service Mesh에 GKE 클러스터 추가를 참조하세요. 이전에 설정한 기준에 따라 멀티 클러스터 인그레스 및 Anthos Service Mesh를 평가하려면 다음 목록을 사용하세요. 이 목록은 상대적인 중요도 순서로 나열되어 있습니다.

  1. Google 관리형 솔루션. 멀티 클러스터 인그레스 및 Anthos Service Mesh 모두 완전 관리형 제품입니다. Google에서 관리되므로, 이러한 제품을 프로비저닝할 필요가 없습니다.
  2. 아키텍처와 상호작용하기 위한 인터페이스. Anthos Service Mesh는 Istio를 해당 코어로 사용합니다. Anthos Service Mesh API는 Kubernetes 리소스 모델을 기준으로 선언적 구성을 지원합니다.
  3. GKE 환경 외부에 서비스 노출. 멀티 클러스터 인그레스 및 Anthos Service Mesh 인그레스 게이트웨이는 GKE 클러스터 외부에 워크로드를 노출할 수 있게 해줍니다.
  4. 클러스터 간 통신. Anthos Service Mesh는 실행되는 클러스터에 관계없이 포드 간에 직접 보안 통신 채널을 설정합니다. 이 설정을 사용하면 이러한 통신 채널을 프로비저닝하고 구성하느라 추가적인 비용을 지출할 필요가 없습니다. Anthos Service Mesh는 Fleet 및 서비스 동일성이라는 개념을 사용해서 GKE 서비스 검색을 멀티 클러스터로 확장합니다. 따라서 메시의 다른 클러스터에서 실행되는 워크로드를 검색하기 위해 현재 워크로드를 수정할 필요가 없습니다.
  5. 트래픽 관리. Anthos Service Mesh는 수신 트래픽을 보호하고 워크로드로 라우팅하는 방법을 제어하기 위해 사용할 수 있는 고급 트래픽 관리 기능을 제공합니다. 예를 들어 Anthos Service Mesh는 결함 삽입, 요청 제한 시간 및 재시도, 회로 차단기, 트래픽 미러링, 트래픽 이동과 같은 모든 Istio 트래픽 관리 기능을 지원합니다. 또한 이러한 트래픽 관리 기능을 사용하여 새 GKE 환경으로의 마이그레이션을 단순화할 수 있습니다. 예를 들어 이전 환경에서 새 환경으로 트래픽을 점진적으로 이동할 수 있습니다.
  6. 추가 도구 프로비저닝 및 구성. 멀티 클러스터 인그레스를 사용하려면 멀티 클러스터 서비스 검색 기본 요건을 충족시켜야 하지만 GKE 클러스터에 추가 도구를 설치할 필요가 없습니다. Anthos Service Mesh를 사용하려면 이를 클러스터에 설치해야 합니다.

Traffic Director

Traffic Director는 애플리케이션 네트워킹을 위한 관리형 제어 영역입니다. 고급 트래픽 관리 및 관측 가능성 기능으로 리치 서비스 메시 토폴로지를 프로비저닝하고 구성할 수 있게 해줍니다. Traffic Director에 대한 자세한 내용은 Traffic Director 개요 및 Traffic Director 기능을 참조하세요. 다중 GKE 클러스터를 포함하는 서비스 메시를 프로비저닝하고 구성하려면 멀티 클러스터 또는 다중 환경 Traffic Director 구성을 사용할 수 있습니다. 이전에 설정한 기준에 따라 Traffic Director를 평가하려면 다음 목록을 사용하세요. 이 목록은 상대적인 중요도 순서로 나열되어 있습니다.

  1. Google 관리형 솔루션. Traffic Director는 완전 관리형 제품입니다. Google에서 관리되므로, 이러한 제품을 프로비저닝할 필요가 없습니다.
  2. 아키텍처와 상호작용하기 위한 인터페이스. Google Cloud Console, Google Cloud CLI, Traffic Director API 또는 Terraform 등의 도구를 사용하여 Traffic Director를 구성할 수 있습니다. Traffic Director는 명령적 구성 모델을 지원하며, xDS 및 gRPC와 같은 오픈소스 제품 및 기술을 기반으로 합니다.
  3. GKE 환경 외부에 서비스 노출. Traffic Director는 서비스 네트워크 외부에서 수신 트래픽을 처리하도록 부하 분산기를 프로비저닝하고 구성합니다.
  4. 클러스터 간 통신. Traffic Director 제어 영역은 멀티 클러스터의 GKE 포드와 같은 엔드포인트를 서비스 백엔드로 그룹화할 수 있게 해주는 API를 제공합니다. 그런 후 이러한 백엔드를 메시의 다른 클라이언트에서 라우팅할 수 있습니다. Traffic Director는 GKE 서비스 검색과 직접 통합되지 않지만 gke-autoneg-controller와 같은 오픈소스 컨트롤러를 사용하여 선택적으로 통합을 자동화할 수 있습니다. 또한 선택적으로 멀티 클러스터 서비스 검색을 사용하여 GKE 서비스 검색을 멀티 클러스터로 확장할 수 있습니다.
  5. 트래픽 관리. Traffic Director는 새 GKE 환경에 대한 마이그레이션을 단순화하고 아키텍처의 안정성을 향상시키기 위해 사용할 수 있는 고급 트래픽 관리 기능을 제공합니다. 미세 조정된 트래픽 라우팅, 가중치 기반 트래픽 분할, 트래픽 미러링, 미세 조정된 부하 분산과 같은 기능의 구성에 대한 자세한 내용은 고급 트래픽 관리 구성을 참조하세요.
  6. 추가 도구 프로비저닝 및 구성. Traffic Director는 GKE 클러스터에서 실행되지 않습니다. Traffic Director 프로비저닝 및 구성에 대한 자세한 내용은 Traffic Director 설정 준비를 참조하세요. 서비스 네트워크에 워크로드를 포함하기 위해 Traffic Director에 필요한 사이드카 포드를 구성하려면 GKE 포드에서 Envoy로 Traffic Director 배포를 참조하세요.

Kubernetes 및 자체 관리형 DNS 레코드 업데이트

클러스터에 추가 소프트웨어를 설치하지 않고 서비스 메시가 제공하는 기능도 필요하지 않으면 Kubernetes 및 자체 관리형 DNS 레코드 업데이트 옵션을 선택할 수 있습니다.

이 옵션을 사용하여 클러스터 내부 검색 및 연결을 구성할 수 있지만, 이 문서에 설명된 다른 옵션 중 하나를 선택하는 것이 좋습니다. 자체 관리형 솔루션을 사용하는 데 필요한 작업은 그로 인해 얻을 수 있는 이점보다 훨씬 큽니다. 또한 다음과 같은 중요한 제한사항도 고려하세요.

type: LoadBalancer 서비스 또는 인그레스 객체를 GKE 클러스터에 만들 때 GKE는 부하 분산기 IP 주소를 사용해서 해당 서비스를 노출하도록 네트워크 부하 분산기 및 HTTP(S) 부하 분산기를 자동으로 만듭니다. 부하 분산기의 IP 주소를 사용하여 서비스와 통신할 수 있습니다. 하지만 IP 주소를 Cloud DNS를 사용하는 DNS 레코드에 매핑하거나 DNS를 사용하여 쿼리할 수 있는 그리고 해당 DNS 레코드를 사용하도록 클라이언트를 구성하는 서비스 디렉터리 엔드포인트에 매핑하여 IP 주소에 대한 의존을 없애는 것이 좋습니다. 서비스의 여러 인스턴스를 배포하고, 모든 결과 부하 분산기 IP 주소를 관련 DNS 레코드 또는 서비스 디렉터리 엔드포인트에 매핑할 수 있습니다.

서비스 인스턴스를 사용 중단하려면 먼저 관련 DNS 레코드 또는 서비스 디렉터리 엔드포인트에서 관련 부하 분산기 IP 주소를 삭제합니다. 그런 후 클라이언트의 DNS 캐시가 업데이트되었는지 확인한 후 서비스를 사용 중단합니다.

워크로드가 서로 다른 GKE 클러스터 내에서 서로 통신할 수 있도록 구성할 수 있습니다. 이렇게 하려면 먼저 내부 TCP/UDP 부하 분산기 또는 내부 HTTP(S) 부하 분산기를 사용하여 클러스터 외부에 서비스를 노출합니다. 그런 후 부하 분산기의 IP 주소를 DNS 레코드 또는 서비스 디렉터리 엔드포인트에 매핑합니다. 마지막으로 각 클러스터에서 DNS 레코드 또는 서비스 디렉터리 엔드포인트를 가리키는 type: ExternalName 서비스를 만듭니다.

원하는 경우 추가 인그레스 컨트롤러를 사용해서 단일 부하 분산기 및 Cloud DNS 레코드 또는 서비스 디렉터리 엔드포인트를 다중 워크로드와 공유할 수 있습니다. 예를 들어 한 클러스터에서 인그레스 컨트롤러를 프로비저닝하는 경우 GKE가 해당 인그레스 컨트롤러에 대해 만드는 부하 분산기로 수신되는 요청을 다중 서비스로 리디렉션하도록 구성할 수 있습니다. 추가 인그레스 컨트롤러를 사용하면 관리해야 하는 DNS 레코드 또는 서비스 디렉터리 엔드포인트 수를 줄일 수 있습니다.

이전에 설정한 기준에 따라 Kubernetes 및 자체 관리형 DNS 레코드를 평가하려면 상대적 중요도에 따라 나열된 다음 목록을 참조하세요.

  1. Google 관리형 솔루션. 이 솔루션의 일부인 Kubernetes 객체를 직접 관리합니다. Cloud DNS, 서비스 디렉터리, 부하 분산은 Google 관리형 서비스입니다.
  2. 아키텍처와 상호작용하기 위한 인터페이스. GKE는 해당 코어에서 Kubernetes를 사용하고, 명령적 및 선언적 구성 모델을 모두 지원합니다.
  3. GKE 환경 외부에 서비스 노출. DNS 레코드, 서비스 디렉터리 엔드포인트, 부하 분산기를 사용하여 GKE 클러스터 외부의 클라이언트에 서비스를 노출할 수 있습니다.
  4. 클러스터 간 통신. type: ExternalName 서비스를 사용하면 다른 GKE 클러스터에 배포된 서비스를 가리키는 엔드포인트를 정의할 수 있습니다. 이 구성을 사용하면 동일 클러스터에 배포된 것처럼 서비스가 서로 통신할 수 있습니다.
  5. 트래픽 관리. 이 솔루션은 Kubernetes 및 GKE에서 이미 제공되는 것 이외의 다른 추가적인 트래픽 관리 기능을 제공하지 않습니다. 예를 들어 이 옵션은 서로 다른 클러스터 간의 트래픽 분할을 지원하지 않습니다.
  6. 추가 도구 프로비저닝 및 구성. 이 옵션은 GKE 클러스터에서 추가 소프트웨어를 프로비저닝하고 구성할 필요가 없습니다. 필요한 경우 인그레스 컨트롤러를 설치할 수 있습니다.

아키텍처 선택

각 옵션에 대한 모든 기준에 값을 할당한 후 각 옵션의 총 점수를 계산합니다. 각 옵션의 총 점수를 계산하려면 기준에 따라 해당 설계 옵션의 모든 평점을 추가합니다. 예를 들어 특정 기준에 따라 환경에 10점이 부여되고, 다른 기준에 따라 6점이 부여된 경우 해당 옵션의 총 점수는 16점입니다.

또한 평가에 대한 각 기준의 중요도를 나타내기 위해 각 기준에 대한 점수에 다른 가중치를 할당할 수 있습니다. 예를 들어 Google 관리형 솔루션이 해당 평가에서 분산 워크로드 아키텍처 지원보다 중요하면 Google 관리형 솔루션에 대해 배수를 1.0으로 지정하고 분산 워크로드 아키텍처에 대해서는 배수를 0.7로 지정하는 등, 이를 반영한 배수를 정의할 수 있습니다. 그런 다음 이러한 배율을 사용하여 옵션의 총 점수를 계산합니다.

평가한 각 환경의 총점을 계산한 후 해당 총점에 따라 내림차순으로 환경을 정리합니다. 그런 다음 점수가 가장 높은 환경을 선택합니다.

이 데이터를 나타내는 방법은 여러 가지가 있습니다. 예를 들어 방사형 차트와 같이 다변수 데이터를 나타내기 적합한 차트로 결과를 시각화할 수 있습니다.

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

이전 환경에서 새 환경으로 데이터를 마이그레이션하는 과정에 대한 안내는 GKE로 Kubernetes 마이그레이션, 이전 환경에서 새 환경으로 데이터 마이그레이션을 참조하세요.

워크로드 배포

이전 환경에서 새 환경으로 데이터 마이그레이션에 대한 자세한 내용은 워크로드 배포를 참조하세요.

이 문서에서 제안되는 모든 아키텍처는 다운타임 또는 컷오버 기간 없이 기존 GKE 환경에서 새로운 멀티 클러스터 환경으로 워크로드를 마이그레이션할 수 있게 해줍니다. 다운타임 없이 워크로드를 마이그레이션하려면 다음을 수행합니다.

  1. 새로운 멀티 클러스터 GKE 환경에서 기존 레거시 GKE 클러스터를 일시적으로 통합합니다.
  2. 새로운 멀티 클러스터 환경에서 워크로드의 인스턴스를 배포합니다.
  3. 워크로드를 새로운 GKE 클러스터로 점진적으로 마이그레이션할 수 있도록 기존 환경에서 점진적으로 트래픽을 마이그레이션하고, 기존 GKE 클러스터를 사용 중단합니다.

배포 완료

런타임 플랫폼 및 환경을 프로비저닝하고 구성한 후, Kubernetes를 GKE로 마이그레이션, 워크로드 배포에 설명된 활동을 수행합니다.

환경 최적화

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

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

GKE 환경의 최적화를 수행하려면 Kubernetes를 GKE로 마이그레이션, 환경 최적화를 참조하세요.

다음 단계