GKE への移行の流れ

このトピックでは、ワークロードを GKE に移行する際に推奨する一連の手順について説明します。

簡単に流れを説明すると、まず検出フェーズと評価フェーズを実施します。ここでは、どのようなワークロードが存在し、ワークロード間にどのような依存関係があるのかを把握します。また、ワークロードがクラウドに移行可能かどうか判断する必要があります。

次に移行計画フェーズに進みます。評価フェーズの結果に基づいて、ワークロードを分割して一緒に移行するグループにまとめます。さらに、グループの移行順序を決めます。

また、GKE に移行する必要があるワークロードと、GKE には適さないが Migrate for Compute Engine で Compute Engine に移行できるワークロードを特定します。GKE に適している場合でも、ワークロードの移行を次の 2 段階で行ったほうが良い場合もあります。

  1. Migrate for Compute Engine を使用して、ワークロードを Compute Engine に移行する。
  2. Migrate for Anthos を使用して Compute Engine から GKE に移行する。

この方法は、データセンターの移行を行うときに、すべてのワークロードを Compute Engine に移行し、適切なワークロードのみを GKE に移行したい場合に適しています。次の図のように、特定のワークロードのパスを選択したら、ランディング ゾーンの設定を行い、最適化フェーズを実施する必要があります。

Migrate for Anthos を使用して VM またはコンテナに移行する手順。

検出

アプリケーションとその依存関係を把握し、移行に必要な情報を収集します。たとえば、次のような情報を収集します。

  • ワークロードを移行する VM。
  • アプリケーションで必要なネットワーク ポートと接続
  • アプリ階層間の依存関係
  • サービス名の解決または DNS 構成

ロール

  • アプリケーションのトポロジと移行について知識のある IT アナリスト

移行計画

アプリケーションを複数のバッチに分け、検出フェーズで収集した情報を Kubernetes モデルに変換します。アプリケーション環境、トポロジ、名前空間、ポリシーを Kubernetes YAML 構成ファイルに記述します。サンプルの YAML ファイルを利用できます

ロール

  • アプリケーション移行エンジニアまたはアナリスト。このロールには、Kubernetes マネージド オブジェクト モデル、GKE デプロイメント、YAML ファイルについて初心者レベルの知識が求められます。

ランディング ゾーンの設定

このステップでは、以下の作業を行います。

  • 移行したワークロードをホストする GKE クラスタを作成または指定します。
  • アプリケーションの VPC ネットワーク ルールと Kubernetes ネットワーク ポリシーを作成します。
  • Kubernetes サービス定義を適用します。
  • 負荷分散について選択を行います。
  • DNS を構成します。

ロール

  • クラスタのデプロイメント、Google Cloud ネットワーキング、ファイアウォール ルール、Cloud Identity and Access Management のサービス アカウントとロール、Google Cloud Marketplace からのデプロイメントの開始などに精通した GKE クラスタ管理者

GKE への移行と検証

GKE クラスタ、VPC ネットワーク、Migrate for Anthos コンポーネントでワークロードを処理する準備ができたら、移行するソース VM ごとに Migrate for Anthos の移行ワークフローを開始できます。ガイドラインに従って、Migrate for Anthos に対する移行元のワークロードとオペレーティング システムの互換性を確認してください。次の図に移行ワークフロー示します。

設定と移行手順の概要を示す図

移行ワークフローには次の 5 つのステップがあります。

  1. 移行プランを生成して確認する - Migrate for Anthos migctl CLI(Linux ワークロードの場合)または移行スクリプト(Windows ワークロードの場合)を使用して、移行プランを生成し、アプリケーション オーナー、セキュリティ管理者、ストレージ管理者などの主要な関係者からのフィードバックを計画に反映します。
  2. アーティファクトを生成する - CLI への入力として移行計画を使用して、ソース VM を処理し、関連するアーティファクトを生成します。
    • Linux ワークロードの場合 - コンテナ イメージ、Dockerfile、リファレンス デプロイ YAML。ステートフル ワークロードに指定されている場合はデータ ボリュームも生成します。
    • Windows ワークロードの場合 - ZIP アーカイブに抽出されたアプリケーション ファイル、Dockerfile。注: 次のステップに進む前に、Dockerfile と抽出されたコンテンツを使用してコンテナ イメージをビルドする必要があります。
  3. テストを行う - テスト、ステージングまたは本番環境のクラスタでアプリケーション レベルの詳細な検証を行う前に、コンテナで実行されたときに、抽出したコンテナ イメージとデータ ボリューム(必要な場合)が正しく機能していることを確認します。処理クラスタでサニティテストを実施し、移行計画の問題を特定して必要な編集を行い、ステップ 2 を繰り返してもう一度テストを行います。
  4. データを同期する - ステートフル ワークロードの移行中(Linux のみ)にワークロードがソースでの実行時に新しいデータと状態の累積を継続している場合は、ソースのシャットダウンを伴う最終的なデータ同期を行う前にデータ同期サイクルを繰り返し行うことができます。これにより、ダウンタイムを短縮できます。それぞれのデータ同期では、最後のデータ同期サイクル以降に変更されたデータのみが転送されます。
  5. CI/CD でデプロイまたは統合する - コンテナ アーティファクトの準備と検証が完了したら、テスト、ステージング、本番環境のクラスタにデプロイを行います。また、Cloud Build などのオーケストレーション ツールを使用すると、アーティファクトをビルドとデプロイのパイプラインに統合できます。

ロール

  • ワークロードを移行する場合:
    • Kubernetes マネージド オブジェクト モデル、GKE デプロイメント、YAML の編集について初級レベルの知識があるアプリケーション オーナーまたはアプリケーション移行アナリスト
  • 省略可: GCP PD 以外の永続ボリュームにデータ ストレージを移行する場合:
    • GKE での Kubernetes 永続ボリュームの管理に精通したストレージ管理者または GKE 管理者

運用と最適化

これで Anthos のツールとより大きな Kubernetes エコシステムを利用できるようになりました。このステップでは、アクセス ポリシーの追加、Istio による暗号化と認証、Cloud Logging と Cloud Monitoring によるモニタリングとロギングを行います。構成の変更は行いますが、アプリケーションのビルドをやり直す必要はありません。Cloud Build などのツールを使用して CI/CD パイプラインと統合し、ソフトウェア パッケージやバージョンのアップデートなど、Day 2 メンテナンス手順を実装することもできます。