---
title: "Istioの最新バージョンは1.31｜1.28〜1.31の新機能・サポート期限とアップグレード手順"
url: "https://www.issoh.co.jp/tech/details/9698/"
published: 2025-11-07
updated: 2026-09-27
categories: ["Kubernetes・コンテナ"]
publisher: "株式会社一創"
---

# 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](https://istio.io/latest/docs/releases/supported-releases/)のサポート状況表と、各版のリリース告知をもとにまとめたものです（2026年9月27日時点）。公開日はリリース告知とGitHubのリリースの日付を使っています。

| 版    | 公開日        | サポート終了         | 対応Kubernetes | Envoy |
| ---- | ---------- | -------------- | ------------ | ----- |
| 1.31 | 2026-08-31 | 2027年2月ごろ（予定）  | 1.32〜1.36    | 1.39系 |
| 1.30 | 2026-05-18 | 2026年12月ごろ（予定） | 1.32〜1.36    | 1.38系 |
| 1.29 | 2026-02-16 | 2026-10-12（予定） | 1.31〜1.35    | 1.37系 |
| 1.28 | 2025-11-05 | 2026-07-01（終了） | 1.30〜1.34    | 1.36系 |
| 1.27 | 2025-08-11 | 2026-04-07（終了） | 1.29〜1.33    | —     |

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一覧とアップグレード手順](/tech/details/17151/)で確認できます。

## 手元の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年版】](/tech/details/15568/)で解説しています。

| 版    | アンビエントモードの主な変更                                      |
| ---- | --------------------------------------------------- |
| 1.28 | ネイティブnftables対応、waypointから別ネットワークへの転送（マルチクラスタはアルファ） |
| 1.29 | DNSキャプチャとiptables再調整が既定で有効、マルチネットワークのマルチクラスタがベータ    |
| 1.30 | ServiceEntryのCIDR指定、waypointでのXFCC生成、サイドカーからの移行ガイド  |
| 1.31 | 重み付きwaypointカナリア、マルチクラスタのメモリリークなどを修正                |

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

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

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

| 版    | 推論拡張（InferencePool）              | agentgateway      |
| ---- | -------------------------------- | ----------------- |
| 1.28 | InferencePool v1に対応（アルファとRC版は削除） | —                 |
| 1.29 | ベータに昇格（推論拡張v1.0.1に準拠）            | —                 |
| 1.30 | —                                | ゲートウェイとして実験的に搭載   |
| 1.31 | —                                | waypointとしても利用可能に |

推論拡張は、`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年版】](/tech/details/16073/)にまとめています。

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

各版のアップグレードノート（[1.28](https://istio.io/latest/news/releases/1.28.x/announcing-1.28/upgrade-notes/)・[1.29](https://istio.io/latest/news/releases/1.29.x/announcing-1.29/upgrade-notes/)・[1.30](https://istio.io/latest/news/releases/1.30.x/announcing-1.30/upgrade-notes/)・[1.31](https://istio.io/latest/news/releases/1.31.x/announcing-1.31/upgrade-notes/)）から、既存の設定の動きが変わる項目を抜き出しました。2マイナー飛ばしで上げる場合は、途中の版の項目もすべて対象になります。

| 上げる先 | 変更点                              | 対処                       |
| ---- | -------------------------------- | ------------------------ |
| 1.28 | BackendTLSPolicy v1alpha3を削除     | v1へ書き換え                  |
| 1.28 | METRIC\_ROTATION\_INTERVALを削除    | statsEvictionIntervalへ移行 |
| 1.29 | デバッグエンドポイントの認可が既定で有効             | Kiali等の権限を確認             |
| 1.29 | baseチャートから重複リソースを削除              | istiodチャート側の名前へ          |
| 1.29 | サーキットブレーカーのremainingメトリクスを既定で無効化 | 必要なら環境変数で戻す              |
| 1.30 | Gateway API CRD v1.5.xが必須        | Istioより先にCRDを更新          |
| 1.30 | ポート15010のXDSデバッグに認証が必要           | `--plaintext`の利用箇所を修正    |
| 1.30 | 同名ホストはKubernetesのServiceを優先      | ServiceEntryとの重複を確認      |
| 1.31 | 不健全なエンドポイントも既定で送信                | minHealthPercentを確認      |
| 1.31 | 大規模アンビエントでWDS再接続が4MiB超過          | 受信上限を引き上げ                |

影響が大きいのは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.30   | 1.30 → 1.31        | イメージ取得元の変更            |
| 1.29   | 1.29 → 1.31        | K8s 1.32以上、CRD v1.5.x |
| 1.28   | 1.28 → 1.30 → 1.31 | K8s 1.32以上、CRD v1.5.x |
| 1.27以前 | 2マイナーずつ段階的に        | 版ごとのK8s範囲を確認          |

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`でタグの参照先だけを差し替えます。ラベルを付け直す必要がなくなります。段階的に切り替える考え方は[カナリアリリースとは？段階リリースの仕組み・他方式との違い・実装と採用判断を実装視点で解説](/tech/details/13592/)と共通です。

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

アンビエントのデータプレーンは、ノードごとに動く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のリリース一覧](https://github.com/istio/istio/releases)で確認できます。

### 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年版】](/tech/details/15568/)
- [Kubernetesの最新バージョンは1.37｜確認方法・EOL一覧とアップグレード手順](/tech/details/17151/)
- [Linkerdとは？軽量なRust製サービスメッシュの仕組みとIstioとの選び分けを解説【2026年版】](/tech/details/15570/)
- [カナリアリリースとは？段階リリースの仕組み・他方式との違い・実装と採用判断を実装視点で解説](/tech/details/13592/)
- [モデルサービングとは？推論APIの構成とKServe・Triton・BentoMLの選定基準を解説【2026年版】](/tech/details/16073/)

---

出典: [Istioの最新バージョンは1.31｜1.28〜1.31の新機能・サポート期限とアップグレード手順](<https://www.issoh.co.jp/tech/details/9698/>)（株式会社一創）