Istioの最新バージョンは1.31｜1.28〜1.31の新機能・サポート期限とアップグレード手順

Istioの最新バージョンは1.31で、2026年9月21日時点の最新パッチは1.31.1です。2025年11月に出た1.28は2026年7月1日にコミュニティのサポートが終わり、1.29も2026年10月12日に終了する予定です。Istioは約3か月ごとにマイナー版を出し、サポートは次々版（N+2）の公開から6週間で切れます。1年前の版はもう修正パッチが出ません。この記事では1.28から1.31までの新機能と破壊的変更を版ごとに整理し、手元の版を確認する方法と、現在の版から1.31へ上げる経路をまとめます。

まとめ：Istio最新バージョン1.31とサポート期限・更新の要点

• 最新版は1.31（1.31.0は2026年8月31日公開、最新パッチは1.31.1・2026年9月21日）。サポート中の系列は1.29・1.30・1.31の3本です。
• 1.28は2026年7月1日にサポート終了。最終パッチは1.28.10です。1.29は2026年10月12日に終了する予定です。
• 1.30以降はKubernetes 1.32〜1.36が対象。Kubernetes 1.31のクラスタでは、Istioより先にKubernetesを上げる必要があります。
• サイドカーモードのカナリア（リビジョン）アップグレードなら2マイナー飛ばしが可能（1.29から1.31へ直接）。インプレースアップグレードとアンビエントモードは1マイナーずつ上げます。
• 1.30へ上げる前にGateway APIのCRDをv1.5.xへ上げる。上げ忘れるとTLSRouteが見えなくなり、TLSパススルーのリスナーが黙って無効になります。
• gcr.io/istio-releaseは2026年12月に廃止。1.31以降のイメージはDocker Hub（docker.io/istio）にしか公開されません。
• 手元の版はistioctl versionで確認し、更新前にistioctl x precheck、更新後にistioctl analyzeを実行します。

Istioのリリース履歴とサポート期限（1.27〜1.31）

次の表は、公式のSupported Releasesのサポート状況表と、各版のリリース告知をもとにまとめたものです（2026年9月27日時点）。公開日はリリース告知とGitHubのリリースの日付を使っています。

1.28の対応Kubernetesは、リリース告知では「1.29〜1.34」、現在のサポート状況表では「1.30〜1.34」と記載が分かれています。これから構成を決めるなら狭いほうの1.30〜1.34を前提にしてください。

サポート期間の規則は「マイナー版はN+2の公開から6週間後まで」です。1.29の終了予定日10月12日は、1.31.0の公開（8月31日）から6週間後にあたります。同じ計算で、1.30のサポートは次の1.32公開の6週間後に切れます。版ごとのKubernetes側の期限はKubernetesの最新バージョンは1.37｜確認方法・EOL一覧とアップグレード手順で確認できます。

手元のIstioバージョンの確認方法

istioctl versionを実行すると、istioctl自身（client）、コントロールプレーン（istiod）、データプレーン（各プロキシ）の3つの版が表示されます。版の不一致は、istioctlだけを先に更新した場合や、複数リビジョンの併用、データプレーンの更新途中などで生じます。接続先のコントロールプレーンとプロキシの版差を確認してください。

$ istioctl version
$ istioctl version --remote=false      # クラスタに接続せずistioctlの版だけを表示
client version: 1.31.1
$ istioctl proxy-status                 # プロキシごとの接続先istiodと版を一覧
$ kubectl get pods -n istio-system -L istio.io/rev

公式の方針では、コントロールプレーンはデータプレーンより1マイナー先行してよいものの、データプレーンがコントロールプレーンより新しい状態は認められていません。istioctl proxy-statusで古い版のサイドカーが見つかったら、名前空間やPodのリビジョン指定とタグの参照先が更新先を指していることを確認してから、対象Podを再作成します。

Istio 1.28〜1.31の新機能（版ごとの差分）

アンビエントモードとAI推論まわりの変化は、版をまたいで追ったほうが分かりやすいので次の章でまとめています。ここではそれ以外の主な変更を版ごとに挙げます。

Istio 1.31：ゾーン認識の負荷分散とメッシュ全体の既定トラフィックポリシー（2026年8月31日）

