Google Cloud へのコンテナの移行: マルチクラスタ GKE 環境への移行

Last reviewed 2023-05-08 UTC

このドキュメントでは、特定の Google Kubernetes Engine(GKE)環境から新しい GKE 環境への移行を計画、設計、実施する方法について説明します。誤った方法で行うと、一方の環境からもう一方の環境へのアプリの移行は困難な作業となる恐れがあります。そのため、移行は慎重に計画して実行する必要があります。

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

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

このドキュメントは、ある GKE 環境から別の GKE 環境への移行を計画している場合に役立ちます。また、移行について検討している場合、その概要を把握するうえでも、このドキュメントが役立ちます。

ある GKE 環境から別の GKE 環境に移行する理由には、次のことなども含まれます。

新しい環境のアーキテクチャを設計する際は、マルチクラスタ GKE 環境の検討をおすすめします。環境内で複数の GKE クラスタをプロビジョニングして構成することにより、次のことを行います。

  • アーキテクチャに単一障害点を持ち込む可能性を減らします。たとえば、あるクラスタが停止した場合に、他のクラスタでそれを引き継ぐことができます。
  • マルチクラスタ環境がもたらす高い柔軟性を活用します。たとえば、変更を一部のクラスタに適用することで、誤った構成変更に起因する問題の影響を制限できます。また、残りのクラスタに変更を適用する前にそれを検証できます。
  • ワークロードが、クラスタをまたいで通信できるようにします。たとえば、あるクラスタにデプロイされたワークロードが、別のクラスタにデプロイされたワークロードと通信できるようにします。

このドキュメントのガイダンスは、単一クラスタの GKE 環境にも適用されます。単一クラスタの GKE 環境に移行すると、マルチクラスタ環境と比較して環境の管理が複雑でなくなります。一方、単一クラスタ環境では、マルチクラスタ GKE 環境の柔軟性、信頼性、復元力の向上の利点が得られません。

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

4 フェーズの移行パス

上図に示すフレームワークには、Google Cloud への移行: スタートガイドで定められている次のフェーズがあります。

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

移行ステップのそれぞれで、上記のフェーズに従います。このドキュメントは、Google Cloud へのコンテナの移行: Kubernetes から GKE への移行で説明されている考え方も踏襲しています。必要に応じて、そのリンクを追加しています。

環境の評価

評価フェーズでは、移行元の環境と移行するワークロードの情報を収集します。この評価は、移行と、移行と移行先の環境に必要なリソースの規模を適正化するうえで非常に重要です。評価フェーズでは、次のことを行います。

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

以降のセクションは、Google Cloud への移行: ワークロードの評価と調査に基づいています。ただし、ここでは、新しい GKE クラスタに移行するワークロードの評価に固有の情報について説明します。

Kubernetes から GKE への移行における環境の評価では、ServiceAccount や PersistentVolume などの Kubernetes クラスタとリソースを評価する方法が説明されています。この情報が、GKE 環境の評価にも適用されます。

インベントリを構築する

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

Kubernetes から GKE への移行におけるインベントリの構築では、Kubernetes クラスタとワークロードのインベントリを構築する方法が説明されています。これは、GKE 環境のインベントリの構築にも適用されます。本ドキュメントの先へ進む前に、そのガイダンスに従って Kubernetes クラスタのインベントリを構築してください。

Kubernetes から GKE への移行のガイダンスに沿ってインベントリを構築した後、そのインベントリを改良します。GKE クラスタとノードプールのインベントリを完了するには、各クラスタとノードプールに関して、次のような GKE 固有の特徴と機能を検討してください。

インベントリを構築するときに、移行の一環として一部の GKE クラスタを廃止する必要が生じる場合があります。Google Cloud リソースには、作成元の GKE クラスタを削除しても削除されないものがあります。移行計画には、そうしたリソースの廃止が含まれるようにしてください。

その他の GKE 固有の特徴と機能については、GKE のドキュメントをご覧ください。

