Ingress NGINX 終了後の選択肢

クラスターがまだ ingress-nginx で流入トラフィックを捌いているなら、それはもう誰も直す人がいないソフトウェアです。リポジトリは 2026 年 3 月 24 日にアーカイブされました。今後リリースもバグ修正もなく、そして最も重要な点として、どのような脆弱性に対してもセキュリティ修正は二度と提供されません。その日に何かが壊れたわけではありません。問題はまさにそこにあります。Ingress は動き続けているので、対応を迫るものが何もないのです。

この記事は期限前ではなく、期限を過ぎた時点で書いた移行ガイドです。影響範囲を 4 つのコマンドで数値化する方法、印象ではなく根拠で移行先を選ぶ方法、翻訳の過程で意味が静かに変わる ingress-nginx の挙動、そして新しいデータプレーンの挙動が想定と違った場合にトラフィックを戻せる移行順序を扱います。

実際に起きたこと、起きていないこと

経緯は短いので正確に押さえておく価値があります（二次情報でかなり歪んで伝わっています）。Kubernetes SIG Network と Security Response Committee は 2025 年 11 月 11 日に廃止を告知しました。2026 年 1 月 29 日には Steering Committee と SRC が異例に踏み込んだ共同声明を出しています。廃止後も Ingress NGINX を使い続けることは、自分と利用者を攻撃にさらすことであり、利用可能な代替のいずれも「そのまま置き換えられるもの」ではない、という内容です。^{[retire][steering]}

最後の行が最も誤解されています。Ingress API 自体は非推奨になっていません。ドキュメントには、GA（一般提供）であること、プロジェクトとして削除する計画はないこと、単に凍結されている（今後の変更・更新を行わない）ことが明記されています。networking.k8s.io/v1 の Ingress オブジェクトは有効な Kubernetes リソースであり、今後も有効です。終了したのは、それを読み取る特定のコントローラーです。^[ingressdoc]

使い続けた場合に引き受けるもの

リスクの規模を測る最も確実な方法は、このプロジェクトが最後の数週間に出したセキュリティ修正を見ることです。2026 年 2 月 2 日 —— Steering の声明から 4 日後、リポジトリが読み取り専用になる 7 週間前 —— に SRC は ingress-nginx の脆弱性 4 件を公開しました：CVE-2026-1580、CVE-2026-24512、CVE-2026-24513、CVE-2026-24514。最も深刻なものは HIGH（8.8）と評価され、v1.13.7 および v1.14.3 で修正されています。^[advisory]

特に押さえるべきは CVE-2026-24512 です。Ingress の rules.http.paths.path フィールドを使って NGINX に設定を注入でき、コントローラーのコンテキストでの任意コード実行と、コントローラーが読み取れるすべての Secret の漏えいにつながります。デフォルト構成では、それはクラスター全体の Secret を意味します。暫定的な緩和策は、path type が ImplementationSpecific の Ingress を拒否する validating admission controller でした。この種の欠陥が攻撃者に要求する条件に注意してください —— Ingress を作成できること。名前空間に書き込み権限がある人は全員該当します。^[cve24512]

この後さらに 2 件あり、そちらが論点を完成させます。CVE-2026-3288 は 2026 年 3 月 9 日公開、HIGH（8.8）。rewrite-target アノテーション経由の設定インジェクションで、後述の挙動比較表が警告しているまさにそのアノテーションです。v1.13.8、v1.14.4、v1.15.0 で修正されました。続く CVE-2026-4342 は 2026 年 3 月 19 日公開、同じベクターで 8.8。コメントを利用した設定インジェクションで、やはりコントローラーでのコード実行とクラスター全体の Secret 漏えいに至ります。修正は v1.13.9、v1.14.5、そして controller-v1.15.1 ——つまり最終リリースです。このプロジェクトが最後に世に出したものは、セキュリティ修正でした。リポジトリが読み取り専用になる 5 日前のことです。この先に見つかるものには、何も提供されません。^{[cve3288][cve4342][lastrel]}

