2026年にインフラチームを変革する五つのマイグレーション

2026年のネットワーキングは、単一のトレンドによって推進されているわけではなく、締め切りによって動かされています。広く使われていた ingress コントローラーが廃止されました。主要な TLS ライブラリのデフォルト設定が変更されました。10年以上続くプロキシ手法がついに本番環境で採用されました。サービスメッシュが独自の拡張性 API を置き換えました。そして IPv4 の枯渇は、フェデラルの規制に背負った組織にとって、単なる話題から実際のマイグレーションプロジェクトへと変わっています。これらは推測ではなく、すでにインフラやプラットフォームチームに行動を促しています。各項目の現状を見てみましょう。

1. Ingress-NGINX の廃止 — 実際の Gateway API マイグレーションパス

見出しの主張は正確ですが、実際に何が起きたのかを正確に理解することが重要です。用語の混乱がマイグレーションのタイムラインに誤解を生んでいるためです。

終了したもの。 コミュニティが管理する kubernetes/ingress-nginx コントローラー — Kubernetes SIG Network による管理 — は、2026年3月にメンテナンスを最善努力の範囲に限定し、リポジトリは正式にアーカイブされ、2026年3月24日に読み取り専用になりました。廃止は2025年11月11日にセキュリティ対応委員会によって最初に発表され、その後2026年1月29日に Kubernetes ステアリング委員会とセキュリティ対応委員会の共同声明で強調され、影響を受けるクラウドネイティブ環境はおよそ半数にのぼるとされました。主な原因は単一の設計上の欠陥ではなく、長年のメンテナの燃え尽きと技術的負債、特に任意の NGINX 設定「スニペット」注釈の導入に伴うもので、これをセキュリティ上のリスクとみなすようになったことです。

終了しなかったもの。 重要な区別が二つあります。しばしば混同されるためです: - Kubernetes の Ingress API 自体は廃止や削除されていません — 機能は凍結されており、現在は Gateway API での開発が進行中です。 - NGINX Ingress Controller (nginxinc/kubernetes-ingress)、商用およびオープンソースの両方で F5/NGINX Inc. によって管理されているものは、全く異なるコードベースであり、この廃止の影響を受けていません。

既存の ingress-nginx デプロイは継続して動作しています。何も一晩で壊れるわけではありません。停止するのは新リリースやバグ修正、そして重要なCVEパッチです。これがすでに現実のリスクとして浮上しています。2026年2月2日に4つの高重大度 CVE が同時に公開され、その後5月には NGINX Rift と呼ばれる CVE-2026-42945 のヒープバッファオーバーフローが発生し、アップストリームの修正は期待できません。コンプライアンス重視の環境では、「EOL ソフトウェアがL7リクエストパスに存在する」ことが SOC 2 / PCI-DSS / ISO 27001 の監査項目となっています。一部のマネージドプラットフォーム（Azure AKS Application Routing、GKE ingress設定の一部）は、2026年11月までベンダー拡張パッチのみを約束しており、これは橋渡しであり解決策ではありません。

Gateway API の現状。 「Gateway API v1.4 へのマイグレーション」という最初の枠組みは既に時代遅れです。v1.4.0 は2025年10月6日に GA になり、BackendTLSPolicy と GA の TLSRoute が追加されました。それ以降: - v1.5 は2026年2月27日にリリースされ、これまでの最大のアップデートとなり、6つの実験的機能（ListenerSet や完全な TLSRoute の GA など）を標準/GA チャネルに昇格させ、Kubernetes の SIG Release に似たリリーストレインモデルを導入しました。 - v1.6 は2026年中頃の最新リリースで、標準および実験的インストールマニフェストは github.com/kubernetes-sigs/gateway-api/releases/download/v1.6.0/ に公開されています。

実際のマイグレーションツール。 ingress2gateway は SIG Network によって管理され、2026年3月20日に 1.0 に到達 — EOL に合わせて意図的にタイミングを合わせました。1.0以前のツールは3つの ingress-nginx 注釈しか理解できませんでしたが、1.0は30以上の一般的な注釈（CORS、バックエンド TLS、正規表現マッチング、パス書き換えなど）をサポートし、それぞれがコントローラーの統合テストによってライブ動作と比較しています。また、実装固有の拡張をターゲットにできるプラグイン可能なエミッターアーキテクチャも導入しています:

