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

このドキュメントは、Google Kubernetes Engine(GKE)環境から新しい GKE 環境への移行を計画、設計、実装する際に役立ちます。方法を誤ると、別の環境へのアプリの移行は困難な作業になる可能性があります。そのため、移行は慎重に計画して実行する必要があります。

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

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

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

GKE 環境から別の GKE 環境に移行する理由には、次のようなものがあります。

  • GKE の機能を有効にするのはクラスタ作成時のみ。GKE は、新機能とセキュリティ修正によって常に進化しています。新機能と修正を最大限に活用するには、GKE クラスタノードプールのアップグレードが必要になる場合があります。新しいバージョンの GKE に自動アップグレードまたは手動のいずれかで実行します。

    一部の新しい GKE 機能を既存のクラスタで有効にすることはできません。新しい GKE クラスタでこれらの新機能を有効にする必要があります。たとえば、GKE での VPC ネイティブ ネットワークDataplane V2メタデータ隠蔽は、新しいクラスタを作成した場合にのみ有効にできます。これらの機能を作成した後に、既存のクラスタの構成を更新して有効にすることはできません。

  • インフラストラクチャの自動プロビジョニングと構成プロセスを実装する。インフラストラクチャを手動でプロビジョニングして構成する場合は、手動でエラーが発生しやすい方法に依存する代わりに、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 から 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 は、デプロイ先の GKE クラスタに関係なくワークロードを公開できる Google マネージド サービスです。また、GKE クラスタ間やリージョン間で共有ロードバランサを構成することもできます。マルチクラスタ GKE 環境でマルチクラスタ Ingress を使用する方法については、マルチクラスタ Ingress を使用したマルチクラスタ GKE のアップグレードおよびIstio メッシュ拡張を使用した移行のサポートをご覧ください。

マルチクラスタ サービス ディスカバリは、GKE 用の Kubernetes ネイティブのクラスタ間サービス ディスカバリと接続メカニズムです。マルチクラスタ サービス ディスカバリは、Kubernetes Service リソースをベースに、アプリがクラスタ境界を越えて互いを検出して接続できるようにします。マルチクラスタ Ingress とマルチクラスタ サービス ディスカバリを、先ほど確立した基準に照らして評価するには、以下のリストを使用し、相対的な重要度の高い順に説明します。

  1. Google が管理するソリューション。マルチクラスタ サービス ディスカバリは、GKE のフルマネージド機能です。リソースの構成(Cloud DNS ゾーンとレコード、ファイアウォール ルール、Traffic Director)を行うため、リソースを管理する必要がありません。
  2. アーキテクチャとやり取りするインターフェース。サービスは、ServiceExport という宣言型の Kubernetes リソースを使用して、他のクラスタにエクスポートされます。
  3. GKE 環境の外部にサービスを公開する。マルチクラスタ Ingress とマルチクラスタ サービス ディスカバリを使用すると、ワークロードをどこにデプロイしたかに関係なく、ワークロードを GKE クラスタの外部に公開できます。
  4. クラスタ間通信。既存の Service を他の GKE クラスタにエクスポートするには、ServiceExport オブジェクトを宣言します。同じフリート内の GKE クラスタは、ServiceExport オブジェクトを使用してエクスポートする Service を自動的にインポートします。マルチクラスタ サービス ディスカバリでは、エクスポートされた Service ごとに仮想 IP アドレスが設定されます。Multi Cluster Service Discovery は、Traffic Director リソース、Cloud DNS、ファイアウォール ルールを自動的に構成し、Kubernetes DNS 規則の単純なバリエーションを使用して Service を検出して接続します。たとえば、my-svc Service にアクセスするには、my-svc.my-ns.svc.clusterset.local 名を使用できます。
  5. トラフィック管理。Multi Cluster Service Discovery はシンプルなレイヤ 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 間で直接安全な通信チャネルを設定します。この設定により、これらの通信チャネルのプロビジョニングと構成に余分な労力を費やす必要がなくなります。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 の構成には、Cloud Console、gcloud コマンドライン インターフェース、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 を構成するには、Traffic Director を Envoy で GKE Pod にデプロイするをご覧ください。

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

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

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

GKE クラスタに Service type: LoadBalancerまたは Ingress オブジェクトを作成すると、GKE は自動的にネットワーク ロードバランサおよびHTTP(S) ロードバランサを作成し、ロードバランサの IP アドレスを使用して、そのサービスを公開します。ロードバランサの IP アドレスを使用して、Service と通信できます。ただし、IPアドレスに依存しないように、IP アドレスをクラウド 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 の Service を作成します。

必要に応じて、追加の 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 Endpoints、ロードバランサを使用して、GKE クラスタの外部にあるクライアントにサービスを公開できます。
  4. クラスタ間通信type: ExternalName のサービスを使用すると、他の GKE クラスタにデプロイされたサービスを指すエンドポイントを定義できます。この構成により、これらのサービスが、同じクラスタ内にデプロイされているかのように通信できます。
  5. トラフィック管理。このソリューションでは、Kubernetes と GKE によってすでに提供されている以上のトラフィック管理機能は提供されません。たとえば、このオプションは異なるクラスタ間のトラフィックのパーティショニングをサポートしていません。
  6. 追加ツールのプロビジョニングと構成。このオプションを使用する場合、GKE クラスタで追加のソフトウェアをプロビジョニングして構成する必要はありません。必要に応じて、Ingress コントローラをインストールできます。

アーキテクチャの選択

各オプションのすべての基準に値を割り当てた後、各オプションの合計スコアを計算します。各オプションの合計スコアを計算するには、基準に基づいてそのオプションのすべての評価を追加します。たとえば、環境が 1 つの評価基準で 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 への移行で、環境の最適化をご覧ください。

次のステップ