上限を知るには、2025 年 3 月の CVE-2025-1974（通称「IngressNightmare」、CVSS 9.8）が参考になります。Kubernetes プロジェクトの表現は率直でした。Pod ネットワーク上のあらゆるものが、認証情報なしにクラスターを掌握できる可能性が十分にあった、というものです。あのときは修正がありました。次はありません。^[nightmare]

既存のデプロイは動き続けます。したがって能動的に確認しない限り、侵害されるまで自分が影響を受けていることに気づかない可能性があります。^[steering]

規模について。Steering Committee と SRC は、Datadog の社内調査を引用して、クラウドネイティブ環境のおよそ 50% がこのコントローラーに依存しているとしています。この数字は精密な測定値ではなく目安として扱うのが妥当です（元データは非公開で、Datadog が監視している環境を反映したものです）。ただし桁としては、プロジェクト自身が 2025 年に示した「Kubernetes クラスターの 40% 超」という数字とも整合します。いずれにせよ、片手間の後片付けで済む話ではありません。

影響範囲を確認する

計画の前にまず計測です。1 つ目のコマンドは Kubernetes プロジェクトが公開しているもの、残り 3 つは実際の作業量を示します。この移行のコストを決めるのは Ingress オブジェクトの数ではなく、その背後にあるアノテーションの種類数だからです。

# 1. The check the Kubernetes project itself publishes
kubectl get pods --all-namespaces \
  --selector app.kubernetes.io/name=ingress-nginx

# 2. Which controller image, and therefore which version, is actually running
kubectl get deploy -A -l app.kubernetes.io/name=ingress-nginx \
  -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.spec.template.spec.containers[0].image}{"\n"}{end}'

# 3. How much surface you have to translate: every Ingress bound to it
kubectl get ingress -A \
  -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}{"\t"}{.spec.ingressClassName}{"\n"}{end}'

# 4. The real cost driver - the annotations, ranked by how often you use them
kubectl get ingress -A -o json \
  | jq -r '.items[].metadata.annotations // {} | keys[]' \
  | grep -F 'nginx.ingress.kubernetes.io/' | sort | uniq -c | sort -rn

4 つ目のコマンドが見積もりそのものです。Ingress が 60 個でアノテーションが 4 種類なら半日仕事です。Ingress が 12 個でアノテーションが 22 種類 —— しかも configuration-snippet を含む —— ならプロジェクトであり、その理由がいま分かったことになります。

YAML に触る前に移行先を決める

現実的な選択肢は 3 つで、正解は ingress-nginx の挙動にどれだけ依存しているかで決まります。候補を絞る前に押さえておくべき点として、Kubernetes がプロジェクトとしてサポート・保守している Ingress コントローラーは AWS 版と GCE 版の 2 つだけです。ドキュメントに載っているそれ以外 —— Traefik、HAProxy、Contour、Kong、APISIX、Cilium、Higress、Istio など —— はすべてサードパーティです。また kubernetes/ingress-nginx は、そのページからすでに削除されています。^[ctrldoc]

Gateway API を選ぶ場合、現行リリースは v1.6.0 です。2026 年 6 月末にタグが打たれ、8 月 3 日に告知されました。このリリースで TCPRoute と UDPRoute が Experimental から Standard（v1）へ昇格し、Gateway、GatewayClass、HTTPRoute、GRPCRoute、TLSRoute、ListenerSet、ReferenceGrant、BackendTLSPolicy に加わりました。TCPRoute と UDPRoute の v1alpha2 は v1.6 時点で非推奨となり、将来削除されます。導入するのは v1.6.0 ではなく、現行のパッチリリースである v1.6.1（2026 年 7 月 16 日）です。クラスターのバージョンについては、プロジェクトは固定の下限を公表していません。公表されている方針は「直近 5 つの Kubernetes マイナーバージョンをサポートする」であり、ブログ記事に書かれた数字ではなく、この方針を自分のクラスターと突き合わせてください。^{[gw16][gw16rel][gw161][versioning]}