# インストール
ngo install github.com/kubernetes-sigs/ingress2gateway@v1.0.0

# 名前空間内のすべてをドライラン変換、ingress-nginx 注釈
ingress2gateway print --providers ingress-nginx --namespace production > gwapi.yaml

# 特定の実装の拡張（例：Envoy Gateway）をターゲット
ingress2gateway print --providers ingress-nginx --emitter envoy-gateway > envoy-gwapi.yaml

このツールは、忠実に変換できない場合（例：nginx.ingress.kubernetes.io/proxy-body-size に直接対応する Gateway API の設定がない場合）は警告を出し、動作を静かに省略しません。切り替え前に必ず警告を確認し、まず非本番クラスターで検証してください。Cilium、Contour、Envoy Gateway、GKE Gateway、Istio など、7つ以上の実装が現在の標準チャネルに準拠しているため、マイグレーション後のベンダー選択肢は豊富です。

2. ポスト量子 TLS がドラフトから標準へ

この点は「今すぐ収穫し、後で解読する」フレームに対して堅実です。今日の古典的な鍵交換で暗号化されたトラフィックは、今キャプチャして保存し、後に量子コンピュータが実現したときに解読される可能性があります。変わったのは、その修正がもはや実験的な仕組みではなくなったことです。

OpenSSL 3.5（2025年4月リリース）は、ハイブリッド鍵交換グループ — 古典的な X25519 楕円曲線 Diffie–Hellman と NIST標準の ML-KEM-768 ポスト量子 KEM を組み合わせたもの — を TLS 1.3 のデフォルトの keyshare にしました。IANA登録名は X25519MLKEM768（コードポイント 0x11ec）です。FIPS志向の代替として SecP256r1MLKEM768（コードポイント 0x11eb）もあります。ハイブリッドのため、セッションはどちらか一方の安全性が保たれている限り安全です。ML-KEM の破壊や将来の X25519 の破壊だけではセッションキーは危険にさらされません。これは IETF の draft-ietf-tls-hybrid-design で規定された構成です。

エッジで TLS を終端する場合の実務的な懸念点:

• オーバーヘッドは交換自体にはほとんど影響しません。 ハイブリッド鍵交換は古典的な X25519 と同じくらいの計算負荷で、1秒あたり数万の操作が可能です。CPUコストはボトルネックになりません。
• ペイロードサイズが実質的なコスト。 ML-KEM-768 の公開鍵は約1.2 KBで、ClientHello/ServerHello のサイズが増加します。サーバーの優先グループがクライアントから事前送信されていない場合、HelloRetryRequest と追加のラウンドトリップが必要です。Chrome と Firefox は事前に X25519MLKEM768 とプレーンな X25519 の両方の鍵共有を事前計算して回避していますが、すべてのクライアントがそうしているわけではありません。PQ 優先設定を有効にした後の P99 ハンドシェイク遅延を監視してください。そこに回帰が現れます。
• 採用はすでに広範囲。 Chrome (v131, 2024年11月) と Firefox (v135, 2025年2月) は両方ともハイブリッド方式をサポートしています。JDK も2026年の早期アクセスビルドで追加済みです。NGINX や HAProxy も OpenSSL 3.5+ でビルドされていれば対応しています。

コンプライアンスのプレッシャーは現実的で期限も設定済みです。米国の CNSA 2.0 スイートは国家安全保障システム向けに厳格な期限を設けており、EU の PQC 連携ロードマップも高リスクセクターを対象に同様のスケジュールを設定しています。Layer-7 プロキシにとっての実務的なマイグレーションは、「OpenSSL 3.5+ に再コンパイルして監視」程度で済むものであり、「量子耐性を持つエッジの構築」というフレームは過剰な期待に過ぎません。

3. MASQUE と CONNECT-UDP：標準は思ったより古く、展開は新しい

最初に訂正します：CONNECT-UDP は新興の概念ではなく、RFC 9298 として2022年8月から完成した IETF 標準です。2026年の実情は、実運用規模の展開とそれに重ねる拡張仕様の進展です。

