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

Last reviewed 2023-05-22 UTC

このドキュメントは、セルフマネージド 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 のセキュリティ コンテキスト。クラスタで構成した Pod のセキュリティ コンテキストに関する情報を取得し、GKE でそれらがどのように動作するかを把握します。
  • サービス アカウント。クラスタ内に Kubernetes API サーバーとやり取りするプロセスがある場合は、そのプロセスが使用しているサービス アカウントに関する情報を取得します。

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

  • Pod とコントローラ。新しい環境でのクラスタのサイズを見積もるには、デプロイしている各ワークロードのインスタンス数および、リソース割り当てとコンピューティング リソース消費上限を使用しているかどうかを評価します。各クラスタのコントロール プレーン ノードで実行されているワークロードと各ワークロードが使用しているコントローラに関する情報を収集します。たとえば、使用している Deployment の数や、DaemonSet の数などです。
  • Job と CronJob。クラスタとワークロードは、初期化またはオペレーション手順の一環として Job または CronJob を実行する必要があります。デプロイした Job と CronJob のインスタンス数、各インスタンスの責任と完了条件を評価します。
  • Kubernetes のオートスケーラー。新しい環境に自動スケーリング ポリシーを移行するには、GKE 上の水平 Pod のオートスケーラー、垂直 Pod のオートスケーラー、多次元 Pod のオートスケーラーの仕組みをご覧ください。
  • ステートレス ワークロードとステートフル ワークロード。ステートレス ワークロードでは、クラスタや永続ストレージにデータや状態が保存されません。ステートフル アプリケーションでは、後で使用するためにデータを保存します。ステートフル ワークロードの移行はステートレスの移行よりも難しいため、ワークロードごとにコンポーネントがステートレスなのか、それともステートフルなのかを評価します。
  • 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 サービスや Ingress オブジェクトをどのようにサポートしているか、どの Ingress コントローラをクラスタにデプロイしたかなどです。
  • サービス メッシュ現在の環境でサービス メッシュを使用している場合は、それがどのように構成されているかを評価します。また、メッシュがまたがっているクラスタの数、メッシュを構成するサービス、メッシュのトポロジを変更する方法も把握する必要があります。たとえば、自動サイドカー インジェクションを使用して Kubernetes Pod にサイドカーを自動的に追加するかなどです。
  • taint と toleration、およびアフィニティとアンチアフィニティ。各 Pod とノードについて、Kubernetes クラスタでの Pod のスケジューリングをカスタマイズするためにノードの taint、Pod の toleration、アフィニティを構成したかどうかを評価します。これらのプロパティは、異種のノードまたは Pod の構成の可能性についての分析情報も提供します。Pod やノード、またはその両方を特別な視点と意識をもって評価する必要があることを意味します。たとえば、Kubernetes クラスタ内の特定のノードでのみスケジュールされる特定の Pod セットを構成した場合、それらのノードでのみ使用できる特別なリソースが Pod に必要な可能性があります。

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

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

評価を完了する

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 への移行: 基盤の構築で詳しく説明されているとおり、ビジネスと組織構造を Google Cloud にマッピングする方法を検討します。

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

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

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

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

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

Kubernetes RBAC が Google Cloud の Identity and Access Management とどのようにやりとりするかを確認し、評価フェーズで収集した要件に従って RBAC を構成します。

お支払い情報を設定する

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

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

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

セキュリティを強化する

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

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

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

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

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

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

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

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

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

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

クラスタを構成する

GKE クラスタをプロビジョニングした後、ワークロードをデプロイするかデータを移行する前に、名前空間、RBAC、ネットワーク ポリシー、リソース割り当て、各 GKE クラスタのその他の Kubernetes オブジェクトと GKE オブジェクトを構成します。

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

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

クラスタ構成を移行する

