Google Cloud へのコンテナの移行: Kubernetes から GKE への移行

このドキュメントは、セルフマネージド Kubernetes 環境から Google Kubernetes Engine(GKE)への移行を計画、設計、実装する方法について説明します。誤った方法で行うと、ある環境から別の環境へのアプリの移行が困難な作業になる場合があります。このため、移行は慎重に計画して実行する必要があります。

このドキュメントは、Google Cloud への移行に関する複数のパートからなるシリーズの一部です。シリーズの概要については、Google Cloud への移行: 移行パスの選択をご覧ください。

このドキュメントは、コンテナを Google Cloud に移行する方法を説明するシリーズの一部です。

このドキュメントは、セルフマネージド Kubernetes 環境から GKE への移行を計画している場合に役立ちます。移行対象の環境として、オンプレミス環境、プライベート ホスティング環境、または別のクラウド プロバイダで実行されているケースを想定しています。また、移行について検討している場合、その概要を把握するうえでも、このドキュメントが役立ちます。

GKE を使用することによって、次のようなメリットが得られます。

このドキュメントでは、次のタスクについて読み、理解していることを前提とします。

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

4 フェーズの移行パス

各移行ステップでは、Google Cloud への移行: スタートガイドで定義されている次のフェーズに従います。

  1. ワークロードの評価と検出。
  2. 基盤の計画と構築。
  3. ワークロードのデプロイ。
  4. 環境の最適化。

環境の評価

評価フェーズでは、セルフマネージド Kubernetes 環境を GKE に移行するための要件と依存関係を明らかにします。

  1. アプリの包括的なインベントリを構築します。
  2. プロパティと依存関係に応じてアプリを分類します。
  3. チームを Google Cloud でトレーニングして教育します。
  4. Google Cloud 上で実験と概念実証を作成します。
  5. ターゲット環境の総所有コスト(TCO)を計算します。
  6. 最初に移行するワークロードを選びます。

以降のセクションは、Google Cloud への移行: ワークロードの評価と調査に基づいています。

インベントリを構築する

移行のスコープを設定するには、現在の Kubernetes 環境を理解している必要があります。まず、クラスタに関する情報を収集し、各クラスタにデプロイされたワークロードとワークロードの依存関係に注目します。評価フェーズの終了時には、クラスタに関するインベントリと、それらのクラスタにデプロイされたワークロードに関するインベントリの 2 つができています。

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

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

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

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

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

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

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

評価を完了する

Kubernetes クラスタとワークロードに関連するインベントリが構築されたら、Google Cloud への移行: ワークロードの評価と調査における評価フェーズの残りの作業を実施します。

基盤の計画と構築

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

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

Kubernetes 環境でワークロードを管理するためにすでに infrastructure-as-code を採用している場合は、Google Cloud 環境に同じプロセスを適用できます。GKE が自動的にプロビジョニングする Google Cloud リソースは、Kubernetes のラベルアノテーションを使用して構成できるため、Kubernetes の記述子を分析します。たとえば、LoadBalancer Service にアノテーションを追加することで、外部ロードバランサの代わりに内部ロードバランサをプロビジョニングできます。

以降のセクションは、Google Cloud への移行: 基盤の構築に基づいています。

リソース階層を構築する

効率的なリソース階層を設計するには、Google Cloud への移行: 基盤の構築本番環境での GKE の準備で詳しく説明されているとおり、ビジネスと組織構造を Google Cloud にマッピングする方法を検討します。

たとえば、GKE でマルチテナント環境が必要な場合は、次の中から選択できます。

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

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

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

Identity and Access Management には、クラウド リソースに対するきめ細かなアクセス制御を一元的に構成するためのツールが用意されています。詳細については、Identity and Access Management と、本番環境での Google GKE の準備をご覧ください。

Kubernetes RBAC が Google Cloud の ID とアクセス管理とどのようにやりとりするかを確認し、評価フェーズで収集した要件に従って RBAC を構成します。

お支払い情報を設定する

Google Cloud リソースをプロビジョニングする前に、Cloud Billing を構成し、GKE の料金モデルを把握します。詳細については、課金をご覧ください。

ネットワーク接続を設定する

ネットワーク構成は、環境の基本的な側面です。GKE ネットワーク モデルとワークロードの接続要件を評価します。その後、ネットワーク構成の設計を開始できます。詳細については、接続性とネットワーキングをご覧ください。

セキュリティを強化する

環境のセキュリティ モデルと Google Cloud のモデルの違いおよび、GKE クラスタのセキュリティを強化する方法の理解は、重要な資産を保護するために欠かせません。詳細については、セキュリティをご覧ください。

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

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

