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 を導入すると、以下の広範なサービスにアクセスできるようになります。

  • マルチクラスタ管理。お客様とお客様の組織が、クラウド環境とオンプレミス環境の両方にわたり、クラスタ、インフラストラクチャ、ワークロードを 1 か所で管理できます。
  • Config Sync と Policy Controller。インフラストラクチャ全体に共通する構成とポリシーを作成し、オンプレミスとクラウドの両方で適用できます。
  • Anthos Service Mesh。サービス運用、トラフィック管理、テレメトリー、サービス間の通信保護を簡素化するフルマネージドのサービス メッシュを導入できます。
  • Binary Authorization。信頼できるコンテナだけが環境にデプロイされるようにすることができます。
  • Cloud Run for Anthos。GKE Enterprise 環境でサーバーレス ワークロードをサポートできます。

移行プロセスの早い段階で、まだ移行を設計しているときに上記のサービスを評価することをおすすめします。この段階で評価するとサービスを導入しやすくなり、プロセスとインフラストラクチャを後で変更する必要がなくなります。これらのサービスの使用は、すぐに開始することも、ワークロードをモダナイズする準備ができた時点で開始することもできます。

ここで説明する移行では、Google Cloud への移行: スタートガイドで定義されている移行フレームワークに従います。このフレームワークには次の 4 つのフェーズがあります。

  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 がパブリック クラウド環境にデプロイされている場合、パブリック クラウド プロバイダが提供する Infrastructure as a Service（IaaS）サービスについては、このチームが担当します。

さまざまな環境を対象とした専用の OpenShift クラスタがあるかどうかを評価することも重要です。たとえば、開発、品質保証、本番のそれぞれに使用する環境を分けている場合や、ネットワークとセキュリティのゾーンを分離している場合（内部ゾーンと非武装地帯など）もあります。

OpenShift プロジェクト

OpenShift プロジェクトは、アノテーションが追加された Kubernetes Namespace です。デベロッパーはこれらのアノテーションを使用して他のチームから隔離された状態でリソースを管理し、リソースを論理的に分離できます。OpenShift プロジェクトのインベントリを作成するには、それぞれのプロジェクトについて、次の点を考慮してください。

  • クラスタロールとローカルロール。OpenShift は、OpenShift プロジェクトにローカルなロールと、クラスタ全体のロールの両方をサポートしています。移行先の環境で有効なアクセス制御メカニズムを設計するためのクラスタロールとローカルロールが作成されているかどうかを評価します。
  • クラスタロールとローカルロールの両方のロール バインディング。ユーザーとグループに OpenShift プロジェクトでオペレーションを実行する権限を付与する方法は、ロール バインディングを割り当てることです。ロールはクラスタレベルでもローカルレベルでもかまいません。多くの場合、ローカルのロール バインディングはクラスタの事前定義ロールにバインドされます。たとえば、デフォルトの OpenShift プロジェクト管理者ロール バインディングは、デフォルトのクラスタ管理者ロールにバインドされている場合があります。
  • ResourceQuota。リソースの合計使用量を制限するために、OpenShift では OpenShift プロジェクト レベルの割り当てと複数の OpenShift プロジェクト全体の割り当ての両方を定義できるようになっています。これらの割り当てが Kubernetes ResourceQuota にどのようにマッピングするかを評価し、OpenShift 環境でプロビジョニングして構成したすべての ResourceQuota を網羅したリストを作成します。

環境の評価で、ServiceAccount や PersistentVolume などの Kubernetes リソースを評価する方法について説明しています。

ビルドとデプロイのプロセス

サービス提供およびプラットフォーム管理モデルに関する情報と、OpenShift プロジェクトに関する情報を収集したら、どのようにワークロードをビルドして環境にデプロイしているかを評価します。

