AWS から Google Cloud への移行: Amazon EKS から GKE への移行

Last reviewed 2024-08-02 UTC

Google Cloud には、Amazon Elastic Kubernetes Service（Amazon EKS）から Google Kubernetes Engine（GKE）に移行するためのツール、プロダクト、ガイダンス、プロフェッショナル サービスが用意されています。このドキュメントは、Amazon EKS から GKE への移行計画の設計、実施、検証に役立ちます。このドキュメントでは、移行の可能性を評価し、移行の概要を検討する際のガイダンスも提供しています。Amazon EKS には、Amazon Elastic Compute Cloud（Amazon EC2）で実行する以外に、Amazon EKS on AWS 出力や Amazon EKS など、他のデプロイ オプションがあります。このドキュメントでは、Amazon EKS on EC2 を中心に説明します。

このドキュメントは、AWS から Google Cloud への移行に関する複数のパートからなるシリーズの一部です。このシリーズには、次のドキュメントが含まれています。

GKE は Google が管理する Kubernetes サービスです。Google のインフラストラクチャを使用してコンテナ化されたアプリケーションを大規模にデプロイして運用するために使用できます。また、次のような Kubernetes 環境の管理に役立つ機能を提供します。

  • 2 つのエディション: GKE Standard と GKE Enterprise。GKE Standard では、コア機能のスタンダード ティアにアクセスできます。GKE Enterprise では、GKE のすべての機能にアクセスできます。詳細については、GKE のエディションをご覧ください。
  • 2 つの運用モード: Standard と Autopilot。Standard では、基盤となるインフラストラクチャと GKE クラスタ内の各ノードの構成を管理します。Autopilot を使用すると、GKE は基盤となるインフラストラクチャ（ノード構成、自動スケーリング、自動アップグレード、ベースライン セキュリティ、ネットワーク構成など）を管理します。GKE の運用モードの詳細については、GKE の運用モードを選択するをご覧ください。
  • 複数のゾーンで Autopilot を使用する場合の Pod の業界固有のサービスレベル契約。
  • ノードの自動プロビジョニングによるノードプールの作成と削除の自動化。
  • Google が管理するマルチクラスタ ネットワーキング。ワークロードの高可用性分散アーキテクチャを設計して実装できます。

GKE の詳細については、GKE の概要をご覧ください。

Google Cloud に移行する場合は、Google Cloud への移行: スタートガイドで説明する移行フレームワークに従うことをおすすめします。

次の図は、移行の過程を示しています。

4 フェーズの移行パス

移行元の環境から Google Cloud には、一連のイテレーションで移行できます。たとえば、最初に一部のワークロードを移行した後、残りのワークロードを移行できます。個別の移行イテレーションごとに、以下の一般的な移行フレームワークのフェーズに従います。

  1. ワークロードとデータを評価して検出します。
  2. Google Cloud で基盤を計画し、構築します。
  3. ワークロードとデータを Google Cloud に移行します。
  4. Google Cloud 環境を最適化します。

このフレームワークのフェーズの詳細については、Google Cloud への移行: スタートガイドをご覧ください。

効果的な移行計画を設計するには、計画の各ステップを検証し、ロールバック戦略を常に持っていることをおすすめします。移行計画の検証については、Google Cloud への移行: 移行計画の検証に関するベスト プラクティスをご覧ください。

移行元の環境を評価する

評価フェーズでは、移行元の環境を Google Cloud に移行するための要件と依存関係を確認します。

移行を成功させるには、評価フェーズが非常に重要です。このフェーズで、移行するワークロードとその要件、依存関係、および現在の環境について詳しく把握する必要があります。また、Google Cloud への移行を計画して実施するための出発点も理解する必要があります。

評価フェーズは、次のタスクで構成されます。

  1. ワークロードの包括的なインベントリを作成する。
  2. プロパティと依存関係に応じてワークロードを分類する。
  3. チームを Google Cloud でトレーニングして教育する。
  4. Google Cloud 上でテストと概念実証を構築する。
  5. ターゲット環境の総所有コスト（TCO）を計算する。
  6. ワークロードの移行戦略を選択する。
  7. 移行ツールを選択する。
  8. 移行計画とタイムラインを定義する。
  9. 移行計画を検証する。

評価フェーズとこれらのタスクの詳細については、Google Cloud への移行: ワークロードの評価と検出をご覧ください。以下のセクションは、このドキュメントの情報に基づいています。

インベントリを構築する

移行の対象範囲を設定するには、次の 2 つのインベントリを作成します。

  1. クラスタのインベントリ。
  2. これらのクラスタにデプロイされているワークロードのインベントリ。

これらのインベントリを作成した後、次のことを行います。

  1. 移行元の環境のデプロイ プロセスと運用プロセスを評価します。
  2. サポート サービスと外部依存関係を評価します。

クラスタのインベントリを作成する