• ゾーン認識の負荷分散：DestinationRuleとMeshConfigにzoneAwareLbSettingが加わりました。同じアベイラビリティゾーンのエンドポイントを優先し、足りないときだけ他ゾーンへあふれさせます。既存のlocalityLbSettingのように割合を固定で書く必要はありません。
• メッシュ全体の既定トラフィックポリシー：MeshConfigのdefaultTrafficPolicyでconnectionPoolとoutlierDetectionの基準値を設定でき、送信側の全クラスタがこれを引き継ぎます。
• 未登録ホストへの動的フォワードプロキシ：外向き通信ポリシーにALLOW_ANY_DYNAMIC_DNSモードが加わり、外部の宛先ごとにServiceEntryを書かなくても、HTTPのHostヘッダーから宛先を解決できます。
• セキュリティ：COMPLIANCE_POLICY=fips-140-3（TLS 1.2以上とFIPS準拠の暗号スイートを強制。GoコンポーネントにはGo 1.24以上とGOFIPS140=v1.0.0などを使った対応ビルドが必要）、AuthorizationPolicyのtrustDomainsとnotTrustDomainsが追加されました。
• 運用：istioctl manifest generate -oでマニフェストをファイルへ書き出せるようになりました。同梱のKialiアドオン（samples/addons）は1.31.1でv2.31.0です。

Istio 1.30：TrafficExtension APIとHelm v4対応（2026年5月18日）

• TrafficExtension API：Envoyを使うサイドカー・ゲートウェイ・waypointに、WasmとLuaの拡張を1つのAPIで設定できます。新しい拡張の推奨APIですが、1.30時点ではアルファです。既存のWasmPluginも引き続き利用でき、1.30での移行は必須ではありません。
• Gateway APIのTLSRoute：TLS終端と混在モードに対応し、east-westゲートウェイでTLSパススルーのリスナーを使えるようになりました。
• Helm v4（サーバーサイドアプライ）に対応：アップグレード時にwebhookのfailurePolicyの所有権が衝突する問題が解消されました。
• 1つのワークロードに複数のCUSTOM認可プロバイダー：APIのパスごとに、OAuth・LDAP・APIキーなど別々の認証方式を割り当てられます。
• 既定のイメージレジストリがregistry.istio.ioに変わりました。ただし次の1.31で方針が変わり、Docker Hubだけになります（後述）。

Istio 1.29：デバッグエンドポイントの認可とCRL対応（2026年2月16日）

• デバッグエンドポイントの認可が既定で有効に：ポート15014のデバッグエンドポイントでは、システム名前空間以外からのアクセスがconfig_dump・ndsz・edsz、それも同じ名前空間のプロキシに限定されます。Kialiや自作の監視ツールが影響を受けることがあります。
• ztunnelが証明書失効リスト（CRL）に対応：外部CAを接続している場合に、失効した証明書を拒否できます。
• istiod・istio-cni・ztunnelのNetworkPolicyをglobal.networkPolicy.enabled=trueで一括作成できます。
• istiodのGOMEMLIMITを自動設定：メモリ上限の90%が設定され、OOMで落ちにくくなりました。
• メトリクスの圧縮が既定で有効：Envoyのprometheus_statsがbrotli・gzip・zstdで返されます。

Istio 1.28：Gateway API v1.4とBackendTLSPolicy v1（2025年11月5日・サポート終了済み）

• BackendTLSPolicy v1：Gateway API v1.4に対応し、PILOT_ENABLE_ALPHA_GATEWAY_API=trueを設定しなくても使えるようになりました。ServiceEntryをtargetRefに指定して外部サービスへのTLSも設定できます。
• デュアルスタック（IPv4/IPv6）がベータに昇格しました。
• JWTのカスタムクレーム：RequestAuthenticationのspaceDelimitedClaimsで、空白区切りの独自クレームを検証できます。
• コンテナのセキュリティ：istio-validationとistio-proxyのコンテナにseccompProfileを設定できるようになり、istiodのNetworkPolicyも任意で作成できます。
• FrontendTLSValidation（GEP-91）に対応し、入口ゲートウェイでクライアント証明書を検証するmTLS構成を組めます。

Kubernetesのネイティブサイドカー（istio-proxyを通常のコンテナでなくinitコンテナとして動かす方式）は1.28ではなく、1つ前の1.27で既定になっています。istio-proxyを通常のコンテナとして書き換える前提の、独自のmutating webhookやコントローラーがあると、1.27以降で動かなくなることがあります。

1.28はすでにサポートが終わっており、脆弱性が見つかっても修正パッチは出ません。1.28で動いている環境は、次の「アップグレードの経路」の章を先に読んでください。

アンビエントモードの変化（1.28〜1.31）