v1.6 の構造的な変更も計画に織り込んでおく価値があります。新しい実験的リソースは別の API グループ gateway.networking.x-k8s.io に置かれ、型名に X の接頭辞が付きます（XBackend、XMesh など）。Standard に昇格する際は gateway.networking.k8s.io にリネームされ、接頭辞が外れます。これは意図的なシグナルです。依存しようとしている kind が X で始まるなら、それは本番運用の約束ではありません。^[gw16]

選定は根拠ベースで行ってください。Gateway API プロジェクトはリリースごとに適合性（conformance）レポートを公開しており、各実装がルート種別ごとにいくつの拡張機能に合格しているかが明記されています。この表は、本記事を含むどのベンダー比較ページよりも優れた一次選別ツールです。実際に動かす予定のバージョンの行を見てください。昨年のものではなく。ただし、すべての実装が毎リリース報告を提出するわけではありません。行が無いことは「このバージョンの報告が無い」という意味であって、「適合していない」という意味ではありません。^[conform]

日本のチームで実務的に効く進め方を補足します。第一に、移行先比較表を作るなら、機能一覧ではなく適合性レポートの数値を列にしてください。「対応している」と書かれていても、HTTPRoute・GRPCRoute・TLSRoute それぞれで合格している拡張機能数は実装ごとに大きく異なります。第二に、マネージドサービス上（EKS、GKE、AKS）であれば、移行の実際のペースを決めるのは自分たちのバックログではなく、プラットフォーム側が提供するコントローラーと、それが認証されている Gateway API のバージョンです。したがって最初の確認事項は「自社クラスターで何が選べるか」であり、次が「そのバージョンで自分のアノテーションが表現できるか」です。影響範囲を先に確定してから段階的移行の計画を立てると、稟議・変更管理の説明も通しやすくなります。

翻訳では再現されない 5 つの挙動

移行が破綻するのはここです。移行先が決まっている場合でも読む価値があります。ingress-nginx には Ingress 仕様に存在しない挙動が積み上がっており、アプリケーションはいまそれに暗黙のうちに依存しています。そして適合性を満たす Gateway API 実装は、それらを再現しません。Kubernetes プロジェクトは、この発見を各自が繰り返さずに済むよう、そのうち 5 つを明示的に文書化しています。^[gotchas]

実務上いちばん厄介なのは末尾スラッシュのリダイレクトです。派手に失敗しないからです。これまで /api へのリクエストは /api/ にリダイレクトされていましたが、移行後はアプリケーションが 404 を返し、エラーはエッジではなくサービスのログに現れます。したがって最初の仮説は「サービスのバグ」になり、「昨夜の移行」にはなりません。

ingress2gateway：変換できるもの、できないもの

公式のコンバーターは存在し、以前よりかなり実用的になっています。ingress2gateway は 2026 年 3 月 20 日に SIG Network のサブプロジェクトとして 1.0 に到達しました。最大の変更は、ingress-nginx アノテーションの対応数が 3 個から 30 個超に拡大したことです（CORS、バックエンド TLS、正規表現マッチ、パス書き換えなどを含む）。1.0 ではさらに、実クラスター上で本物の ingress-nginx と本物の Gateway API コントローラーを起動し、YAML の差分ではなく実行時の挙動を比較するコントローラーレベルの結合テストが追加されました。^[i2gblog]

# Install the official converter (Go 1.25.5 or newer to build from source)
go install github.com/kubernetes-sigs/ingress2gateway@v1.0.0
# or: brew install ingress2gateway

# Convert a manifest on disk, without touching the cluster
ingress2gateway print --input-file ingress.yaml \
  --providers=ingress-nginx > gwapi.yaml

# Convert one namespace from a live cluster
ingress2gateway print --namespace shop \
  --providers=ingress-nginx > gwapi.yaml