クラスタのインベントリを構築するには、クラスタごとに次の点を検討します。

  • ノードの数とタイプ。現在の環境にあるノードの数と各ノードの特性がわかっている場合は、GKE に移行するときにクラスタのサイズを見積ります。新しい環境内のノードは、現在の環境で使用しているものとは異なる世代のハードウェア アーキテクチャ上で動作している可能性があります。アーキテクチャの世代によってパフォーマンスが異なるため、新しい環境で必要なノードの数は現在とは異なるかもしれません。高性能ストレージ デバイス、GPU、TPU など、ノードで使用しているハードウェアの種類を評価します。ノードで使用しているオペレーティング システム イメージを評価します。
  • 内部または外部クラスタ。内部環境あるいは外部環境の、どちらの関係者に向けて各クラスタが公開されるのかを評価します。ユースケースをサポートするために、この評価にはクラスタで実行されているワークロードと、クラスタとやり取りするインターフェースが含まれます。
  • マルチテナンシー。環境内でマルチテナントのクラスタを管理している場合は、新しい Google Cloud 環境で動作するかどうかを評価します。マルチテナント戦略は Google Cloud での基盤構築の手段に影響するため、マルチテナント クラスタの改善方法を評価する良い機会です。
  • Kubernetes のバージョン。クラスタの Kubernetes バージョンに関する情報を収集し、それらのバージョンと GKE で使用可能なバージョンに違いがあるかどうかを評価します。古いバージョンまたは最近リリースされた Kubernetes のバージョンを実行している場合は、GKE で使用できない機能が使われている可能性があります。それらの機能がサポートされていないか、機能を提供する Kubernetes バージョンがまだ GKE で利用できない場合があります。
  • Kubernetes のアップグレード サイクル。信頼性の高い環境を維持するには、Kubernetes のアップグレードの取り扱い方法と、アップグレード サイクルが GKE のアップグレードとどのように関連しているかを理解します。
  • ノードプール。どの形式のノードグループ化を使用する場合でも、そのグループ化の条件が GKE に適さない場合があるため、こうしたグループ化が GKE のノードプールのコンセプトにどのように対応するかを考慮することも可能です。
  • ノードの初期化。各ノードを初期化する方法を評価した後で、ワークロードの実行に利用可能なノードを選び、初期化手順を GKE に移植します。
  • ネットワーク構成。クラスタのネットワーク構成、IP アドレスの割り振り、ネットワーク プラグインの構成方法、DNS サーバーと DNS サービス プロバイダの構成方法、これらのクラスタに NAT または SNAT のいずれかの形式を構成しているかどうか、マルチクラスタ環境の一部であるかどうかを評価します。
  • コンプライアンス: クラスタが満たす必要のあるコンプライアンスと規制要件、およびこれらの要件を満たしているかどうかを評価します。
  • 割り当てと上限。クラスタの割り当てと上限の構成方法を評価します。たとえば、各ノードで実行できる Pod の数や、クラスタに設定できるノード数を評価します。
  • ラベルとタグ。クラスタ、ノードプール、ノードに適用したメタデータとその使用方法を評価します。たとえば、ラベルベースの詳細な費用アトリビューションを含むレポートを生成できます。

インベントリで評価する次の項目は、インフラストラクチャと Kubernetes クラスタのセキュリティに重点を置いたものです。

  • Namespace。クラスタで Kubernetes の Namespace を使用してリソースを論理的に分けている場合は、各 Namespace にどのリソースがあるかを評価し、そのように分けている理由を把握します。たとえば、マルチテナンシー戦略の一環で Namespace を使用しているとします。Kubernetes システム コンポーネント用に予約された Namespace にワークロードをデプロイしていて、GKE では十分制御できない場合があります。
  • ロールベース アクセス制御（RBAC）。クラスタで RBAC 認可を使用する場合は、クラスタで構成したすべての ClusterRoles と ClusterRoleBinding の説明をリスト化します。
  • ネットワーク ポリシー。クラスタで構成したすべてのネットワーク ポリシーをリスト化し、GKE でのネットワーク ポリシーの仕組みを理解します。
  • Pod のセキュリティ コンテキスト。クラスタで構成した Pod のセキュリティ コンテキストに関する情報を取得し、GKE でそれらがどのように動作するかを把握します。
  • サービス アカウント。クラスタ内に Kubernetes API サーバーとやり取りするプロセスがある場合は、そのプロセスが使用しているサービス アカウントに関する情報を取得します。

Kubernetes クラスタのインベントリを構築する際に、移行の一環として一部のクラスタを廃止しなければならない場合があります。移行計画には、こうしたリソースの処分が含まれるようにしてください。

Kubernetes ワークロードのインベントリを作成する

Kubernetes クラスタのインベントリを完了し、環境のセキュリティを評価した後、それらのクラスタにデプロイされたワークロードのインベントリを構築します。ワークロードを評価する際は、次の点に関する情報を収集します。

  • Pod とコントローラ。新しい環境でのクラスタのサイズを見積もるには、デプロイしている各ワークロードのインスタンス数を評価します。また、リソース割り当てとコンピューティング リソース消費上限を使用しているかどうかも評価します。各クラスタのコントロール プレーン ノードで実行されているワークロードと各ワークロードが使用しているコントローラに関する情報を収集します。たとえば、使用している Deployment の数や、DaemonSet の数などです。
  • Job と CronJob。クラスタとワークロードは、初期化またはオペレーション手順の一環として Job または CronJob を実行する必要があります。デプロイした Jobと CronJob のインスタンス数、各インスタンスの責任と完了条件を評価します。
  • Kubernetes オートスケーラー。新しい環境に自動スケーリング ポリシーを移行するには、GKE での HorizontalPodAutoscaler と VerticalPodAutoscaler の仕組みをご覧ください。
  • ステートレス ワークロードとステートフル ワークロード。ステートレス ワークロードでは、クラスタや永続ストレージにデータや状態が保存されません。ステートフル アプリケーションでは、後で使用するためにデータを保存します。ステートフル ワークロードの移行はステートレスの移行よりも難しいため、ワークロードごとにコンポーネントがステートレスなのか、それともステートフルなのかを評価します。
  • Kubernetes の機能。クラスタのインベントリから、各クラスタが実行されている Kubernetes のバージョンがわかります。Kubernetes の各バージョンのリリースノートを確認して、Kubernetes の新機能とサポートが終了した機能を把握します。次に、必要な Kubernetes 機能に関係するワークロードを評価します。この作業の目的は、サポートが終了した機能や GKE でまだ使用できない機能を使っていないかどうかを把握することです。使用できない機能が見つかった場合は、GKE で利用可能になったときに非推奨の機能を避けて移行し、新しい機能を採用します。
  • ストレージ。ステートフル ワークロードの場合は、PersistenceVolumeClaims を使用するかどうかを評価します。サイズやアクセスモードなどのストレージ要件と、PersistenceVolumeClaim が PersistenceVolume にどのように対応しているかをリスト化します。将来の増加を考慮して、PersistenceVolumeClaim を拡張する必要があるかどうかを評価します。
  • 構成と Secret の挿入。環境の構成が変更されるたびにデプロイ可能なアーティファクトを再構築することを避けるために、ConfigMap と Secret を使用して Pod に構成と Secret を挿入します。ワークロードごとに、そのワークロードが使用している ConfigMap と Secret、それらのオブジェクトの設定方法を評価します。
  • 依存関係。ワークロードは、おそらく単独では機能せず、クラスタの内部または外部システムからの依存関係を保持していると考えられます。ワークロードごとに依存関係を把握して、ワークロードがそれを利用できない状況を許容できるかどうかを確認します。たとえば、一般的な依存関係には、分散ファイル システム、データベース、Secret 配信プラットフォーム、ID およびアクセス管理システム、サービス ディスカバリのメカニズム、その他の外部システムがあります。
  • Kubernetes Services。ワークロードを内部クライアントと外部クライアントに公開するには、Service を使用します。各 Service について、そのタイプを把握する必要があります。外部に公開されたサービスについては、そのサービスが他のインフラストラクチャとどのように相互作用するかを評価します。たとえば、インフラストラクチャが LoadBalancer サービス、Gateway オブジェクト、Ingress オブジェクトをどのようにサポートしているかや、どの Ingress コントローラをクラスタにデプロイしたかなどです。
  • サービス メッシュ現在の環境でサービス メッシュを使用している場合は、それがどのように構成されているかを評価します。また、メッシュがまたがっているクラスタの数、メッシュを構成するサービス、メッシュのトポロジを変更する方法も把握する必要があります。
  • taint と toleration、およびアフィニティとアンチアフィニティ。各 Pod とノードについて、Kubernetes クラスタでの Pod のスケジューリングをカスタマイズするためにノード taint、Pod の容認、アフィニティを構成したかどうかを評価します。これらのプロパティは、異種のノードまたは Pod の構成の可能性についての分析情報も提供します。Pod やノード、またはその両方を特別な視点と意識をもって評価する必要があることを意味します。たとえば、Kubernetes クラスタ内の特定のノードでのみスケジュールされる特定の Pod セットを構成した場合、それらのノードでのみ使用できる特別なリソースが Pod に必要な可能性があります。
  • 認証: ワークロードがクラスタ内のリソースと外部リソースに対して認証を行う方法を評価します。