Kubernetes クラスタの構成を移行元の環境から GKE クラスタに移行するには、次の方法を使用できます。

  • infrastructure-as-code プロセスを採用して移行元の環境の Kubernetes クラスタでオブジェクトを構成すると、次のことが可能になります。

    1. Kubernetes ツール（kubectl）またはマネージド サービス（Config Sync）を使用して、オブジェクト名、ロケーション、名前空間など、メタデータを少し変更するだけで GKE と互換性のあるオブジェクトを移行する。
    2. GKE と互換性のないオブジェクトをリファクタリングまたは廃止する。

  • infrastructure-as-code プロセスを採用していない場合は、次のことが可能です。

    • Crane や Velero などのサードパーティ ツールを使用して、Kubernetes オブジェクトの構成を移行元の環境から GKE 環境に移行する。

データを移行する

ステートフル ワークロードに必要なデータを移行元の環境から GKE 環境に移行するには、Google Cloud への移行: 大規模なデータセットを転送するのガイダンスに沿ってデータ移行計画を設計することをおすすめします。

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

GKE のデータ ストレージ オプションの詳細については、ストレージ構成をご覧ください。たとえば、Compute Engine 永続ディスク（ゾーンまたはリージョン全体に複製）か、Filestore を使用できます。

StorageClasses をプロビジョニングしたら、移行するデータを格納するために必要なすべての PersistentVolume をプロビジョニングします。次に、移行元の環境からこれらの PersistentVolume にデータを移行します。このデータ移行の詳細は、移行元の環境の特性によって異なります。たとえば、次のようなことが可能です。

  1. Compute Engine インスタンスをプロビジョニングする。
  2. 永続ディスクを Compute Engine インスタンスにアタッチする。
  3. 移行元の環境から永続ディスクにデータをコピーする。
  4. Compute Engine インスタンスをシャットダウンする。
  5. Compute Engine インスタンスから永続ディスクを切断する。
  6. 永続ディスクを GKE PersistentVolume として構成する。
  7. Compute Engine インスタンスを廃止する。

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

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

ワークロードをデプロイする場合は、次のいずれかの方法を実施することをおすすめします。

  • Google Cloud 上でデプロイ プロセスを実装する。
  • 既存のデプロイ プロセスをリファクタリングして、GKE 環境にワークロードをデプロイする。

デプロイ フェーズは、デプロイ プロセスとワークロードをモダナイズする機会でもあります。たとえば、現在の環境で Pod を使用している場合は、それらのワークロードを Kubernetes Deployment に移行することを検討してください。

デプロイ プロセスのリファクタリングの詳細については、Google Cloud への移行: 手動デプロイからコンテナと自動化への移行をご覧ください。このページには、手動デプロイからコンテナ オーケストレーション ツールへの移行と自動化に関するガイダンスが含まれています。

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

Google Cloud 上にデプロイ プロセスを実装する

Google Cloud 上にデプロイ プロセスを実装するには、Google Cloud プロダクトのスケーラビリティ、マネージド オペレーション、セキュリティを考慮した設計を使用します。

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

既存のデプロイ プロセスのリファクタリング

成功のために厳密に必要なわけではありませんが、移行中にデプロイ プロセスをリファクタリングすることもできます。たとえば、既存のデプロイ プロセスをモダナイズして自動化し、Google Cloud に実装できます。

ワークロードの移行と同時にデプロイ プロセスを Google Cloud に移行すると、移行が複雑になり、移行失敗のリスクが高くなる可能性があります。特に複雑な移行の場合は、デプロイ プロセスの移行を別の機会に行うこととし、現在のプロセスを引き続き使用して GKE 環境にワークロードをデプロイすることもできます。このアプローチは、移行の複雑さを軽減するのに役立ちます。既存のデプロイ プロセスを引き続き使用することで、移行プロセスを簡素化できます。

ワークロードを検証する

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

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

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

ワークロードを公開する

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

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

GKE が Kubernetes Service をサポートする方法の詳細については、Service をご覧ください。

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

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

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

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

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

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

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

移行元の環境を廃止する

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

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

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

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

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

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

環境を最適化する

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

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

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

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

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

最適化の要件を確立する

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

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

  • マルチクラスタ環境を設計する。GKE にマルチクラスタ環境を実装すると、次のことが可能になります。

    • アーキテクチャに単一障害点が生じる可能性を下げる。
    • GKE クラスタのサブセットで構成の変更をテストできる柔軟性を向上させる。
    • GKE クラスタ間でワークロードを分散する。

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

最適化を実施する

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

次のステップ