# Convert everything, and keep the warnings - they are the migration backlog
ingress2gateway print --all-namespaces \
  --providers=ingress-nginx > gwapi.yaml 2> unsupported.log

対応プロバイダーは 9 種類 —— ingress-nginx、nginx、traefik、kong、istio、apisix、cilium、gce、openapi —— で、出力エミッターは envoy-gateway や kgateway を含む 6 種類です。出力は Gateway API v1.5.0 を対象としています。このツールが肩代わりしてくれないもの：^[i2g]

• configuration-snippet と server-snippet：非対応で、等価物も存在しません。任意の NGINX ディレクティブを書けるという設計判断こそ、Kubernetes プロジェクトが「解消不能な技術的負債」の原因として名指ししたものです。スニペットに業務ロジックが入っている場合、そのロジックはアプリケーション、フィルター、あるいは実装固有のポリシー CRD に移す必要があります。^[retire]
• proxy-body-size：Gateway API に等価な項目はありません。データプレーン側で設定することになり、その結果、実装固有の設定となって可搬性を失います。
• proxy-read-timeout / proxy-send-timeout：timeouts.request へのベストエフォートのマッピングであり、同じものではありません。同等と仮定せず、負荷をかけて再計測してください。
• URL 正規化：標準の Gateway API では設定できません。依存していたなら、それはデータプレーンに依存していたということであり、実装ごとに検証が必要です。

ツールの警告はノイズではなく、移行のバックログとして読んでください。stderr に出力されるものはすべて、ツールが持ち越せなかった挙動であり、そのひとつひとつが DNS 切替を待っている本番障害です。

Ingress と Gateway API の対比

最小限だが現実的な例です。ホスト名 1 つ、TLS、そして API と Web フロントエンドで分割されたパス。並べて見る意味は、Gateway API 版のほうが長いという点にあります。この長さは形式ではなく、ingress-nginx が暗黙に提供していた挙動が明示的に書き出された結果です。

移行前 — Ingress 1 件

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop-ingress
  namespace: shop
spec:
  ingressClassName: nginx
  tls:
    - hosts: [shop.example.com]
      secretName: shop-example-com-tls
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 8080
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 80

移行後 — Gateway 1 件と HTTPRoute 2 件

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shop-gateway
  namespace: shop
spec:
  gatewayClassName: nginx          # must match an installed GatewayClass
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      hostname: shop.example.com
      allowedRoutes:
        namespaces:
          from: Same
    - name: https
      protocol: HTTPS
      port: 443
      hostname: shop.example.com
      tls:
        mode: Terminate
        certificateRefs:
          - group: ""              # empty string = core API group
            kind: Secret
            name: shop-example-com-tls
      allowedRoutes:
        namespaces:
          from: Same
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop-route
  namespace: shop
spec:
  parentRefs:
    - name: shop-gateway
      sectionName: https
  hostnames: [shop.example.com]
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: api-service
          port: 8080
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: web-service
          port: 80
---
# ingress-nginx redirected HTTP to HTTPS for you. Gateway API does not.
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop-route-ssl-redirect
  namespace: shop
spec:
  parentRefs:
    - name: shop-gateway
      sectionName: http
  hostnames: [shop.example.com]
  rules:
    - filters:
        - type: RequestRedirect
          requestRedirect:
            scheme: https
            statusCode: 308

注目点は 3 つです。sectionName はルートを特定のリスナーに束縛します。これにより HTTP と HTTPS の挙動を分離できます。allowedRoutes は Ingress API になかった役割分離です。プラットフォームチームが Gateway を所有してどの名前空間から接続を許すかを決め、アプリケーションチームが自分たちの HTTPRoute を所有します。そして 3 つ目のオブジェクトは、ingress-nginx がデフォルトで行っていたリダイレクトを再現するためだけに存在します —— これは移行全体の要約としてもかなり的確です。^[gwapi]