既存の OpenShift 環境では、すべてのワークロードに共通のビルドとデプロイのプロセスが使用されている場合もあれば、複数の異なるプロセスを評価しなければならない場合もあります。コンテナ化されるワークロードのビルドプロセスのアーティファクトは、コンテナ イメージです。OpenShift 環境では、コンテナ イメージをさまざまな方法でビルド、保存、デプロイできます。

  • コンテナ イメージのビルドプロセスを完全に OpenShift 外部で実行します。ビルドプロセスは、手動ステップに基づく場合があります。また、コンテナ イメージと Kubernetes マニフェストを最終プロダクトとする、自動化された継続的インテグレーション / 継続的デプロイ（CI / CD）パイプラインに基づく場合もあります。
  • コンテナ イメージのビルドプロセスを OpenShift 内で実行します。OpenShift は、さまざまなビルド オプションをサポートしています。具体的には、Dockerfile とコンテナ イメージのビルドに必要なすべてのアーティファクトを提供するオプション、Source-to-Image ビルドを構成するオプション、パイプラインによるビルドを構成するオプション、カスタムビルドを構成するオプションなどです。これらのビルド戦略では、ビルドの選択、ソース アーティファクトの場所、ターゲット コンテナ イメージ、コンテナ イメージのビルドプロセスをトリガーできるイベントを定義する、BuildConfig リソースを作成します。

各コンテナ イメージをビルドしたら、後でデプロイできるようにイメージを Container Registry に保存します。Container Registry は、OpenShift 上でも OpenShift 環境の外部でもホストできます。移行先の環境で同様のシステムが必要になる場合があるため、この点を評価します。

ワークロード、要件、依存関係

各 OpenShift アプリケーションには、次のコンポーネントが含まれています。

  • OpenShift DeploymentConfig または Kubernetes Deployment オブジェクト。これらのオブジェクトの違いについては、Deployment と DeploymentConfig の比較をご覧ください。
  • クライアントがアプリケーションに到達できるようにするための Kubernetes Service と、クラスタの外部からその Kubernetes Service に接続するための OpenShift Route。
  • コンテナ イメージの参照を抽象化する OpenShift ImageStream。OpenShift ImageStream は 1 つ以上のコンテナ イメージを含み、各コンテナ イメージはタグによって一意に識別され、関連イメージの単一の抽象ビューを表します。これは、コンテナ イメージ リポジトリに似ています。
  • 該当する OpenShift アプリケーションのコンテナ イメージを OpenShift 内でビルドするための OpenShift BuildConfig。

アプリケーションの目的に応じて、Deployment オブジェクトや DeploymentConfig オブジェクトを使用する代わりに、以下のさまざまなオブジェクトを使用してアプリを定義できます。

  • Job または cron ジョブを使用してバッチ アプリケーションを定義する。
  • StatefulSet を使用してステートフル アプリケーションを定義する。
  • すべてのノードで実行する必要があるか、特定のノードにバインドする必要があるオペレーション関連のワークロードがある場合は、DaemonSet を使用してワークロードを定義する。

次の表に、アプリケーションを移行先の GKE Enterprise 環境に移行するために OpenShift リソースから収集する最も重要な仕様とパラメータを示します。

移行元 OpenShift のリソース マニフェスト 最も重要な仕様とパラメータ
Deployment、DeploymentConfig、StatefulSet、Job、cron ジョブ コンテナ イメージとリポジトリ、コンテナポート、Pod レプリカの数、ConfigMap、Secret、PersistentVolumeClaim、リソース リクエストの量と上限、更新戦略、StatefulSet サービス名、cron ジョブ スケジュール
ImageStream コンテナ イメージ、イメージの pull ポリシー、コンテナ イメージ リポジトリ
水平 Pod オートスケーラー 自動スケーリング基準
Service クラスタ内部からアプリケーションに接続するために使用されるホスト名、Service が公開されている IP アドレスとポート、外部リソース用に作成されたエンドポイント
ルート クラスタ外部からアプリケーションに接続するために使用されるホスト名とリソースパス、ルーティング ルール、暗号化、証明書チェーン情報

環境の評価で、次のような Kubernetes リソースを評価する方法について説明しています。

OpenShift 4 で Operator Framework が導入されました。この OpenShift バージョンを使用している場合は、インストール済みの Operator を使用して一部のアプリケーションをデプロイしている可能性があります。この場合、インストールされている Operator のリストを取得して、Operator ごとのデプロイ済み Operator インスタンスに関する情報を収集します。これらのインスタンスは Operator で定義されたカスタム リソースであり、上述の Kubernetes リソースのいくつかをデプロイします。

これらのリソースを評価するだけでなく、次の点についても評価します。

  • アプリケーションのネットワーク接続要件。たとえば、Service または Pod を特定のネットワークに公開する必要があるかどうか、Service または Pod が特定のバックエンド システムにアクセスする必要があるかどうかなど。
  • 特定の場所でワークロードを実行しなければならない制約。たとえば、他のワークロードと通信する際のレイテンシ、データの場所に関するポリシー、ユーザーへの近接性などの要件を満たすために、オンプレミスに維持する必要があるワークロードやデータセットがあるかどうかなど。

