GKE または Anthos への移行の流れ

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

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

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

また、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 に移行するときに、第 2 段階で適切なワークロードを選択して GKE に合わせてモダナイズする場合に、この方法を使用します。図に示すように、特定のワークロードに目的のパスを選択したら、ランディング ゾーンの設定の移行を行い、必要に応じて移行後の最適化フェーズを行う必要があります。

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

検出

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

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

Migrate for Anthos には、コンテナに移行する VM ワークロードの適合性を判定するツールが用意されています。詳しくは、次をご覧ください。

ロール

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

移行計画

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

ロール

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

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

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

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

役割

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

移行と検証

クラスタ、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 パイプラインと統合し、ソフトウェア パッケージやバージョンのアップデートなど、2 日目のメンテナンス手順を実装することもできます。