切り戻しできる切替手順

この移行で最も有用な性質は、2 つのコントローラーを同時に動かせることです。別々のオブジェクトが別々のリソースを監視し、別々のロードバランサーの背後にいます。一斉切替を強いるものは何もないので、一斉切替はしないでください。

1. 新しいコントローラーを既存の隣に導入する。専用の GatewayClass、専用の名前空間、独自の LoadBalancer Service と外部アドレス。トラフィックは引き続き ingress-nginx を通ります。
2. 変換し、内容を確認する。1 つの名前空間に対して ingress2gateway を実行し、警告をすべて読み、翻訳できなかったアノテーションを手作業で補います。出力を読まずに apply しないこと。
3. 同じホスト名で Gateway API オブジェクトを apply する。この時点で利用者側の変化はありません。新しいコントローラーは独自の IP を持ち、DNS レコードはまだそこを指していません。
4. 2 つのエッジを直接比較する。--resolve を使ってリクエスト単位で、ステータスコード、リダイレクト先、ヘッダー、そして特に末尾スラッシュと正規表現のケースを突き合わせます。上記 5 つの挙動差を捕まえられるのはこの手順です。
5. DNS を段階的に移す。低 TTL のレコード、重み付けポリシー、あるいはまず重要度の低いホスト名から。新しいエッジが実トラフィックのピークを 1 回乗り切るまで、ingress-nginx は稼働させたままにします。
6. 意図的に撤去する。ingress-nginx の Deployment、Service、IngressClass、ValidatingWebhookConfiguration を削除します。admission webhook を残したままにするのが、数週間後にクラスターが壊れる典型パターンです。

# Install the Standard channel CRDs (server-side apply, as the project documents)
kubectl apply --server-side -f \
  https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.6.1/standard-install.yaml

# The Gateway must be Programmed before you move any traffic to it
kubectl get gateway shop-gateway -n shop \
  -o jsonpath='{.status.conditions[?(@.type=="Programmed")].status}{"\n"}'

# Every parentRef must be Accepted, and every backendRef ResolvedRefs.
# Nested ranges keep each condition paired with its own status.
kubectl get httproute shop-route -n shop -o jsonpath='{range .status.parents[*]}{.controllerName}{"\t"}{range .conditions[*]}{.type}={.status}{" "}{end}{"\n"}{end}'

# Compare old and new on the same request, before DNS moves.
# A cloud load balancer publishes either .ip or .hostname - AWS uses .hostname,
# so --connect-to is used instead of --resolve: it accepts both.
OLD=$(kubectl get svc -n ingress-nginx ingress-nginx-controller \
  -o jsonpath='{.status.loadBalancer.ingress[0].ip}{.status.loadBalancer.ingress[0].hostname}')
NEW=$(kubectl get gateway shop-gateway -n shop \
  -o jsonpath='{.status.addresses[0].value}')
for edge in "$OLD" "$NEW"; do
  curl -sS -o /dev/null -w "$edge  %{http_code}  %{redirect_url}\n" \
    --connect-to "shop.example.com:443:$edge:443" https://shop.example.com/api
done

2 つ目のコマンドの Programmed 条件に注目してください。Gateway が存在することと、Gateway が実際に処理していることは別です。status の conditions が契約であり、それを確認するコストは、DNS 切替の最中に違いを発見するコストよりはるかに安く済みます。

ingress-nginx / NGINX Ingress / NGINX Gateway Fabric

似た名前の 3 つの別プロジェクトがあり、まさにこの移行の場面で誤った判断の温床になっています。ingress-nginx から「NGINX Ingress」へ移行して何かを変えたつもりになり、後で気づくケース。あるいは 3 つとも同時に終わったと思い込んで NGINX 全体を候補から外してしまうケースです。

Kubernetes プロジェクト自身が明記する必要を感じた点です。両者はデータプレーンに NGINX を使っているが、それ以外に関係はない。コミュニティ版から F5 版への移行は、独自のアノテーション変換作業を伴う正真正銘の移行であり、名称変更ではありません。^[gotchas]