評価を完了する

GKE クラスタとワークロードに関連するインベントリが構築されたら、コンテナを Google Cloud に移行する: Kubernetes から GKE への移行の評価フェーズの残りの作業を完了します。

基盤の計画と構築

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

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

ネットワーク接続を設定するときに、ノード、Pod、Service に割り振るのに十分な数の IP アドレスがサブネットにあることを確認します。クラスタのネットワークを設定するときは、IP アドレスの割り当てを慎重に計画してください。たとえば、GKE 用にプライベートで使用されるパブリック IP を構成できます。クラスタの Pod と Service に設定したセカンダリ IP アドレス範囲は、割り当て後に変更できません。/22(1,024 アドレス)以下の Pod または Service の範囲を割り振る場合は特に注意してください。そうしないと、クラスタが拡大したときに Pod と Service の IP アドレスが不足する可能性があります。詳細については、IP アドレス範囲の計画をご覧ください。

GKE 環境用に作成する内部ロードバランサには、個別の共有サブネットを使用することをおすすめします。type: LoadBalancer の Kubernetes Service を使用する場合は、ロードバランサのサブネットを指定できます。内部 HTTP(S) 内部ロードバランサを構成する場合は、プロキシ専用サブネットを構成する必要があります。

GKE 環境の基盤を構築するには、Google Cloud へのコンテナの移行: Kubernetes から GKE への移行の計画と構築フェーズの作業を完了してください。

ワークロードのデプロイ

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

  1. 移行先の環境のプロビジョニングと構成を行います。
  2. 移行元の環境から移行先の環境にデータを移行します。
  3. 移行したワークロードを移行先の環境にデプロイします。

このセクションでは、GKE へのワークロードのデプロイに固有の情報について説明します。Kubernetes から GKE への移行: ワークロードのデプロイの情報をに基づいています。

ランタイム プラットフォームと環境を評価する

柔軟性、信頼性、保守性に優れたインフラストラクチャを実現するために、マルチクラスタ アーキテクチャを設計、実装することをおすすめします。マルチクラスタ アーキテクチャでは、環境内に複数の本番環境 GKE クラスタが存在します。たとえば、環境内に複数の GKE クラスタをプロビジョニングする場合、ローリング アップグレードまたは Blue Green アップグレードなどの高度なクラスタのライフサイクル戦略を実装できます。マルチクラスタ GKE アーキテクチャの設計とそのメリットの詳細については、マルチクラスタ Ingress を使用したマルチクラスタ GKE のアップグレードをご覧ください。

環境を複数のクラスタで実行する場合には、次に挙げるような検討課題も存在します。

  • 構成管理、サービス ディスカバリと通信、アプリケーションのロールアウト、受信トラフィックのロード バランシングに対応する必要があります。
  • クラスタで追加のソフトウェアを実行する必要があり、追加の自動化とインフラストラクチャが必要になります。

これらの課題に対処するには、継続的インテグレーション / 継続的デプロイ(CI / CD)パイプラインでクラスタの構成を順次更新し、ミスの影響を最小限に抑える必要があります。また、あるクラスタから別のクラスタにトラフィックを分散するロードバランサが必要になることもあります。

インフラストラクチャを手動で管理すると、エラーが発生しやすく、構成ミスや、インフラストラクチャの現在の状態に関する内部ドキュメントがないなどの問題が発生する場合があります。そうした問題によるリスクを軽減するために、インフラストラクチャをコードパターンとして適用することをおすすめします。このパターンを適用した場合、インフラストラクチャのプロビジョニングは、ワークロードのソースコードと同じ方法で扱います。

このセクションに後述するように、マルチクラスタ GKE 環境には、アーキテクチャ上の選択肢が複数あります。複数の選択肢から選ばれる 1 つは、複数の要因によって決まり、他の選択肢より本質的に優れているものはありません。どの種類にも独自の強みと弱みがあります。アーキテクチャの種類を選択するには、次のようにします。

  1. マルチクラスタ GKE 環境のアーキテクチャの種類を評価する、一連の基準を確立します。
  2. 評価基準に照らして各選択肢を評価します。
  3. ニーズに最適な選択肢を選びます。