OpenShift クラスタの構成

次に、OpenShift クラスタを評価します。このタスクを行うには、次の情報を収集します。

  • OpenShift のバージョン。このドキュメントで扱う OpenShift のメジャー バージョンは、OpenShift 3 と OpenShift 4 です。バージョンによって、OpenShift の機能が異なる場合があります。OpenShift のバージョン固有の機能を使用しているかどうかを確認するには、実行している OpenShift のバージョンを確認します。
  • 認証に使用されている ID プロバイダ。認証には、組み込み OAuth サーバーと 1 つ以上の ID プロバイダが使用されている可能性があります。
  • セキュリティ コンテキストの制約。クラスタで定義した OpenShift のセキュリティ コンテキストの制約と、それらの構成、それらの制約が割り当てられているユーザー、グループ、サービス アカウントを評価します。
  • ネットワーク ポリシーと分離。NetworkPolicy と、どのように Pod ネットワーク分離が構成されているか、どの OpenShift SDN モードがクラスタで構成されているかを評価します。

  • Monitoring。移行先の環境でのモニタリング ソリューションを設計して実装する方法を決定するために、現在のモニタリング要件と、現在のモニタリング システムがどのようにプロビジョニングされて構成されているかを評価します。この評価を参考に、新しいモニタリング ソリューションを使用するか、既存のソリューションを引き続き使用できるかを判断できます。OpenShift の多くのバージョンには、システム コンポーネントをモニタリングするために、Prometheus に基づくモニタリング スタックが組み込まれています。アプリケーションのモニタリングにも、このスタックを使用できます。ターゲット ソリューションを設計する際は、次の点を考慮してください。

    • OpenShift 環境で現在使用しているモニタリング ソリューション（OpenShift でホストされている Prometheus、独立した Prometheus-Grafana スタック、Zabbix、InfluxData、Nagios など）。
    • 指標がどのように生成されて収集されているか（pull または push メカニズムなど）。
    • OpenShift クラスタにデプロイされているコンポーネントに依存するもの。
    • モニタリング システムの場所（クラウド環境にデプロイされているのか、それともオンプレミスにデプロイされているのかなど）。
    • ワークロードに関して現在収集している指標。
    • 現在のモニタリング システムに構成した、指標に基づくアラート。

  • Logging。移行先の環境でのロギング ソリューションを設計して実装する方法を決定するために、現在のロギング要件と、現在のロギング システムがどのようにプロビジョニングされて構成されているかを評価します。この評価を参考に、新しいロギング ソリューションを使用するか、既存のソリューションを引き続き使用できるかを判断できます。OpenShift の多くのバージョンには、システム コンポーネントからログを収集するために使用される Elasticsearch、Fluentd、Kibana（EFK）スタックに基づくロギング ソリューションが同梱されています。アプリケーションのロギングにも、このソリューションを使用できます。ターゲット ソリューションを設計する際は、次の点を考慮してください。

    • OpenShift 環境で現在使用しているロギング ソリューション（OpenShift でホストされている EFK スタック、独立した EFK スタック、Splunk など）。
    • OpenShift クラスタにデプロイされているコンポーネントに依存するもの。
    • アーキテクチャと、ログ ストレージ コンポーネントの容量。
    • ロギング システムの場所（クラウド環境にデプロイされているのか、それともオンプレミスにデプロイされているのかなど）。
    • ログの保持ポリシーと構成。

環境の評価で、次の評価方法を説明しています。

  • クラスタの数
  • クラスタあたりのノードの数とタイプ
  • ロギング、モニタリング、トレースに関するその他の考慮事項
  • カスタムの Kubernetes リソース

評価を完了する

OpenShift のプロセスとワークロードに関連するインベントリを作成したら、Google Cloud への移行: ワークロードの評価と調査で説明している評価フェーズの残りの作業を実施します。

基盤の計画と構築

この計画と構築のフェーズでは、次の作業を行って、ワークロードをサポートするインフラストラクチャとサービスをプロビジョニングして構成します。

  1. リソース階層を構築する。
  2. Identity and Access Management を構成する。
  3. お支払い情報を設定する。
  4. ネットワーク接続を設定する。
  5. セキュリティを強化する。
  6. モニタリングとアラートを設定する。