サイドカーを使わないアンビエントモードは1.24で一般提供（GA）になり、それ以降の版ではマルチクラスタ構成と運用まわりの整備が続いています。サイドカー方式との仕組みの違いはIstioとは？サービスメッシュの仕組みとサイドカー/アンビエント方式・導入判断を解説【2026年版】で解説しています。

1.28のnftables対応は、インストール時に--set values.global.nativeNftables=trueを指定すると有効になります。1.28のマルチクラスタはまだアルファで、waypointの新しい転送動作に問題が出た場合は、istiodの環境変数AMBIENT_ENABLE_MULTI_NETWORK_WAYPOINT=falseで元の動作に戻せます。

1.29でDNSキャプチャが既定になりましたが、対象になるのは新しく起動したPodだけです。既存のPodにも適用するには、Podを再起動するか、istio-cniの更新時に--set cni.ambient.reconcileIptablesOnStartup=trueを指定します。

1.30では、サイドカーで運用しているメッシュをアンビエントへ移す移行ガイドが公開されました。名前空間ごとに段階的に移行でき、途中で元に戻すこともできます。移行中はサイドカーとアンビエントのワークロードが共存します。1.31では、サービスや名前空間に正規のwaypointとカナリアのwaypointを両方指定し、istio.io/use-waypoint-canary-weightアノテーションで一部の接続だけをカナリアへ流せるようになりました。

AI推論とエージェント通信への対応（推論拡張とagentgateway）

IstioのAI関連機能は、自前でホストする生成AIモデルへの推論リクエストを振り分ける「Gateway API Inference Extension」と、AIエージェントやMCPサーバーの通信を扱う「agentgateway」の2本立てです。版ごとの到達点は次のとおりです。

推論拡張は、InferencePoolというCRDと、既存のGateway API（Gateway・HTTPRoute）を組み合わせて使います。1.29時点では、istiodの環境変数ENABLE_GATEWAY_API_INFERENCE_EXTENSIONを有効にしないと動きません。1.28への更新でアルファ版とRC版のAPIは削除されたため、RC版のendpointPickerRef.portNumberを使っていた場合はendpointPickerRef.port.numberに書き換えます。ポート9002も暗黙には補われなくなりました。

agentgatewayはEnvoyとは別のデータプレーンで、有効にするとゲートウェイのPodでEnvoyの代わりに動きます。1.30ではPILOT_ENABLE_AGENTGATEWAY=trueを設定し、GatewayClassのistio-agentgatewayを使います。1.31ではwaypoint用のistio-agentgateway-waypointが加わりました。公式は1.30の時点で「early-access」と明言しているので、本番の入口に置くのはベータへの昇格を待つのが安全です。推論基盤の側の構成（KServeやTritonの選び方）はモデルサービングとは？推論APIの構成とKServe・Triton・BentoMLの選定基準を解説【2026年版】にまとめています。

アップグレード前に確認する破壊的変更（1.27→1.31）

各版のアップグレードノート（1.28・1.29・1.30・1.31）から、既存の設定の動きが変わる項目を抜き出しました。2マイナー飛ばしで上げる場合は、途中の版の項目もすべて対象になります。

影響が大きいのは1.30のGateway API CRDです。Istio 1.30はGateway API v1.5.1を前提にTLSRouteとReferenceGrantを標準チャネル（gateway.networking.k8s.io/v1）から読みます。CRDを古いまま残すとistiodからこれらのリソースが見えなくなり、TLSパススルーのリスナーはattachedRoutes: 0を報告したまま、エラーを出さずに設定されません。Istioを上げる前に次のコマンドでCRDを更新します。

$ kubectl apply -k "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v1.5.1"

1.31で問題になるのは大規模なアンビエントメッシュです。ztunnelが再接続時に送るリクエストに各リソースの版が含まれるようになり、サイズが約3分の1増えました。istiodのgRPC受信上限は既定で4MiBなので、およそ4万ワークロードを超えるとResourceExhaustedエラーで再接続を繰り返します。公式は1万ワークロード・サービスあたり約1MiBを目安にISTIO_GPRC_MAXRECVMSGSIZEを引き上げるよう案内しています（例：--set pilot.env.ISTIO_GPRC_MAXRECVMSGSIZE=33554432で32MiB）。

イメージ配布元の移行：gcr.io/istio-releaseの廃止

IstioはインフラをGoogle CloudからAWSへ移しており、gcr.io/istio-release・registry.istio.io・istio-release.storage.googleapis.comは2026年12月に廃止されます。この影響は1.31へ上げるかどうかに関係なく、古い版を使い続けている環境にも及びます。移行先は次のとおりです。