今週やるとしたら

まだ着手していないなら、今日のうちに 4 つの確認コマンドを実行してください。アノテーションの種類数だけが、これが半日仕事なのか四半期仕事なのかを教えてくれる唯一の数字です。「半日」なら今週中に終わらせ、リスクを抱えるのをやめること。「四半期」だとしても、有効な一手は同じです —— いま並行して 2 つ目のコントローラーを導入し、重要度の低いホスト名を 1 つ移す。最初の移行こそが、自分の前提のうちどれが実は ingress-nginx の挙動だったのかを知る場だからです。

より一般的な教訓は退屈なクラウドアーキテクチャでも書きました。最も痛い目に遭わせてくるのは、誰も意識していないコンポーネントです。何年も動き続けてきたからこそ意識されません。ボランティア 1〜2 名が保守するコントローラーがクラウドネイティブ世界の半分の前段に立っていた状態は、アーカイブされるずっと前からリスクの集中でした。自分のスタックに同じ形をしたものが他にないか棚卸しする価値がありますし、Kubernetes を使うべきでないときと同じ問いを立てる価値もあります —— このプラットフォームは、それが要求する運用面積に見合っているか。

よくある質問

当面 ingress-nginx を動かし続けても大丈夫ですか？

動作はしますし、今後も動き続けます。ただしセキュリティ修正が提供されることは二度とありません。そして最終リリースが実際に何だったかを見てください。controller-v1.15.1 は CVE-2026-4342 の修正であり、コントローラーでのコード実行とクラスター全体の Secret 漏えいに至る設定インジェクションを、アドバイザリ公開と同日に、リポジトリが読み取り専用になる 5 日前に塞いだものです。それは 7 週間で 6 件目の同種の欠陥でした。次の 1 件には修正がありません。どうしてもあと数週間動かす必要がある場合は、最低限、Ingress オブジェクトを作成できる人を制限し、インストール構成がコントローラーにクラスター全体の Secret アクセスを与えているなら剥奪し、admission webhook を露出させないでください。

Kubernetes の Ingress API も非推奨になったのですか？

なっていません。これが最も多い誤読です。Ingress API は GA であり、通常の GA 安定性保証の対象で、Kubernetes プロジェクトは削除する計画がないと明言しています。凍結されている（今後開発しない）だけです。廃止されたのはコミュニティ版 NGINX コントローラーであって、それが実装している API ではありません。

ingress-nginx と NGINX Ingress Controller の違いは？

別組織による別プロジェクトです。kubernetes/ingress-nginx は Kubernetes コミュニティが保守していたもので、現在はアーカイブ済み。nginx/kubernetes-ingress は F5 の NGINX Ingress Controller で、開発が継続しています。Kubernetes プロジェクト自身の表現では、両者はデータプレーンに NGINX を使う点は共通だが、それ以外に関係はない、となります。一方から他方への移行は名称変更ではなく、実質的な移行作業です。

ingress2gateway でクラスターを自動移行できますか？

部分的には可能です。1.0 は ingress-nginx のアノテーション 30 個超（従来は 3 個）に対応しており、出発点としては適切です。ただし configuration-snippet は等価物がなく非対応、proxy-body-size は Gateway API に対応項目がなく、プロキシのタイムアウトはベストエフォートのマッピングのみ、URL 正規化にいたっては表現できません。stderr に出力される内容はすべて読んでください。その出力が残りの手作業そのものです。

Gateway API に移行すべきか、Ingress コントローラーを替えるだけにすべきか？

コントローラーの入れ替えのほうが早く、既存オブジェクトも残せますが、着地先は凍結された API であり、結局すべてのアノテーションを新しい方言で書き直すことになります。つまり、いずれもう一度やることになる可能性が高い。Gateway API は書き換え量が大きい一方、開発が進んでいるのはこちらで、Gateway を所有するプラットフォームチームとルートを所有するアプリケーションチームの役割分離も得られます。単純な Ingress が大量にあるならコントローラー入れ替え、複数チームで共有するエッジなら Gateway API が向きます。