MASQUE（Multiplexed Application Substrate over QUIC Encryption）は複数の仕様群であり、依存関係は次の通りです：RFC 9000 (QUIC) → RFC 9221 (信頼性の低い QUIC datagrams) → RFC 9114 (HTTP/3, Extended CONNECT の改良) → RFC 9297 (HTTP Datagrams と Capsule Protocol) → RFC 9298 (CONNECT-UDP) → RFC 9484 (CONNECT-IP, 2023年10月、IPトンネリング拡張)。クライアントは :protocol: connect-udp で Extended CONNECT リクエストを開き、プロキシは UDP datagrams をターゲットに中継します。これらは既に暗号化された QUIC 上の HTTP Datagrams として運ばれ、ポート443上で動作し、WebRTC、ゲーム、WireGuard などのトラフィックは、TLS を破っていない中間装置からは通常のブラウジングと区別できません。

これは理論ではなく、MASQUE はすでに Apple の iCloud Private Relay や Cloudflare の WARP などのサービスの基盤となっており、エンタープライズの Zero Trust 製品にも採用されています。

標準の進展点: - draft-ietf-masque-connect-udp-listen（現在 draft -13、2026年6月30日公開）は、CONNECT-UDP を サーバー起動 の UDP に拡張します。WebRTC などのピアツーピアプロトコルに有用で、MASQUE プロキシに STUN/TURN リレーの代替手段を提供します。 - draft-ietf-httpbis-connect-tcp は、従来の CONNECT の代替として TCP 用のテンプレート駆動の方式を提案し、複数の異なるプロキシサービスを一つの HTTP サーバの背後にホストするギャップを埋めます。 - オープンソース実装も急速に成熟しています：masque-go（quic-go ベース）は RFC 9298 のクライアントとプロキシをサポートし、gost などの汎用トンネリングツールも MASQUE サポートを追加するリクエストがコミュニティから寄せられています。

インフラチームにとっての実務的なポイントは、「最先端のプロトコルを採用する」ではなく、「エンタープライズファイアウォールが ‘非標準 UDP ポートをブロック’ という前提を前提としなくなる設計の変化に予算を割く」ことです。これは、トンネルを構築する側とそれを見破る側の両方にとって重要です。

4. プロキシ拡張性：WasmPlugin は単なる普及ではなく、置き換えが進行中

この部分は、最も修正が必要な箇所です。技術自体は間違っていませんが、「ホットスワップ可能な Wasm フィルター」という表現は2021年から2025年の話であり、現状はまた変化しています。

Istio は WasmPlugin CRD による Wasm 拡張性を導入し、2021年の Istio 1.12 から導入されました。これは、従来の EnvoyFilter パッチの脆弱性を置き換えるもので、コンテナ内の WebAssembly モジュール（Rust、Go/TinyGo、C++、AssemblyScript で作成、Proxy-Wasm SDK 対応）を OCI レジストリ経由で配布し、Envoy の Extension Configuration Discovery Service (ECDS) によってライブで新しいバージョンをホットロードします。

しかし、API の表層は変わっています。Istio 1.30 では TrafficExtension API が導入され、Wasm と Lua の拡張性を一つのリソースに統合し、推奨の拡張性メカニズムとなっています。 WasmPlugin は引き続き動作しますが（Istio は既存の WasmPlugin リソースを TrafficExtension に変換して Envoy 設定を生成します）、新規の拡張はこの新 API をターゲットにすべきです:

apiVersion: extensions.istio.io/v1alpha1
kind: TrafficExtension
metadata:
  name: basic-auth-gateway
spec:
  targetRefs:
    - kind: Gateway
      group: gateway.networking.k8s.io
      name: bookinfo-gateway
  phase: AUTHN
  wasm:
    url: oci://ghcr.io/istio-ecosystem/wasm-extensions/basic_auth:1.12.0
    pluginConfig:
      basic_auth_rules:
        - prefix: "/productpage"
          request_methods: ["GET", "POST"]