サポート サービスと外部依存関係を評価する

クラスタとそのワークロードを評価した後、次のようなインフラストラクチャの他のサポート サービスと側面を評価します。

  • StorageClasses と PersistentVolume。ダイナミック プロビジョニングのための StorageClasses、静的にプロビジョニングされた PersistentVolumes をリスト化することによってインフラストラクチャが PersistentVolumeClaims をどのようにサポートしているかを評価します。PersistentVolume ごとに、容量、ボリューム モード、アクセスモード、クラス、再利用ポリシー、マウント オプション、ノード アフィニティを検討します。
  • VolumeSnapshots と VolumeSnapshotContents。PersistentVolume ごとに、VolumeSnapshot を構成しているかどうか、既存の VolumeSnapshotContent を移行する必要があるかどうかを評価します。
  • Container Storage Interface（CSI）ドライバ。クラスタにデプロイされている場合は、これらのドライバが GKE と互換性があるかどうか、また、GKE と互換性のある CSI ドライバと連携するようにボリュームの構成を調整する必要があるかどうかを評価します。
  • データ ストレージ。PersistentVolume のプロビジョニングが外部システムに依存している場合は、GKE 環境のワークロードがそのシステムを使用できるようにします。外部システムと GKE 環境の間のレイテンシはシステム間の距離に比例するため、データのローカル性はステートフル ワークロードのパフォーマンスに影響を与えます。各外部データ ストレージ システムについて、そのタイプ（ブロック ボリューム、ファイル ストレージ、オブジェクト ストレージなど）と、満たす必要があるパフォーマンスと可用性の要件を検討します。
  • カスタム リソースと Kubernetes アドオン。クラスタにデプロイした可能性のあるカスタム Kubernetes リソースと、Kubernetes アドオンに関する情報を収集します。これらは GKE では動作しないか、これらを変更する必要がある場合があるためです。たとえば、カスタム リソースが外部システムとやり取りする場合は、それが Google Cloud 環境に適用できるかどうかを判断します。
  • バックアップ。移行元の環境でクラスタの構成とステートフル ワークロード データをバックアップする方法を確認します。

デプロイと運用のプロセスを評価する

デプロイ プロセスと運用プロセスの仕組みを明確に理解することが重要です。これらのプロセスは、本番環境とそこで実行されるワークロードを準備して維持するプラクティスの基本となる部分です。

デプロイ プロセスと運用プロセスで、ワークロードが機能するために必要なアーティファクトをビルドする場合があります。したがって、各アーティファクト タイプに関する情報を収集する必要があります。たとえば、アーティファクトには、オペレーティング システム パッケージ、アプリケーションのデプロイ パッケージ、オペレーティング システム イメージ、コンテナ イメージなどがあります。