マルチクラスタ GKE 環境のアーキテクチャの種類を評価する基準を確立するには、完了した環境の評価を使用して、必要な機能を特定します。機能は、重要度に応じて並べ替えます。たとえば、ワークロードと環境を評価した後、重要度の高いものから列挙された次の評価基準を検討します。

  1. Google が管理するソリューション。Google が管理するサービスやプロダクトと、自分で管理するサービスやプロダクトのどちらが望ましいですか?
  2. アーキテクチャと相互作用するインターフェース。操作できる機械読み取り可能なインターフェースはありますか?そのインターフェースがオープン標準として定義されていますか?そのインターフェースでは、宣言型ディレクティブ、命令型ディレクティブ、またはその両方がサポートされていますか?
  3. GKE 環境外へのサービス公開。このアーキテクチャでは、ワークロードがデプロイされる GKE クラスタの外部に、そのワークロードを公開できますか?
  4. クラスタ間通信。アーキテクチャはクラスタ間の通信チャネルをサポートしていますか?ワークロードは分散アーキテクチャをサポートしていますか?この基準は、Jenkins などの分散設計のワークロードをサポートするうえで重要です。
  5. トラフィック管理。このアーキテクチャは、フォールト インジェクショントラフィック シフト、リクエストタイムアウトおよび再試行サーキット ブレーカートラフィックのミラーリングなどの、高度なトラフィック管理機能をサポートしていますか?これらの機能を使用する準備ができているか、または、自分で実装する必要がありますか?
  6. 追加ツールのプロビジョニングと構成。追加のハードウェア コンポーネントまたはソフトウェア コンポーネントをプロビジョニングして構成する必要はありますか?

Google Cloud には、マルチクラスタ GKE 環境のアーキテクチャを設計するための次の選択肢が用意されています。ワークロードに最適な選択肢を見極めるには、まず先ほど確立した評価基準に照らして評価します。任意に順序付けしたスケールによって、設計の選択肢それぞれに各評価基準のスコアを割り当てます。たとえば、各評価基準に照らして 1~10 のスケールを各環境に割り当てることができます。設計の選択肢を、新しいマルチクラスタ GKE 環境を管理するために必要な労力が高い順に表すと、次のようになります。

  1. マルチクラスタ Ingressマルチクラスタ サービス ディスカバリ
  2. マルチクラスタ IngressAnthos Service Mesh
  3. Traffic Director
  4. Kubernetes とセルフマネージド DNS レコードの更新

以降のセクションでは、これらの選択肢について詳しく説明します。また、各選択肢を評価する基準も示します。プロダクトのドキュメントを参照して、一部の基準に対してスコアを割り当てることができます。たとえば、ドキュメントを参照することで、先ほど確立した評価基準の一部に照らして Anthos Service Mesh を評価できます。ただし、他の基準にスコアを割り当てるには、より詳細なベンチマークとシミュレーションを設計して実行する必要があります。たとえば、さまざまなマルチクラスタ GKE アーキテクチャのパフォーマンスは、ベンチマークしてワークロードに適しているかどうかを評価する必要があります。

マルチクラスタ Ingress とマルチクラスタ サービス ディスカバリ

マルチクラスタ Ingress は Google マネージド サービスで、デプロイされている GKE クラスタに関係なくワークロードを公開できます。また、GKE クラスタ間やリージョン間で共有ロードバランサを構成することもできます。マルチクラスタ GKE 環境でマルチクラスタ Ingress を使用する方法については、マルチクラスタ Ingress を使用したマルチクラスタ GKE のアップグレードIstio メッシュ拡張を使用して移行をサポートするをご覧ください。