ワークロードのデプロイ

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

  1. ランタイム プラットフォームと環境のプロビジョニングおよび構成
  2. 古い環境から新しい環境にデータを移行する。
  3. ワークロードをデプロイする。

以降のセクションは、Google Cloud への移行: 大規模なデータセットの転送Google Cloud への移行: ワークロードのデプロイGoogle Cloud への移行: 手動デプロイから、自動かつコンテナ化されたデプロイへの移行に基づいています。

ランタイム プラットフォームと環境のプロビジョニングおよび構成

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

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

GKE クラスタを作成した後、ワークロードをデプロイする前に、各 GKE クラスタの Namespace、RBAC、ネットワーク ポリシー、ResourceQuotasPodSecurityPolicy をプロビジョニングして構成します。

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

これで、ステートフル ワークロードに必要なデータを転送できるようになりました。

Google Cloud への移行: 大規模なデータセットの転送には、このトピックに関するガイダンスが含まれています。マイクロサービス アーキテクチャを適用するためにワークロードをモダナイズする場合や、すでにそのアーキテクチャを採用している場合は、モノリシック アプリケーションを GKE のマイクロサービスに移行するをご覧ください。GKE のデータ ストレージ オプションの詳細については、ストレージ構成をご覧ください。たとえば、Compute Engine 永続ディスク(ゾーンまたはリージョン全体に複製)か、Filestore を使用できます。

必要なすべてのストレージ インフラストラクチャをプロビジョニングした後、データを移行します。StorageClass プロビジョナーを使用している場合は、新しいクラスタでそれを構成します。

ワークロードのデプロイ

ワークロードをデプロイするには、要件に応じてデプロイ プロセスを設計して実装します。現在のデプロイ プロセスでは十分とは言えず、最新の自動プロセスに移行する場合は、Google Cloud への移行: 手動デプロイから自動かつコンテナ化されたデプロイへの移行をご覧ください。このページには、手動デプロイからコンテナ オーケストレーション ツールへの移行と自動化に関するガイダンスが含まれています。デプロイ フェーズでは、ワークロードをモダナイズすることもできます。たとえば、現在の環境で Pod を使用している場合は、それらのワークロードを Deployment に移行することを検討してください。

デプロイ プロセスの準備ができたら、ワークロードを GKE にデプロイできます。

環境の最適化

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

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

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

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

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

最適化の要件を確立する

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

  • 最新のデプロイ プロセスを実装するカナリア デプロイや、Blue/Green デプロイのようなプロセスを使用すると、柔軟性が増加します。また、環境の信頼度を高め、テストを拡張し、問題がユーザーに与える影響を軽減することが可能になります。
  • サービス メッシュを構成する。サービス メッシュを環境に導入することで、オブザーバビリティ、トラフィック管理、サービスの相互認証などの機能を使用して、DevOps チームの制約を削減します。ワークロードのセグメント化や展開されたサービス メッシュを改善するマルチクラスタのサービス メッシュをデプロイして、新環境への移行をサポートできます。
  • 自動スケーリングを設定する。GKE 環境を自動的にスケールするさまざまな補完的オプションがあります。クラスタと各クラスタ内のワークロードを自動的にスケールできます。クラスタ オートスケーラーを構成することにより、ワークロードの需要に基づいてワーカーノードの追加や削除を行う GKE クラスタのサイズ変更が自動的に行えます。ワークロードを自動的にスケールする場合は、垂直 Pod オートスケーラーによって CPUメモリの消費要求および制限を調整します。オートスケーラーを使用する場合、各コンテナの CPU とメモリのリクエストで指定する値を考える必要はありません。
  • プリエンプティブル仮想マシン(VM)でコストを削減する。可用性の保証がない実行環境を許容できるワークロードがある場合は、それをプリエンプティブル VM で構成されるノードプールにデプロイすることを検討します。プリエンプティブル VM は標準の Compute Engine VM より料金が低く設定されているため、クラスタのコストを抑えることができます。
  • GKE を他のプロダクトと統合する。一部の Google Cloud プロダクトは、GKE と統合して環境のセキュリティを強化できます。たとえば、コンテナの脆弱性を分析することや、Container Registryマネージド ベース イメージを使用することが可能です。

こうした最適化要件のいくつかは Kubernetes 環境で実行できますが、GKE ではクラスタを実行し続ける必要がないため、より簡単です。そして容易になった分、最適化に集中できます。

最適化を実施する

最適化要件のリストを作成した後、最適化フェーズの残りの作業を実施します

次のステップ