アーティファクト タイプに加えて、次のタスクの実施方法を検討してください。

  • ワークロードを開発する。ワークロードを構築するために開発チームが実施しているプロセスを評価します。たとえば、開発チームはワークロードの設計、コーディング、テストをどのように行っているのか評価します。
  • 移行元の環境にデプロイするアーティファクトを生成する。移行元の環境にワークロードをデプロイするには、コンテナ イメージやオペレーティング システム イメージなどのデプロイ可能なアーティファクトを生成するか、ソフトウェアをインストールして構成することで、サードパーティのオペレーティング システム イメージなどの既存のアーティファクトをカスタマイズします。これらのアーティファクトの生成方法に関する情報を収集すると、生成されたアーティファクトが Google Cloud へのデプロイに適していることを確認できます。

  • アーティファクトを保存する。移行元環境のアーティファクト レジストリに保存するアーティファクトを生成する場合は、Google Cloud 環境でアーティファクトを利用可能にする必要があります。これは、次のような方法で実行できます。

    • 環境間の通信チャネルを確立する: 移行元の環境のアーティファクトが移行先の Google Cloud 環境からアクセスできるようにします。
    • アーティファクトのビルドプロセスのリファクタリング: 移行元の環境と移行先の環境の両方にアーティファクトを保存できるように、移行元の環境のマイナー リファクタリングを完了します。このアプローチでは、ターゲットの Google Cloud 環境にアーティファクトのビルドプロセスを実装する前に、アーティファクト リポジトリなどのインフラストラクチャを構築することで、移行をサポートします。このアプローチは直接実装することも、最初に通信チャネルを確立する以前のアプローチをベースにして実装することもできます。

    移行元環境と移行先環境の両方でアーティファクトを使用できるため、移行の一部としてターゲットの Google Cloud 環境にアーティファクト ビルド プロセスを実装する必要はありません。

  • コードをスキャンして署名する。アーティファクトのビルドプロセスの一環として、コードスキャンを使用して一般的な脆弱性や意図しないネットワーク公開を防ぐことができます。また、コード署名を使用して、環境で実行されるコードが信頼できるものであることを確認できます。

  • ソース環境にアーティファクトをデプロイする。デプロイ可能なアーティファクトを生成した後、それらを移行元の環境にデプロイしていることがあります。各デプロイ プロセスを評価することをおすすめします。この評価により、デプロイ プロセスに Google Cloud との互換性があるかどうかを確認できます。また、最終的にプロセスをリファクタリングするために必要な作業についても把握できます。たとえば、デプロイ プロセスが移行元の環境で機能する場合は、Google Cloud 環境をターゲットとするようにリファクタリングが必要になることがあります。

  • ランタイム構成を挿入する。特定のクラスタ、ランタイム環境、ワークロード デプロイのランタイム構成を挿入していることがあります。この構成では、環境変数と、シークレット、認証情報、キーなどの構成値が初期化される場合があります。ランタイム構成の挿入プロセスが Google Cloud で機能するように、移行元の環境で実行されるワークロードの構成を評価することをおすすめします。

  • ロギング、モニタリング、プロファイリング。移行元環境の健全性、関心のある指標、これらのプロセスによって提供されるデータの使用方法をモニタリングするために、実装されているロギング、モニタリング、プロファイリングのプロセスを評価します。

  • 認証。移行元の環境に対して認証を行う方法を評価します。

  • リソースのプロビジョニングと構成。移行元の環境を準備するために、リソースをプロビジョニングして構成するプロセスを設計して実装している場合があります。たとえば、Terraform を構成管理ツールとともに使用して、ソース環境でリソースをプロビジョニングして構成している場合があります。

移行元環境のインベントリを作成するツール

Amazon EKS クラスタのインベントリを構築するには、Migration Center を使用することをおすすめします。現在の環境から Google Cloud へのエンドツーエンドのクラウド移行を加速できます。Migration Center を使用すると、Amazon EKS とその他の AWS リソースからデータをインポートできます。Migration Center は、関連性が高い Google Cloud サービスを移行先として推奨します。

Amazon EKS クラスタとワークロードのインベントリを改良する

Migration Center が提供するデータでは、対象項目を完全には取得できない場合があります。その場合、そのデータを、AWS API、AWS デベロッパー ツール、AWS コマンドライン インターフェースに基づいて作成した他のデータ収集メカニズムの結果と統合できます。

Migration Center から取得するデータに加えて、移行する各 Amazon EKS クラスタについて次のデータポイントを考慮します。

  • 各 Amazon EKS クラスタについて、次のような Amazon EKS 固有の特徴と機能を検討します。
    • 限定公開クラスタ
    • クラスタ エンドポイントのアクセス制御
    • シークレットの暗号化
    • マネージド ノードグループとセルフマネージド ノード
    • Amazon EKS リソースのタグ
    • EKS での Amazon カスタム AMI
    • Amazon EKS Fargate の使用
    • Amazon EKS マネージド Prometheus の使用
    • OpenID Connect 認証構成
  • Amazon EKS クラスタに対する認証方法と、Amazon EKS の AWS Identity and Access Management（IAM）の構成方法を評価します。
  • Amazon EKS クラスタのネットワーク構成を評価します。

基盤の計画と構築

計画と構築フェーズでは、インフラストラクチャをプロビジョニングして構成し、以下のことを行います。

  • Google Cloud 環境でワークロードをサポートします。
  • 移行元の環境と Google Cloud 環境を接続して、移行を完了します。

計画と構築のフェーズは、次のタスクで構成されます。

  1. リソース階層を構築する。
  2. Google Cloud の Identity and Access Management（IAM）を構成する。
  3. お支払いとご請求の設定をします。
  4. ネットワーク接続を設定する。
  5. セキュリティを強化する。
  6. ロギング、モニタリング、アラートを設定する。

これらの各タスクの詳細については、Google Cloud への移行: 基盤の計画と構築をご覧ください。

以降のセクションでは、「Google Cloud への移行: 基盤の計画と構築」の考慮事項をまとめています。

マルチテナンシーを計画する

効率的なリソース階層を設計するには、ビジネスと組織構造を Google Cloud にマッピングする方法を検討します。たとえば、GKE でマルチテナント環境が必要な場合は、次の中から選択できます。

  • テナントごとに 1 つの Google Cloud プロジェクトを作成する。
  • 異なるテナント間で 1 つのプロジェクトを共有し、複数の GKE クラスタをプロビジョニングする。
  • Kubernetes の Namespace を使用する。

どの方法を選択するかは、分離、複雑さ、スケーラビリティのニーズによって変わります。たとえば、テナントごとに 1 つのプロジェクトを作成すると、テナントは互いに分離されますが、プロジェクト数が多くなることからリソース階層が複雑になります。ただし、Kubernetes の Namespace の管理は、複雑なリソース階層よりも比較的簡単ですが、この方法では分離が保証されません。たとえば、コントロール プレーンは複数のテナントで共有されます。詳細については、クラスタ マルチテナンシーをご覧ください。

ID およびアクセス管理を構成する

GKE は、RBAC を使用して Google Cloud プロジェクト内のリソースとクラスタ内のリソースへのアクセス権を管理するための複数のオプションをサポートしています。詳細については、アクセス制御をご覧ください。

GKE ネットワーキングを構成する

ネットワーク構成は、環境の基本的な側面です。クラスタをプロビジョニングして構成する前に、GKE ネットワーク モデル、GKE ネットワーキングのベスト プラクティス、GKE への移行時に IP アドレスを計画する方法を評価することをおすすめします。

モニタリングとアラートを設定する

インフラストラクチャとワークロードのパフォーマンスを明確に把握することは、改善点を見つけるうえで重要です。GKE では、Google Cloud Observability との緊密な統合により、GKE クラスタとそのクラスタ内のワークロードに関するロギングとモニタリング情報を取得できます。

データの移行とワークロードのデプロイ