マルチクラスタ サービス ディスカバリは、GKE でクラスタをまたぐサービス ディスカバリと接続を行う Kubernetes ネイティブの仕組みです。マルチクラスタ サービス ディスカバリは、Kubernetes Service リソース上に構築され、アプリがクラスタの境界を越えて相互に検出して接続できるようにします。マルチクラスタ Ingress とマルチクラスタ サービス ディスカバリを上記で確立した基準に照らして評価するには、相対的な重要度順に番号付けされた次のリストを使用します。

  1. Google が管理するソリューション。マルチクラスタ サービス ディスカバリは、GKE のフルマネージド機能です。リソース(Cloud DNS のゾーンとレコード、ファイアウォール ルール、Traffic Director)を構成するので、管理する必要がありません。
  2. アーキテクチャと相互作用するインターフェース。Service は、ServiceExport という宣言型 Kubernetes リソースを使用して他のクラスタにエクスポートされます。
  3. GKE 環境外へのサービス公開。マルチクラスタ Ingress とマルチクラスタ サービス ディスカバリを使用すると、ワークロードをどこにデプロイしたかに関係なく、ワークロードを GKE クラスタの外部に公開できます。
  4. クラスタ間通信ServiceExport オブジェクトを宣言することによって、既存の Service を他の GKE クラスタにエクスポートします。同じフリート内の GKE クラスタでは、ServiceExport オブジェクトを使用してエクスポートする Service が自動的にインポートされます。マルチクラスタ サービス ディスカバリでは、エクスポートされた Service ごとに仮想 IP アドレスが設定されます。また、マルチクラスタ サービス ディスカバリでは、Traffic Director リソース、Cloud DNS、ファイアウォール ルールが自動的に構成され、Kubernetes DNS 規則の単純なバリエーションを使用して Service を検出し接続します。たとえば、my-svc Service にアクセスするには、my-svc.my-ns.svc.clusterset.local 名を使用できます。
  5. トラフィック管理。マルチクラスタ サービス ディスカバリでは、単純なレイヤ 3 / 4 接続が構成され、サービス ディスカバリに DNS を用います。トラフィック管理機能はありません。
  6. 追加ツールのプロビジョニングと構成。マルチクラスタ サービス ディスカバリは、Google API を有効にすることで設定できます。他のツールをインストールする必要はありません。詳細については、Google Cloud へのコンテナの移行: マルチクラスタ サービス ディスカバリとマルチクラスタ Ingress を使用したマルチクラスタ GKE 環境への移行をご覧ください。

マルチクラスタ Ingress と Anthos Service Mesh

サービス メッシュは、分散アプリのネットワーク課題への対応に役立つアーキテクチャ パターンです。この課題には、サービス ディスカバリ、ロード バランシング、フォールト トレラント、トラフィック制御、オブザーバビリティ、認証、認可、転送データの暗号化などがあります。通常、サービス メッシュの実装は、データプレーンとコントロール プレーンで構成されます。データプレーンは、トラフィックを直接処理し、通常、サイドカー プロキシを使用して宛先ワークロードに転送する役割を担います。コントロール プレーンは、データプレーンを構成するコンポーネントのことです。

インフラストラクチャにサービス メッシュ パターンを実装する場合は、Anthos Service Mesh と Traffic Director の 2 つの Google Cloud プロダクトから選択できます。どちらのプロダクトも、複数の GKE クラスタ間でアプリケーション レイヤ(L7)のネットワーキングを構成するコントロール プレーンを提供します。Anthos Service Mesh は Istio をベースとし、宣言型のオープンソース API を提供します。Traffic Director は、Google のロード バランシング機能とオープンソース テクノロジーの組み合わせに基づいており、命令型の Google API を提供します。