TrafficExtension は Lua をファーストクラスの軽量オプションとしても正式化しています。インラインスクリプトでモジュール配布を伴わず、HTTP のみ対応（Layer 7）、Wasm よりもメモリフットプリントが小さく（約20–26 MiB 対 110–290 MiB）、ヘッダー操作やロギング、条件付きルーティングに適しています。実務的な指針は、シンプルなヘッダー操作やロギングには Lua を、複雑な認証フローやレートリミティング、ペイロード変換には Wasm を使うことです。

このトピックは、既存の proxy-extensibility や Istio のアンビエントメッシュに関する過去の記事と重複しますが、今回特に新しいのは TrafficExtension API の導入と、それによる WasmPlugin の置き換えです。もしこの話題を取り上げるなら、最初にこの角度を示すのが良いでしょう。

5. IPv6オンリー Kubernetes クラスター：NAT64/DNS64 が実運用の必須に

この二重スタックの疲弊は正確であり、少なくとも一つの事例ではもはやオプションではありません。米国エネルギー省の科学ネットワーク ESnet は、IPv4 のフェーズアウトに伴い、Cilium を使った IPv6オンリー Kubernetes への移行を進めています。最大の障壁はネットワーク層ではなく、アプリケーションコードに埋め込まれた IPv4 アドレスで、IPv4 がなくなったときに初めて顕在化しました。彼らは Cilium の Multi-pool IPAM を使い、各名前空間に /64 プレフィックスを割り当て、マスカレード不要なマイクロセグメントを実現しています。

基本的な仕組みは変わっていませんが、ツールは成熟しています:

• NAT64 は IPv6 の Pod と IPv4 インターネット間の状態を持つ変換を行い、64:ff9b::/96（RFC 6052）を使います。Jool は最も一般的なオープンソースの NAT64 カーネルモジュールです。
• DNS64 は、A レコードしか持たないドメインに対し、IPv4 アドレスにプレフィックスを付与して AAAA レコードを生成します。CoreDNS の DNS64 プラグインや、Unbound、BIND もよく使われます。
• 新しい選択肢として、kubernetes-sigs/nat64 という eBPF ベースの NAT64 エージェントもあり、外部 NAT64/DNS64 ゲートウェイを立てる運用コストを避けることを目指しています。

# DNS64 対応リゾルバの例（クラスターアドオン）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: dns64
  namespace: network-services
spec:
  replicas: 3
  selector:
    matchLabels: { app: dns64 }
  template:
    metadata:
      labels: { app: dns64 }
    spec:
      containers:
        - name: unbound
          image: mvance/unbound:latest
          ports:
            - containerPort: 53
              protocol: UDP
            - containerPort: 53
              protocol: TCP

クラウド固有の注意点として、EKS ではクラスターの API エンドポイントは IPv4 のみでアクセス可能なため、「IPv6オンリー」でも Pod 間や Pod からインターネットへの通信は IPv6 だけで済みますが、NAT64/DNS64 の仕組みは境界に必要です。つまり、完全に IPv4 を排除するわけではなく、Pod 間や Pod からインターネットへの通信だけが IPv6 で、境界に変換機構が必要ということです。これは、「go IPv6-only」移行ガイドを書くときに重要なニュアンスです。

共通のテーマ

これら五つのトピックは、いずれも誇大宣伝の対象ではなく、外部の強制力によって動いています。廃止されたコントローラーの EOL、既に出荷済みの暗号設定、長年の RFC の実運用、サービスメッシュ内の API 置き換え、フェデラルの規制による本番移行 — これらは次に何を取り上げるべきかの有用なフィルターです。技術的な面白さではなく、「締め切りがあるかどうか」に焦点を当てることが重要です。

---

参考資料

Ingress-NGINX EOL / Gateway API - Kubernetes ステアリング + セキュリティ対応委員会の共同声明 — https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/ - kubernetes/ingress-nginx のリリース/アーカイブ履歴 — https://github.com/kubernetes/ingress-nginx/releases - Ingress2Gateway 1.0 発表 — https://kubernetes.io/blog/2026/03/20/ingress2gateway-1-0-release/ - Gateway API v1.4 リリースノート — https://kubernetes.io/blog/2025/11/06/gateway-api-v1-4/ - Gateway API v1.5 リリースノート — https://kubernetes.io/blog/2026/04/21/gateway-api-v1-5/ - Gateway API リポジトリ（現 v1.6.0 の状況） — https://github.com/kubernetes-sigs/gateway-api - Ingress-NGINX EOL CVE 追跡 — https://www.herodevs.com/blog-posts/ingress-nginx-end-of-life-2026-migration-and-support