デプロイ フェーズでは、次のことを実施します。

  1. GKE 環境をプロビジョニングして構成する。
  2. GKE クラスタを構成する。
  3. ワークロードをリファクタリングする。
  4. デプロイ プロセスと運用プロセスのリファクタリング。
  5. 移行元の環境から Google Cloud にデータを移行する。
  6. GKE 環境にワークロードをデプロイする。
  7. ワークロードと GKE 環境を検証する。
  8. GKE で実行されているワークロードを公開する。
  9. 移行元の環境から GKE 環境にトラフィックをシフトする。
  10. 移行元の環境を廃止する。

Google Cloud 環境をプロビジョニングして構成する

ワークロードを新しい Google Cloud 環境に移行する前に、GKE クラスタをプロビジョニングします。

GKE は、既存のクラスタで特定の機能を有効にすることをサポートしていますが、クラスタの作成時にのみ有効にできる機能もあります。中断を回避し、移行を簡素化するために、クラスタ作成時に必要なクラスタ機能を有効にすることをおすすめします。クラスタの作成後に必要なクラスタ機能を有効にできない場合は、クラスタを破棄して再作成する必要があります。

評価フェーズが終了し、新しい Google Cloud 環境でニーズに合わせて GKE クラスタをプロビジョニングする方法を理解しています。クラスタをプロビジョニングするには、次の点を考慮してください。

GKE クラスタのプロビジョニングの詳細については、以下をご覧ください。

フリート管理

GKE クラスタをプロビジョニングする際、環境のすべてのユースケースをサポートするために多数のクラスタが必要になる場合があります。たとえば、本番環境と非本番環境の分離や、チームまたは地域間でのサービスの分離が必要になる場合があります。詳細については、マルチクラスタのユースケースをご覧ください。

クラスタの数が増えると、スケーラビリティと運用上の課題が大きくなるため、GKE 環境の運用が困難になる可能性があります。GKE には、Kubernetes クラスタの論理グループであるフリートの管理に役立つツールと機能が用意されています。詳細については、フリート管理をご覧ください。

マルチクラスタ ネットワーク

GKE 環境の信頼性を向上させ、複数の GKE クラスタにワークロードを分散するには、次の方法を使用します。

シングルクラスタ GKE 環境からマルチクラスタ GKE 環境への移行の詳細については、マルチクラスタ ネットワークに移行するをご覧ください。

GKE クラスタを構成する

GKE クラスタをプロビジョニングした後、ワークロードをデプロイするかデータを移行する前に、Namespace、RBAC、ネットワーク ポリシー、サービス アカウント、各 GKE クラスタのその他の Kubernetes オブジェクトと GKE オブジェクトを構成します。

GKE クラスタで Kubernetes オブジェクトと GKE オブジェクトを構成するには、次のことをおすすめします。

  1. 移行元の環境と GKE 環境の両方のクラスタにアクセスするために必要な認証情報と権限があることを確認します。
  2. 移行元環境の Kubernetes クラスタ内のオブジェクトが GKE と互換性があるかどうか、それらのオブジェクトを支える実装が移行元の環境や GKE とどのように異なるかを評価します。
  3. 互換性のないオブジェクトをリファクタリングして GKE と互換性を持たせるか、廃止します。
  4. これらのオブジェクトを GKE クラスタに作成します。
  5. GKE クラスタで必要な追加オブジェクトを構成します。

Config Sync

GKE のスケーリングに合わせて GKE クラスタの構成を管理するために GitOps のベスト プラクティスを採用するには、Config Sync を使用することをおすすめします。これは、信頼できる情報源から構成をデプロイする GitOps サービスです。たとえば、GKE クラスタの構成を Git リポジトリに保存し、Config Sync を使用してその構成を適用できます。

詳細については、Config Sync のアーキテクチャをご覧ください。

Policy Controller

Policy Controller を使用すると、プログラム可能なポリシーを適用することで、GKE クラスタとワークロードが安全かつコンプライアンスを遵守した状態で実行されるようにできます。GKE 環境のスケーリングに伴い、Policy Controller を使用して、すべての GKE クラスタにポリシー、ポリシー バンドル、制約を自動的に適用できます。たとえば、コンテナ イメージを取得するリポジトリを制限したり、各 Namespace に少なくとも 1 つのラベルを要求して、リソース使用量を正確にトラッキングできます。

詳細については、Policy Controller をご覧ください。

ワークロードをリファクタリングする

コンテナ化されたワークロードを設計する際のベスト プラクティスは、コンテナ オーケストレーション プラットフォームへの依存関係を回避することです。ただし、ワークロードの要件や設計によっては、これが常に可能であるとは限りません。たとえば、ワークロードが、アドオン、拡張機能、統合など、移行元の環境でのみ使用可能な環境固有の機能に依存している場合があります。

ほとんどのワークロードはそのまま GKE に移行できますが、環境固有の機能に依存するワークロードはリファクタリングして、これらの依存関係を最小限に抑え、最終的に GKE で利用可能な代替手段に切り替える必要がある場合があります。

ワークロードを GKE に移行する前にリファクタリングするには、次の操作を行います。

  1. アドオン、拡張機能、統合など、移行元の環境に固有の機能を確認します。
  2. 適切な代替 GKE ソリューションを採用します。
  3. ワークロードをリファクタリングする。

移行元の環境に固有の機能を確認する

移行元の環境に固有の機能を使用していて、ワークロードがこれらの機能に依存している場合は、次の操作を行う必要があります。

  1. 適切な代替の GKE ソリューションを見つける。
  2. 代替の GKE ソリューションを利用できるように、ワークロードをリファクタリングする。

この確認作業の一環として、次のことをおすすめします。

  • 移行元の環境に固有の機能のサポートを終了できるかどうかを検討します。
  • 移行を成功させるために、移行元の環境固有の機能の重要性を評価します。

適切な代替 GKE ソリューションを採用する

移行元の環境固有の機能を確認して、適切な GKE 代替ソリューションにマッピングしたら、これらのソリューションを GKE 環境に採用します。移行の複雑さを軽減するために、次のことをおすすめします。

  • 非推奨にする移行元の環境固有の機能に、代替の GKE ソリューションを採用しないでください。
  • 移行元で最も重要なソースに代替の GKE ソリューションを採用することに重点を置き、残りの機能については専用の移行プロジェクトを計画します。