Anthos Service Mesh は、Google が管理する一連のツールで、デプロイされている GKE クラスタに関係なく、アプリのコードを変更せずにワークロードを接続、管理、保護、モニタリングできます。Anthos Service Mesh を使用して、複数の GKE クラスタにまたがるメッシュを設定する方法の詳細については、GKE クラスタを Anthos Service Mesh に追加するをご覧ください。上記で確立した基準に照らしてマルチクラスタ Ingress と Anthos Service Mesh を評価するには、相対的な重要度で番号付けされた次のリストを使用します。

  1. Google が管理するソリューション。マルチクラスタ Ingress と Anthos Service Mesh は、どちらもフルマネージド プロダクトです。そうしたプロダクトは、Google によって管理されるため、プロビジョニングは不要です。
  2. アーキテクチャと相互作用するインターフェースAnthos Service Mesh は、Istio をコアとして使用します。Anthos Service Mesh API は、Kubernetes リソースモデルに基づく宣言型構成をサポートします。
  3. GKE 環境外へのサービス公開。マルチクラスタ Ingress と Anthos Service Mesh の Ingress ゲートウェイを使用すると、GKE クラスタの外部にワークロードを公開できます。
  4. クラスタ間通信。Anthos Service Mesh は、Pod が動作しているクラスタに関係なく、直接 Pod 間に安全な通信チャネルを設定します。この設定により、このような通信チャネルのプロビジョニングと構成に追加の時間をかける必要がなくなります。Anthos Service Mesh では、フリートとサービスの同一性の概念を使用して、GKE サービス ディスカバリを複数のクラスタに拡張します。したがって、メッシュ内の他のクラスタで実行されているワークロードを検出するために自分のワークロードを変更する必要はありません。
  5. トラフィック管理。Anthos Service Mesh には、高度なトラフィック管理機能があり、受信トラフィックを保護する仕組みとワークロードに転送する方法を制御できます。たとえば、Anthos Service Mesh は、Istio トラフィック管理機能フォールト インジェクション、リクエストのタイムアウト再試行サーキット ブレーカートラフィック ミラーリングトラフィックのシフトなど)をすべてサポートします。こうしたトラフィック管理機能を使用して、新しい GKE 環境への移行を簡素化することもできます。たとえば、古い環境から新しい環境へトラフィックを段階的にシフトできます。
  6. 追加ツールのプロビジョニングと構成。マルチクラスタ Ingress を使用するには、マルチクラスタ サービス ディスカバリの前提条件を満たす必要がありますが、GKE クラスタに他のツールをインストールする必要はありません。Anthos Service Mesh を使用するには、それをクラスタにインストールする必要があります。

Traffic Director

Traffic Director は、アプリケーション ネットワーキングを対象とするマネージド コントロール プレーンです。高度なトラフィック管理とオブザーバビリティ機能を備えた、充実したサービス メッシュ トポロジをプロビジョニングして構成できます。Traffic Director の詳細については、Traffic Director の概要Traffic Director の機能をご覧ください。複数の GKE クラスタにまたがるサービス メッシュをプロビジョニングして構成するには、マルチクラスタまたはマルチ環境の Traffic Director 構成を使用します。先ほど確立した基準に照らして Traffic Director を評価するには、相対的な重要度で番号付された次のリストを使用します。

  1. Google が管理するソリューション。Traffic Director は、フルマネージドのプロダクトです。このプロダクトは、Google によって管理されるため、プロビジョニングは不要です。
  2. アーキテクチャと相互作用するインターフェースTraffic Director の構成には、Google Cloud コンソール、Google Cloud CLI、Traffic Director API、Terraform などのツールを使用できます。Traffic Director は命令型構成モデルをサポートし、xDS および gRPC など、オープンソースのプロダクトやテクノロジーで構築されています。
  3. GKE 環境外へのサービス公開。Traffic Director は、サービス ネットワークの外部からの受信トラフィックを扱うように、ロードバランサをプロビジョニングして構成します。
  4. クラスタ間通信。Traffic Director のコントロール プレーンには、エンドポイント(複数のクラスタの GKE Pod など)をサービス バックエンドにグループ化できる API があります。これらのバックエンドは、メッシュ内の他のクライアントからルーティングできます。Traffic Director は GKE サービス ディスカバリと直接のインテグレーションが行われていませんが、gke-autoneg-controller などのオープンソース コントローラを使用して、任意にインテグレーションを自動化できます。また任意に、マルチクラスタ サービス ディスカバリを使用して、GKE サービス ディスカバリを複数のクラスタに拡張することもできます。
  5. トラフィック管理。Traffic Director は、新しい GKE 環境への移行を簡素化し、アーキテクチャの信頼性を強化するために使用できる高度なトラフィック管理機能を提供します。きめ細かいトラフィック ルーティング重み付けに基づくトラフィック分割トラフィックのミラーリング微調整されたロード バランシングなどの機能の構成については、高度なトラフィック管理の構成をご覧ください。
  6. 追加ツールのプロビジョニングと構成Traffic Director は GKE クラスタでは実行されません。Traffic Director のプロビジョニングと構成については、Traffic Director の設定の準備をご覧ください。Traffic Director がワークロードをサービス ネットワークに含めるために必要なサイドカー Pod を構成するには、Envoy で GKE Pod に Traffic Director をデプロイするをご覧ください。