このセクションでは、Google Cloud への移行: 基盤の構築で提供されている情報に基づき、GKE Enterprise で基盤を構築する場合に固有の情報を提供します。

Google Cloud 内に基盤を構築する前に GKE Enterprise の技術概要を確認して、GKE Enterprise の仕組みと必要になる可能性がある GKE Enterprise コンポーネントを理解してください。評価フェーズで収集したワークロードとデータの局所性の要件に応じて、ワークロードを GKE on VMware、Google Cloud 上の GKE クラスタ、または GKE on AWS にデプロイします。複数のクラスタをさまざまな環境に分散させることができます。Google Cloud 上に GKE の基盤を構築する方法については、基盤の計画と構築をご覧ください。

GKE on VMware の基盤を構築するには、そのコアコンセプトを読んでから、次の点を考慮して GKE on VMware のインストールを検討してください。

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 クラスタ、GKE on VMware クラスタ、または GKE on AWS クラスタをプロビジョニングできます。たとえば、オンプレミスにデプロイする必要があるワークロードが存在する場合は、1 つ以上の GKE on VMware クラスタをプロビジョニングします。ワークロードに場所に関する要件がない場合は、Google Cloud 上で GKE クラスタをプロビジョニングします。どちらの場合も、GKE Enterprise を使用してクラスタの管理とモニタリングを行います。マルチクラウドの要件がある場合は、他の GKE Enterprise クラスタとともに GKE on AWS クラスタをプロビジョニングします。

まず、必要な GKE Enterprise クラスタの数とタイプを定義します。これらの要件は、実装する必要があるサービスモデルや、各環境を隔離する方法など、評価フェーズで収集した情報に大きく依存します。現在、複数の開発チームが OpenShift クラスタを共有している場合は、GKE Enterprise 上で次のようにしてマルチテナンシー モデルを実装する必要があります。

  • 複数の異なる Kubernetes Namespace を使用します。プラットフォーム チームが OpenShift プロジェクトごとに Kubernetes Namespace を作成し、クラスタ マルチテナンシー モデルを実装します。このモデルは、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 プロジェクトとクラスタの評価フェーズで収集した要件を満たすために次のコンポーネントを構成します。

  • Identity and Access Management。Identity and Access Management を構成するの説明に従って、Identity and Access Management を構成できます。Cloud Identity に移行してメインの ID プロバイダとして使用できます。あるいは、Google Cloud Directory Sync を使用して、Cloud Identity を既存の LDAP サーバーまたは Active Directory サーバーと同期することもできます。GKE on VMware では、コマンドラインを使用してユーザー クラスタに対する認証を行えるよう、OpenID Connect（OIDC）をサポートしています。OIDC と Google による認証に従って、コマンドラインを使用した認証を Cloud Identity に統合します。
  • Monitoring。制約と要件に応じて、現在のモニタリング ソリューションを移行先の GKE Enterprise 環境に適応させることができます。現在のソリューションが OpenShift でホストされている場合は、基盤の構築で説明されているように、Cloud Monitoring を実装できます。または、GKE on VMware で Prometheus と Grafana を実装できます。
  • Logging。制約と要件に応じて、現在のロギング ソリューションを移行先の GKE Enterprise 環境に適応させることができます。現在のソリューションが OpenShift でホストされている場合は、基盤の構築: モニタリングとアラートに沿って Cloud Logging を実装できます。

Config Sync を使用すると、Git 準拠の共有リポジトリ内に次のリソースの構成を一元的に定義して、オンプレミスとクラウドの両方ですべてのクラスタにその構成を適用できます。

Config Sync をインストールするには、Config Sync をインストールするをご覧ください。Policy Controller をインストールするには、Policy Controller をインストールするをご覧ください。

古い環境からデータを移行する

移行元の環境から移行先の環境にデータを移行する準備が整いました。