ワークロードをリファクタリングする

ワークロードのほとんどは GKE でそのまま機能する可能性がありますが、一部のワークロードはリファクタリングが必要になる場合があります。特に、代替の GKE ソリューションを採用した移行元の環境固有の機能に依存している場合は、リファクタリングが必要になる可能性があります。

このリファクタリングには、次のような作業が含まれます。

  • YAML 形式で表現された Deployment や Service などの Kubernetes オブジェクト記述子。
  • コンテナ イメージ記述子（Dockerfile や Containerfile など）。
  • ワークロードのソースコード。

リファクタリングの作業を簡素化するため、ワークロードを GKE に適したものにするために必要な最小限の変更と、重大なバグの修正に集中することをおすすめします。その他の改善や変更は、今後のプロジェクトの一環として計画できます。

デプロイ プロセスと運用プロセスをリファクタリングする

ワークロードをリファクタリングしたら、デプロイ プロセスと運用プロセスをリファクタリングして、次のことを行います。

  • 移行元の環境でリソースをプロビジョニングするのではなく、Google Cloud 環境でリソースをプロビジョニングして構成します。
  • ワークロードを構築して構成し、移行元の環境にデプロイするのではなく、Google Cloud にデプロイします。

このプロセスの前の評価フェーズで、これらのプロセスに関する情報を収集しました。

これらのプロセスで検討すべきリファクタリングの種類は、どのように設計し実装したかによって異なります。リファクタリングは、プロセスごとに最終状態をどうするのかによっても異なります。たとえば、次の点を考えます。

  • これらのプロセスを移行元の環境に実装した可能性があり、Google Cloud でも同様のプロセスを設計して実装したい場合もあります。たとえば、Cloud Build、Cloud Deploy、Infrastructure Manager を使用するようにこれらのプロセスをリファクタリングできます。
  • これらのプロセスを移行元の環境外の別のサードパーティ環境に実装している場合もあります。この場合、移行元の環境ではなく Google Cloud 環境を対象とするように、これらのプロセスをリファクタリングする必要があります。
  • 前述のアプローチを組み合わせたケース。

デプロイ プロセスと運用プロセスのリファクタリングは複雑になり、多大な労力が必要になる場合があります。ワークロードの移行の一環としてこれらのタスクを実行すると、ワークロードの移行が複雑になり、リスクが発生する可能性があります。デプロイ プロセスと運用プロセスを評価すると、その設計と複雑さを理解できるはずです。デプロイ プロセスと運用プロセスのリファクタリングに多大な労力が必要になると予想される場合は、これらのプロセスを別の専用プロジェクトの一部としてリファクタリングすることをおすすめします。

Google Cloud でデプロイ プロセスを設計して実装する方法については、以下をご覧ください。

このドキュメントでは、デプロイするアーティファクトを生成し、ターゲット ランタイム環境にデプロイするデプロイ プロセスについて説明します。リファクタリング戦略は、これらのプロセスの複雑さに大きく依存します。次のリストに、一般的なリファクタリング戦略の概要を示します。

  1. Google Cloud にアーティファクト リポジトリをプロビジョニングします。たとえば、Artifact Registry を使用してアーティファクトを保存し、依存関係をビルドできます。
  2. 移行元の環境と Artifact Registry の両方にアーティファクトを保存するように、ビルドプロセスをリファクタリングします。
  3. デプロイ プロセスをリファクタリングして、移行先の Google Cloud 環境にワークロードをデプロイします。たとえば、Artifact Registry に保存されているアーティファクトを使用して、Google Cloud にワークロードの小さなサブセットをデプロイできます。次に、移行するすべてのワークロードが Google Cloud で実行されるまで、Google Cloud にデプロイされるワークロードの数を徐々に増やします。
  4. アーティファクトを Artifact Registry にのみ保存するようにビルドプロセスをリファクタリングします。
  5. 必要に応じて、以前のバージョンのアーティファクトを移行して、移行元環境のリポジトリから Artifact Registry にデプロイします。たとえば、コンテナ イメージを Artifact Registry にコピーできます。
  6. リポジトリが不要になったら、移行元の環境のリポジトリを廃止します。

移行中に予期しない問題が発生した場合のロールバックを容易にするために、Google Cloud への移行中に、Google Cloud の現在のアーティファクト リポジトリと Artifact Registry の両方にコンテナ イメージを保存できます。最後に、移行元の環境の運用停止の一環として、コンテナ イメージのビルドプロセスをリファクタリングして、アーティファクトを Google Cloud にのみ保存できます。

移行の成功に不可欠ではないかもしれませんが、以前のバージョンのアーティファクトを移行元の環境から Google Cloud のアーティファクト リポジトリに移行することが必要になる場合があります。たとえば、ワークロードを任意の時点にロールバックできるようにするには、以前のバージョンのアーティファクトを Artifact Registry に移行する必要があります。詳細については、サードパーティ レジストリからイメージを移行するをご覧ください。

Artifact Registry を使用してアーティファクトを保存する場合は、アクセス制御、データ流出防止、脆弱性スキャン、Binary Authorization など、アーティファクト リポジトリを保護する制御を構成することをおすすめします。詳細については、アクセスを制御してアーティファクトを保護するをご覧ください。

データの移行

GKE は、ブロック ストレージ、RAW ブロック ストレージ、ファイル ストレージ、オブジェクト ストレージなど、いくつかのデータ ストレージ サービスをサポートしています。詳細については、GKE クラスタのストレージの概要をご覧ください。

データを GKE 環境に移行するには、次の操作を行います。

  1. 必要なストレージ インフラストラクチャをすべてプロビジョニングして構成します。
  2. GKE クラスタで StorageClass プロビジョナーを構成します。すべての StorageClass プロビジョナーがすべての環境に対応しているわけではありません。StorageClass プロビジョナーをデプロイする前に、GKE との互換性と依存関係を評価することをおすすめします。
  3. StorageClass を構成します。
  4. 移行するデータを保存する PersistentVolumes と PersistentVolumeClaims を構成します。
  5. 移行元の環境からこれらの PersistentVolume にデータを移行します。このデータ移行の詳細は、移行元の環境の特性によって異なります。