Kubernetes とセルフマネージド DNS レコードの更新

クラスタに追加のソフトウェアをインストールせず、サービス メッシュが提供する機能を必要としない場合は、Kubernetes とセルフマネージド DNS レコードの更新オプションが選択できます。

このオプションを使用してクラスタ間の検出と接続を構成できますが、このドキュメントで説明する別のオプションのいずれかを選択することをおすすめします。セルフマネージド ソリューションを運用するために必要な作業量は、得られるメリットに対して大きすぎます。また、次の重要な制限事項も考慮してください。

GKE クラスタに type: LoadBalancer の Service または Ingress オブジェクトを作成すると、GKE は自動的にネットワーク ロードバランサおよび HTTP(S) ロードバランサを作成し、ロードバランサの IP アドレスを使用して、その Service を公開します。ロードバランサの IP アドレスを使用して、Service と通信できます。ただし、IP アドレスに依存しないように、IP アドレスを Cloud DNS を使った DNS レコードにマッピングするか、DNS を使ってクエリ可能 Service Directory エンドポイントにマッピングし、その DNS レコードを使用するようにクライアントを構成することをおすすめします。Service の複数のインスタンスをデプロイし、生成されたすべてのロードバランサ IP アドレスを関連する DNS レコードまたは Service Directory エンドポイントにマッピングできます。

Service のインスタンスを廃止するには、まず、関連する DNS レコードまたは Service Directory エンドポイントから、関連するロードバランサの IP アドレスを削除します。次に、クライアントの DNS キャッシュが更新されたことを確認してから、Service を廃止します。

異なる GKE クラスタ間で相互に通信できるようにワークロードを構成できます。そのためにはまず、内部 TCP/UDP ロードバランサまたは内部 HTTP(S) ロードバランサを使用して、クラスタ外にサービスを公開します。次に、ロードバランサの IP アドレスを DNS レコードまたは Service Directory エンドポイントにマッピングします。最後に、各クラスタの DNS レコードまたは Service Directory エンドポイントを指す type: ExternalName のサービスを作成します。

必要に応じて、追加の Ingress コントローラを使用し、単一のロードバランサと Cloud DNS レコード、または Service Directory エンドポイントを複数のワークロードと共有できます。たとえば、クラスタに Ingress コントローラをプロビジョニングする場合、GKE でその Ingress コントローラ用に作成したロードバランサに送信されたリクエストを複数の Service にリダイレクトするように構成できます。追加の Ingress コントローラを使用すると、管理が必要な DNS レコードや Service Directory エンドポイントの数を減らせます。

