--- title: "Cloud Service Meshとは？GKEでの構築手順・料金と2028年ISTIODサポート終了への移行判断【2026年10月】" url: "https://www.issoh.co.jp/tech/details/18409/" published: 2026-10-17 updated: 2026-10-17 categories: ["Google Cloud"] publisher: "株式会社一創" --- # Cloud Service Meshとは？GKEでの構築手順・料金と2028年ISTIODサポート終了への移行判断【2026年10月】 Cloud Service Meshは、Google CloudがIstioをベースに提供するマネージドのサービスメッシュです。2024年にAnthos Service MeshとTraffic Directorを統合して生まれ、2026年9月28日には旧来のISTIOD方式のコントロールプレーンを2028年3月1日でサポート終了にすると告知されました。この記事では、3つのコントロールプレーン実装の違い、1クライアント月約0.5ドルの料金の試算、gcloudでGKEに入れるコマンド、ISTIOD終了に向けた移行作業、OSSのIstioとの選び分けを順に整理します。 ## まとめ：Cloud Service MeshはGKE上のIstio運用をGoogleに預けるマネージド版 Cloud Service Meshを一言で表すと、Istioのコントロールプレーンの運用と更新をGoogleに任せるサービスです。設定はOSSのIstioと同じVirtualServiceやAuthorizationPolicyで書き、サイドカー付きのPodが1つ増えるごとに月約0.50ドルがかかります。GKEを主な実行基盤にしていて、Istioのバージョン追従に人を割けない組織なら、自前運用より安く済みます。 すでにAnthos Service Meshを使っている組織は、まず自社がISTIOD方式かどうかを確認してください。2028年3月1日を過ぎると、移行していないマネージドISTIODのクラスタではサイドカーが通信できなくなります。逆に、アンビエントモードやWasmPluginに頼る構成、GKE以外のクラウドが主体の構成では、OSSのIstioを自前で運用するほうが制約に当たりません。 ## Cloud Service Meshの統合経緯とコントロールプレーン構成 名称が何度も変わったため、古い記事と現行のドキュメントで用語が食い違います。ここでは2026年10月時点の[Cloud Service Meshの公式概要](https://docs.cloud.google.com/service-mesh/docs/overview)に沿って、製品の範囲を確認します。 ### 2024年5月23日のサービス統合で変わった製品の範囲と提供の経緯 Cloud Service Meshは2024年4月11日の[Google Cloud公式ブログ](https://cloud.google.com/blog/products/networking/introducing-cloud-service-mesh)で発表され、同年6月3日に一般提供となりました。中身は、GKE向けのIstioベースのAnthos Service Meshと、VMやgRPC向けのマネージドなコントロールプレーンだったTraffic Directorを1つにまとめたものです。[マネージドコントロールプレーンのページ](https://docs.cloud.google.com/service-mesh/docs/managed-control-plane-overview)は、統合日を2024年5月23日と記録しています。 Anthos Service Meshは、Anthos（のちのGKE Enterprise）を構成する機能の1つでした。Anthos全体の改称の流れは[Anthosの名称変更とGKEへの統合の解説](https://www.issoh.co.jp/tech/details/13263/)にまとめています。 ### コントロールプレーンの3つの実装と新規フリートで使われる既定の方式 同じCloud Service Meshでも、コントロールプレーンの実装は3種類あります。どれで動いているかによって、2028年に向けて必要な作業が変わります。 | 実装 | 動く場所 | 2026年10月時点の扱い | | ----------------- | ----------- | --------------------- | | TRAFFIC\_DIRECTOR | Googleの管理基盤 | 2024年7月1日以降の新規フリートの既定 | | ISTIOD（マネージド） | Googleの管理基盤 | 非推奨・2028年3月1日終了 | | クラスタ内（in-cluster） | 利用者のクラスタ | GKE上は非推奨・2028年3月1日終了 | 新規フリートへのISTIOD方式の提供は2024年9月8日で終わっています。つまり2024年秋以降にマネージド版を有効にしたクラスタは、原則としてTRAFFIC\_DIRECTORで動いています。クラスタ内方式は、Google Distributed Cloud（ソフトウェアのみ）上では引き続きサポート対象です。 ### GKEとCompute Engineで異なる設定用APIとプロキシの方式 公式概要によると、GKEのワークロードはOSSのIstio APIで設定し、Compute EngineのワークロードはGoogle Cloud固有のサービスルーティングAPIで設定します。VMではEnvoyプロキシを置く方式と、Go・C++・Java・Pythonで使えるproxyless gRPCの方式を選べます。 GKEで使う限り、書くマニフェストはOSSのIstioとほぼ同じです。Istioのistiodとデータプレーンの役割分担は[Istioの仕組みとサイドカー／アンビエント方式の解説](https://www.issoh.co.jp/tech/details/15568/)で先に押さえておくと、この先の手順が読みやすくなります。 ## Cloud Service Meshの料金を1クライアント月約0.5ドルで試算する方法 料金はコントロールプレーンの台数ではなく、メッシュに参加するクライアントの数で決まります。[公式の料金ページ](https://cloud.google.com/service-mesh/pricing)の単価は、1クライアントあたり時間0.0006945ドル、月にして約0.50ドルです。 ### 課金対象はサイドカー付きPod・Cloud Run・proxyless gRPCの実行数 クライアントとして数えられるのは、メッシュが有効なGKEのPod、Cloud Runのインスタンス、proxyless gRPCのインスタンスです。Deploymentのレプリカが3つに増えれば、3クライアント分の課金になります。HPAで夜間に縮むサービスは、その時間だけ安くなる計算です。 料金にはマネージドのコントロールプレーン、標準メトリクスを使うテレメトリダッシュボード、証明書ごとの課金がないMesh CAが含まれます。カスタムメトリクスだけはCloud Monitoringの料金が別にかかります。 ### Pod数20と200の構成で比べる月額料金と別料金になる監視費 常時稼働のPod数で月額（730時間）を出すと、次のとおりです。 | 構成 | クライアント数 | 月額の目安 | | ----------------- | ------- | ------ | | 小規模（10サービス×2レプリカ） | 20 | 約10ドル | | 中規模（40サービス×5レプリカ） | 200 | 約101ドル | 金額だけを見れば、自前でistiodを動かすノード代と大差はありません。差が出るのは人件費の側で、Istioのマイナー版は年に数回出るため、クラスタ内で運用すると更新の検証と適用が毎回発生します。マネージド版ではこの作業がGoogle側に移ります。 ## GKEにCloud Service Meshを入れるgcloudの作業手順 ここからは[公式のプロビジョニング手順](https://docs.cloud.google.com/service-mesh/docs/onboarding/provision-control-plane)に沿って、既存のGKEクラスタにフリートAPIでマネージド版を入れます。GKE自体の構成や料金は[GKEのAutopilot／Standardの違いの解説](https://www.issoh.co.jp/tech/details/15661/)を参照してください。 ### Workload Identityの有効化とGKEのリリースチャネルの事前確認 前提条件は、課金が有効なプロジェクト、サポート対象のリージョンとGKEバージョン、そしてクラスタとノードプールでのWorkload Identityの有効化です。Workload Identityの仕組みと設定は[GKEのWorkload Identityの解説](https://www.issoh.co.jp/tech/details/5256/)で扱っています。 もう1つ見落としやすい条件が、GKEのリリースチャネルです。メッシュの更新はRapid、Regular、Stableの順に配られ、マネージド版ではチャネルの変更がサポートされません。本番より先に更新を受ける検証クラスタを、1つ早いチャネルに置いておく構成を公式は推奨しています。 ### フリート登録から–management automaticで有効化するまでのコマンド APIの有効化、フリートでのメッシュ機能の有効化、クラスタのフリート登録、自動管理の指定を順に実行します。 ``` FLEET_PROJECT_ID=my-fleet-project CLUSTER_NAME=prod-cluster CLUSTER_LOCATION=asia-northeast1 gcloud services enable mesh.googleapis.com --project=$FLEET_PROJECT_ID gcloud container fleet mesh enable --project $FLEET_PROJECT_ID gcloud container clusters update $CLUSTER_NAME \ --location $CLUSTER_LOCATION --fleet-project $FLEET_PROJECT_ID gcloud container fleet memberships list --project $FLEET_PROJECT_ID gcloud container fleet mesh update \ --management automatic \ --memberships $CLUSTER_NAME \ --project $FLEET_PROJECT_ID \ --location $CLUSTER_LOCATION ``` 上の例では–membershipsにクラスタ名を入れていますが、実際にはmemberships listで表示されたメンバーシップ名を渡してください。Terraformで管理する場合は、GKE Hubのfeature membershipモジュールで同じ設定を書けます。 ### describeでimplementation欄を確かめサイドカー注入ラベルを付ける作業 数分待ってから状態を確認します。controlPlaneManagementのstateがACTIVEになり、implementation欄にTRAFFIC\_DIRECTORと出ていれば、新方式で動いています。 ``` gcloud container fleet mesh describe --project $FLEET_PROJECT_ID kubectl label namespace my-app \ istio.io/rev- istio-injection=enabled --overwrite kubectl get namespace -L istio-injection kubectl rollout restart deployment -n my-app ``` ラベルを付けただけでは、既存のPodにサイドカーは入りません。最後のrollout restartでPodを作り直し、各PodのコンテナにEnvoyが加わったことを確かめます。サービス間通信の暗号化はmTLSで行われ、その仕組みは[mTLS（相互TLS認証）の解説](https://www.issoh.co.jp/tech/details/14378/)で説明しています。 ## 2028年3月1日のISTIODサポート終了に向けた自社クラスタの移行作業 2026年9月28日の[Cloud Service Meshのリリースノート](https://docs.cloud.google.com/service-mesh/docs/release-notes)は、GKE上のクラスタ内コントロールプレーンとマネージドISTIODの両方を非推奨とし、サポート終了を2028年3月1日と告知しました。終了後、マネージドISTIODのまま残ったクラスタではサイドカーがリクエストを送受信できなくなると明記されています。 ### クラスタ内istiodかマネージドISTIODかを見分ける確認コマンド 最初の作業は、自社のクラスタがどの実装で動いているかの棚卸しです。 ``` kubectl get deployment -n istio-system kubectl -n istio-system get controlplanerevision gcloud container fleet mesh describe --project $FLEET_PROJECT_ID \ --format="yaml(membershipStates)" ``` istio-systemにistiodで始まるDeploymentがあれば、クラスタ内方式です。マネージド版は同じクラスタにクラスタ内のコントロールプレーンが同居する構成を認めておらず、公式がサポートする移行方法もカナリアクラスタ方式だけです。新しいクラスタを用意して、ワークロードを移し替えます。describeの出力でimplementationがISTIODなら、マネージドISTIOD方式です。こちらは既存のクラスタのままTRAFFIC\_DIRECTORへ切り替えられます。 ### TRAFFIC\_DIRECTORへの切り替えで止まる非対応機能の洗い出し 切り替えの前に、TRAFFIC\_DIRECTORで使えない設定を外す必要があります。[マネージド版のサポート機能一覧](https://docs.cloud.google.com/service-mesh/docs/supported-features-managed)から、実務で当たりやすいものを並べます。 - WasmPlugin API、IstioOperator API、KubernetesのIngress APIは使えない - istioctl psは使えず、gcloud beta container fleet mesh debugで代替する - hostNetwork: trueのPodはメッシュに入れられない - マルチクラスタはmulti-primary構成だけで、primary-remote構成は不可 - Redis・MySQL・KafkaなどはL7の機能が使えず、TCPのバイトストリームとして通す Istioのマルチクラスタ用シークレットで複数クラスタをつないでいる場合も、宣言型の設定へ書き換えが要ります。互換性レポートを有効にし、フリートがMODERNIZATION\_COMPATIBLEを返すまで、ここを直していきます。 ### Google主導の自動移行と顧客主導で開始する移行の手順と通知条件 [モダナイズの公式ガイド](https://docs.cloud.google.com/service-mesh/docs/modernization)によると、移行の進め方はGoogle主導と顧客主導の2つです。顧客主導で開始する場合に使う指定が、次のコマンドにある–modernization-strategyです。既定はGoogle主導で、組織内のすべてのフリートが互換になった時点で日程が組まれ、フリートには14日以上前、クラスタには24時間以上前に通知が来ます。非互換のフリートが1つでも残っていると、組織全体の移行が止まります。 ``` # 自社の都合で今すぐ移行を始める gcloud alpha container fleet mesh update \ --modernization-strategy automatic --project $FLEET_PROJECT_ID # 検証クラスタから先に移す gcloud container clusters update stg-cluster --location $CLUSTER_LOCATION \ --update-labels="mesh-modernization-order=early" ``` 移行後は最低6営業日の様子見期間があり、その間ならdeferredを指定して戻せます。MODERNIZATION\_FINALIZEDになると戻せません。Deploymentは自動で再起動されますが、StatefulSetとDaemonSetは手動で再起動しないと旧istiodにつながったままになります。データベースやキューをStatefulSetで動かしている場合は、再起動の時間帯を先に決めておきます。 ## Cloud Service MeshとOSSのIstioを選び分ける採用条件と見送る条件 ここまでの料金と制約から、判断を言い切ります。Cloud Service MeshはGKEを中心に据えた組織のためのIstioで、マルチクラウドの共通基盤として選ぶ製品ではありません。 ### Cloud Service Meshの採用条件：GKE中心で更新担当を置けない現場 次のどれかに当てはまるなら、Cloud Service Meshを第一候補にしてかまいません。 - 本番のKubernetesがGKEで、サービス間のmTLSと認可を全サービスへ一律にかけたい - Istioの更新とCVE対応を、社内の担当者ではなくGoogleに任せたい - VMやCloud Runのサービスも、同じメッシュの監視画面で見たい 費用はPod200個で月約101ドルです。Istioの更新に毎回数人日を使っている組織なら、この金額で運用工数を手放せます。GKEとメッシュの構成設計、既存のAnthos Service Meshからの移行計画をまとめて相談したい場合は、[Google Cloudを含むインフラ構築の支援](https://www.issoh.co.jp/service/system/aws/)で構成案から検討できます。 ### OSSのIstioを選ぶ条件：アンビエントやWasmPluginが必要な構成 2026年10月時点のマネージド版のサポート機能一覧には、アンビエントモードの記載がありません。サイドカーのメモリ消費を減らす目的でアンビエントモードを使いたいなら、OSSのIstioを自前で運用します。WasmPluginで独自の処理を差し込んでいる構成も同じです。 AWSやAzureのクラスタが主体で、GKEが一部にすぎない場合もCloud Service Meshは採用しません。クラウド各社のマネージドメッシュには提供終了の前例があり、AWSは[2026年9月にAWS App Meshを終了](https://www.issoh.co.jp/tech/details/15478/)しています。今回のISTIOD終了も、マネージド版の内部実装が利用者の都合と関係なく入れ替わる例です。サービスが10個に満たず、mTLSも不要な規模なら、そもそもメッシュ自体が過剰です。メッシュが要るかどうかの判断は[サービスメッシュの導入判断の解説](https://www.issoh.co.jp/tech/details/13224/)で整理しています。 ## Cloud Service Meshの導入と移行でよくある質問 Cloud Service Meshを検討する段階で出やすい質問を5つ取り上げます。 ### Cloud Service MeshとAnthos Service Meshは同じものですか？ Anthos Service Meshは、2024年5月にTraffic Directorと統合されてCloud Service Meshになりました。既存のAnthos Service Meshの利用者は、引き続きIstio APIで設定を書きます。ただし統合後はコントロールプレーンの実装がTRAFFIC\_DIRECTORへ移りつつあり、旧来のISTIOD方式は2028年3月1日にサポートが終わります。名前が変わっただけと考えず、動いている実装を確認してください。 ### Cloud Service MeshとOSSのIstioの違いは何ですか？ 設定に使うAPIは同じIstio APIで、違いは運用の担い手と使える機能の範囲です。Cloud Service Meshではコントロールプレーンの運用、更新、証明書の発行をGoogleが担い、利用者はクライアント数に応じた料金を払います。その代わり、WasmPluginやIstioOperatorなど一部のAPIが使えず、アンビエントモードもサポート機能一覧に載っていません。 ### Cloud RunのサービスもCloud Service Meshに入れられますか？ Cloud Runのサービスもメッシュへの参加対象です。Cloud Runへの対応はTraffic Director由来の機能として統合時に加わり、料金ページもCloud Runのインスタンスを課金対象のクライアントに数えています。GKEのサービスとCloud Runのサービスを同じメッシュでつなぐことで、ルーティングや監視を共通のメッシュでそろえることが可能です。設定はGKEのIstio APIとは別の手順になるため、公式ドキュメントのCloud Run向けの章を参照してください。 ### GKE AutopilotのクラスタでもCloud Service Meshは使えますか？ GKE Autopilotのクラスタもマネージド版の導入対象です。Google CloudはAutopilotクラスタにマネージド版を入れるチュートリアルを公開しており、istioctlなどのクライアント側ツールを使わずにフリートAPIだけで有効化できます。Autopilotでは、ワークロードやゲートウェイをデプロイするまでデータプレーンの状態がPROVISIONINGのまま残る場合があり、デプロイ後に確認する必要がある状態です。故障ではないので、アプリを載せてから再確認してください。 ### 2028年3月1日までに移行しないとどうなりますか？ クラスタ内方式は、更新とセキュリティパッチ、Googleのサポートが止まります。動き続けても、新しいCVEへの修正は届きません。マネージドISTIOD方式はより深刻で、移行していないクラスタではサイドカーがリクエストを送受信できなくなるとリリースノートに書かれています。Google主導の移行は非互換の設定が残っていると始まらないため、期限の直前ではなく、2027年中に互換性の確認を終えておくのが安全です。 ## 関連記事 - [Istioとは？サービスメッシュの仕組みとサイドカー/アンビエント方式・導入判断を解説【2026年版】](https://www.issoh.co.jp/tech/details/15568/)：Cloud Service Meshの土台であるOSSのIstioの仕組み。 - [サービスメッシュとは？サイドカー方式の仕組みとAPIゲートウェイとの違い・導入判断を解説](https://www.issoh.co.jp/tech/details/13224/)：メッシュそのものが必要かを判断する前提知識。 - [Anthosとは？GKE Enterpriseへ統合されたマルチクラウドKubernetes管理の全体像](https://www.issoh.co.jp/tech/details/13263/)：Anthos Service Meshが属していた製品群の変遷。 - [Google Kubernetes Engine（GKE）とは？Autopilot／Standardの違い・料金モデルとEKSとの使い分けを実装者目線で解説](https://www.issoh.co.jp/tech/details/15661/)：メッシュを載せるGKE側の構成と料金。 - [Linkerdとは？軽量なRust製サービスメッシュの仕組みとIstioとの選び分けを解説【2026年版】](https://www.issoh.co.jp/tech/details/15570/)：Istio系以外の軽量なメッシュを比べたい場合に。 --- 出典: [Cloud Service Meshとは？GKEでの構築手順・料金と2028年ISTIODサポート終了への移行判断【2026年10月】]()（株式会社一創）