OpenShift ステートフル アプリケーションが Kubernetes 永続ボリュームでデータをホストしている場合、移行先の環境にデータを移行する以下のさまざまな戦略があります。どの戦略が適切であるかは、移行元と移行先のバックエンド ストレージ プロバイダやデプロイ先ロケーションなどの各種の要因に依存します。

  • ストレージ プロバイダが提供するボリュームのクローン作成機能、エクスポート機能、インポート機能を使用します。オンプレミス環境で VMware vSphere ボリュームを使用している場合、GKE on VMware に移行するには、VMDK 仮想ディスクの基盤となる PersistentVolume のクローンを作成し、それらのクローンを移行先の環境でボリュームとしてマウントします。GKE に移行する場合は、仮想ディスクを Compute Engine の永続ディスクとしてインポートし、永続ボリュームとして使用します。
  • オペレーティング システム ツールまたはデータベース ツールを使用して、移行元の環境からデータをバックアップします。両方の環境からアクセスできる一時的な場所でデータをホストしたうえで、移行先の環境でデータを復元します。
  • rsync などのリモート コピーツールを使用して、移行元の環境から移行先の環境にデータをコピーします。
  • restic を統合した Velero などのストレージに依存しないバックアップ ソリューションを使用します。

詳細については、Google Cloud への移行: 大規模なデータセットの転送をご覧ください。

GKE でのデータ移行とストレージ管理戦略について詳しくは、古い環境から新しい環境にデータを移行すると、ストレージ構成に関する GKE ドキュメントをご覧ください。

GKE on VMware では、VMware vSphere ストレージ、Kubernetes のツリー内ボリューム プラグイン、Container Storage Interface（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 環境でのデプロイ方法を使用するワークロードを、Operator を使用してデプロイする必要がある場合は、ワークロードをデプロイする前に Operator をインストールする必要があります。必要な Operator の可用性は、次のソースで確認できます。

手動でデプロイする

OpenShift 環境に手動でワークロードをデプロイしている場合、その手動デプロイ プロセスを新しい GKE Enterprise 環境に適応させることができます。たとえば、ワークロード、要件、依存関係で評価した OpenShift リソース マニフェストを、対応する GKE Enterprise リソース マニフェストに手動で変換できます。

次の表は、このドキュメントのワークロード、要件、依存関係セクションで記載した表を拡張し、これらを使用できるターゲットの GKE Enterprise リソースに関する情報を追加したものです。

移行元 OpenShift のリソース マニフェスト 最も重要な仕様とパラメータ ターゲット GKE Enterprise のリソース マニフェスト
Deployment、DeploymentConfig、StatefulSet、Job、cron ジョブ コンテナ イメージとリポジトリ、コンテナポート、Pod レプリカの数、ConfigMap、Secret、PersistentVolumeClaim、リソース リクエストと制限、更新戦略、StatefulSet サービス名、cron ジョブ スケジュール Deployment、StatefulSet、Job、cron ジョブ
ImageStream コンテナ イメージ、イメージの pull ポリシー、コンテナ イメージ リポジトリ Deployment
水平 Pod オートスケーラー 自動スケーリング基準 水平 Pod オートスケーラー
Service クラスタ内部からアプリケーションに接続するために使用されるホスト名、Service が公開されている IP アドレスとポート、外部リソース用に作成されたエンドポイント Service
ルート クラスタ外部からアプリケーションに接続するために使用されるホスト名とリソースパス、ルーティング ルール Ingress

自動デプロイ プロセスを設計して実装する

ワークロードを自動的にビルドしてデプロイするには、ビルドとデプロイのプロセスを設計して実装するか、既存のプロセスを新しい環境をサポートするように適応させます。ワークロードをハイブリッド環境にデプロイする必要がある場合は、デプロイ プロセスで Google Cloud 上の GKE と GKE on VMware の両方をサポートする必要があります。

ビルドとデプロイのプロセスを実装するには、Cloud Build を使用できます。ビルドとデプロイのプロセスを自動化する場合は、ビルドトリガーまたは GitHub アプリトリガーを構成するか、Google Cloud コンソールを使用して自動デプロイを設定します。ポリシー コントローラの制約を使用している場合は、Kubernetes と GKE Enterprise の記述子を Cloud Build ジョブのポリシーと照合して、デベロッパーにフィードバックを提供できます。

オンプレミスでビルドジョブを実行するか、ソースコードを保存する必要がある場合は、GitLab を使用します。GitLab は、ソースコード リポジトリ、コラボレーション プラットフォーム、CI / CD 機能、コンテナ イメージ レジストリを提供します。Cloud Marketplace から直接 GKE Enterprise クラスタに GitLab をデプロイできます。または、他の利用可能なインストール オプションのいずれかを使用して GitLab をインストールすることもできます。