移行元の環境から Google Cloud 環境にデータを移行するには、Google Cloud への移行: 大規模なデータセットを転送するのガイダンスに従ってデータの移行を計画することをおすすめします。

EKS から GKE にデータを移行する

AWS は、Amazon EKS 向けにいくつかのデータ ストレージ オプションを提供しています。このドキュメントでは、次のデータ移行シナリオを中心に説明します。

  • Amazon EBS ボリュームから GKE の PersistentVolume リソースにデータを移行する。
  • Amazon EBS ボリュームから Amazon S3 または Cloud Storage にデータをコピーしてから、GKE の PersistentVolume リソースにデータを移行する。
Amazon EBS ボリュームから GKE PersistentVolume にデータを移行する

Amazon EBS ボリュームから GKE の PersistentVolume リソースにデータを移行するには、次のいずれかの方法を使用します。

  • Amazon EBS ボリュームから Compute Engine 永続ディスクにデータを直接コピーする。
    1. Amazon EC2 インスタンスをプロビジョニングし、移行するデータを含む Amazon EBS ボリュームをアタッチする。
    2. 移行するデータを保存するのに十分な容量がある空の永続ディスクを使用して、Compute Engine インスタンスをプロビジョニングする。
    3. rsync などのデータ同期ツールを実行して、Amazon EBS ボリュームから Compute Engine 永続ディスクにデータをコピーする。
    4. Compute Engine インスタンスから永続ディスクを切断する。
    5. Compute Engine インスタンスを廃止する。
    6. 永続ディスクを GKE PersistentVolume リソースとして構成する。
  • Amazon EC2 インスタンスと Amazon EBS ボリュームを Compute Engine に移行する。
    1. Amazon EC2 インスタンスをプロビジョニングし、移行するデータを含む Amazon EBS ボリュームをアタッチする。
    2. Migrate for Virtual Machines を使用して、Amazon EC2 インスタンスと Amazon EBS ボリュームを Compute Engine に移行する。
    3. Compute Engine インスタンスから永続ディスクを切断する。
    4. Compute Engine インスタンスを廃止する。
    5. 永続ディスクを GKE PersistentVolume リソースとして構成する。

Amazon EC2 インスタンスの Compute Engine への移行の詳細については、AWS から Google Cloud への移行: Amazon EC2 から Compute Engine への移行をご覧ください。

Compute Engine 永続ディスクを GKE PersistentVolume リソースとして使用する方法については、既存の永続ディスクを PersistentVolume として使用するをご覧ください。

Amazon EBS ボリュームから一時メディアにデータをコピーして、GKE PersistentVolume に移行する

Amazon EBS ボリュームから GKE の PersistentVolume リソースに直接移行するのではなく、オブジェクト ストアなどの一時メディアを使用できます。

  1. Amazon EBS ボリュームから Amazon S3 バケットや Cloud Storage バケットなどの一時メディアにデータをアップロードします。
  2. 一時メディアから GKE PersistentVolume リソースにデータをダウンロードします。

特定のシナリオでは、複数のメディアを使用することで、ネットワークとセキュリティ構成に基づいてデータ移転を簡素化できます。たとえば、最初にデータを S3 バケットにアップロードし、次に S3 バケットから Cloud Storage バケットにコピーし、最後に永続ボリュームにデータをダウンロードできます。どのアプローチを選択するかにかかわらず、重要な検討事項を考慮して、スムーズに移行できるように、AWS から Google Cloud への移行: Amazon S3 から Cloud Storage への移行を確認することをおすすめします。

移行方法を選択する

最適な移行オプションは、次の検討事項のような特定のニーズと要件によって異なります。

  • 移行する必要があるデータの量。
    • 移行するデータが少量の場合（データファイルが少ないなど）は、rsync などのツールを使用してデータを Compute Engine 永続ディスクに直接コピーすることを検討してください。このオプションは比較的手早く行えますが、大量のデータには適さない場合があります。
    • 移行するデータが大量にある場合は、Migrate to Virtual Machines を使用してデータを Compute Engine に移行することを検討してください。このオプションは、データを直接コピーするよりも複雑ですが、信頼性とスケーラビリティに優れています。
  • 移行する必要があるデータの種類
  • 移行元の環境と移行先の環境間のネットワーク接続
    • AWS EC2 インスタンスと Compute Engine インスタンスの間で直接接続を確立できない場合は、Amazon S3 または Cloud Storage を使用してデータを一時的に保存し、Compute Engine に移行することをご検討ください。このオプションを使用すると、EC2 インスタンスと Compute Engine インスタンスを同時に実行し続ける必要がないため、費用を抑えられる可能性があります。
  • 移行タイムライン。
    • ネットワーク帯域幅が限られているかデータ量が大きい場合に、タイムラインが厳しくなければ、Transfer Appliance を使用してデータを AWS から Google Cloud へ移行することも検討してください。

どのオプションを選択する場合でも、移行を開始する前に移行をテストすることが重要です。テストにより、潜在的な問題を特定し、移行が正常に完了することを確認できます。

ワークロードをデプロイする

デプロイ プロセスの準備ができたら、ワークロードを GKE にデプロイできます。詳細については、ワークロードのデプロイの概要をご覧ください。

GKE にデプロイするワークロードを準備するには、Kubernetes の記述子を分析することをおすすめします。GKE が自動的にプロビジョニングする Google Cloud リソースの一部は、これらのリソースを手動でプロビジョニングするのではなく、Kubernetes のラベルとアノテーションを使用して構成できます。たとえば、LoadBalancer Service にアノテーションを追加することで、外部ロードバランサの代わりに内部ロードバランサをプロビジョニングできます。

ワークロードを検証する

GKE 環境にワークロードをデプロイした後、それらのワークロードをユーザーに公開する前に、広範な検証とテストを行うことをおすすめします。このテストは、ワークロードが想定どおりに動作していることを確認するのに役立ちます。たとえば、次のようなことが可能です。

  • インテグレーション テスト、負荷テスト、コンプライアンス テスト、信頼性テストなど、さまざまな検証手順を実施し、ワークロードが想定されるパラメータ内で、仕様どおりに動作していることを確認します。
  • Google Cloud Observability のログ、指標、エラーレポートを調べて、潜在的な問題を特定し、傾向を見つけることで問題が発生する前に予測します。