• コンテナイメージ：docker.io/istio（1.31以降はここにだけ公開）
• Helmチャート：https://blob.istio.io/istio-release/charts
• OCI形式のHelmチャート：ghcr.io/istio/release/charts
• istioctlなどその他の成果物：https://blob.istio.io/istio-release/releases

廃止に先立って、旧配布元を一時的に止める「スクリームテスト」が予定されています。公式告知では1回目を2026年9月15日に予定しており、その後の日程は10月13日（UTC 15時〜18時）、11月17日（UTC 15時〜21時）、12月8日UTC 15時〜9日UTC 15時の24時間です。日本時間では10月14日0時からの3時間などにあたります。この時間帯にノードの追加やPodの再スケジュールが起きると、イメージを取得できずに起動が止まります。署名鍵も変わり、1.31.1以降のイメージはistio-key-v2.pubで検証します。

現在の版から1.31へ上げる経路と手順

現在の版ごとの上げ方（カナリアは2マイナー飛ばし可）

リビジョンを使うカナリアアップグレードは2マイナー先まで直接上げられます（公式の例では1.15から1.17）。インプレースアップグレードは1マイナーずつ上げる必要があります。

1.28から上げるとき、Kubernetes側の制約に注意が必要です。1.28が動くKubernetesは1.30〜1.34、1.30以降が求めるのは1.32以上です。Kubernetes 1.30や1.31のクラスタでは、Kubernetesを1.32以上へ上げてからIstioを上げます。

アンビエントモードでは2マイナー飛ばしを避けて、1マイナーずつ上げるのが安全です。公式のアンビエント用アップグレードガイドでは、ztunnelとistio-cniのバージョン1.xは、同じ1.xまたは1マイナー新しい1.x+1のコントロールプレーンと互換性があるとされています。istiodを2マイナー先へ上げると、ztunnelの更新が終わるまでこの範囲から外れます。

カナリア（リビジョン）アップグレードの手順

新しい版のistiodを別リビジョンとして横に立て、名前空間のラベルを付け替えてからワークロードを再起動します。古いistiodを残しておけば、名前空間のラベルを旧リビジョンへ戻し、対象Podを再作成して旧版のサイドカーを注入することで切り戻せます。ゲートウェイも更新した場合は、その切り戻しを別途行います。

次の例は、旧リビジョン1-29-8で動いている名前空間app-nsを1.31.1へ上げる場合です。インストールされる版はリビジョン名ではなく、実行するistioctlの版で決まります。1.31.1のistioctlを使ってください。リビジョン名には.を使えないため、1-31-1のようにハイフンでつなぎます。既存のistiodに独自の設定値を渡している場合は、同じ設定を新しいリビジョンにも渡します。

# 1. 事前チェック（--from-versionで指定した版以降の動作変更も検査する）
$ istioctl x precheck --from-version 1.29

# 2. 新しいリビジョンのistiodを追加（既存のistiodはそのまま）
$ istioctl install --set revision=1-31-1

# 3. 名前空間を新リビジョンへ切り替え、再起動してサイドカーを入れ替える
$ kubectl label namespace app-ns istio-injection- istio.io/rev=1-31-1 --overwrite
$ kubectl rollout restart deployment -n app-ns
$ istioctl proxy-status

# 4. 全名前空間の移行が済んだら古いリビジョンを削除
$ istioctl uninstall --revision 1-29-8

名前空間が多い場合は、リビジョンを直接指定せずにリビジョンタグを使います。名前空間にはistio.io/rev=prodのようなタグを付けておき、istioctl tag set prod --revision 1-31-1 --overwriteでタグの参照先だけを差し替えます。ラベルを付け直す必要がなくなります。段階的に切り替える考え方はカナリアリリースとは？段階リリースの仕組み・他方式との違い・実装と採用判断を実装視点で解説と共通です。

アンビエントモードで上げるときの順序

アンビエントのデータプレーンは、ノードごとに動くztunnelと、L7処理を担うwaypointに分かれているため、更新の手順が増えます。順序は次のとおりです。

1. CRDとコントロールプレーン（istiod）を上げる
2. istio-cniのDaemonSetを上げる（リビジョンを使ってもカナリア更新はできません）
3. ztunnelのDaemonSetを上げる
4. リビジョンタグを1つずつ新しいリビジョンへ向け、waypointとゲートウェイを切り替える

