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の公式概要に沿って、製品の範囲を確認します。
2024年5月23日のサービス統合で変わった製品の範囲と提供の経緯
Cloud Service Meshは2024年4月11日のGoogle Cloud公式ブログで発表され、同年6月3日に一般提供となりました。中身は、GKE向けのIstioベースのAnthos Service Meshと、VMやgRPC向けのマネージドなコントロールプレーンだったTraffic Directorを1つにまとめたものです。マネージドコントロールプレーンのページは、統合日を2024年5月23日と記録しています。
Anthos Service Meshは、Anthos（のちのGKE Enterprise）を構成する機能の1つでした。Anthos全体の改称の流れはAnthosの名称変更とGKEへの統合の解説にまとめています。
コントロールプレーンの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の仕組みとサイドカー／アンビエント方式の解説で先に押さえておくと、この先の手順が読みやすくなります。
Cloud Service Meshの料金を1クライアント月約0.5ドルで試算する方法
料金はコントロールプレーンの台数ではなく、メッシュに参加するクライアントの数で決まります。公式の料金ページの単価は、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の作業手順
ここからは公式のプロビジョニング手順に沿って、既存のGKEクラスタにフリートAPIでマネージド版を入れます。GKE自体の構成や料金はGKEのAutopilot／Standardの違いの解説を参照してください。
Workload Identityの有効化とGKEのリリースチャネルの事前確認
前提条件は、課金が有効なプロジェクト、サポート対象のリージョンとGKEバージョン、そしてクラスタとノードプールでのWorkload Identityの有効化です。Workload Identityの仕組みと設定はGKEのWorkload Identityの解説で扱っています。
もう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認証）の解説で説明しています。
2028年3月1日のISTIODサポート終了に向けた自社クラスタの移行作業
2026年9月28日のCloud Service Meshのリリースノートは、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で使えない設定を外す必要があります。マネージド版のサポート機能一覧から、実務で当たりやすいものを並べます。
- 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主導の自動移行と顧客主導で開始する移行の手順と通知条件
モダナイズの公式ガイドによると、移行の進め方は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を含むインフラ構築の支援で構成案から検討できます。
OSSのIstioを選ぶ条件：アンビエントやWasmPluginが必要な構成
2026年10月時点のマネージド版のサポート機能一覧には、アンビエントモードの記載がありません。サイドカーのメモリ消費を減らす目的でアンビエントモードを使いたいなら、OSSのIstioを自前で運用します。WasmPluginで独自の処理を差し込んでいる構成も同じです。
AWSやAzureのクラスタが主体で、GKEが一部にすぎない場合もCloud Service Meshは採用しません。クラウド各社のマネージドメッシュには提供終了の前例があり、AWSは2026年9月にAWS App Meshを終了しています。今回のISTIOD終了も、マネージド版の内部実装が利用者の都合と関係なく入れ替わる例です。サービスが10個に満たず、mTLSも不要な規模なら、そもそもメッシュ自体が過剰です。メッシュが要るかどうかの判断はサービスメッシュの導入判断の解説で整理しています。
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年版】：Cloud Service Meshの土台であるOSSのIstioの仕組み。
- サービスメッシュとは？サイドカー方式の仕組みとAPIゲートウェイとの違い・導入判断を解説：メッシュそのものが必要かを判断する前提知識。
- Anthosとは？GKE Enterpriseへ統合されたマルチクラウドKubernetes管理の全体像：Anthos Service Meshが属していた製品群の変遷。
- Google Kubernetes Engine（GKE）とは？Autopilot／Standardの違い・料金モデルとEKSとの使い分けを実装者目線で解説：メッシュを載せるGKE側の構成と料金。
- Linkerdとは？軽量なRust製サービスメッシュの仕組みとIstioとの選び分けを解説【2026年版】：Istio系以外の軽量なメッシュを比べたい場合に。