ポスト量子 TLS - OpenSSL 企業、ポスト量子対応の概要 — https://openssl-corporation.org/post-quantum.html - OpenSSL 3.5 のハイブリッド PQC デフォルト — https://faisalyahya.com/access-control/openssl-3-5-entering-the-post-quantum-era/ - 本番環境での PQC TLS 展開パターン — https://www.systemshardening.com/articles/network/tls-post-quantum-hybrid-deployment/ - Kubernetes におけるポスト量子暗号 — https://kubernetes.io/blog/2025/07/18/pqc-in-k8s/

MASQUE / CONNECT-UDP - MASQUE プロトコル解説 — https://http.dev/masque - MASQUE のアーキテクチャと RFC 依存関係 — https://instatunnel.substack.com/p/masque-the-http3-tunneling-protocol - draft-ietf-masque-connect-udp-listen — https://datatracker.ietf.org/doc/draft-ietf-masque-connect-udp-listen/

プロキシ拡張性 - Istio TrafficExtension API の紹介 — https://istio.io/latest/blog/2026/traffic-extension-api/ - Istio の拡張性概念（Wasm vs. Lua） — https://istio.io/latest/docs/concepts/extensibility/ - WasmPlugin 参照 — https://istio.io/latest/docs/reference/config/proxy_extensions/wasm-plugin/

IPv6-Only クラスター / NAT64 - Cilium IPv6 ネイティブネットワーキング（ESnet ケーススタディ） — https://cilium.io/use-cases/ipv6/ - kubernetes-sigs/nat64（eBPF NAT64 エージェント） — https://github.com/kubernetes-sigs/nat64 - EKS IPv6 クラスターのネットワーク制約 — https://aws.github.io/aws-eks-best-practices/networking/ipv6/

---

更新履歴

削除： SEOタイトル/ターゲットキーワード/フックメタデータと、ソースドラフトの宣伝的「編集者の見解」フレーム — これらは記事の内容ではありません。

修正： - 「Gateway API v1.4」については、Ingress-NGINX の EOL 発表時点の状態を反映し、その後 v1.5（2026年2月27日）から v1.6（現状）へと進化したため、現在のバージョンと追加された機能を正確に反映させました。 - ingress-nginx の EOL は、主にメンテナの燃え尽きと技術的負債（特に「スニペット」注釈）に起因し、単一の「設計上のセキュリティ制約」ではなかったことを明示しました。 - 廃止された kubernetes/ingress-nginx プロジェクトと、影響を受けていない商用管理の nginxinc/kubernetes-ingress コントローラーを明確に区別しました。 - MASQUE / CONNECT-UDP の枠組みについて、CONNECT-UDP は2022年8月から RFC 9298 として完成済みの標準であり、2026年のニュースは展開規模と拡張仕様の進展に焦点を当てるべきだと修正しました。 - PQC ハイブリッドグループの正確な IANA コードポイント（X25519MLKEM768 = 0x11ec、SecP256r1MLKEM768 = 0x11eb）と、それを規定する IETF 草案（draft-ietf-tls-hybrid-design）を明示しました。

編集判断を要する部分： - セクション4（プロキシ拡張性 / WasmPlugin）は、過去の proxy-extensibility や Istio の記事と重複しますが、Istio 1.30 の TrafficExtension API の導入と、それによる WasmPlugin の置き換えが新しいポイントです。これを最初に示すのが望ましいです。

追加： - ingress2gateway、TrafficExtension、DNS64 展開例の具体的な CLI / YAML 例 - ingress-nginx の EOL セキュリティリスクの具体的な CVE 識別子と日付 - ESnet の IPv6オンリー移行事例 - EKS の IPv4-only コントロールプレーンの注意点