Gateway API の実装はどう選べばよいですか？

マーケティング資料ではなく、公開されている適合性レポートで選んでください。Gateway API プロジェクトはリリースごとに、各実装が HTTPRoute・GRPCRoute・TLSRoute でいくつの拡張機能に合格しているかを明示しています。実際に動かす予定のバージョンのレポートを確認し、自分のアノテーションが翻訳された先の具体的な機能に対応しているか、そして自分のプラットフォームでサポートされているかを確かめてください。

Gateway API を入れる前に Kubernetes を上げる必要はありますか？

プロジェクトは固定の最低 Kubernetes バージョンを公表していません。公表されている方針は直近 5 つのマイナーバージョンをサポートすることなので、ブログの数字ではなくこの方針を自分のクラスターと突き合わせてください。現行のパッチリリースである v1.6.1（2026 年 7 月 16 日）の Standard チャネル CRD を、プロジェクトが文書化しているとおり server-side apply でインストールします。Experimental チャネルを入れる場合、その CRD はクライアントサイドの kubectl apply には大きすぎます。また実験的な型は別 API グループで X 接頭辞を持ちます —— 誤って本番をその上に構築しないための設計です。

同じ規律はその下層の暗号にも当てはまる。これらのシステムが依存する接続で何を検証すべきかはポスト量子のSSHとTLSを参照。

参考資料

上記の主張はすべて以下のいずれかに遡れます。一次情報・公式情報のみです：Kubernetes プロジェクトのブログとドキュメント、リポジトリの状態、セキュリティアドバイザリ、および Gateway API 仕様。

1. Kubernetes blog — Ingress NGINX Retirement: What You Need to Know (11 Nov 2025)
2. Kubernetes blog — Ingress NGINX: Statement from the Steering and Security Response Committees (29 Jan 2026)
3. Kubernetes blog — Before You Migrate: Five Surprising Ingress-NGINX Behaviors You Need to Know (27 Feb 2026)
4. GitHub — kubernetes/ingress-nginx (public archive, read-only since 24 Mar 2026)
5. GitHub — ingress-nginx controller-v1.15.1, the final release (19 Mar 2026)
6. Kubernetes Security Response Committee — [Security Advisory] Multiple issues in ingress-nginx (2 Feb 2026)
7. kubernetes/kubernetes#136678 — CVE-2026-24512, configuration injection via the Ingress path field
8. kubernetes/kubernetes#137560 — CVE-2026-3288, configuration injection via the rewrite-target annotation
9. kubernetes/kubernetes#137893 — CVE-2026-4342, comment-based configuration injection (fixed by the final release)
10. Kubernetes blog — Ingress-nginx CVE-2025-1974: What You Need to Know (24 Mar 2025)
11. Kubernetes documentation — Ingress (the API is generally available and frozen)
12. Kubernetes documentation — Ingress Controllers
13. Gateway API — API overview and channel status
14. Kubernetes blog — Gateway API v1.6: TCPRoute and UDPRoute Graduate to Standard (3 Aug 2026)
15. GitHub — Gateway API v1.6.0 release notes
16. GitHub — Gateway API v1.6.1, the current patch release (16 July 2026)
17. Gateway API — v1.6 conformance reports by implementation
18. GitHub — kubernetes-sigs/ingress2gateway
19. Kubernetes blog — Announcing Ingress2Gateway 1.0: Your Path to Gateway API (20 Mar 2026)
20. GitHub — nginx/kubernetes-ingress, the F5 NGINX Ingress Controller (a different project)
21. GitHub — nginx/nginx-gateway-fabric, F5's Gateway API implementation
22. Gateway API — versioning, release channels and graduation criteria