ワークロード検証の詳細については、信頼性のテストをご覧ください。

ワークロードを公開する

GKE 環境で実行されているワークロードの検証テストが完了したら、ワークロードを公開して到達できるようにします。

GKE 環境で実行されているワークロードを公開するには、Kubernetes Service とサービス メッシュを使用します。

GKE で実行されているワークロードの公開の詳細については、以下をご覧ください。

Google Cloud 環境にトラフィックをシフトする

ワークロードが GKE 環境で実行されていることを確認し、ワークロードをクライアントに公開したら、移行元の環境から GKE 環境にトラフィックを移行します。大規模な移行とそれに関連するすべてのリスクを回避するため、移行元の環境から GKE にトラフィックを段階的に移行することをおすすめします。

GKE 環境の設計方法に応じて、トラフィックを移行元の環境から移行先の環境に段階的に移行するロード バランシング メカニズムを実装する方法はいくつかあります。たとえば、GKE 環境に属する IP アドレスへのリクエストのうち、一定の割合を解決するポリシーに従って DNS レコードを解決する DNS 解決ポリシーを実装できます。または、仮想 IP アドレスとネットワーク ロードバランサを使用してロード バランシング メカニズムを実装することもできます。

GKE 環境へのトラフィックの段階的なシフトを開始したら、負荷の増加に伴うワークロードの動作をモニタリングすることをおすすめします。

最後に、カットオーバーを実行します。これは、すべてのトラフィックを移行元の環境から GKE 環境にシフトする際に発生します。

ロード バランシングの詳細については、フロントエンドでのロード バランシングをご覧ください。

移行元の環境を廃止する

GKE 環境のワークロードが正しくリクエストを処理したら、移行元の環境を廃止します。

移行元の環境でリソースの廃止を開始する前に、次のことをおすすめします。

  • 移行元の環境のリソースを復元するために、データをバックアップします。
  • 環境を廃止する前にユーザーに通知します。

移行元の環境を廃止するには、次のようにします。

  1. 移行元の環境のクラスタで実行されているワークロードを廃止します。
  2. 移行元の環境にあるクラスタを削除します。
  3. セキュリティ グループ、ロードバランサ、仮想ネットワークなど、これらのクラスタに関連付けられているリソースを削除します。

孤立したリソースが残らないようにするには、移行元の環境のリソースを廃止する順序が重要です。たとえば、一部のプロバイダでは、ロードバランサの作成を開始する Kubernetes Service を廃止してから、これらのロードバランサを含む仮想ネットワークを廃止する必要があります。

Google Cloud 環境を最適化する

最適化が移行の最終フェーズになります。このフェーズではターゲット環境が最適化の要件を満たすまで最適化タスクを繰り返します。このイテレーションの手順は次のとおりです。

  1. 現在の環境、チーム、最適化ループを評価する。
  2. 最適化の要件と目標を設定する。
  3. 環境とチームを最適化する。
  4. 最適化ループを調整する。

最適化の目標を達成するまで、このシーケンスを繰り返します。

Google Cloud 環境の最適化の詳細については、Google Cloud への移行: 環境の最適化とパフォーマンスの最適化プロセスをご覧ください。

以降のセクションでは、「Google Cloud への移行: 環境を最適化する」の考慮事項を統合しています。

最適化の要件を確立する

最適化要件は、現在の最適化イテレーションの範囲を絞り込むのに役立ちます。最適化の要件と目標の詳細については、最適化の要件と目標を設定するをご覧ください。

GKE 環境の最適化要件を確立するには、まず次の点を考慮します。

  • セキュリティ、プライバシー、コンプライアンス: GKE 環境のセキュリティ ポスチャーを強化します。
  • 信頼性: GKE 環境の可用性、スケーラビリティ、復元性を向上させます。
  • 費用の最適化: GKE 環境のリソース使用量とそれに伴う費用を最適化します。
  • 運用効率: GKE 環境を効率的に維持、運用できるようにします。
  • パフォーマンスの最適化: GKE 環境にデプロイされたワークロードのパフォーマンスを最適化します。

セキュリティ、プライバシー、コンプライアンス

信頼性

  • クラスタの信頼性を向上させる。ゾーンの停止が起こりにくい GKE を設計するには、ゾーンクラスタやマルチゾーン クラスタではなく、リージョン クラスタを使用することをおすすめします。
  • ワークロードのバックアップと復元。Backup for GKE を使用してワークロードのバックアップと復元のワークフローを構成します。

費用の最適化

GKE 環境のコストを最適化する方法については、以下をご覧ください。

運用効率

本番環境に影響する問題を回避するために、次のことをおすすめします。

  • GKE クラスタを代替可能にするように設計する。クラスタを代替可能と見なし、クラスタのプロビジョニングと構成を自動化することで、運用プロセスを合理化および一般化し、その後の移行と GKE クラスタのアップグレードを整備して簡素化できます。たとえば、代替可能な GKE クラスタを新しい GKE バージョンにアップグレードする必要がある場合は、アップグレードされた新しいクラスタを自動的にプロビジョニングして構成し、新しいクラスタにワークロードを自動的にデプロイし、古い、旧式の GKE クラスタを廃止できます。
  • 関心のある指標をモニタリングする。ワークロードとクラスタに関する重要な指標がすべて適切に収集されていることを確認します。また、これらの指標を入力として使用する関連アラートがすべて設定され、機能していることを確認します。

GKE 環境でモニタリング、ロギング、プロファイリングを構成する方法については、以下をご覧ください。

パフォーマンスの最適化

  • クラスタの自動スケーリングとノードの自動プロビジョニングを設定する。クラスタの自動スケーリングとノードの自動プロビジョニングを使用して、需要に応じて GKE クラスタのサイズを自動的に変更します。
  • ワークロードを自動的にスケーリングする。GKE は、次のようないくつかのスケーリング メカニズムをサポートしています。

詳細については、GKE のスケーラビリティについてをご覧ください。

次のステップ

寄稿者

著者:

  • Marco Ferrari | クラウド ソリューション アーキテクト
  • Xiang Shen | ソリューション アーキテクト