ztunnelはノード単位のプロキシなので、インプレースで更新すると、リビジョンを使っていてもそのノードのアンビエント通信が一瞬途切れます。影響を受けるのは主に長時間張りっぱなしのTCP接続です。こうした接続を持つアプリケーションがある場合は、ノードをcordonしてdrainしてからztunnelを更新します。

更新後の設定検証：istioctl analyzeのCI組み込み

istioctl analyzeは、クラスタや手元のYAMLを検査して設定の誤りを報告するコマンドです。1.31.1には53個のアナライザーがあり、Gateway APIのCRDがそのIstioの要求版に達しているかを調べるk8sgateway.CRDVersionAnalyzerも含まれます。--use-kube=falseを付ければクラスタに接続せずにYAMLだけを検査できます。存在しないGatewayとサブセットを参照する次のVirtualService（vs.yaml）を、istioctl 1.31.1で検査しました。

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
  namespace: default
spec:
  hosts:
  - reviews
  gateways:
  - bookinfo-gateway
  http:
  - route:
    - destination:
        host: reviews
        subset: v2

結果は次のとおりです。

$ istioctl analyze --use-kube=false vs.yaml
Error [IST0101] (VirtualService default/reviews vs.yaml:10) Referenced gateway not found: "bookinfo-gateway"
Error [IST0101] (VirtualService default/reviews vs.yaml:14) Referenced host+subset in destinationrule not found: "reviews+v2"
Warning [IST0132] (VirtualService default/reviews vs.yaml:10) one or more host [reviews] defined in VirtualService default/reviews not found in Gateway default/bookinfo-gateway.
Error: Analyzers found issues when analyzing namespace: default.
See https://istio.io/v1.31/docs/reference/config/analysis for more information about causes and resolutions.
$ echo $?
79

既定ではErrorレベルの問題が見つかると終了コードが0以外（この例では79）になります。Warningだけなら0で終了するため、警告もCIで失敗扱いにする場合は--failure-threshold Warningを指定します。更新直後はクラスタに対してistioctl analyze --all-namespacesを実行し、新しい版で警告に変わった設定がないかを確認します。

よくある質問

Istioの最新バージョンはいくつですか？

最新のマイナー版は1.31です（1.31.0は2026年8月31日公開）。2026年9月27日時点の最新パッチは2026年9月21日公開の1.31.1です。同じ日に1.30.5と1.29.8も出ています。最新の版はGitHubのリリース一覧で確認できます。

Istio 1.28のサポートはいつまでですか？

2026年7月1日に終了しました。最終パッチは1.28.10です。これ以降に見つかった脆弱性は1.28では修正されないため、サイドカーモードのカナリアアップグレードでは1.30を経由して1.31へ、アンビエントモードでは1.29、1.30、1.31の順に1マイナーずつ更新してください。

Istio 1.29から1.31へ直接アップグレードできますか？

リビジョンを使ったカナリアアップグレードなら直接上げられます。インプレースアップグレードでは1.30を経由する必要があります。アンビエントモードでは、ztunnelとistio-cniの互換がコントロールプレーンの1マイナー差までなので、1つずつ上げるのが安全です。1.29のサポートは2026年10月12日に終了する予定です。

Istioのアンビエントモードは本番環境で使えますか？

アンビエントモードの中核機能（ztunnel・waypoint・API）は1.24で一般提供（GA）になっています。ただし、マルチネットワークのマルチクラスタ構成は1.29でベータになった段階です。ztunnelのインプレース更新ではノード上の通信が一瞬途切れる点も、運用設計に組み込んでおく必要があります。

IstioをAIゲートウェイとして使えますか？

推論リクエストの振り分けには、1.29でベータになったGateway API Inference Extension（InferencePool）を使えます。AIエージェントやMCPサーバーの通信向けのagentgatewayは、1.30で実験的に入り、1.31でwaypointにも対応した段階です。本番の入口に置くのはまだ早いと言えます。

関連記事

• Istioとは？サービスメッシュの仕組みとサイドカー/アンビエント方式・導入判断を解説【2026年版】
• Kubernetesの最新バージョンは1.37｜確認方法・EOL一覧とアップグレード手順
• Linkerdとは？軽量なRust製サービスメッシュの仕組みとIstioとの選び分けを解説【2026年版】
• カナリアリリースとは？段階リリースの仕組み・他方式との違い・実装と採用判断を実装視点で解説
• モデルサービングとは？推論APIの構成とKServe・Triton・BentoMLの選定基準を解説【2026年版】