現在、OpenShift のいずれかの機能を使用してワークロードのビルドまたは自動デプロイを行っている場合は、現在のプロセスに応じて、次のいずれかの戦略を採用できます。

  • Jenkins パイプライン。Jenkins パイプラインを使用してビルドとデプロイのプロセスを自動化している場合、そのパイプラインを Cloud Build に移植するか、既存の Jenkins 環境を使用できます。または、Google Cloud 内に Jenkins をデプロイすることもできます。
  • Dockerfile と必要なアーティファクトを使用したビルドとデプロイ。Cloud Build では、Dockerfile またはビルド構成ファイルを使用してコンテナ イメージをビルドできます。オンプレミス クラスタでビルドを実行する場合は、GitLab を使用できます。
  • Source-to-Image ビルド。Cloud Build では、生成されたコンテナ イメージに必要となるアーティファクトを作成するための準備ステップを実装する必要があります。Source-to-Image ジョブで Python アプリをビルドしてコンテナ イメージを生成する場合は、Python アプリをビルドしてからコンテナ イメージをビルドするカスタム ビルドステップを構成する必要があります。この方法を使用する場合は、Dockerfile も提供する必要があります。あるいは、Dockerfile を提供する代わりに、Java アプリケーション用の Google Cloud の Buildpack または Jib を使用することもできます。
  • カスタムビルド。現在 OpenShift で行っているようにカスタム Cloud Build ビルダーを作成できます。既存のカスタム ビルダーが OpenShift 固有の機能を使用していなければ、Cloud Build でそのまま使用できます。

どの方法でビルドするかを問わず、生成されたコンテナ イメージはコンテナ イメージ リポジトリに保存する必要があります。それには次のオプションがあります。

コンテナ イメージを保存する手段にかかわらず、クラスタがコンテナ イメージ リポジトリにアクセスするための認証情報をプロビジョニングして構成する必要があります。

ビルドのステータスとコンテナ イメージに関する通知をユーザーやサードパーティ サービスに送信する必要がある場合、Cloud Functions を使用して、Cloud Build と Container Registry で発生したイベントに応答できます。

OpenShift から GKE Enterprise への機能マッピングの概要

次の表は、OpenShift で使用していた機能に GKE Enterprise の機能をマッピングする方法をまとめたものです。

OpenShift GKE Enterprise
OpenShift プロジェクト
  • Config Sync によって一元管理される Kubernetes Namespace
  • Config Sync によって一元管理される Kubernetes RBAC 認可
  • Config Sync によって一元管理される Kubernetes リソース割り当て
OpenShift SDN とネットワーク分離
  • Config Sync によって一元管理される Calico ネットワーク セキュリティ ポリシー
OpenShift セキュリティ コンテキストの制約
  • Policy Controller の制約
OpenShift パイプライン
  • Cloud Build
  • Google Cloud Jenkins プラグインを使用した Jenkins 統合
  • GitLab
OpenShift Source-to-Image
  • Cloud Native Buildpack
  • Jib
ID 統合
  • Cloud Identity
  • Google Cloud Directory Sync
  • GKE on VMware の OIDC インテグレーション

環境の最適化

移行の最終フェーズは、最適化です。このフェーズで、環境を以前よりも効率的なものにします。このフェーズでは環境が最適化の要件を満たすまで、反復可能な手順を複数回繰り返し実施します。この反復可能な手順は、次のとおりです。

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

以降のセクションは、Google Cloud への移行: 環境の最適化に基づいています。

現在の環境、チーム、最適化ループを評価する

最初の評価では、現在の環境を GKE Enterprise へ移行することに焦点を当てていましたが、ここでの評価は最適化フェーズに合わせたものになっています。

最適化の要件を確立する

Google Cloud 上の GKE の最適化要件について、環境の最適化で確立された最適化要件を確認します。

次に挙げる GKE Enterprise 環境の最適化要件を確認します。

最適化を実施する

最適化要件のリストを作成した後、Google Cloud への移行: 環境の最適化での最適化フェーズの残りの作業を実施します。

サポート

Google Cloud では、Google Cloud サービスを最大限有効に利用していただくために、必要なヘルプとサポートを見つける際の各種のオプションとリソースを提供しています。

Google Cloud 移行センターには、ワークロードの Google Cloud への移行に利用できるリソースがさらにあります。

これらのリソースの詳細については、Google Cloud への移行: スタートガイドのサポートを見つけるのセクションをご覧ください。

次のステップ