Kubernetes とセルフマネージド DNS レコードの更新を、先ほど確立した基準に照らして評価するには、相対的な重要度で番号付された次のリストを使用します。

  1. Google が管理するソリューション。このソリューションに含まれる Kubernetes オブジェクトは、自分で管理します。Cloud DNS、Service Directory、ロード バランシングは、Google が管理するサービスです。
  2. アーキテクチャと相互作用するインターフェースGKE はコアに Kubernetes を使用し、命令型と宣言型の両方の構成モデルをサポートしています。
  3. GKE 環境外へのサービス公開。DNS レコード、Service Directory エンドポイント、ロードバランサを使用して、GKE クラスタの外部にあるクライアントにサービスを公開できます。
  4. クラスタ間通信type: ExternalName の Service を使用すると、他の GKE クラスタにデプロイされたサービスを参照するエンドポイントを定義できます。この構成により、これらのサービスが、同じクラスタ内にデプロイされているかのように相互通信できます。
  5. トラフィック管理。このソリューションでは、Kubernetes と GKE によってすでに提供されている以外のトラフィック管理機能は利用できません。たとえば、このオプションでは、異なるクラスタ間のトラフィックのパーティショニングをサポートしていません。
  6. 追加ツールのプロビジョニングと構成。このオプションでは、GKE クラスタに追加のソフトウェアをプロビジョニングして構成する必要はありません。必要に応じて、Ingress コントローラをインストールできます。

アーキテクチャの選択

各オプションのすべての基準に値を割り当てた後、各オプションの合計スコアを計算します。各オプションの合計スコアを計算するには、基準に基づいてその設計オプションのすべての評価を追加します。たとえば、基準に対する環境のスコアが 10、別の基準に対するスコアが 6 の場合、そのオプションの合計スコアは 16 になります。

また、各評価基準のスコアに異なる重みを割り当てて、各評価基準の重要度を表すこともできます。たとえば、評価における分散ワークロード アーキテクチャのサポートよりも Google マネージド ソリューションのほうが重要な場合は、それを反映する乗数を次のように定義できます(Google マネージド ソリューションの乗数 1.0 と分散ワークロード アーキテクチャの乗数 0.7)。次に、これらの乗数を使用して、オプションの合計スコアを計算します。

評価した各環境の合計スコアを計算した後、合計スコアを降順にして環境を整理します。環境としてスコアが最も高いオプションを選択します。

このデータを表現する方法は複数あります。たとえば、レーダー チャートのような多変量データを表すグラフを使用して結果を可視化できます。

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

古い環境から新しい環境にデータを移行する方法については、Kubernetes から GKE への移行(古い環境から新しい環境にデータを移行する)をご覧ください。

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

古い環境から新しい環境にデータを移行する際のガイダンスについては、ワークロードをデプロイするをご覧ください。

このドキュメントで提案するすべてのアーキテクチャでは、既存の GKE 環境から新しいマルチクラスタ環境にワークロードを移行できます。ダウンタイムやカットオーバー期間はありません。ダウンタイムを発生させずにワークロードを移行するには、次のようにします。

  1. 既存の古い GKE クラスタを新しいマルチクラスタの GKE 環境に一時的に統合します。
  2. 新しいマルチクラスタ環境にワークロードのインスタンスをデプロイします。
  3. 既存の環境からトラフィックを段階的に移行します。そのため、ワークロードを新しい GKE クラスタに段階的に移行し、それから古い GKE クラスタを廃止します。

デプロイを完了する

ランタイム プラットフォームと環境のプロビジョニングおよび構成が完了したら、Kubernetes から GKE への移行、ワークロードのデプロイで説明されている作業を完了します。

環境の最適化

最適化が移行の最終フェーズになります。このフェーズでは、環境を以前よりも効率的なものにします。環境を最適化するには、環境が最適化の要件を満たすまで、次のイテレーションを複数回繰り返し実施します。

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

GKE 環境の最適化を行うには、Kubernetes から GKE への移行で、環境の最適化をご覧ください。

次のステップ