このドキュメントは、セルフマネージド Kubernetes 環境から Google Kubernetes Engine（GKE）への移行を計画、設計、実施する方法について説明します。誤った方法で行うと、ある環境から別の環境へのアプリの移行が困難な作業になる場合があります。このため、移行は慎重に計画して実行する必要があります。
このドキュメントは、セルフマネージド Kubernetes 環境から GKE への移行を計画している場合に役立ちます。移行対象の環境として、オンプレミス環境、プライベート ホスティング環境、または別のクラウド プロバイダで実行されているケースを想定しています。また、移行について検討している場合、その概要を把握するうえでも、このドキュメントが役立ちます。
GKE は Google が管理する Kubernetes サービスです。Google のインフラストラクチャを使用してコンテナ化されたアプリケーションを大規模にデプロイして運用するために使用できます。また、次のような Kubernetes 環境の管理に役立つ機能を提供します。
- 2 つのエディション: GKE Standard と GKE Enterprise。GKE Standard では、コア機能のスタンダード ティアにアクセスできます。GKE Enterprise では、GKE のすべての機能にアクセスできます。詳細については、GKE のエディションをご覧ください。
- 2 つの運用モード: Standard と Autopilot。Standard では、基盤となるインフラストラクチャと GKE クラスタ内の各ノードの構成を管理します。Autopilot を使用すると、GKE は基盤となるインフラストラクチャ（ノード構成、自動スケーリング、自動アップグレード、ベースライン セキュリティ、ネットワーク構成など）を管理します。GKE の運用モードの詳細については、GKE の運用モードを選択するをご覧ください。
- 複数のゾーンで Autopilot を使用する場合の Pod の業界固有のサービスレベル契約。
- ノードの自動プロビジョニングによるノードプールの作成と削除の自動化。
- Google が管理するマルチクラスタ ネットワーキング。ワークロードの高可用性分散アーキテクチャを設計して実装できます。
GKE の詳細については、GKE の概要をご覧ください。
Google Cloud に移行する場合は、Google Cloud への移行: スタートガイドで説明する移行フレームワークに従うことをおすすめします。
次の図は、移行の過程を示しています。
移行元の環境から Google Cloud には、一連のイテレーションで移行できます。たとえば、最初に一部のワークロードを移行した後、残りのワークロードを移行できます。個別の移行イテレーションごとに、以下の一般的な移行フレームワークのフェーズに従います。
- ワークロードとデータを評価して検出します。
- Google Cloud で基盤を計画し、構築します。
- ワークロードとデータを Google Cloud に移行します。
- Google Cloud 環境を最適化します。
このフレームワークのフェーズの詳細については、Google Cloud への移行: スタートガイドをご覧ください。
効果的な移行計画を設計するには、計画の各ステップを検証し、ロールバック戦略を常に持っていることをおすすめします。移行計画の検証については、Google Cloud への移行: 移行計画の検証に関するベスト プラクティスをご覧ください。
環境を評価する
評価フェーズでは、移行元の環境を Google Cloud に移行するための要件と依存関係を確認します。
移行を成功させるには、評価フェーズが非常に重要です。このフェーズで、移行するワークロードとその要件、依存関係、および現在の環境について詳しく把握する必要があります。また、Google Cloud への移行を計画して実施するための出発点も理解する必要があります。
評価フェーズは、次のタスクで構成されます。
- ワークロードの包括的なインベントリを作成する。
- プロパティと依存関係に応じてワークロードを分類する。
- チームを Google Cloud でトレーニングして教育する。
- Google Cloud 上でテストと概念実証を構築する。
- ターゲット環境の総所有コスト（TCO）を計算する。
- ワークロードの移行戦略を選択する。
- 移行ツールを選択する。
- 移行計画とタイムラインを定義する。
- 移行計画を検証する。
評価フェーズとこれらのタスクの詳細については、Google Cloud への移行: ワークロードの評価と検出をご覧ください。以下のセクションは、このドキュメントの情報に基づいています。
インベントリを構築する
移行の対象範囲を設定するには、次の 2 つのインベントリを作成します。
- クラスタのインベントリ。
- これらのクラスタにデプロイされているワークロードのインベントリ。
これらのインベントリを作成した後、次のことを行います。
- 移行元の環境のデプロイ プロセスと運用プロセスを評価します。
- サポート サービスと外部依存関係を評価します。
クラスタのインベントリを作成する
クラスタのインベントリを構築するには、クラスタごとに次の点を検討します。
- ノードの数とタイプ。現在の環境にあるノードの数と各ノードの特性がわかっている場合は、GKE に移行するときにクラスタのサイズを見積ります。新しい環境内のノードは、現在の環境で使用しているものとは異なる世代のハードウェア アーキテクチャ上で動作している可能性があります。アーキテクチャの世代によってパフォーマンスが異なるため、新しい環境で必要なノードの数は現在とは異なるかもしれません。高性能ストレージ デバイス、GPU、TPU など、ノードで使用しているハードウェアの種類を評価します。ノードで使用しているオペレーティング システム イメージを評価します。
- 内部または外部クラスタ。内部環境あるいは外部環境の、どちらの関係者に向けて各クラスタが公開されるのかを評価します。ユースケースをサポートするために、この評価にはクラスタで実行されているワークロードと、クラスタとやり取りするインターフェースが含まれます。
- マルチテナンシー。環境内でマルチテナントのクラスタを管理している場合は、新しい Google Cloud 環境で動作するかどうかを評価します。マルチテナント戦略は Google Cloud での基盤構築の手段に影響するため、マルチテナント クラスタの改善方法を評価する良い機会です。
- Kubernetes のバージョン。クラスタの Kubernetes バージョンに関する情報を収集し、それらのバージョンと GKE で使用可能なバージョンに違いがあるかどうかを評価します。古いバージョンまたは最近リリースされた Kubernetes のバージョンを実行している場合は、GKE で使用できない機能が使われている可能性があります。それらの機能がサポートされていないか、機能を提供する Kubernetes バージョンがまだ GKE で利用できない場合があります。
- Kubernetes のアップグレード サイクル。信頼性の高い環境を維持するには、Kubernetes のアップグレードの取り扱い方法と、アップグレード サイクルが GKE のアップグレードとどのように関連しているかを理解します。
- ノードプール。どの形式のノードグループ化を使用する場合でも、そのグループ化の条件が GKE に適さない場合があるため、こうしたグループ化が GKE のノードプールのコンセプトにどのように対応するかを考慮することも可能です。
- ノードの初期化。各ノードを初期化する方法を評価した後で、ワークロードの実行に利用可能なノードを選び、初期化手順を GKE に移植します。
- ネットワーク構成。クラスタのネットワーク構成、IP アドレスの割り振り、ネットワーク プラグインの構成方法、DNS サーバーと DNS サービス プロバイダの構成方法、これらのクラスタに NAT または SNAT のいずれかの形式を構成しているかどうか、マルチクラスタ環境の一部であるかどうかを評価します。
- コンプライアンス: クラスタが満たす必要のあるコンプライアンスと規制要件、およびこれらの要件を満たしているかどうかを評価します。
- 割り当てと上限。クラスタの割り当てと上限の構成方法を評価します。たとえば、各ノードで実行できる Pod の数や、クラスタに設定できるノード数を評価します。
- ラベルとタグ。クラスタ、ノードプール、ノードに適用したメタデータとその使用方法を評価します。たとえば、ラベルベースの詳細な費用アトリビューションを含むレポートを生成できます。
インベントリで評価する次の項目は、インフラストラクチャと Kubernetes クラスタのセキュリティに重点を置いたものです。
- Namespace。クラスタで Kubernetes の Namespace を使用してリソースを論理的に分けている場合は、各 Namespace にどのリソースがあるかを評価し、そのように分けている理由を把握します。たとえば、マルチテナンシー戦略の一環で Namespace を使用しているとします。Kubernetes システム コンポーネント用に予約された Namespace にワークロードをデプロイしていて、GKE では十分制御できない場合があります。
- ロールベース アクセス制御（RBAC）。クラスタで RBAC 認可を使用する場合は、クラスタで構成したすべての ClusterRoles と ClusterRoleBinding の説明をリスト化します。
- ネットワーク ポリシー。クラスタで構成したすべてのネットワーク ポリシーをリスト化し、GKE でのネットワーク ポリシーの仕組みを理解します。
- Pod のセキュリティ コンテキスト。クラスタで構成した Pod のセキュリティ コンテキストに関する情報を取得し、GKE でそれらがどのように動作するかを把握します。
- サービス アカウント。クラスタ内に Kubernetes API サーバーとやり取りするプロセスがある場合は、そのプロセスが使用しているサービス アカウントに関する情報を取得します。
Kubernetes クラスタのインベントリを構築する際に、移行の一環として一部のクラスタを廃止しなければならない場合があります。移行計画には、こうしたリソースの処分が含まれるようにしてください。
Kubernetes ワークロードのインベントリを作成する
Kubernetes クラスタのインベントリを完了し、環境のセキュリティを評価した後、それらのクラスタにデプロイされたワークロードのインベントリを構築します。ワークロードを評価する際は、次の点に関する情報を収集します。
- Pod とコントローラ。新しい環境でのクラスタのサイズを見積もるには、デプロイしている各ワークロードのインスタンス数を評価します。また、リソース割り当てとコンピューティング リソース消費上限を使用しているかどうかも評価します。各クラスタのコントロール プレーン ノードで実行されているワークロードと各ワークロードが使用しているコントローラに関する情報を収集します。たとえば、使用している Deployment の数や、DaemonSet の数などです。
- Job と CronJob。クラスタとワークロードは、初期化またはオペレーション手順の一環として Job または CronJob を実行する必要があります。デプロイした Jobと CronJob のインスタンス数、各インスタンスの責任と完了条件を評価します。
- Kubernetes オートスケーラー。新しい環境に自動スケーリング ポリシーを移行するには、GKE での HorizontalPodAutoscaler と VerticalPodAutoscaler の仕組みをご覧ください。
- ステートレス ワークロードとステートフル ワークロード。ステートレス ワークロードでは、クラスタや永続ストレージにデータや状態が保存されません。ステートフル アプリケーションでは、後で使用するためにデータを保存します。ステートフル ワークロードの移行はステートレスの移行よりも難しいため、ワークロードごとにコンポーネントがステートレスなのか、それともステートフルなのかを評価します。
- 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 サービス、Gateway オブジェクト、Ingress オブジェクトをどのようにサポートしているかや、どの Ingress コントローラをクラスタにデプロイしたかなどです。
- サービス メッシュ現在の環境でサービス メッシュを使用している場合は、それがどのように構成されているかを評価します。また、メッシュがまたがっているクラスタの数、メッシュを構成するサービス、メッシュのトポロジを変更する方法も把握する必要があります。
- taint と toleration、およびアフィニティとアンチアフィニティ。各 Pod とノードについて、Kubernetes クラスタでの Pod のスケジューリングをカスタマイズするためにノード taint、Pod の容認、アフィニティを構成したかどうかを評価します。これらのプロパティは、異種のノードまたは Pod の構成の可能性についての分析情報も提供します。Pod やノード、またはその両方を特別な視点と意識をもって評価する必要があることを意味します。たとえば、Kubernetes クラスタ内の特定のノードでのみスケジュールされる特定の Pod セットを構成した場合、それらのノードでのみ使用できる特別なリソースが Pod に必要な可能性があります。
- 認証: ワークロードがクラスタ内のリソースと外部リソースに対して認証を行う方法を評価します。
サポート サービスと外部依存関係を評価する
クラスタとそのワークロードを評価した後、次のようなインフラストラクチャの他のサポート サービスと側面を評価します。
- StorageClasses と PersistentVolume。ダイナミック プロビジョニングのための StorageClasses、静的にプロビジョニングされた PersistentVolumes をリスト化することによってインフラストラクチャが PersistentVolumeClaims をどのようにサポートしているかを評価します。PersistentVolume ごとに、容量、ボリューム モード、アクセスモード、クラス、再利用ポリシー、マウント オプション、ノード アフィニティを検討します。
- VolumeSnapshots と VolumeSnapshotContents。PersistentVolume ごとに、VolumeSnapshot を構成しているかどうか、既存の VolumeSnapshotContent を移行する必要があるかどうかを評価します。
- Container Storage Interface（CSI）ドライバ。クラスタにデプロイされている場合は、これらのドライバが GKE と互換性があるかどうか、また、GKE と互換性のある CSI ドライバと連携するようにボリュームの構成を調整する必要があるかどうかを評価します。
- データ ストレージ。PersistentVolume のプロビジョニングが外部システムに依存している場合は、GKE 環境のワークロードがそのシステムを使用できるようにします。外部システムと GKE 環境の間のレイテンシはシステム間の距離に比例するため、データのローカル性はステートフル ワークロードのパフォーマンスに影響を与えます。各外部データ ストレージ システムについて、そのタイプ（ブロック ボリューム、ファイル ストレージ、オブジェクト ストレージなど）と、満たす必要があるパフォーマンスと可用性の要件を検討します。
- カスタム リソースと Kubernetes アドオン。クラスタにデプロイした可能性のあるカスタム Kubernetes リソースと、Kubernetes アドオンに関する情報を収集します。これらは GKE では動作しないか、これらを変更する必要がある場合があるためです。たとえば、カスタム リソースが外部システムとやり取りする場合は、それが Google Cloud 環境に適用できるかどうかを判断します。
- バックアップ。移行元の環境でクラスタの構成とステートフル ワークロード データをバックアップする方法を確認します。
デプロイと運用のプロセスを評価する
デプロイ プロセスと運用プロセスの仕組みを明確に理解することが重要です。これらのプロセスは、本番環境とそこで実行されるワークロードを準備して維持するプラクティスの基本となる部分です。
デプロイ プロセスと運用プロセスで、ワークロードが機能するために必要なアーティファクトをビルドする場合があります。したがって、各アーティファクト タイプに関する情報を収集する必要があります。たとえば、アーティファクトには、オペレーティング システム パッケージ、アプリケーションのデプロイ パッケージ、オペレーティング システム イメージ、コンテナ イメージなどがあります。
アーティファクト タイプに加えて、次のタスクの実施方法を検討してください。
- ワークロードを開発する。ワークロードを構築するために開発チームが実施しているプロセスを評価します。たとえば、開発チームはワークロードの設計、コーディング、テストをどのように行っているのか評価します。
- 移行元の環境にデプロイするアーティファクトを生成する。移行元の環境にワークロードをデプロイするには、コンテナ イメージやオペレーティング システム イメージなどのデプロイ可能なアーティファクトを生成するか、ソフトウェアをインストールして構成することで、サードパーティのオペレーティング システム イメージなどの既存のアーティファクトをカスタマイズします。これらのアーティファクトの生成方法に関する情報を収集すると、生成されたアーティファクトが Google Cloud へのデプロイに適していることを確認できます。
アーティファクトを保存する。移行元環境のアーティファクト レジストリに保存するアーティファクトを生成する場合は、Google Cloud 環境でアーティファクトを利用可能にする必要があります。これは、次のような方法で実行できます。
- 環境間の通信チャネルを確立する: 移行元の環境のアーティファクトが移行先の Google Cloud 環境からアクセスできるようにします。
- アーティファクトのビルドプロセスのリファクタリング: 移行元の環境と移行先の環境の両方にアーティファクトを保存できるように、移行元の環境のマイナー リファクタリングを完了します。このアプローチでは、ターゲットの Google Cloud 環境にアーティファクトのビルドプロセスを実装する前に、アーティファクト リポジトリなどのインフラストラクチャを構築することで、移行をサポートします。このアプローチは直接実装することも、最初に通信チャネルを確立する以前のアプローチをベースにして実装することもできます。
移行元環境と移行先環境の両方でアーティファクトを使用できるため、移行の一部としてターゲットの Google Cloud 環境にアーティファクト ビルド プロセスを実装する必要はありません。
コードをスキャンして署名する。アーティファクトのビルドプロセスの一環として、コードスキャンを使用して一般的な脆弱性や意図しないネットワーク公開を防ぐことができます。また、コード署名を使用して、環境で実行されるコードが信頼できるものであることを確認できます。
ソース環境にアーティファクトをデプロイする。デプロイ可能なアーティファクトを生成した後、それらを移行元の環境にデプロイしていることがあります。各デプロイ プロセスを評価することをおすすめします。この評価により、デプロイ プロセスに Google Cloud との互換性があるかどうかを確認できます。また、最終的にプロセスをリファクタリングするために必要な作業についても把握できます。たとえば、デプロイ プロセスが移行元の環境で機能する場合は、Google Cloud 環境をターゲットとするようにリファクタリングが必要になることがあります。
ランタイム構成を挿入する。特定のクラスタ、ランタイム環境、ワークロード デプロイのランタイム構成を挿入していることがあります。この構成では、環境変数と、シークレット、認証情報、キーなどの構成値が初期化される場合があります。ランタイム構成の挿入プロセスが Google Cloud で機能するように、移行元の環境で実行されるワークロードの構成を評価することをおすすめします。
ロギング、モニタリング、プロファイリング。移行元環境の健全性、関心のある指標、これらのプロセスによって提供されるデータの使用方法をモニタリングするために、実装されているロギング、モニタリング、プロファイリングのプロセスを評価します。
認証。移行元の環境に対して認証を行う方法を評価します。
リソースのプロビジョニングと構成。移行元の環境を準備するために、リソースをプロビジョニングして構成するプロセスを設計して実装している場合があります。たとえば、Terraform を構成管理ツールとともに使用して、ソース環境でリソースをプロビジョニングして構成している場合があります。
基盤の計画と構築
計画と構築フェーズでは、インフラストラクチャをプロビジョニングして構成し、以下のことを行います。
- Google Cloud 環境でワークロードをサポートします。
- 移行元の環境と Google Cloud 環境を接続して、移行を完了します。
計画と構築のフェーズは、次のタスクで構成されます。
- リソース階層を構築する。
- Google Cloud の Identity and Access Management（IAM）を構成する。
- お支払いとご請求の設定をします。
- ネットワーク接続を設定する。
- セキュリティを強化する。
- ロギング、モニタリング、アラートを設定する。
これらの各タスクの詳細については、Google Cloud への移行: 基盤の計画と構築をご覧ください。
以降のセクションでは、「Google Cloud への移行: 基盤の計画と構築」の考慮事項をまとめています。
マルチテナンシーを計画する
効率的なリソース階層を設計するには、ビジネスと組織構造を Google Cloud にマッピングする方法を検討します。たとえば、GKE でマルチテナント環境が必要な場合は、次の中から選択できます。
- テナントごとに 1 つの Google Cloud プロジェクトを作成する。
- 異なるテナント間で 1 つのプロジェクトを共有し、複数の GKE クラスタをプロビジョニングする。
- Kubernetes の Namespace を使用する。
どの方法を選択するかは、分離、複雑さ、スケーラビリティのニーズによって変わります。たとえば、テナントごとに 1 つのプロジェクトを作成すると、テナントは互いに分離されますが、プロジェクト数が多くなることからリソース階層が複雑になります。ただし、Kubernetes の Namespace の管理は、複雑なリソース階層よりも比較的簡単ですが、この方法では分離が保証されません。たとえば、コントロール プレーンは複数のテナントで共有されます。詳細については、クラスタ マルチテナンシーをご覧ください。
ID およびアクセス管理を構成する
GKE は、RBAC を使用して Google Cloud プロジェクト内のリソースとクラスタ内のリソースへのアクセス権を管理するための複数のオプションをサポートしています。詳細については、アクセス制御をご覧ください。
GKE ネットワーキングを構成する
ネットワーク構成は、環境の基本的な側面です。クラスタをプロビジョニングして構成する前に、GKE ネットワーク モデル、GKE ネットワーキングのベスト プラクティス、GKE への移行時に IP アドレスを計画する方法を評価することをおすすめします。
モニタリングとアラートを設定する
インフラストラクチャとワークロードのパフォーマンスを明確に把握することは、改善点を見つけるうえで重要です。GKE では、Google Cloud Observability との緊密な統合により、GKE クラスタとそのクラスタ内のワークロードに関するロギングとモニタリング情報を取得できます。
データの移行とワークロードのデプロイ
デプロイ フェーズでは、次のことを実施します。
- GKE 環境をプロビジョニングして構成する。
- GKE クラスタを構成する。
- ワークロードをリファクタリングする。
- デプロイ プロセスと運用プロセスのリファクタリング。
- 移行元の環境から Google Cloud にデータを移行する。
- GKE 環境にワークロードをデプロイする。
- ワークロードと GKE 環境を検証する。
- GKE で実行されているワークロードを公開する。
- 移行元の環境から GKE 環境にトラフィックをシフトする。
- 移行元の環境を廃止する。
Google Cloud 環境をプロビジョニングして構成する
ワークロードを新しい Google Cloud 環境に移行する前に、GKE クラスタをプロビジョニングします。
GKE は、既存のクラスタで特定の機能を有効にすることをサポートしていますが、クラスタの作成時にのみ有効にできる機能もあります。中断を回避し、移行を簡素化するために、クラスタ作成時に必要なクラスタ機能を有効にすることをおすすめします。クラスタの作成後に必要なクラスタ機能を有効にできない場合は、クラスタを破棄して再作成する必要があります。
評価フェーズが終了し、新しい Google Cloud 環境でニーズに合わせて GKE クラスタをプロビジョニングする方法を理解しています。クラスタをプロビジョニングするには、次の点を考慮してください。
- クラスタ数、クラスタあたりのノード数、クラスタの種類、各クラスタと各ノードの構成、各クラスタのスケーラビリティに関する計画。
- 各クラスタの運用モード。GKE には、GKE Autopilot と GKE Standard の 2 つのクラスタ運用モードがあります。
- 限定公開クラスタの数。
- VPC ネイティブまたはルーターベースのネットワーキングの選択。
- GKE クラスタに必要な Kubernetes のバージョンとリリース チャンネル。
- GKE クラスタで論理的にノードをグループ化するためのノードプールと、必要な場合はノードの自動プロビジョニングにより自動的に作成したノードプール。
- 現在の環境から GKE 環境に移植できる初期化手順と、実装可能な新しい手順。たとえば、クラスタ内の各ノードまたはノードプールに 1 つまたは複数の最終的な特権付き初期化手順を実装することで、GKE ノードを自動的にブートできます。
- 各クラスタのスケーラビリティに関する計画。
- Cloud Service Mesh や GKE アドオンなど、必要な追加の GKE 機能（Backup for GKE など）。
GKE クラスタのプロビジョニングの詳細については、以下をご覧ください。
- クラスタ構成の選択について。
- GKE クラスタを管理、構成、デプロイする。
- GKE のセキュリティについて。
- クラスタのセキュリティの強化。
- GKE ネットワークの概要。
- GKE ネットワーキングのベスト プラクティス。
- GKE クラスタのストレージの概要
フリート管理
GKE クラスタをプロビジョニングする際、環境のすべてのユースケースをサポートするために多数のクラスタが必要になる場合があります。たとえば、本番環境と非本番環境の分離や、チームまたは地域間でのサービスの分離が必要になる場合があります。詳細については、マルチクラスタのユースケースをご覧ください。
クラスタの数が増えると、スケーラビリティと運用上の課題が大きくなるため、GKE 環境の運用が困難になる可能性があります。GKE には、Kubernetes クラスタの論理グループであるフリートの管理に役立つツールと機能が用意されています。詳細については、フリート管理をご覧ください。
マルチクラスタ ネットワーク
GKE 環境の信頼性を向上させ、複数の GKE クラスタにワークロードを分散するには、次の方法を使用します。
- マルチクラスタ サービス ディスカバリ。クラスタ間のサービス ディスカバリと呼び出しメカニズムです。サービスは検出可能であり、GKE クラスタ間でアクセスできます。詳細については、マルチクラスタ サービス ディスカバリをご覧ください。
- マルチクラスタ Gateway: クラスタ間の Ingress トラフィック ロード バランシング メカニズム。詳細については、マルチクラスタ Gateway のデプロイをご覧ください。
- マネージド Cloud Service Mesh のマルチクラスタ メッシュ。詳細については、マルチクラスタ メッシュを設定するをご覧ください。
シングルクラスタ GKE 環境からマルチクラスタ GKE 環境への移行の詳細については、マルチクラスタ ネットワークに移行するをご覧ください。
GKE クラスタを構成する
GKE クラスタをプロビジョニングした後、ワークロードをデプロイするかデータを移行する前に、Namespace、RBAC、ネットワーク ポリシー、サービス アカウント、各 GKE クラスタのその他の Kubernetes オブジェクトと GKE オブジェクトを構成します。
GKE クラスタで Kubernetes オブジェクトと GKE オブジェクトを構成するには、次のことをおすすめします。
- 移行元の環境と GKE 環境の両方のクラスタにアクセスするために必要な認証情報と権限があることを確認します。
- 移行元環境の Kubernetes クラスタ内のオブジェクトが GKE と互換性があるかどうか、それらのオブジェクトを支える実装が移行元の環境や GKE とどのように異なるかを評価します。
- 互換性のないオブジェクトをリファクタリングして GKE と互換性を持たせるか、廃止します。
- これらのオブジェクトを GKE クラスタに作成します。
- GKE クラスタで必要な追加オブジェクトを構成します。
Config Sync
GKE のスケーリングに合わせて GKE クラスタの構成を管理するために GitOps のベスト プラクティスを採用するには、Config Sync を使用することをおすすめします。これは、信頼できる情報源から構成をデプロイする GitOps サービスです。たとえば、GKE クラスタの構成を Git リポジトリに保存し、Config Sync を使用してその構成を適用できます。
詳細については、Config Sync のアーキテクチャをご覧ください。
Policy Controller
Policy Controller を使用すると、プログラム可能なポリシーを適用することで、GKE クラスタとワークロードが安全かつコンプライアンスを遵守した状態で実行されるようにできます。GKE 環境のスケーリングに伴い、Policy Controller を使用して、すべての GKE クラスタにポリシー、ポリシー バンドル、制約を自動的に適用できます。たとえば、コンテナ イメージを取得するリポジトリを制限したり、各 Namespace に少なくとも 1 つのラベルを要求して、リソース使用量を正確にトラッキングできます。
詳細については、Policy Controller をご覧ください。
ワークロードをリファクタリングする
コンテナ化されたワークロードを設計する際のベスト プラクティスは、コンテナ オーケストレーション プラットフォームへの依存関係を回避することです。ただし、ワークロードの要件や設計によっては、これが常に可能であるとは限りません。たとえば、ワークロードが、アドオン、拡張機能、統合など、移行元の環境でのみ使用可能な環境固有の機能に依存している場合があります。
ほとんどのワークロードはそのまま GKE に移行できますが、環境固有の機能に依存するワークロードはリファクタリングして、これらの依存関係を最小限に抑え、最終的に GKE で利用可能な代替手段に切り替える必要がある場合があります。
ワークロードを GKE に移行する前にリファクタリングするには、次の操作を行います。
- アドオン、拡張機能、統合など、移行元の環境に固有の機能を確認します。
- 適切な代替 GKE ソリューションを採用します。
- ワークロードをリファクタリングする。
移行元の環境に固有の機能を確認する
移行元の環境に固有の機能を使用していて、ワークロードがこれらの機能に依存している場合は、次の操作を行う必要があります。
- 適切な代替の GKE ソリューションを見つける。
- 代替の GKE ソリューションを利用できるように、ワークロードをリファクタリングする。
この確認作業の一環として、次のことをおすすめします。
- 移行元の環境に固有の機能のサポートを終了できるかどうかを検討します。
- 移行を成功させるために、移行元の環境固有の機能の重要性を評価します。
適切な代替 GKE ソリューションを採用する
移行元の環境固有の機能を確認して、適切な GKE 代替ソリューションにマッピングしたら、これらのソリューションを GKE 環境に採用します。移行の複雑さを軽減するために、次のことをおすすめします。
- 非推奨にする移行元の環境固有の機能に、代替の GKE ソリューションを採用しないでください。
- 移行元で最も重要なソースに代替の GKE ソリューションを採用することに重点を置き、残りの機能については専用の移行プロジェクトを計画します。
ワークロードをリファクタリングする
ワークロードのほとんどは GKE でそのまま機能する可能性がありますが、一部のワークロードはリファクタリングが必要になる場合があります。特に、代替の GKE ソリューションを採用した移行元の環境固有の機能に依存している場合は、リファクタリングが必要になる可能性があります。
このリファクタリングには、次のような作業が含まれます。
- YAML 形式で表現された Deployment や Service などの Kubernetes オブジェクト記述子。
- コンテナ イメージ記述子（Dockerfile や Containerfile など）。
- ワークロードのソースコード。
リファクタリングの作業を簡素化するため、ワークロードを GKE に適したものにするために必要な最小限の変更と、重大なバグの修正に集中することをおすすめします。その他の改善や変更は、今後のプロジェクトの一環として計画できます。
デプロイ プロセスと運用プロセスをリファクタリングする
ワークロードをリファクタリングしたら、デプロイ プロセスと運用プロセスをリファクタリングして、次のことを行います。
- 移行元の環境でリソースをプロビジョニングするのではなく、Google Cloud 環境でリソースをプロビジョニングして構成します。
- ワークロードを構築して構成し、移行元の環境にデプロイするのではなく、Google Cloud にデプロイします。
このプロセスの前の評価フェーズで、これらのプロセスに関する情報を収集しました。
これらのプロセスで検討すべきリファクタリングの種類は、どのように設計し実装したかによって異なります。リファクタリングは、プロセスごとに最終状態をどうするのかによっても異なります。たとえば、次の点を考えます。
- これらのプロセスを移行元の環境に実装した可能性があり、Google Cloud でも同様のプロセスを設計して実装したい場合もあります。たとえば、Cloud Build、Cloud Deploy、Infrastructure Manager を使用するようにこれらのプロセスをリファクタリングできます。
- これらのプロセスを移行元の環境外の別のサードパーティ環境に実装している場合もあります。この場合、移行元の環境ではなく Google Cloud 環境を対象とするように、これらのプロセスをリファクタリングする必要があります。
- 前述のアプローチを組み合わせたケース。
デプロイ プロセスと運用プロセスのリファクタリングは複雑になり、多大な労力が必要になる場合があります。ワークロードの移行の一環としてこれらのタスクを実行すると、ワークロードの移行が複雑になり、リスクが発生する可能性があります。デプロイ プロセスと運用プロセスを評価すると、その設計と複雑さを理解できるはずです。デプロイ プロセスと運用プロセスのリファクタリングに多大な労力が必要になると予想される場合は、これらのプロセスを別の専用プロジェクトの一部としてリファクタリングすることをおすすめします。
Google Cloud でデプロイ プロセスを設計して実装する方法については、以下をご覧ください。
このドキュメントでは、デプロイするアーティファクトを生成し、ターゲット ランタイム環境にデプロイするデプロイ プロセスについて説明します。リファクタリング戦略は、これらのプロセスの複雑さに大きく依存します。次のリストに、一般的なリファクタリング戦略の概要を示します。
- Google Cloud にアーティファクト リポジトリをプロビジョニングします。たとえば、Artifact Registry を使用してアーティファクトを保存し、依存関係をビルドできます。
- 移行元の環境と Artifact Registry の両方にアーティファクトを保存するように、ビルドプロセスをリファクタリングします。
- デプロイ プロセスをリファクタリングして、移行先の Google Cloud 環境にワークロードをデプロイします。たとえば、Artifact Registry に保存されているアーティファクトを使用して、Google Cloud にワークロードの小さなサブセットをデプロイできます。次に、移行するすべてのワークロードが Google Cloud で実行されるまで、Google Cloud にデプロイされるワークロードの数を徐々に増やします。
- アーティファクトを Artifact Registry にのみ保存するようにビルドプロセスをリファクタリングします。
- 必要に応じて、以前のバージョンのアーティファクトを移行して、移行元環境のリポジトリから Artifact Registry にデプロイします。たとえば、コンテナ イメージを Artifact Registry にコピーできます。
- リポジトリが不要になったら、移行元の環境のリポジトリを廃止します。
移行中に予期しない問題が発生した場合のロールバックを容易にするために、Google Cloud への移行中に、Google Cloud の現在のアーティファクト リポジトリと Artifact Registry の両方にコンテナ イメージを保存できます。最後に、移行元の環境の運用停止の一環として、コンテナ イメージのビルドプロセスをリファクタリングして、アーティファクトを Google Cloud にのみ保存できます。
移行の成功に不可欠ではないかもしれませんが、以前のバージョンのアーティファクトを移行元の環境から Google Cloud のアーティファクト リポジトリに移行することが必要になる場合があります。たとえば、ワークロードを任意の時点にロールバックできるようにするには、以前のバージョンのアーティファクトを Artifact Registry に移行する必要があります。詳細については、サードパーティ レジストリからイメージを移行するをご覧ください。
Artifact Registry を使用してアーティファクトを保存する場合は、アクセス制御、データ流出防止、脆弱性スキャン、Binary Authorization など、アーティファクト リポジトリを保護する制御を構成することをおすすめします。詳細については、アクセスを制御してアーティファクトを保護するをご覧ください。
ワークロードをデプロイする
デプロイ プロセスの準備ができたら、ワークロードを GKE にデプロイできます。詳細については、ワークロードのデプロイの概要をご覧ください。
GKE にデプロイするワークロードを準備するには、Kubernetes の記述子を分析することをおすすめします。GKE が自動的にプロビジョニングする Google Cloud リソースの一部は、これらのリソースを手動でプロビジョニングするのではなく、Kubernetes のラベルとアノテーションを使用して構成できます。たとえば、LoadBalancer Service にアノテーションを追加することで、外部ロードバランサの代わりに内部ロードバランサをプロビジョニングできます。
ワークロードを検証する
GKE 環境にワークロードをデプロイした後、それらのワークロードをユーザーに公開する前に、広範な検証とテストを行うことをおすすめします。このテストは、ワークロードが想定どおりに動作していることを確認するのに役立ちます。たとえば、次のようなことが可能です。
- インテグレーション テスト、負荷テスト、コンプライアンス テスト、信頼性テストなど、さまざまな検証手順を実施し、ワークロードが想定されるパラメータ内で、仕様どおりに動作していることを確認します。
- Google Cloud Observability のログ、指標、エラーレポートを調べて、潜在的な問題を特定し、傾向を見つけることで問題が発生する前に予測します。
ワークロード検証の詳細については、信頼性のテストをご覧ください。
ワークロードを公開する
GKE 環境で実行されているワークロードの検証テストが完了したら、ワークロードを公開して到達できるようにします。
GKE 環境で実行されているワークロードを公開するには、Kubernetes Service とサービス メッシュを使用します。
GKE で実行されているワークロードの公開の詳細については、以下をご覧ください。
Google Cloud 環境にトラフィックをシフトする
ワークロードが GKE 環境で実行されていることを確認し、ワークロードをクライアントに公開したら、移行元の環境から GKE 環境にトラフィックを移行します。大規模な移行とそれに関連するすべてのリスクを回避するため、移行元の環境から GKE にトラフィックを段階的に移行することをおすすめします。
GKE 環境の設計方法に応じて、トラフィックを移行元の環境から移行先の環境に段階的に移行するロード バランシング メカニズムを実装する方法はいくつかあります。たとえば、GKE 環境に属する IP アドレスへのリクエストのうち、一定の割合を解決するポリシーに従って DNS レコードを解決する DNS 解決ポリシーを実装できます。または、仮想 IP アドレスとネットワーク ロードバランサを使用してロード バランシング メカニズムを実装することもできます。
GKE 環境へのトラフィックの段階的なシフトを開始したら、負荷の増加に伴うワークロードの動作をモニタリングすることをおすすめします。
最後に、カットオーバーを実行します。これは、すべてのトラフィックを移行元の環境から GKE 環境にシフトする際に発生します。
ロード バランシングの詳細については、フロントエンドでのロード バランシングをご覧ください。
移行元の環境を廃止する
GKE 環境のワークロードが正しくリクエストを処理したら、移行元の環境を廃止します。
移行元の環境でリソースの廃止を開始する前に、次のことをおすすめします。
- 移行元の環境のリソースを復元するために、データをバックアップします。
- 環境を廃止する前にユーザーに通知します。
移行元の環境を廃止するには、次のようにします。
- 移行元の環境のクラスタで実行されているワークロードを廃止します。
- 移行元の環境にあるクラスタを削除します。
- セキュリティ グループ、ロードバランサ、仮想ネットワークなど、これらのクラスタに関連付けられているリソースを削除します。
孤立したリソースが残らないようにするには、移行元の環境のリソースを廃止する順序が重要です。たとえば、一部のプロバイダでは、ロードバランサの作成を開始する Kubernetes Service を廃止してから、これらのロードバランサを含む仮想ネットワークを廃止する必要があります。
Google Cloud 環境を最適化する
最適化が移行の最終フェーズになります。このフェーズではターゲット環境が最適化の要件を満たすまで最適化タスクを繰り返します。このイテレーションの手順は次のとおりです。
- 現在の環境、チーム、最適化ループを評価する。
- 最適化の要件と目標を設定する。
- 環境とチームを最適化する。
- 最適化ループを調整する。
最適化の目標を達成するまで、このシーケンスを繰り返します。
Google Cloud 環境の最適化の詳細については、Google Cloud への移行: 環境の最適化とパフォーマンスの最適化プロセスをご覧ください。
以降のセクションでは、「Google Cloud への移行: 環境を最適化する」の考慮事項を統合しています。
最適化の要件を確立する
最適化要件は、現在の最適化イテレーションの範囲を絞り込むのに役立ちます。最適化の要件と目標の詳細については、最適化の要件と目標を設定するをご覧ください。
GKE 環境の最適化要件を確立するには、まず次の点を考慮します。
- セキュリティ、プライバシー、コンプライアンス: GKE 環境のセキュリティ ポスチャーを強化します。
- 信頼性: GKE 環境の可用性、スケーラビリティ、復元性を向上させます。
- 費用の最適化: GKE 環境のリソース使用量とそれに伴う費用を最適化します。
- 運用効率: GKE 環境を効率的に維持、運用できるようにします。
- パフォーマンスの最適化: GKE 環境にデプロイされたワークロードのパフォーマンスを最適化します。
セキュリティ、プライバシー、コンプライアンス
- GKE クラスタのセキュリティ ポスチャーをモニタリングする。セキュリティ ポスチャー ダッシュボードを使用すると、GKE 環境のセキュリティ ポスチャーの改善に役立つ推奨事項を入手できます。
- GKE 環境を強化する。GKE セキュリティ モデルと、GKE クラスタのセキュリティを強化する方法を理解します。
- ソフトウェア サプライ チェーンを保護する。セキュリティが重要なワークロードの場合、Google Cloud は、ソフトウェア ライフサイクル全体でソフトウェア サプライ チェーン セキュリティのベスト プラクティスを実装するモジュラー プロダクト セットを提供します。
信頼性
- クラスタの信頼性を向上させる。ゾーンの停止が起こりにくい GKE を設計するには、ゾーンクラスタやマルチゾーン クラスタではなく、リージョン クラスタを使用することをおすすめします。
- ワークロードのバックアップと復元。Backup for GKE を使用してワークロードのバックアップと復元のワークフローを構成します。
費用の最適化
GKE 環境のコストを最適化する方法については、以下をご覧ください。
運用効率
本番環境に影響する問題を回避するために、次のことをおすすめします。
- GKE クラスタを代替可能にするように設計する。クラスタを代替可能と見なし、クラスタのプロビジョニングと構成を自動化することで、運用プロセスを合理化および一般化し、その後の移行と GKE クラスタのアップグレードを整備して簡素化できます。たとえば、代替可能な GKE クラスタを新しい GKE バージョンにアップグレードする必要がある場合は、アップグレードされた新しいクラスタを自動的にプロビジョニングして構成し、新しいクラスタにワークロードを自動的にデプロイし、古い、旧式の GKE クラスタを廃止できます。
- 関心のある指標をモニタリングする。ワークロードとクラスタに関する重要な指標がすべて適切に収集されていることを確認します。また、これらの指標を入力として使用する関連アラートがすべて設定され、機能していることを確認します。
GKE 環境でモニタリング、ロギング、プロファイリングを構成する方法については、以下をご覧ください。
パフォーマンスの最適化
- クラスタの自動スケーリングとノードの自動プロビジョニングを設定する。クラスタの自動スケーリングとノードの自動プロビジョニングを使用して、需要に応じて GKE クラスタのサイズを自動的に変更します。
- ワークロードを自動的にスケーリングする。GKE は、次のようないくつかのスケーリング メカニズムをサポートしています。
- 指標に基づいてワークロードを自動的にスケーリングします。
- 水平 Pod 自動スケーリングを構成して、Kubernetes ワークロードの Pod 数を変更し、ワークロードを自動的にスケーリングします。
- 垂直 Pod 自動スケーリングを構成してリソース リクエストと上限を調整し、ワークロードを自動的にスケーリングします。
詳細については、GKE のスケーラビリティについてをご覧ください。
次のステップ
- 移行に関するヘルプを確認するタイミングを確認する。
- Cloud Architecture Center で、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
寄稿者
著者: Marco Ferrari | クラウド ソリューション アーキテクト